From noreply at sourceforge.net Wed Mar 1 01:07:34 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 28 Feb 2006 16:07:34 -0800 Subject: [Patches] [ python-Patches-1440660 ] Stop help() crashing with incorrect privileges Message-ID: Patches item #1440660, was opened at 2006-03-01 00:07 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=1440660&group_id=5470 Please note that this 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: splitscreen (splitscreen) Assigned to: Nobody/Anonymous (nobody) Summary: Stop help() crashing with incorrect privileges Initial Comment: When in the interactive help() menu, trying to access a module with the 'modules html' comannd the menu will miss an exception. This patch catches the exception, notifies the user and simply 'skips' the module that the user does not have permission to use (i.e read permission of a file within the module). See bug report #1438537 for deatails. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1440660&group_id=5470 From noreply at sourceforge.net Wed Mar 1 05:35:58 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 28 Feb 2006 20:35:58 -0800 Subject: [Patches] [ python-Patches-1104669 ] new-style exceptions Message-ID: Patches item #1104669, was opened at 2005-01-18 10:09 Message generated for change (Comment added) made by bcannon You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1104669&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Core (C code) Group: Python 2.5 >Status: Closed >Resolution: Accepted Priority: 5 Submitted By: Michael Hudson (mwh) Assigned to: Nobody/Anonymous (nobody) Summary: new-style exceptions Initial Comment: This patch allows new-style exceptions and makes Exception a new-style class. The test suite runs, apart from failures in test_tempfile (will dig, but doubt this is my fault) and test__locale (known OS X problem). ---------------------------------------------------------------------- >Comment By: Brett Cannon (bcannon) Date: 2006-02-28 20:35 Message: Logged In: YES user_id=357491 Rev. 42711 has the patch with the requisite tweaks for it to work for PEP 352. Thanks, Michael! ---------------------------------------------------------------------- Comment By: Michael Chermside (mcherm) Date: 2005-12-12 09:00 Message: Logged In: YES user_id=99874 I haven't tried out the patch, I just want to chime in to say how VERY much I would like to have this. I'm ready NOW to completely give up using old-style classes, but because of exceptions I'm not allowed to. This would fix that for me. If Python had a "vote for your favorite bugs" list, I'd be voting for this one. ---------------------------------------------------------------------- Comment By: Nick Coghlan (ncoghlan) Date: 2005-12-10 09:19 Message: Logged In: YES user_id=1038590 New patch worked fine on Ubuntu 5.10 (all tests in 'make test' passed, aside from the skips due to the various extension modules I can't build) ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2005-12-05 14:17 Message: Logged In: YES user_id=6656 Here's a patch updated to SVN HEAD (the PEP 342 implementation meant this wasn't quite trivial). ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2005-02-15 11:37 Message: Logged In: YES user_id=6656 > Is it worth adding a comment on parsing precedence? I've been studiously avoiding thinking about that :) > Making something both an instance and a subclass of > anything besides object might be weird enough that you > don't *want* to document the results yet. Quite. What happens, happens IMHO. I'm prepared to be argued into a different position on this, but I do think the only reason someone would do this is curiousity :) ---------------------------------------------------------------------- Comment By: Jim Jewett (jimjjewett) Date: 2005-02-15 09:51 Message: Logged In: YES user_id=764593 Is it worth adding a comment on parsing precedence? An object can be both an instance and a class, which puts some ambiguity between "raise class" and "raise classinstance". Assuming the class seems sensible; I'm just wondering whether it should be made explicit. (Making something both an instance and a subclass of anything besides object might be weird enough that you don't *want* to document the results yet.) ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2005-02-15 09:39 Message: Logged In: YES user_id=6656 Jim: Yes. It looks like I ran delete-trailing-whitespace on the file at some point. I could redo the diff without them, but it would be tedious... Tim: thanks! ---------------------------------------------------------------------- Comment By: Jim Jewett (jimjjewett) Date: 2005-02-15 09:34 Message: Logged In: YES user_id=764593 Several lines near the end of errors.c had no visible change. Was this a whitespace cleanup, or is this a risk of tab/space mixing? ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2005-02-15 08:17 Message: Logged In: YES user_id=31435 FYI, there's nothing special about PicklingError in the pickletools doctest, it's just aiming at an example of an instance -- that it's also an exception instance is irrelevant to what the test is aiming at. Tell you what: I'll check in a suitable change to pickletools.py, so that the example it uses stops interfering with this patch. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2005-02-15 08:03 Message: Logged In: YES user_id=31435 FYI, there's nothing special about PicklingError in the pickletools doctest, it's just aiming at an example of an instance -- that it's also an exception instance is irrelevant to what the test is aiming at. Tell you what: I'll check in a suitable change to pickletools.py, so that the example it uses stops interfering with this patch. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2005-02-15 07:40 Message: Logged In: YES user_id=6656 I found the final wart (caught by test_tempfile of all things). I think the attached is good to go. Issues remaining: test_pickletools fails, because PickleError is now new- style and thus pickles differently. Docs. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2005-02-09 06:18 Message: Logged In: YES user_id=6656 New patch attached. Did this a while ago, don't actually remember the details of what's new :-/ The problem with the previous patch was that one of my exception- checking macros had the side-effect of clearing any pending exception... ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2005-01-19 05:25 Message: Logged In: YES user_id=6656 You're right! Odd. No time to fix it today, I'm afraid. ---------------------------------------------------------------------- Comment By: Simon Percivall (percivall) Date: 2005-01-18 11:47 Message: Logged In: YES user_id=329382 One thing: Raising an old-style class/instance doesn't give a traceback or populate sys.last_*. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1104669&group_id=5470 From noreply at sourceforge.net Wed Mar 1 13:29:45 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 01 Mar 2006 04:29:45 -0800 Subject: [Patches] [ python-Patches-1440928 ] Inconsistency in os' function naming Message-ID: Patches item #1440928, was opened at 2006-03-01 13: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=1440928&group_id=5470 Please note that this 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: Frederik 'Freso' S. Olesen (freso) Assigned to: Nobody/Anonymous (nobody) Summary: Inconsistency in os' function naming Initial Comment: The os module uses get/set for pretty much everything, except for env, where it uses get/put. It still uses un_set_env though. This patch makes a newfunction setenv if putenv is available, and makes setenv(key, value) call putenv(key, value). I wasn't sure whether to use default values (key=None, value=None) or not, but I ended up doing so anyway. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1440928&group_id=5470 From noreply at sourceforge.net Wed Mar 1 13:40:55 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 01 Mar 2006 04:40:55 -0800 Subject: [Patches] [ python-Patches-1440928 ] Inconsistency in os' function naming Message-ID: Patches item #1440928, was opened at 2006-03-01 13:29 Message generated for change (Comment added) made by freso You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1440928&group_id=5470 Please note that this 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: Frederik 'Freso' S. Olesen (freso) Assigned to: Nobody/Anonymous (nobody) Summary: Inconsistency in os' function naming Initial Comment: The os module uses get/set for pretty much everything, except for env, where it uses get/put. It still uses un_set_env though. This patch makes a newfunction setenv if putenv is available, and makes setenv(key, value) call putenv(key, value). I wasn't sure whether to use default values (key=None, value=None) or not, but I ended up doing so anyway. ---------------------------------------------------------------------- >Comment By: Frederik 'Freso' S. Olesen (freso) Date: 2006-03-01 13:40 Message: Logged In: YES user_id=287697 And I just realised that the __doc__ was far too wide and that both arguments to putenv are required, and thus they should be required be setenv as well. Pray let me know if there is anything I can do to better the patch. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1440928&group_id=5470 From noreply at sourceforge.net Wed Mar 1 13:42:31 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 01 Mar 2006 04:42:31 -0800 Subject: [Patches] [ python-Patches-1440928 ] Inconsistency in os' function naming Message-ID: Patches item #1440928, was opened at 2006-03-01 13:29 Message generated for change (Comment added) made by freso You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1440928&group_id=5470 Please note that this 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: Frederik 'Freso' S. Olesen (freso) Assigned to: Nobody/Anonymous (nobody) Summary: Inconsistency in os' function naming Initial Comment: The os module uses get/set for pretty much everything, except for env, where it uses get/put. It still uses un_set_env though. This patch makes a newfunction setenv if putenv is available, and makes setenv(key, value) call putenv(key, value). I wasn't sure whether to use default values (key=None, value=None) or not, but I ended up doing so anyway. ---------------------------------------------------------------------- >Comment By: Frederik 'Freso' S. Olesen (freso) Date: 2006-03-01 13:42 Message: Logged In: YES user_id=287697 And apparently you can't upload/attach a file *and* delete another one at the same time... ? (Or perhaps it's simple due to the fact they were both of the same name... ?) ---------------------------------------------------------------------- Comment By: Frederik 'Freso' S. Olesen (freso) Date: 2006-03-01 13:40 Message: Logged In: YES user_id=287697 And I just realised that the __doc__ was far too wide and that both arguments to putenv are required, and thus they should be required be setenv as well. Pray let me know if there is anything I can do to better the patch. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1440928&group_id=5470 From noreply at sourceforge.net Wed Mar 1 15:47:09 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 01 Mar 2006 06:47:09 -0800 Subject: [Patches] [ python-Patches-1436130 ] Incremental codecs Message-ID: Patches item #1436130, was opened at 2006-02-21 20:32 Message generated for change (Comment added) made by doerwalter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1436130&group_id=5470 Please note that this 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: Walter D?rwald (doerwalter) Assigned to: M.-A. Lemburg (lemburg) Summary: Incremental codecs Initial Comment: This patch extends the codec machinery to add incremental codecs: stateful codecs that don't use a stream API. It adds the following stuff: a class codecs.CodecInfo (a subclass of tuple), that is used as the return value of codecs.lookup(); codecs.IncrementalEncoder and codecs.IncrementalDecoder (the basic interface classes), codecs.BufferedIncrementalDecoder (a class that can be used to implement decoders that must handle incomplete input); codecs.iterencode() and codecs.iterdecode() (generators that use the incremental codecs for encoding/decoding an input iterable). On the C level PyCodec_IncrementalEncoder() and PyCodec_IncrementalDecoder() are added. ---------------------------------------------------------------------- >Comment By: Walter D?rwald (doerwalter) Date: 2006-03-01 15:47 Message: Logged In: YES user_id=89016 This third version of the patch fixes the bug when the iterator in iterencode() or iterdecode() is empty and updates the docstring in encodings/__init__.py. ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2006-02-28 13:08 Message: Logged In: YES user_id=89016 This second version of the patch enhances codecs.iterencode() and codecs.iterdecode(), so that additional keyword arguments are passed through to the Incremental(De|En)coder constructor. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1436130&group_id=5470 From noreply at sourceforge.net Wed Mar 1 21:54:33 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 01 Mar 2006 12:54:33 -0800 Subject: [Patches] [ python-Patches-1440601 ] Add col information to parse & ast nodes Message-ID: Patches item #1440601, was opened at 2006-02-28 21:36 Message generated for change (Comment added) made by jpe You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1440601&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Parser/Compiler Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: John Ehresman (jpe) Assigned to: Martin v. L??wis (loewis) Summary: Add col information to parse & ast nodes Initial Comment: This adds fields to the parser to capture the column where each token starts and each ast node starts (this is defined as the initial token in the ast node). With this it's reasonably easy to extract the text that ast nodes are based on. The patch is incomplete, will probably change a bit, and lacks tests, but I wanted to get feedback on a few questions. * The byte offset of the column position is what is being recorded. I wonder now if the unicode character position should be recorded. This will slow things down somewhat, but the performance loss may not be signficant. * I changed the signature of PyNode_AddChild and PyParse_AddToken. Is this permitted or do new functions need to be created so that the old signatures are preserved. * Where should I put a function that given an ast tree and the source text will add the text that each node is based on? This will be a python function (I'm pretty sure) so it's not easily put in the _ast module. Note that generated files are omitted from the patch. ---------------------------------------------------------------------- >Comment By: John Ehresman (jpe) Date: 2006-03-01 20:54 Message: Logged In: YES user_id=22785 Updated patch that includes some tests and documentation. The slightly tricky part is the col_offset of an Attribute node -- it was being set to the start of the attribute and after the initial name. Now it points to the start of the initial name. I think we need to wait for some use cases to determine if any more positional information is needed. I suspect some uses may want the positions of each identifier, which is not easily obtainable right now. Includes change to asdl.py to return attributes in the order specified in the .asdl file. ---------------------------------------------------------------------- Comment By: Martin v. L??wis (loewis) Date: 2006-02-28 22:39 Message: Logged In: YES user_id=21627 - the byte offset is actually a UTF-8 byte offset. That should be documented, in the grammar, and perhaps elaborated in libast.tex. - changing the signatures is fine; it is unlikely that anybody calls this API, and if they do, the compiler will tell them. - applications of the AST should go into Demo/parser. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1440601&group_id=5470 From noreply at sourceforge.net Wed Mar 1 21:57:55 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 01 Mar 2006 12:57:55 -0800 Subject: [Patches] [ python-Patches-1440620 ] asdl generation changes Message-ID: Patches item #1440620, was opened at 2006-02-28 22:17 Message generated for change (Comment added) made by jpe You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1440620&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Parser/Compiler Group: Python 2.5 >Status: Closed Resolution: None Priority: 5 Submitted By: John Ehresman (jpe) Assigned to: Jeremy Hylton (jhylton) Summary: asdl generation changes Initial Comment: Adds statics to variables in _ast module and preserves order of class attributes (they were reversed previously). Note that patch 1440601 is sensitive to attribute order and currently depends on the reversed order. ---------------------------------------------------------------------- >Comment By: John Ehresman (jpe) Date: 2006-03-01 20:57 Message: Logged In: YES user_id=22785 Closing because Neal made most of the changes already and the attribute ordering changes are in the col patch ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2006-02-28 22:22 Message: Logged In: YES user_id=33168 Jeremy, I'm assigning the AST type patches to you for review. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1440620&group_id=5470 From noreply at sourceforge.net Thu Mar 2 01:07:04 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 01 Mar 2006 16:07:04 -0800 Subject: [Patches] [ python-Patches-1440601 ] Add col information to parse & ast nodes Message-ID: Patches item #1440601, was opened at 2006-02-28 22:36 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1440601&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Parser/Compiler Group: Python 2.5 >Status: Closed >Resolution: Accepted Priority: 5 Submitted By: John Ehresman (jpe) Assigned to: Martin v. L??wis (loewis) Summary: Add col information to parse & ast nodes Initial Comment: This adds fields to the parser to capture the column where each token starts and each ast node starts (this is defined as the initial token in the ast node). With this it's reasonably easy to extract the text that ast nodes are based on. The patch is incomplete, will probably change a bit, and lacks tests, but I wanted to get feedback on a few questions. * The byte offset of the column position is what is being recorded. I wonder now if the unicode character position should be recorded. This will slow things down somewhat, but the performance loss may not be signficant. * I changed the signature of PyNode_AddChild and PyParse_AddToken. Is this permitted or do new functions need to be created so that the old signatures are preserved. * Where should I put a function that given an ast tree and the source text will add the text that each node is based on? This will be a python function (I'm pretty sure) so it's not easily put in the _ast module. Note that generated files are omitted from the patch. ---------------------------------------------------------------------- >Comment By: Martin v. L??wis (loewis) Date: 2006-03-02 01:07 Message: Logged In: YES user_id=21627 Thanks for the patch. Committed as 42753 ---------------------------------------------------------------------- Comment By: John Ehresman (jpe) Date: 2006-03-01 21:54 Message: Logged In: YES user_id=22785 Updated patch that includes some tests and documentation. The slightly tricky part is the col_offset of an Attribute node -- it was being set to the start of the attribute and after the initial name. Now it points to the start of the initial name. I think we need to wait for some use cases to determine if any more positional information is needed. I suspect some uses may want the positions of each identifier, which is not easily obtainable right now. Includes change to asdl.py to return attributes in the order specified in the .asdl file. ---------------------------------------------------------------------- Comment By: Martin v. L??wis (loewis) Date: 2006-02-28 23:39 Message: Logged In: YES user_id=21627 - the byte offset is actually a UTF-8 byte offset. That should be documented, in the grammar, and perhaps elaborated in libast.tex. - changing the signatures is fine; it is unlikely that anybody calls this API, and if they do, the compiler will tell them. - applications of the AST should go into Demo/parser. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1440601&group_id=5470 From noreply at sourceforge.net Thu Mar 2 01:27:51 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 01 Mar 2006 16:27:51 -0800 Subject: [Patches] [ python-Patches-1118341 ] unknown locale: lt_LT (patch) Message-ID: Patches item #1118341, was opened at 2005-02-08 04:39 Message generated for change (Comment added) made by nerijus You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1118341&group_id=5470 Please note that this 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: Fixed Priority: 5 Submitted By: Nerijus Baliunas (nerijus) Assigned to: Nobody/Anonymous (nobody) Summary: unknown locale: lt_LT (patch) Initial Comment: When running wxPython app I get: ... from wx._core import * File "/usr/lib/python2.3/site-packages/wx-2.5.4-gtk2-ansi/wx/_core.py", line 11035, in ? default = locale.getdefaultlocale()[1] File "/usr/lib/python2.3/locale.py", line 346, in getdefaultlocale return _parse_localename(localename) File "/usr/lib/python2.3/locale.py", line 280, in _parse_localename raise ValueError, 'unknown locale: %s' % localename ValueError: unknown locale: lt_LT Attached patch helps. I also changed Latvian, as ISO8859-13 is an official standard in both Latvia and Lithuania, and Estonian, as they use ISO8859-15 now. Also added Windows language identifiers for all 3 languages. It can be applied to both 2.3 and 2.4. ---------------------------------------------------------------------- >Comment By: Nerijus Baliunas (nerijus) Date: 2006-03-02 02:27 Message: Logged In: YES user_id=3416 OK, it is fixed (workarounded) in wxPython now, but I still get the same problem (ValueError: unknown locale: lt_LT) with PyGtk application. But as it won't be fixed in python 2.4 and it is fixed in python 2.5 (svn), I'm closing this issue. ---------------------------------------------------------------------- Comment By: Nerijus Baliunas (nerijus) Date: 2005-03-18 02:52 Message: Logged In: YES user_id=3416 I found something. locale.getdefaultlocale()[1] fails if I have: $ set|grep lt_LT LANG=lt_LT.ISO8859-13 LC_ALL=lt_LT LC_CTYPE=lt_LT But, if I explicitly set LC_ALL=lt_LT.ISO8859-13, it works. I didn't change my locale settings for years. So something changed in either wxPython or python. ---------------------------------------------------------------------- Comment By: Anthony Baxter (anthonybaxter) Date: 2005-03-16 06:16 Message: Logged In: YES user_id=29957 Please don't mess with the priority settings in the tracker. ---------------------------------------------------------------------- Comment By: Serge Orlov (sorlov) Date: 2005-03-10 20:52 Message: Logged In: YES user_id=1235914 That's strange, it works for me, as you see there is no exception for lt_LT.iso8859-13. I've been using this "fix" in Linux and Solaris for many years. I'm for applying this patch to 2.3 and 2.4 but without changing charset as it's unknown if there are users that depend on the current value. Python 2.3.3 (#1, Jun 30 2004, 21:13:17) [GCC 3.3.3 (SuSE Linux)] on linux2 >>> os.environ['LANG']='lt_LT' >>> locale.getdefaultlocale() Traceback (most recent call last): File "", line 1, in ? File "/usr/lib64/python2.3/locale.py", line 346, in getdefaultlocale return _parse_localename(localename) File "/usr/lib64/python2.3/locale.py", line 280, in _parse_localename raise ValueError, 'unknown locale: %s' % localename ValueError: unknown locale: lt_LT >>> os.environ['LANG']='lt_LT.iso8859-13' >>> locale.getdefaultlocale() ['lt_LT', 'iso8859-13'] ---------------------------------------------------------------------- Comment By: Serge Orlov (sorlov) Date: 2005-03-10 15:33 Message: Logged In: YES user_id=1235914 That's strange, it works for me, as you see there is no exception for lt_LT.iso8859-13. I've been using this "fix" in Linux and Solaris for many years. I'm for applying this patch to 2.3 and 2.4 but without changing charset as it's unknown if there are users that depend on the current value. Python 2.3.3 (#1, Jun 30 2004, 21:13:17) [GCC 3.3.3 (SuSE Linux)] on linux2 >>> os.environ['LANG']='lt_LT' >>> locale.getdefaultlocale() Traceback (most recent call last): File "", line 1, in ? File "/usr/lib64/python2.3/locale.py", line 346, in getdefaultlocale return _parse_localename(localename) File "/usr/lib64/python2.3/locale.py", line 280, in _parse_localename raise ValueError, 'unknown locale: %s' % localename ValueError: unknown locale: lt_LT >>> os.environ['LANG']='lt_LT.iso8859-13' >>> locale.getdefaultlocale() ['lt_LT', 'iso8859-13'] ---------------------------------------------------------------------- Comment By: Nerijus Baliunas (nerijus) Date: 2005-03-10 01:47 Message: Logged In: YES user_id=3416 $ set|grep LANG LANG=lt_LT.ISO8859-13 My LANG is already as you suggest. OK, I'll ask wxPython developer, as with earlier wxPython versions I didn't have such problem. But my patch should be safe anyway. ---------------------------------------------------------------------- Comment By: Serge Orlov (sorlov) Date: 2005-03-09 20:31 Message: Logged In: YES user_id=1235914 I don't think the values in locale_alias should be changed in minor releases (They have been changed in 2.5 as in your patch) Please apply changes that only add lt_lt and lv_lv aliases. I suspect the whole alias thing has wrong values for many countries (not only in Python). At least it has wrong values for Russian in Solaris and Linux for more than ten years. I know that many Russian users have given up relying on it. They just set charset explicitly: LANG=ru_RU.koi8-r or LANG=ru_RU.utf-8. Nerijus, LANG=lt_LT.ISO8859-13 should work for you. Besides OpenDict should catch the exception, print a warning and fall back to C locale if the locale set by the user is not available. The windows language identifiers are OK to add. ---------------------------------------------------------------------- Comment By: Nerijus Baliunas (nerijus) Date: 2005-02-28 00:14 Message: Logged In: YES user_id=3416 I'm increasing priority, as I have real world application (OpenDict using wxPython) not starting w/o this patch: $ opendict ... ValueError: unknown locale: lt_LT It's really a very simple patch, please apply it to both 2.3 and 2.4. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1118341&group_id=5470 From noreply at sourceforge.net Thu Mar 2 05:01:55 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 01 Mar 2006 20:01:55 -0800 Subject: [Patches] [ python-Patches-1441452 ] Updated Demo\parser\unpack.py Message-ID: Patches item #1441452, was opened at 2006-03-02 04: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=1441452&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Parser/Compiler Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: John Ehresman (jpe) Assigned to: Nobody/Anonymous (nobody) Summary: Updated Demo\parser\unpack.py Initial Comment: Updated demo for ast inspection. It now generates code for all files under Lib, but I have not checked to see if the code is correct. The next step is to reorder the methods, implement a check to see if generated code is correct, and fix it so it is correct. Use the --testdir argument to process all files in the given directory recursively. I intend to work more on this, but I'm having problems with my laptop so I may not be working tomorrow. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1441452&group_id=5470 From noreply at sourceforge.net Thu Mar 2 05:02:51 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 01 Mar 2006 20:02:51 -0800 Subject: [Patches] [ python-Patches-1441452 ] Updated Demo\parser\unpack.py Message-ID: Patches item #1441452, was opened at 2006-03-02 04:01 Message generated for change (Settings changed) made by jpe You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1441452&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Parser/Compiler Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: John Ehresman (jpe) >Assigned to: Martin v. L??wis (loewis) Summary: Updated Demo\parser\unpack.py Initial Comment: Updated demo for ast inspection. It now generates code for all files under Lib, but I have not checked to see if the code is correct. The next step is to reorder the methods, implement a check to see if generated code is correct, and fix it so it is correct. Use the --testdir argument to process all files in the given directory recursively. I intend to work more on this, but I'm having problems with my laptop so I may not be working tomorrow. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1441452&group_id=5470 From noreply at sourceforge.net Thu Mar 2 12:54:31 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 02 Mar 2006 03:54:31 -0800 Subject: [Patches] [ python-Patches-1441660 ] db4.4 support for bsddb Message-ID: Patches item #1441660, was opened at 2006-03-02 12:54 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1441660&group_id=5470 Please note that this 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: J?rome Laheurte (fraca7) Assigned to: Nobody/Anonymous (nobody) Summary: db4.4 support for bsddb Initial Comment: Here is a patch to support db4.4 in Python 2.4.2. The regression tests passed. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1441660&group_id=5470 From noreply at sourceforge.net Fri Mar 3 00:03:38 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 02 Mar 2006 15:03:38 -0800 Subject: [Patches] [ python-Patches-1436130 ] Incremental codecs Message-ID: Patches item #1436130, was opened at 2006-02-21 20:32 Message generated for change (Comment added) made by lemburg You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1436130&group_id=5470 Please note that this 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: Walter D?rwald (doerwalter) Assigned to: M.-A. Lemburg (lemburg) Summary: Incremental codecs Initial Comment: This patch extends the codec machinery to add incremental codecs: stateful codecs that don't use a stream API. It adds the following stuff: a class codecs.CodecInfo (a subclass of tuple), that is used as the return value of codecs.lookup(); codecs.IncrementalEncoder and codecs.IncrementalDecoder (the basic interface classes), codecs.BufferedIncrementalDecoder (a class that can be used to implement decoders that must handle incomplete input); codecs.iterencode() and codecs.iterdecode() (generators that use the incremental codecs for encoding/decoding an input iterable). On the C level PyCodec_IncrementalEncoder() and PyCodec_IncrementalDecoder() are added. ---------------------------------------------------------------------- >Comment By: M.-A. Lemburg (lemburg) Date: 2006-03-03 00:03 Message: Logged In: YES user_id=38388 Very nice ! This is a much better approach than the feed style path you wanted to take previously. Minor nits: Please separate out the non-related changes to the IDNA codec into a new patch and assign that to Martin for review. Is it possible to make IncrementalEncoder/Decoder instances iterable per-se (without the need to go through the helper functions iterencode/iterdecode) ? Thanks. ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2006-03-01 15:47 Message: Logged In: YES user_id=89016 This third version of the patch fixes the bug when the iterator in iterencode() or iterdecode() is empty and updates the docstring in encodings/__init__.py. ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2006-02-28 13:08 Message: Logged In: YES user_id=89016 This second version of the patch enhances codecs.iterencode() and codecs.iterdecode(), so that additional keyword arguments are passed through to the Incremental(De|En)coder constructor. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1436130&group_id=5470 From noreply at sourceforge.net Fri Mar 3 00:21:47 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 02 Mar 2006 15:21:47 -0800 Subject: [Patches] [ python-Patches-1440928 ] Inconsistency in os' function naming Message-ID: Patches item #1440928, was opened at 2006-03-01 13:29 Message generated for change (Comment added) made by effbot You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1440928&group_id=5470 Please note that this 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: Frederik 'Freso' S. Olesen (freso) Assigned to: Nobody/Anonymous (nobody) Summary: Inconsistency in os' function naming Initial Comment: The os module uses get/set for pretty much everything, except for env, where it uses get/put. It still uses un_set_env though. This patch makes a newfunction setenv if putenv is available, and makes setenv(key, value) call putenv(key, value). I wasn't sure whether to use default values (key=None, value=None) or not, but I ended up doing so anyway. ---------------------------------------------------------------------- >Comment By: Fredrik Lundh (effbot) Date: 2006-03-03 00:21 Message: Logged In: YES user_id=38376 the os module generally uses the same name as the underlying POSIX API. in this case, os.putenv maps to POSIX putenv(3) and os.getenv maps to POSIX getenv(3). there is a setenv() function available on some platforms, which is more like: def setenv(key, value, overwrite): if not getenv(key) or overwrite: putenv(key, value) (why are you using these functions anyway? use the environ dictionary, already!) ---------------------------------------------------------------------- Comment By: Frederik 'Freso' S. Olesen (freso) Date: 2006-03-01 13:42 Message: Logged In: YES user_id=287697 And apparently you can't upload/attach a file *and* delete another one at the same time... ? (Or perhaps it's simple due to the fact they were both of the same name... ?) ---------------------------------------------------------------------- Comment By: Frederik 'Freso' S. Olesen (freso) Date: 2006-03-01 13:40 Message: Logged In: YES user_id=287697 And I just realised that the __doc__ was far too wide and that both arguments to putenv are required, and thus they should be required be setenv as well. Pray let me know if there is anything I can do to better the patch. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1440928&group_id=5470 From noreply at sourceforge.net Fri Mar 3 00:25:25 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 02 Mar 2006 15:25:25 -0800 Subject: [Patches] [ python-Patches-1440928 ] Inconsistency in os' function naming Message-ID: Patches item #1440928, was opened at 2006-03-01 13:29 Message generated for change (Comment added) made by effbot You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1440928&group_id=5470 Please note that this 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: Frederik 'Freso' S. Olesen (freso) Assigned to: Nobody/Anonymous (nobody) Summary: Inconsistency in os' function naming Initial Comment: The os module uses get/set for pretty much everything, except for env, where it uses get/put. It still uses un_set_env though. This patch makes a newfunction setenv if putenv is available, and makes setenv(key, value) call putenv(key, value). I wasn't sure whether to use default values (key=None, value=None) or not, but I ended up doing so anyway. ---------------------------------------------------------------------- >Comment By: Fredrik Lundh (effbot) Date: 2006-03-03 00:25 Message: Logged In: YES user_id=38376 (and yes, unsetenv is named that way because the underlying Unix function is called unsetenv(). like setenv(), this isn't a POSIX function, and is not available on all platforms). ---------------------------------------------------------------------- Comment By: Fredrik Lundh (effbot) Date: 2006-03-03 00:21 Message: Logged In: YES user_id=38376 the os module generally uses the same name as the underlying POSIX API. in this case, os.putenv maps to POSIX putenv(3) and os.getenv maps to POSIX getenv(3). there is a setenv() function available on some platforms, which is more like: def setenv(key, value, overwrite): if not getenv(key) or overwrite: putenv(key, value) (why are you using these functions anyway? use the environ dictionary, already!) ---------------------------------------------------------------------- Comment By: Frederik 'Freso' S. Olesen (freso) Date: 2006-03-01 13:42 Message: Logged In: YES user_id=287697 And apparently you can't upload/attach a file *and* delete another one at the same time... ? (Or perhaps it's simple due to the fact they were both of the same name... ?) ---------------------------------------------------------------------- Comment By: Frederik 'Freso' S. Olesen (freso) Date: 2006-03-01 13:40 Message: Logged In: YES user_id=287697 And I just realised that the __doc__ was far too wide and that both arguments to putenv are required, and thus they should be required be setenv as well. Pray let me know if there is anything I can do to better the patch. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1440928&group_id=5470 From noreply at sourceforge.net Fri Mar 3 01:12:59 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 02 Mar 2006 16:12:59 -0800 Subject: [Patches] [ python-Patches-1441660 ] db4.4 support for bsddb Message-ID: Patches item #1441660, was opened at 2006-03-02 03:54 Message generated for change (Comment added) made by nnorwitz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1441660&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Library (Lib) Group: Python 2.4 >Status: Closed >Resolution: Out of Date Priority: 5 Submitted By: J?rome Laheurte (fraca7) >Assigned to: Neal Norwitz (nnorwitz) Summary: db4.4 support for bsddb Initial Comment: Here is a patch to support db4.4 in Python 2.4.2. The regression tests passed. ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2006-03-02 16:12 Message: Logged In: YES user_id=33168 db4.4 support was recently added. it will be available in 2.4.3 which should be released in about a month. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1441660&group_id=5470 From noreply at sourceforge.net Fri Mar 3 02:16:48 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 02 Mar 2006 17:16:48 -0800 Subject: [Patches] [ python-Patches-1436368 ] PEP 357 --- adding nb_index Message-ID: Patches item #1436368, was opened at 2006-02-21 22:35 Message generated for change (Comment added) made by gvanrossum You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1436368&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Core (C code) Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: Travis Oliphant (teoliphant) Assigned to: Guido van Rossum (gvanrossum) Summary: PEP 357 --- adding nb_index Initial Comment: See PEP 357 for details. ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2006-03-02 20:16 Message: Logged In: YES user_id=6380 I promise I'll review this further tomorrow! Feedback so far: - compilation error with svn HEAD on abstract.c:650 - all the uses of the nb_index slot must check for some Py_TPFLAGS_... bit before using that slot (see object.h) - the comment in ceval.c about the clipping of values < -PY_SSIZE_T_MAX is incorrect; they are boosted to -PY_SSIZE_T_MAX, not to zero ---------------------------------------------------------------------- Comment By: Travis Oliphant (teoliphant) Date: 2006-02-22 12:52 Message: Logged In: YES user_id=5296 I followed Neal's comments and updated a new patch. The new patch contains the tests and the documentation updates as well. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2006-02-22 03:03 Message: Logged In: YES user_id=33168 I see one problem in Modules/operator.c. This code: + if (i==-1 && PyErr_Occurred()) return NULL; + else return PyInt_FromLong((long)i); Should be: + if (i == -1 && PyErr_Occurred()) + return NULL; + return PyInt_FromSsizeT(i); There was a discussion on python-checkins recently about this. The short answer is that if Py_ssize_t's are cast to a long, that will lose precision on Win64 (size_ts are 64-bits, but longs are still 32). Since i is Py_ssize_t, the cast would lose the high order values (above 2G). In Objects/stringobject.c: - i += PyString_GET_SIZE(self); - return string_item(self,i); + i += PyList_GET_SIZE(self); + return string_item(self, i); I don't see how that (PyList) can be correct, self is a string object. I would change this code: + lenfunc func; + PyNumberMethods *nb; + if ((nb=item->ob_type->tp_as_number) && \ + (func=nb->nb_index)) { + Py_ssize_t i = func(item); to: + PyNumberMethods *nb = item->ob_type->tp_as_number; + if (nb != NULL && nb->nb_index != NULL) { + Py_ssize_t i = nb->nb_index(item); Let the compiler do the work. We can optimize later if this is a problem. I think the code is clearer this way and is more similar to the rest of the code. I don't care as much about the use of func here as the change to nb = ... If you want to keep the local variable, I would prefer a better name like nb_index instead of func. There's no need for a \ after &&. Most of these comments apply to Objects/listobject.c, Objects/tupleobject.c, Objects/unicodeobject.c, PyNumber_Index. In Objects/classobject.c, you don't check that indexstr is non-NULL after assignment. In instance_index(), remove the cast (int) of the return result outcome. In slot_nb_index() remove . from end of exception string. Note: you don't need the Py_DECREF() and return -1 in the last if as it would be the same if it fell through. Use whichever version you think is clearer. Either way is fine with me. In Include/abstract.h, do all the comments still say a C integer is returned even though a Py_ssize_t is returned? If not, can you update your comment too. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2006-02-22 02:33 Message: Logged In: YES user_id=33168 Travis, I briefly looked over the patches and have a few comments. It's easier if there's one big patch that contains all the code, tests, and doc. I noticed a second patch that contains the tests, but I didn't see any doc updates. I noticed some formatting which is not consistent with the style of the surrounding code (I think). Stuff like n=var->field (no spaces) and if (XXX) dosomething(); else return 5; Most places in the python code check for == NULL rather than the implicit check for 0. Most places in code don't do assignment in if (cond), though this last one is more variable. I'll try to look this over in more detail soon. But it probably won't be until PyCon. If you're there, maybe we can discuss in person. Also, if you have further PEP updates, feel free to send them to me and I can check them in. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1436368&group_id=5470 From noreply at sourceforge.net Fri Mar 3 02:18:12 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 02 Mar 2006 17:18:12 -0800 Subject: [Patches] [ python-Patches-1440928 ] Inconsistency in os' function naming Message-ID: Patches item #1440928, was opened at 2006-03-01 07:29 Message generated for change (Comment added) made by gvanrossum You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1440928&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Library (Lib) Group: None >Status: Closed >Resolution: Rejected Priority: 5 Submitted By: Frederik 'Freso' S. Olesen (freso) Assigned to: Nobody/Anonymous (nobody) Summary: Inconsistency in os' function naming Initial Comment: The os module uses get/set for pretty much everything, except for env, where it uses get/put. It still uses un_set_env though. This patch makes a newfunction setenv if putenv is available, and makes setenv(key, value) call putenv(key, value). I wasn't sure whether to use default values (key=None, value=None) or not, but I ended up doing so anyway. ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2006-03-02 20:18 Message: Logged In: YES user_id=6380 -1. "We already got one." ---------------------------------------------------------------------- Comment By: Fredrik Lundh (effbot) Date: 2006-03-02 18:25 Message: Logged In: YES user_id=38376 (and yes, unsetenv is named that way because the underlying Unix function is called unsetenv(). like setenv(), this isn't a POSIX function, and is not available on all platforms). ---------------------------------------------------------------------- Comment By: Fredrik Lundh (effbot) Date: 2006-03-02 18:21 Message: Logged In: YES user_id=38376 the os module generally uses the same name as the underlying POSIX API. in this case, os.putenv maps to POSIX putenv(3) and os.getenv maps to POSIX getenv(3). there is a setenv() function available on some platforms, which is more like: def setenv(key, value, overwrite): if not getenv(key) or overwrite: putenv(key, value) (why are you using these functions anyway? use the environ dictionary, already!) ---------------------------------------------------------------------- Comment By: Frederik 'Freso' S. Olesen (freso) Date: 2006-03-01 07:42 Message: Logged In: YES user_id=287697 And apparently you can't upload/attach a file *and* delete another one at the same time... ? (Or perhaps it's simple due to the fact they were both of the same name... ?) ---------------------------------------------------------------------- Comment By: Frederik 'Freso' S. Olesen (freso) Date: 2006-03-01 07:40 Message: Logged In: YES user_id=287697 And I just realised that the __doc__ was far too wide and that both arguments to putenv are required, and thus they should be required be setenv as well. Pray let me know if there is anything I can do to better the patch. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1440928&group_id=5470 From noreply at sourceforge.net Fri Mar 3 05:32:07 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 02 Mar 2006 20:32:07 -0800 Subject: [Patches] [ python-Patches-1436368 ] PEP 357 --- adding nb_index Message-ID: Patches item #1436368, was opened at 2006-02-21 22:35 Message generated for change (Comment added) made by gvanrossum You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1436368&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Core (C code) Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: Travis Oliphant (teoliphant) Assigned to: Guido van Rossum (gvanrossum) Summary: PEP 357 --- adding nb_index Initial Comment: See PEP 357 for details. ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2006-03-02 23:32 Message: Logged In: YES user_id=6380 Travis -- I'm working on a new patch. Please don't work on one at the same time for the new few hours! (Until midnight PST.) ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2006-03-02 20:16 Message: Logged In: YES user_id=6380 I promise I'll review this further tomorrow! Feedback so far: - compilation error with svn HEAD on abstract.c:650 - all the uses of the nb_index slot must check for some Py_TPFLAGS_... bit before using that slot (see object.h) - the comment in ceval.c about the clipping of values < -PY_SSIZE_T_MAX is incorrect; they are boosted to -PY_SSIZE_T_MAX, not to zero ---------------------------------------------------------------------- Comment By: Travis Oliphant (teoliphant) Date: 2006-02-22 12:52 Message: Logged In: YES user_id=5296 I followed Neal's comments and updated a new patch. The new patch contains the tests and the documentation updates as well. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2006-02-22 03:03 Message: Logged In: YES user_id=33168 I see one problem in Modules/operator.c. This code: + if (i==-1 && PyErr_Occurred()) return NULL; + else return PyInt_FromLong((long)i); Should be: + if (i == -1 && PyErr_Occurred()) + return NULL; + return PyInt_FromSsizeT(i); There was a discussion on python-checkins recently about this. The short answer is that if Py_ssize_t's are cast to a long, that will lose precision on Win64 (size_ts are 64-bits, but longs are still 32). Since i is Py_ssize_t, the cast would lose the high order values (above 2G). In Objects/stringobject.c: - i += PyString_GET_SIZE(self); - return string_item(self,i); + i += PyList_GET_SIZE(self); + return string_item(self, i); I don't see how that (PyList) can be correct, self is a string object. I would change this code: + lenfunc func; + PyNumberMethods *nb; + if ((nb=item->ob_type->tp_as_number) && \ + (func=nb->nb_index)) { + Py_ssize_t i = func(item); to: + PyNumberMethods *nb = item->ob_type->tp_as_number; + if (nb != NULL && nb->nb_index != NULL) { + Py_ssize_t i = nb->nb_index(item); Let the compiler do the work. We can optimize later if this is a problem. I think the code is clearer this way and is more similar to the rest of the code. I don't care as much about the use of func here as the change to nb = ... If you want to keep the local variable, I would prefer a better name like nb_index instead of func. There's no need for a \ after &&. Most of these comments apply to Objects/listobject.c, Objects/tupleobject.c, Objects/unicodeobject.c, PyNumber_Index. In Objects/classobject.c, you don't check that indexstr is non-NULL after assignment. In instance_index(), remove the cast (int) of the return result outcome. In slot_nb_index() remove . from end of exception string. Note: you don't need the Py_DECREF() and return -1 in the last if as it would be the same if it fell through. Use whichever version you think is clearer. Either way is fine with me. In Include/abstract.h, do all the comments still say a C integer is returned even though a Py_ssize_t is returned? If not, can you update your comment too. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2006-02-22 02:33 Message: Logged In: YES user_id=33168 Travis, I briefly looked over the patches and have a few comments. It's easier if there's one big patch that contains all the code, tests, and doc. I noticed a second patch that contains the tests, but I didn't see any doc updates. I noticed some formatting which is not consistent with the style of the surrounding code (I think). Stuff like n=var->field (no spaces) and if (XXX) dosomething(); else return 5; Most places in the python code check for == NULL rather than the implicit check for 0. Most places in code don't do assignment in if (cond), though this last one is more variable. I'll try to look this over in more detail soon. But it probably won't be until PyCon. If you're there, maybe we can discuss in person. Also, if you have further PEP updates, feel free to send them to me and I can check them in. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1436368&group_id=5470 From noreply at sourceforge.net Fri Mar 3 06:12:03 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 02 Mar 2006 21:12:03 -0800 Subject: [Patches] [ python-Patches-1436368 ] PEP 357 --- adding nb_index Message-ID: Patches item #1436368, was opened at 2006-02-21 22:35 Message generated for change (Comment added) made by gvanrossum You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1436368&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Core (C code) Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: Travis Oliphant (teoliphant) Assigned to: Guido van Rossum (gvanrossum) Summary: PEP 357 --- adding nb_index Initial Comment: See PEP 357 for details. ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2006-03-03 00:12 Message: Logged In: YES user_id=6380 OK, Travis, here's a new patch. It corrects the issues I mentioned before, and does some whitespace cleanup (like what Neal mentioned). The biggest change is definitely the check for Py_TPFLAGS_HAVE_INDEX whenever the nb_index slot is referenced. You don't have to do anything; but if you do have more changes, please throw away your old changes, sync to the head, and apply my patch, before doing any more work. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2006-03-02 23:32 Message: Logged In: YES user_id=6380 Travis -- I'm working on a new patch. Please don't work on one at the same time for the new few hours! (Until midnight PST.) ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2006-03-02 20:16 Message: Logged In: YES user_id=6380 I promise I'll review this further tomorrow! Feedback so far: - compilation error with svn HEAD on abstract.c:650 - all the uses of the nb_index slot must check for some Py_TPFLAGS_... bit before using that slot (see object.h) - the comment in ceval.c about the clipping of values < -PY_SSIZE_T_MAX is incorrect; they are boosted to -PY_SSIZE_T_MAX, not to zero ---------------------------------------------------------------------- Comment By: Travis Oliphant (teoliphant) Date: 2006-02-22 12:52 Message: Logged In: YES user_id=5296 I followed Neal's comments and updated a new patch. The new patch contains the tests and the documentation updates as well. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2006-02-22 03:03 Message: Logged In: YES user_id=33168 I see one problem in Modules/operator.c. This code: + if (i==-1 && PyErr_Occurred()) return NULL; + else return PyInt_FromLong((long)i); Should be: + if (i == -1 && PyErr_Occurred()) + return NULL; + return PyInt_FromSsizeT(i); There was a discussion on python-checkins recently about this. The short answer is that if Py_ssize_t's are cast to a long, that will lose precision on Win64 (size_ts are 64-bits, but longs are still 32). Since i is Py_ssize_t, the cast would lose the high order values (above 2G). In Objects/stringobject.c: - i += PyString_GET_SIZE(self); - return string_item(self,i); + i += PyList_GET_SIZE(self); + return string_item(self, i); I don't see how that (PyList) can be correct, self is a string object. I would change this code: + lenfunc func; + PyNumberMethods *nb; + if ((nb=item->ob_type->tp_as_number) && \ + (func=nb->nb_index)) { + Py_ssize_t i = func(item); to: + PyNumberMethods *nb = item->ob_type->tp_as_number; + if (nb != NULL && nb->nb_index != NULL) { + Py_ssize_t i = nb->nb_index(item); Let the compiler do the work. We can optimize later if this is a problem. I think the code is clearer this way and is more similar to the rest of the code. I don't care as much about the use of func here as the change to nb = ... If you want to keep the local variable, I would prefer a better name like nb_index instead of func. There's no need for a \ after &&. Most of these comments apply to Objects/listobject.c, Objects/tupleobject.c, Objects/unicodeobject.c, PyNumber_Index. In Objects/classobject.c, you don't check that indexstr is non-NULL after assignment. In instance_index(), remove the cast (int) of the return result outcome. In slot_nb_index() remove . from end of exception string. Note: you don't need the Py_DECREF() and return -1 in the last if as it would be the same if it fell through. Use whichever version you think is clearer. Either way is fine with me. In Include/abstract.h, do all the comments still say a C integer is returned even though a Py_ssize_t is returned? If not, can you update your comment too. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2006-02-22 02:33 Message: Logged In: YES user_id=33168 Travis, I briefly looked over the patches and have a few comments. It's easier if there's one big patch that contains all the code, tests, and doc. I noticed a second patch that contains the tests, but I didn't see any doc updates. I noticed some formatting which is not consistent with the style of the surrounding code (I think). Stuff like n=var->field (no spaces) and if (XXX) dosomething(); else return 5; Most places in the python code check for == NULL rather than the implicit check for 0. Most places in code don't do assignment in if (cond), though this last one is more variable. I'll try to look this over in more detail soon. But it probably won't be until PyCon. If you're there, maybe we can discuss in person. Also, if you have further PEP updates, feel free to send them to me and I can check them in. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1436368&group_id=5470 From noreply at sourceforge.net Fri Mar 3 13:41:03 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 03 Mar 2006 04:41:03 -0800 Subject: [Patches] [ python-Patches-1442442 ] Faster list comprehensions Message-ID: Patches item #1442442, was opened at 2006-03-03 07:41 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1442442&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Parser/Compiler Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: Collin Winter (collinwinter) Assigned to: Nobody/Anonymous (nobody) Summary: Faster list comprehensions Initial Comment: The attached patch results in a 16% speed increase for list comprehensions. By changing how the LIST_APPEND opcode works (which was previously totally unused), it's possible to dramatically simplify the emitted bytecode for listcomps. More details are available on my blog: http://oakwinter.com/code/?p=22. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1442442&group_id=5470 From noreply at sourceforge.net Fri Mar 3 13:49:08 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 03 Mar 2006 04:49:08 -0800 Subject: [Patches] [ python-Patches-1442442 ] Faster list comprehensions Message-ID: Patches item #1442442, was opened at 2006-03-03 07:41 Message generated for change (Comment added) made by collinwinter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1442442&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Parser/Compiler Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: Collin Winter (collinwinter) Assigned to: Nobody/Anonymous (nobody) Summary: Faster list comprehensions Initial Comment: The attached patch results in a 16% speed increase for list comprehensions. By changing how the LIST_APPEND opcode works (which was previously totally unused), it's possible to dramatically simplify the emitted bytecode for listcomps. More details are available on my blog: http://oakwinter.com/code/?p=22. ---------------------------------------------------------------------- >Comment By: Collin Winter (collinwinter) Date: 2006-03-03 07:49 Message: Logged In: YES user_id=1344176 I forgot to mention: the patch also includes updates to things like Lib/test/test_dis.py and Lib/opcode.py to make them work with the updated LIST_APPEND opcode and code generation. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1442442&group_id=5470 From noreply at sourceforge.net Fri Mar 3 17:21:15 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 03 Mar 2006 08:21:15 -0800 Subject: [Patches] [ python-Patches-1442442 ] Faster list comprehensions Message-ID: Patches item #1442442, was opened at 2006-03-03 07:41 Message generated for change (Comment added) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1442442&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Parser/Compiler Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: Collin Winter (collinwinter) >Assigned to: Neal Norwitz (nnorwitz) Summary: Faster list comprehensions Initial Comment: The attached patch results in a 16% speed increase for list comprehensions. By changing how the LIST_APPEND opcode works (which was previously totally unused), it's possible to dramatically simplify the emitted bytecode for listcomps. More details are available on my blog: http://oakwinter.com/code/?p=22. ---------------------------------------------------------------------- >Comment By: Raymond Hettinger (rhettinger) Date: 2006-03-03 11:21 Message: Logged In: YES user_id=80475 Neal, did the LIST_APPEND generation get left out of the AST. In Py2.4, is was working fine: Python 2.4.2 (#67, Sep 28 2005, 12:41:11) [MSC v.1310 32 bit (Intel)] on win32 >>> from dis import dis >>> dis(compile('[x for x in range(10) if x % 2]', '', 'single')) 1 0 BUILD_LIST 0 3 DUP_TOP 4 STORE_NAME 0 (_[1]) 7 LOAD_NAME 1 (range) 10 LOAD_CONST 0 (10) 13 CALL_FUNCTION 1 16 GET_ITER >> 17 FOR_ITER 28 (to 48) 20 STORE_NAME 2 (x) 23 LOAD_NAME 2 (x) 26 LOAD_CONST 1 (2) 29 BINARY_MODULO 30 JUMP_IF_FALSE 11 (to 44) 33 POP_TOP 34 LOAD_NAME 0 (_[1]) 37 LOAD_NAME 2 (x) 40 LIST_APPEND 41 JUMP_ABSOLUTE 17 >> 44 POP_TOP 45 JUMP_ABSOLUTE 17 >> 48 DELETE_NAME 0 (_[1]) 51 PRINT_EXPR 52 LOAD_CONST 2 (None) 55 RETURN_VALUE ---------------------------------------------------------------------- Comment By: Collin Winter (collinwinter) Date: 2006-03-03 07:49 Message: Logged In: YES user_id=1344176 I forgot to mention: the patch also includes updates to things like Lib/test/test_dis.py and Lib/opcode.py to make them work with the updated LIST_APPEND opcode and code generation. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1442442&group_id=5470 From noreply at sourceforge.net Fri Mar 3 18:08:27 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 03 Mar 2006 09:08:27 -0800 Subject: [Patches] [ python-Patches-1436368 ] PEP 357 --- adding nb_index Message-ID: Patches item #1436368, was opened at 2006-02-21 20:35 Message generated for change (Comment added) made by teoliphant You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1436368&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Core (C code) Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: Travis Oliphant (teoliphant) Assigned to: Guido van Rossum (gvanrossum) Summary: PEP 357 --- adding nb_index Initial Comment: See PEP 357 for details. ---------------------------------------------------------------------- >Comment By: Travis Oliphant (teoliphant) Date: 2006-03-03 10:08 Message: Logged In: YES user_id=5296 I think there is still a need for a HASINDEX check in the ISINDEX definition in ceval.c ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2006-03-02 22:12 Message: Logged In: YES user_id=6380 OK, Travis, here's a new patch. It corrects the issues I mentioned before, and does some whitespace cleanup (like what Neal mentioned). The biggest change is definitely the check for Py_TPFLAGS_HAVE_INDEX whenever the nb_index slot is referenced. You don't have to do anything; but if you do have more changes, please throw away your old changes, sync to the head, and apply my patch, before doing any more work. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2006-03-02 21:32 Message: Logged In: YES user_id=6380 Travis -- I'm working on a new patch. Please don't work on one at the same time for the new few hours! (Until midnight PST.) ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2006-03-02 18:16 Message: Logged In: YES user_id=6380 I promise I'll review this further tomorrow! Feedback so far: - compilation error with svn HEAD on abstract.c:650 - all the uses of the nb_index slot must check for some Py_TPFLAGS_... bit before using that slot (see object.h) - the comment in ceval.c about the clipping of values < -PY_SSIZE_T_MAX is incorrect; they are boosted to -PY_SSIZE_T_MAX, not to zero ---------------------------------------------------------------------- Comment By: Travis Oliphant (teoliphant) Date: 2006-02-22 10:52 Message: Logged In: YES user_id=5296 I followed Neal's comments and updated a new patch. The new patch contains the tests and the documentation updates as well. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2006-02-22 01:03 Message: Logged In: YES user_id=33168 I see one problem in Modules/operator.c. This code: + if (i==-1 && PyErr_Occurred()) return NULL; + else return PyInt_FromLong((long)i); Should be: + if (i == -1 && PyErr_Occurred()) + return NULL; + return PyInt_FromSsizeT(i); There was a discussion on python-checkins recently about this. The short answer is that if Py_ssize_t's are cast to a long, that will lose precision on Win64 (size_ts are 64-bits, but longs are still 32). Since i is Py_ssize_t, the cast would lose the high order values (above 2G). In Objects/stringobject.c: - i += PyString_GET_SIZE(self); - return string_item(self,i); + i += PyList_GET_SIZE(self); + return string_item(self, i); I don't see how that (PyList) can be correct, self is a string object. I would change this code: + lenfunc func; + PyNumberMethods *nb; + if ((nb=item->ob_type->tp_as_number) && \ + (func=nb->nb_index)) { + Py_ssize_t i = func(item); to: + PyNumberMethods *nb = item->ob_type->tp_as_number; + if (nb != NULL && nb->nb_index != NULL) { + Py_ssize_t i = nb->nb_index(item); Let the compiler do the work. We can optimize later if this is a problem. I think the code is clearer this way and is more similar to the rest of the code. I don't care as much about the use of func here as the change to nb = ... If you want to keep the local variable, I would prefer a better name like nb_index instead of func. There's no need for a \ after &&. Most of these comments apply to Objects/listobject.c, Objects/tupleobject.c, Objects/unicodeobject.c, PyNumber_Index. In Objects/classobject.c, you don't check that indexstr is non-NULL after assignment. In instance_index(), remove the cast (int) of the return result outcome. In slot_nb_index() remove . from end of exception string. Note: you don't need the Py_DECREF() and return -1 in the last if as it would be the same if it fell through. Use whichever version you think is clearer. Either way is fine with me. In Include/abstract.h, do all the comments still say a C integer is returned even though a Py_ssize_t is returned? If not, can you update your comment too. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2006-02-22 00:33 Message: Logged In: YES user_id=33168 Travis, I briefly looked over the patches and have a few comments. It's easier if there's one big patch that contains all the code, tests, and doc. I noticed a second patch that contains the tests, but I didn't see any doc updates. I noticed some formatting which is not consistent with the style of the surrounding code (I think). Stuff like n=var->field (no spaces) and if (XXX) dosomething(); else return 5; Most places in the python code check for == NULL rather than the implicit check for 0. Most places in code don't do assignment in if (cond), though this last one is more variable. I'll try to look this over in more detail soon. But it probably won't be until PyCon. If you're there, maybe we can discuss in person. Also, if you have further PEP updates, feel free to send them to me and I can check them in. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1436368&group_id=5470 From noreply at sourceforge.net Fri Mar 3 18:23:19 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 03 Mar 2006 09:23:19 -0800 Subject: [Patches] [ python-Patches-1442442 ] Faster list comprehensions Message-ID: Patches item #1442442, was opened at 2006-03-03 07:41 Message generated for change (Comment added) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1442442&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Parser/Compiler Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: Collin Winter (collinwinter) >Assigned to: Nobody/Anonymous (nobody) Summary: Faster list comprehensions Initial Comment: The attached patch results in a 16% speed increase for list comprehensions. By changing how the LIST_APPEND opcode works (which was previously totally unused), it's possible to dramatically simplify the emitted bytecode for listcomps. More details are available on my blog: http://oakwinter.com/code/?p=22. ---------------------------------------------------------------------- >Comment By: Raymond Hettinger (rhettinger) Date: 2006-03-03 12:23 Message: Logged In: YES user_id=80475 I believe the patch is not correct for comprehensions with multiple for-loops. It needs to leave ceval.c, opcode.h, and opcode.py exactly as the were in Py2.4. Also, the code for ceval.c should only access the stack through the stack access macros and avoid derefencing the stack pointer directly. The patch should be resubmitted to only modify compile.c and to produce the same code as in Py2.4 (see example below and note the inclusion of the DUP_TOP after the BUILD_LIST). ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2006-03-03 11:21 Message: Logged In: YES user_id=80475 Neal, did the LIST_APPEND generation get left out of the AST. In Py2.4, is was working fine: Python 2.4.2 (#67, Sep 28 2005, 12:41:11) [MSC v.1310 32 bit (Intel)] on win32 >>> from dis import dis >>> dis(compile('[x for x in range(10) if x % 2]', '', 'single')) 1 0 BUILD_LIST 0 3 DUP_TOP 4 STORE_NAME 0 (_[1]) 7 LOAD_NAME 1 (range) 10 LOAD_CONST 0 (10) 13 CALL_FUNCTION 1 16 GET_ITER >> 17 FOR_ITER 28 (to 48) 20 STORE_NAME 2 (x) 23 LOAD_NAME 2 (x) 26 LOAD_CONST 1 (2) 29 BINARY_MODULO 30 JUMP_IF_FALSE 11 (to 44) 33 POP_TOP 34 LOAD_NAME 0 (_[1]) 37 LOAD_NAME 2 (x) 40 LIST_APPEND 41 JUMP_ABSOLUTE 17 >> 44 POP_TOP 45 JUMP_ABSOLUTE 17 >> 48 DELETE_NAME 0 (_[1]) 51 PRINT_EXPR 52 LOAD_CONST 2 (None) 55 RETURN_VALUE ---------------------------------------------------------------------- Comment By: Collin Winter (collinwinter) Date: 2006-03-03 07:49 Message: Logged In: YES user_id=1344176 I forgot to mention: the patch also includes updates to things like Lib/test/test_dis.py and Lib/opcode.py to make them work with the updated LIST_APPEND opcode and code generation. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1442442&group_id=5470 From noreply at sourceforge.net Fri Mar 3 18:39:23 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 03 Mar 2006 09:39:23 -0800 Subject: [Patches] [ python-Patches-1436130 ] Incremental codecs Message-ID: Patches item #1436130, was opened at 2006-02-21 20:32 Message generated for change (Comment added) made by doerwalter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1436130&group_id=5470 Please note that this 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: Walter D?rwald (doerwalter) Assigned to: M.-A. Lemburg (lemburg) Summary: Incremental codecs Initial Comment: This patch extends the codec machinery to add incremental codecs: stateful codecs that don't use a stream API. It adds the following stuff: a class codecs.CodecInfo (a subclass of tuple), that is used as the return value of codecs.lookup(); codecs.IncrementalEncoder and codecs.IncrementalDecoder (the basic interface classes), codecs.BufferedIncrementalDecoder (a class that can be used to implement decoders that must handle incomplete input); codecs.iterencode() and codecs.iterdecode() (generators that use the incremental codecs for encoding/decoding an input iterable). On the C level PyCodec_IncrementalEncoder() and PyCodec_IncrementalDecoder() are added. ---------------------------------------------------------------------- >Comment By: Walter D?rwald (doerwalter) Date: 2006-03-03 18:39 Message: Logged In: YES user_id=89016 This fourth version of the patch removes the changes to Lib/encodings/idna.py (only the addition of the IncrementalEncoder/IncrementalDecoder and the changed getregentry() remain). This patch to idna.py probably only makes sense once this patch is in. > Is it possible to make IncrementalEncoder/Decoder > instances iterable per-se (without the need to go > through the helper functions iterencode/iterdecode) ? For IncrementalEncoder/Decoder to be iterable it would have to have some iterable from which it gets the input. But this has the same limitation as the stream API: The user is forced to provide the input as a service that the encoder/decoder uses, which requires support for a certain API. The only change would be that now it's an iterator API instead of a stream API. The incremental codecs invert the call logic: The user no longer has to provide a callback service to the codec, but calls the codec directly. This gives much more flexibility. ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2006-03-03 00:03 Message: Logged In: YES user_id=38388 Very nice ! This is a much better approach than the feed style path you wanted to take previously. Minor nits: Please separate out the non-related changes to the IDNA codec into a new patch and assign that to Martin for review. Is it possible to make IncrementalEncoder/Decoder instances iterable per-se (without the need to go through the helper functions iterencode/iterdecode) ? Thanks. ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2006-03-01 15:47 Message: Logged In: YES user_id=89016 This third version of the patch fixes the bug when the iterator in iterencode() or iterdecode() is empty and updates the docstring in encodings/__init__.py. ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2006-02-28 13:08 Message: Logged In: YES user_id=89016 This second version of the patch enhances codecs.iterencode() and codecs.iterdecode(), so that additional keyword arguments are passed through to the Incremental(De|En)coder constructor. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1436130&group_id=5470 From noreply at sourceforge.net Fri Mar 3 18:45:36 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 03 Mar 2006 09:45:36 -0800 Subject: [Patches] [ python-Patches-1436368 ] PEP 357 --- adding nb_index Message-ID: Patches item #1436368, was opened at 2006-02-21 22:35 Message generated for change (Comment added) made by gvanrossum You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1436368&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Core (C code) Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: Travis Oliphant (teoliphant) Assigned to: Guido van Rossum (gvanrossum) Summary: PEP 357 --- adding nb_index Initial Comment: See PEP 357 for details. ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2006-03-03 12:45 Message: Logged In: YES user_id=6380 Totally right. I have one more concern: >>> import sys >>> (sys.maxint+1).__index__() Traceback (most recent call last): File "", line 1, in OverflowError: long int too large to convert to int >>> whiile I agree that the C API ought to silently truncate values to fit within the boundaries established by ssize_t, I think that when calling __index__() from Python, it should be allowed to return an unbounded value. Anyway, I haven't had time to whip up code to implement that, but here's a new patch that adds the test to ISINDEX() -- thanks for catching that! ---------------------------------------------------------------------- Comment By: Travis Oliphant (teoliphant) Date: 2006-03-03 12:08 Message: Logged In: YES user_id=5296 I think there is still a need for a HASINDEX check in the ISINDEX definition in ceval.c ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2006-03-03 00:12 Message: Logged In: YES user_id=6380 OK, Travis, here's a new patch. It corrects the issues I mentioned before, and does some whitespace cleanup (like what Neal mentioned). The biggest change is definitely the check for Py_TPFLAGS_HAVE_INDEX whenever the nb_index slot is referenced. You don't have to do anything; but if you do have more changes, please throw away your old changes, sync to the head, and apply my patch, before doing any more work. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2006-03-02 23:32 Message: Logged In: YES user_id=6380 Travis -- I'm working on a new patch. Please don't work on one at the same time for the new few hours! (Until midnight PST.) ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2006-03-02 20:16 Message: Logged In: YES user_id=6380 I promise I'll review this further tomorrow! Feedback so far: - compilation error with svn HEAD on abstract.c:650 - all the uses of the nb_index slot must check for some Py_TPFLAGS_... bit before using that slot (see object.h) - the comment in ceval.c about the clipping of values < -PY_SSIZE_T_MAX is incorrect; they are boosted to -PY_SSIZE_T_MAX, not to zero ---------------------------------------------------------------------- Comment By: Travis Oliphant (teoliphant) Date: 2006-02-22 12:52 Message: Logged In: YES user_id=5296 I followed Neal's comments and updated a new patch. The new patch contains the tests and the documentation updates as well. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2006-02-22 03:03 Message: Logged In: YES user_id=33168 I see one problem in Modules/operator.c. This code: + if (i==-1 && PyErr_Occurred()) return NULL; + else return PyInt_FromLong((long)i); Should be: + if (i == -1 && PyErr_Occurred()) + return NULL; + return PyInt_FromSsizeT(i); There was a discussion on python-checkins recently about this. The short answer is that if Py_ssize_t's are cast to a long, that will lose precision on Win64 (size_ts are 64-bits, but longs are still 32). Since i is Py_ssize_t, the cast would lose the high order values (above 2G). In Objects/stringobject.c: - i += PyString_GET_SIZE(self); - return string_item(self,i); + i += PyList_GET_SIZE(self); + return string_item(self, i); I don't see how that (PyList) can be correct, self is a string object. I would change this code: + lenfunc func; + PyNumberMethods *nb; + if ((nb=item->ob_type->tp_as_number) && \ + (func=nb->nb_index)) { + Py_ssize_t i = func(item); to: + PyNumberMethods *nb = item->ob_type->tp_as_number; + if (nb != NULL && nb->nb_index != NULL) { + Py_ssize_t i = nb->nb_index(item); Let the compiler do the work. We can optimize later if this is a problem. I think the code is clearer this way and is more similar to the rest of the code. I don't care as much about the use of func here as the change to nb = ... If you want to keep the local variable, I would prefer a better name like nb_index instead of func. There's no need for a \ after &&. Most of these comments apply to Objects/listobject.c, Objects/tupleobject.c, Objects/unicodeobject.c, PyNumber_Index. In Objects/classobject.c, you don't check that indexstr is non-NULL after assignment. In instance_index(), remove the cast (int) of the return result outcome. In slot_nb_index() remove . from end of exception string. Note: you don't need the Py_DECREF() and return -1 in the last if as it would be the same if it fell through. Use whichever version you think is clearer. Either way is fine with me. In Include/abstract.h, do all the comments still say a C integer is returned even though a Py_ssize_t is returned? If not, can you update your comment too. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2006-02-22 02:33 Message: Logged In: YES user_id=33168 Travis, I briefly looked over the patches and have a few comments. It's easier if there's one big patch that contains all the code, tests, and doc. I noticed a second patch that contains the tests, but I didn't see any doc updates. I noticed some formatting which is not consistent with the style of the surrounding code (I think). Stuff like n=var->field (no spaces) and if (XXX) dosomething(); else return 5; Most places in the python code check for == NULL rather than the implicit check for 0. Most places in code don't do assignment in if (cond), though this last one is more variable. I'll try to look this over in more detail soon. But it probably won't be until PyCon. If you're there, maybe we can discuss in person. Also, if you have further PEP updates, feel free to send them to me and I can check them in. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1436368&group_id=5470 From noreply at sourceforge.net Fri Mar 3 18:45:41 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 03 Mar 2006 09:45:41 -0800 Subject: [Patches] [ python-Patches-1436368 ] PEP 357 --- adding nb_index Message-ID: Patches item #1436368, was opened at 2006-02-21 19:35 Message generated for change (Comment added) made by nnorwitz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1436368&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Core (C code) Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: Travis Oliphant (teoliphant) Assigned to: Guido van Rossum (gvanrossum) Summary: PEP 357 --- adding nb_index Initial Comment: See PEP 357 for details. ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2006-03-03 09:45 Message: Logged In: YES user_id=33168 The doc needs \versionadded tags. I can add those after checkin. Should sequences in Modules/ be upgraded too? mmap, array, various db modules, bufferobject, rangeobject. Travis already mentioned the TP_FLAGS_HAVE_INDEX check in ceval.c. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2006-03-03 09:45 Message: Logged In: YES user_id=6380 Totally right. I have one more concern: >>> import sys >>> (sys.maxint+1).__index__() Traceback (most recent call last): File "", line 1, in OverflowError: long int too large to convert to int >>> whiile I agree that the C API ought to silently truncate values to fit within the boundaries established by ssize_t, I think that when calling __index__() from Python, it should be allowed to return an unbounded value. Anyway, I haven't had time to whip up code to implement that, but here's a new patch that adds the test to ISINDEX() -- thanks for catching that! ---------------------------------------------------------------------- Comment By: Travis Oliphant (teoliphant) Date: 2006-03-03 09:08 Message: Logged In: YES user_id=5296 I think there is still a need for a HASINDEX check in the ISINDEX definition in ceval.c ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2006-03-02 21:12 Message: Logged In: YES user_id=6380 OK, Travis, here's a new patch. It corrects the issues I mentioned before, and does some whitespace cleanup (like what Neal mentioned). The biggest change is definitely the check for Py_TPFLAGS_HAVE_INDEX whenever the nb_index slot is referenced. You don't have to do anything; but if you do have more changes, please throw away your old changes, sync to the head, and apply my patch, before doing any more work. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2006-03-02 20:32 Message: Logged In: YES user_id=6380 Travis -- I'm working on a new patch. Please don't work on one at the same time for the new few hours! (Until midnight PST.) ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2006-03-02 17:16 Message: Logged In: YES user_id=6380 I promise I'll review this further tomorrow! Feedback so far: - compilation error with svn HEAD on abstract.c:650 - all the uses of the nb_index slot must check for some Py_TPFLAGS_... bit before using that slot (see object.h) - the comment in ceval.c about the clipping of values < -PY_SSIZE_T_MAX is incorrect; they are boosted to -PY_SSIZE_T_MAX, not to zero ---------------------------------------------------------------------- Comment By: Travis Oliphant (teoliphant) Date: 2006-02-22 09:52 Message: Logged In: YES user_id=5296 I followed Neal's comments and updated a new patch. The new patch contains the tests and the documentation updates as well. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2006-02-22 00:03 Message: Logged In: YES user_id=33168 I see one problem in Modules/operator.c. This code: + if (i==-1 && PyErr_Occurred()) return NULL; + else return PyInt_FromLong((long)i); Should be: + if (i == -1 && PyErr_Occurred()) + return NULL; + return PyInt_FromSsizeT(i); There was a discussion on python-checkins recently about this. The short answer is that if Py_ssize_t's are cast to a long, that will lose precision on Win64 (size_ts are 64-bits, but longs are still 32). Since i is Py_ssize_t, the cast would lose the high order values (above 2G). In Objects/stringobject.c: - i += PyString_GET_SIZE(self); - return string_item(self,i); + i += PyList_GET_SIZE(self); + return string_item(self, i); I don't see how that (PyList) can be correct, self is a string object. I would change this code: + lenfunc func; + PyNumberMethods *nb; + if ((nb=item->ob_type->tp_as_number) && \ + (func=nb->nb_index)) { + Py_ssize_t i = func(item); to: + PyNumberMethods *nb = item->ob_type->tp_as_number; + if (nb != NULL && nb->nb_index != NULL) { + Py_ssize_t i = nb->nb_index(item); Let the compiler do the work. We can optimize later if this is a problem. I think the code is clearer this way and is more similar to the rest of the code. I don't care as much about the use of func here as the change to nb = ... If you want to keep the local variable, I would prefer a better name like nb_index instead of func. There's no need for a \ after &&. Most of these comments apply to Objects/listobject.c, Objects/tupleobject.c, Objects/unicodeobject.c, PyNumber_Index. In Objects/classobject.c, you don't check that indexstr is non-NULL after assignment. In instance_index(), remove the cast (int) of the return result outcome. In slot_nb_index() remove . from end of exception string. Note: you don't need the Py_DECREF() and return -1 in the last if as it would be the same if it fell through. Use whichever version you think is clearer. Either way is fine with me. In Include/abstract.h, do all the comments still say a C integer is returned even though a Py_ssize_t is returned? If not, can you update your comment too. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2006-02-21 23:33 Message: Logged In: YES user_id=33168 Travis, I briefly looked over the patches and have a few comments. It's easier if there's one big patch that contains all the code, tests, and doc. I noticed a second patch that contains the tests, but I didn't see any doc updates. I noticed some formatting which is not consistent with the style of the surrounding code (I think). Stuff like n=var->field (no spaces) and if (XXX) dosomething(); else return 5; Most places in the python code check for == NULL rather than the implicit check for 0. Most places in code don't do assignment in if (cond), though this last one is more variable. I'll try to look this over in more detail soon. But it probably won't be until PyCon. If you're there, maybe we can discuss in person. Also, if you have further PEP updates, feel free to send them to me and I can check them in. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1436368&group_id=5470 From noreply at sourceforge.net Fri Mar 3 21:30:14 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 03 Mar 2006 12:30:14 -0800 Subject: [Patches] [ python-Patches-1442442 ] Faster list comprehensions Message-ID: Patches item #1442442, was opened at 2006-03-03 04:41 Message generated for change (Comment added) made by nnorwitz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1442442&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Parser/Compiler Group: Python 2.5 >Status: Closed >Resolution: Out of Date Priority: 5 Submitted By: Collin Winter (collinwinter) >Assigned to: Neal Norwitz (nnorwitz) Summary: Faster list comprehensions Initial Comment: The attached patch results in a 16% speed increase for list comprehensions. By changing how the LIST_APPEND opcode works (which was previously totally unused), it's possible to dramatically simplify the emitted bytecode for listcomps. More details are available on my blog: http://oakwinter.com/code/?p=22. ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2006-03-03 12:30 Message: Logged In: YES user_id=33168 Raymond, I added back the LIST_APPEND opcode. Collin, if you have a further enhancements, please open a new patch. Closing this one. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2006-03-03 09:23 Message: Logged In: YES user_id=80475 I believe the patch is not correct for comprehensions with multiple for-loops. It needs to leave ceval.c, opcode.h, and opcode.py exactly as the were in Py2.4. Also, the code for ceval.c should only access the stack through the stack access macros and avoid derefencing the stack pointer directly. The patch should be resubmitted to only modify compile.c and to produce the same code as in Py2.4 (see example below and note the inclusion of the DUP_TOP after the BUILD_LIST). ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2006-03-03 08:21 Message: Logged In: YES user_id=80475 Neal, did the LIST_APPEND generation get left out of the AST. In Py2.4, is was working fine: Python 2.4.2 (#67, Sep 28 2005, 12:41:11) [MSC v.1310 32 bit (Intel)] on win32 >>> from dis import dis >>> dis(compile('[x for x in range(10) if x % 2]', '', 'single')) 1 0 BUILD_LIST 0 3 DUP_TOP 4 STORE_NAME 0 (_[1]) 7 LOAD_NAME 1 (range) 10 LOAD_CONST 0 (10) 13 CALL_FUNCTION 1 16 GET_ITER >> 17 FOR_ITER 28 (to 48) 20 STORE_NAME 2 (x) 23 LOAD_NAME 2 (x) 26 LOAD_CONST 1 (2) 29 BINARY_MODULO 30 JUMP_IF_FALSE 11 (to 44) 33 POP_TOP 34 LOAD_NAME 0 (_[1]) 37 LOAD_NAME 2 (x) 40 LIST_APPEND 41 JUMP_ABSOLUTE 17 >> 44 POP_TOP 45 JUMP_ABSOLUTE 17 >> 48 DELETE_NAME 0 (_[1]) 51 PRINT_EXPR 52 LOAD_CONST 2 (None) 55 RETURN_VALUE ---------------------------------------------------------------------- Comment By: Collin Winter (collinwinter) Date: 2006-03-03 04:49 Message: Logged In: YES user_id=1344176 I forgot to mention: the patch also includes updates to things like Lib/test/test_dis.py and Lib/opcode.py to make them work with the updated LIST_APPEND opcode and code generation. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1442442&group_id=5470 From noreply at sourceforge.net Fri Mar 3 23:31:37 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 03 Mar 2006 14:31:37 -0800 Subject: [Patches] [ python-Patches-1424065 ] The email package needs an "application" type Message-ID: Patches item #1424065, was opened at 2006-02-04 09:39 Message generated for change (Comment added) made by bwarsaw You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1424065&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. >Category: Library (Lib) >Group: Python 2.5 >Status: Closed >Resolution: Accepted Priority: 5 Submitted By: Keith Dart (kdart) Assigned to: Barry A. Warsaw (bwarsaw) Summary: The email package needs an "application" type Initial Comment: The email package lacks a top-level MIME class for "application/*" MIME types. Attached to this bug is one that you might want to include. ---------------------------------------------------------------------- >Comment By: Barry A. Warsaw (bwarsaw) Date: 2006-03-03 17:31 Message: Logged In: YES user_id=12800 Thanks Keith, I've added this for email 4.0 (Python 2.5), albeit with some changes, test cases, and documentation additions. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1424065&group_id=5470 From noreply at sourceforge.net Sat Mar 4 03:40:43 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 03 Mar 2006 18:40:43 -0800 Subject: [Patches] [ python-Patches-1442867 ] Add support for the If-Modified-Since header Message-ID: Patches item #1442867, was opened at 2006-03-03 18:40 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1442867&group_id=5470 Please note that this 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: Shannon -jj Behrens (jjinux) Assigned to: Nobody/Anonymous (nobody) Summary: Add support for the If-Modified-Since header Initial Comment: Added support for the If-Modified-Since header to SimpleHTTPServer. That way things like images don't get downloaded again on every new page request. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1442867&group_id=5470 From noreply at sourceforge.net Sat Mar 4 07:21:14 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 03 Mar 2006 22:21:14 -0800 Subject: [Patches] [ python-Patches-1442927 ] PyLong_FromString optimization Message-ID: Patches item #1442927, was opened at 2006-03-04 01:21 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1442927&group_id=5470 Please note that this 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: Alan McIntyre (alanmcintyre) Assigned to: Nobody/Anonymous (nobody) Summary: PyLong_FromString optimization Initial Comment: The current implementation of PyLong_FromString in Python 2.5 uses muladd1 to add each digit of the input string into the final number. Because muladd1 creates a new long to hold the result on every call, an intermediate long object is created/destroyed for each digit in the input string. This patch improves on the current implementation of PyLong_FromString in 3 main ways: 1. Creates and manipulates (in-place) a single long object to hold the result, skipping the creation of all those intermediate long objects. 2. Multiple digits from the input string are consolidated into a single long digit before adding them into the long integer object. This greatly reduces the number of "multiply/add" cycles required to push all the digits into the long object. 3. Three chunks of code like "if (ch <= '9') k = ch - '0'" in longobject.c are replaced by a digit value lookup vector. I'm not irreversibly stuck on this idea; it doesn't measurably add to performance, but it just seems (to me, anyway) to make the code in long_from_binary_base and PyLong_FromString a little less cluttered. This is the same lookup table from patch 1335972 (an optimization for int()). I expect if both patches get accepted it would be best to make them both reference a single instance of this table; if it looks like that's what will happen I'll tweak one or both patches as necessary. My cheezy test results (included in the attached file in an OpenOffice spreadsheet) show that the patch makes long() about 50% faster than the existing implementation for decimal input strings of about 10 characters. Longer input strings show even better performance improvement, leveling off around 3x faster for very long strings. This patch passes regression tests on my machine (WinXP, Visual C++ .net Standard 2003). I plan to try out the tests on my Linux box this weekend just to make sure the performance boost still remains when Python gets compiled by a C compiler that isn't neutered (standard .net 2003 doesn't appear to allow any optimizations). The test and test data generation scripts I used for this performance comparison are included in the attached zip file. At the moment I don't have any added tests; if somebody can suggest some things that ought to be tested I'll gladly write some tests. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1442927&group_id=5470 From noreply at sourceforge.net Sat Mar 4 19:45:01 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 04 Mar 2006 10:45:01 -0800 Subject: [Patches] [ python-Patches-1443155 ] Incremental codecs for CJKCodecs Message-ID: Patches item #1443155, was opened at 2006-03-05 03:45 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1443155&group_id=5470 Please note that this 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: Hye-Shik Chang (perky) Assigned to: Nobody/Anonymous (nobody) Summary: Incremental codecs for CJKCodecs Initial Comment: Here's a supplemental patch for SF #1436130 to implement CJKCodecs part of the Incremental codec specification. This patch is implemented in an interface of Walter's fourth patch on #1436130. Please test this whether it agrees the design. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1443155&group_id=5470 From noreply at sourceforge.net Sat Mar 4 19:52:45 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 04 Mar 2006 10:52:45 -0800 Subject: [Patches] [ python-Patches-1443159 ] Remove bad PREDICT in ceval.c Message-ID: Patches item #1443159, was opened at 2006-03-04 13:52 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1443159&group_id=5470 Please note that this 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: Collin Winter (collinwinter) Assigned to: Nobody/Anonymous (nobody) Summary: Remove bad PREDICT in ceval.c Initial Comment: The current FOR_ITER -> UNPACK_SEQUENCE prediction is only right 6.41% of the time (212 million opcodes analysed). This patch removes it. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1443159&group_id=5470 From noreply at sourceforge.net Sat Mar 4 21:02:18 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 04 Mar 2006 12:02:18 -0800 Subject: [Patches] [ python-Patches-1006238 ] cross compile patch Message-ID: Patches item #1006238, was opened at 2004-08-10 00:05 Message generated for change (Comment added) made by hugo_koopmans You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1006238&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Build Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Daniel Goertzen (goertzen) Assigned to: Nobody/Anonymous (nobody) Summary: cross compile patch Initial Comment: Here's a cross compile patch I prepared a while ago but never got around to submitting. I've been using it happily for months to cross compile python for embedded systems. Below is a descriptive excerpt from the patch. Also note that the patch modifies configure.in, but not configure. You will need to regenerate configure with something like autoconf configure.in >configure This patch is inpsired from work by Klaus Reimer at http://www.ailis.de/~k/docs/crosscompiling/python.php + Cross Compiling + --------------- + + Python can be cross compiled by supplying different --host and --build + parameters to configure. (Python is compiled on the "build" system + and executed on the "host" system, in case you forgot :). Python is + tricky to cross compile because it needs to execute parts of itself + during construction. To work around this, make's VPATH feature is + used to compile a native python in the subdirectory "buildpython". + When parts of python need to be executed during construction, the + "buildpython" versions are used. + + A consequence of using the VPATH feature is that you may not do a + cross compile build in the source directory. In other words, do this: + + mkdir mydir + cd mydir + ../Python/configure --host=powerpc-405-linux-gnu --build=i686-pc-linux-gnu + make + + Cross compiling works well under linux, mileage may vary for other + platforms. + + A few reminders on using configure to cross compile: + - Cross compile tools must be in the PATH. + - Cross compile tools must be prefixed with the host type + (ie powerpc-405-linux-gnu-cc, powerpc-405-linux-gnu-ranlib, ...) + - CC, CXX, AR, and RANLIB must be undefined when running configure and + make. Configure will detect them. + + If you need a cross compiler, check out Dan Kegel's crosstool: + http://www.kegel.com/crosstool + + ---------------------------------------------------------------------- Comment By: hugo (hugo_koopmans) Date: 2006-03-04 21:02 Message: Logged In: YES user_id=1229536 Hi there, I am trying to cross compile python on the fox board (etrax). now everything seemed to go well but when running the python binary is says: ./python: error while loading shared libraries: libstdc++.so.5: cannot load shared object file: No such file or directory I only ftp-ed the python bin not the (much bigger) libpython2.4a .... seems this is a library archive of some kind ? do i need it? how do i use it then? thanx a million if you can help me out. hugo ---------------------------------------------------------------------- Comment By: Daniel Goertzen (goertzen) Date: 2006-02-24 23:32 Message: Logged In: YES user_id=843814 You didn't apply the patch properly. See the other messages about the use of the -p option. Start with a fresh source tree and use: cd Python-2.4.2 patch -p3 <../python-patch.txt ---------------------------------------------------------------------- Comment By: Nicolas (nico0438) Date: 2006-02-24 22:37 Message: Logged In: YES user_id=1330285 If I try to aplly the patch again, I get messages saying a patch has allready been applied. To apply the patch I executed the following : cd Python-2.4.2 patch <../python-patch.txt ---------------------------------------------------------------------- Comment By: Daniel Goertzen (goertzen) Date: 2006-02-24 22:30 Message: Logged In: YES user_id=843814 The build system python should be in "MyPython/buildpython", and the host python should just be in "MyPython" Are you sure you applied the patch right? What you're getting is what would happen if you didn't apply the patch at all. ---------------------------------------------------------------------- Comment By: Nicolas (nico0438) Date: 2006-02-24 22:19 Message: Logged In: YES user_id=1330285 Yes I guess. But it seems that all I get is for the build system. If I try to execute on the build system ./python it runs. Also, there is no hostbuild subdirectory. Is it ok ? Nicolas ---------------------------------------------------------------------- Comment By: Daniel Goertzen (goertzen) Date: 2006-02-24 22:14 Message: Logged In: YES user_id=843814 > I then cd to a "MyPython" directory. > I call ../Python-2.4.2/configure ... Then your files should be in your "MyPython" directory. ---------------------------------------------------------------------- Comment By: Nicolas (nico0438) Date: 2006-02-24 21:54 Message: Logged In: YES user_id=1330285 Me again, sorry... What Should I get after compilation has finished ? Where are the files for my target ? Nicolas ---------------------------------------------------------------------- Comment By: Nicolas (nico0438) Date: 2006-02-24 20:55 Message: Logged In: YES user_id=1330285 Hi again, I finaly dad enought time to work on my project. So, I compiled autoconf tools for my system. Then, I rerun all the steps successfully. Thanks again for your help. Nicolas ---------------------------------------------------------------------- Comment By: nicolas pinault (nico38) Date: 2006-02-24 16:12 Message: Logged In: YES user_id=1081828 You are right, I have misunderstood --build and --host signification. And I also forgotten to run autoconf partialy because I don't have autoconf installed on my system. So I didn't pay attention it didn't run. Thanks for your help. I'll let you know if this works in a few days. Nicolas ---------------------------------------------------------------------- Comment By: Daniel Goertzen (goertzen) Date: 2006-02-24 15:51 Message: Logged In: YES user_id=843814 Did you run autoconf after patching as instructed? Also, your --build and --host options seem backwards. host is the arch you want python to run on, build is the arch you build python on. Cheers, Dan. ---------------------------------------------------------------------- Comment By: nicolas pinault (nico38) Date: 2006-02-24 13:38 Message: Logged In: YES user_id=1081828 Hi, I try to cross compile Python-2.4.2 for an etrax processor. I have successfully applied the patch to Python sources. I then cd to a "MyPython" directory. I call ../Python-2.4.2/configure --build cris --host i386-linux It works ok (did not see an error) I all make I get the following error after a while : make : *** No rule to make target '@BUILDPGEN@', needed by '../Python-2.4.2/Include/graminit.h'. Stop. Any Idea ? Nicolas ---------------------------------------------------------------------- Comment By: xudong (xudong888) Date: 2006-01-10 15:45 Message: Logged In: YES user_id=1420135 I have resolved my question,now I can run python on the mips machine,and can run some binary build by python.Can I also cross compile pygame for python?But the pygame source does't has 'configure' and 'Makefiel' files,setup.py instead in source package.How should I do? Thanks :-) ---------------------------------------------------------------------- Comment By: xudong (xudong888) Date: 2006-01-06 12:08 Message: Logged In: YES user_id=1420135 If you have accounts of MSN,please add me.My accounts is xudong_888 at hotmail.com. I am very impatient.I hope I can get some help from you.Thanks. ---------------------------------------------------------------------- Comment By: xudong (xudong888) Date: 2006-01-06 11:57 Message: Logged In: YES user_id=1420135 Thank you for your rapid answer.But I still can't solve my question.I can't find the whole instructions. Can you give me the whole instructions by EMAIL,my email is xudong888 at 163.com,thanks. My "host" system is mips embbed_linux,the release of the linux kernel is 2.4.xx and the CPU type is MIPS 4Kc.There are no python installed on this system.My "build" system is i86 and operate system is RedHat9.0,and has installed python2.4.1 and cross-compiling Tools mipsel-linux-gcc.I can cross compile C program for the "host" system.I have writed some program with python language.I can get the binary from python script by use freeze.py on the "build" system. Now I want to run the binary on the "host" system.Can you tell me how should I do. in addition,I don't know what parameter I should input to use this patch. finally,I'm sorry for my poor English.I like python very much,but I can't get help in chinese. ---------------------------------------------------------------------- Comment By: Daniel Goertzen (goertzen) Date: 2006-01-05 18:24 Message: Logged In: YES user_id=843814 After configure you run "make". But did you use configure as the instructions say? You cannot just use "./configure". Good luck, Dan. ---------------------------------------------------------------------- Comment By: xudong (xudong888) Date: 2006-01-05 17:55 Message: Logged In: YES user_id=1420135 I am a Chinese and my English is very poor.I'm sorry if what I said is wrong.My question is What should I do after './configure'.Before this I have done patch and autoconf. Thanks :-) ---------------------------------------------------------------------- Comment By: David Lambert (jdalambert) Date: 2005-11-08 17:06 Message: Logged In: YES user_id=845425 Oops! All works fine now. Thanks :-) ---------------------------------------------------------------------- Comment By: Daniel Goertzen (goertzen) Date: 2005-11-08 16:09 Message: Logged In: YES user_id=843814 patch isn't lying about wrong -p options. Use -p3 instead of -p0. Cheers, Dan. ---------------------------------------------------------------------- Comment By: David Lambert (jdalambert) Date: 2005-11-08 15:26 Message: Logged In: YES user_id=845425 Thanks for the quick reply, and sorry for the confusion. I DID try the cross compile in a sub directory. That failed with the same error. I then tried a non-cross build in the main directory, that also failed (which was my previous post). Here is my complete transcript after untarring Python: [dlambert at lambsys Python-2.4.2]$ patch -p0 < ../python-patch can't find file to patch at input line 3 Perhaps you used the wrong -p or --strip option? The text leading up to this was: -------------------------- |*** python-cvs-pristine/dist/src/README Fri Mar 5 08:33:21 2004 |--- python/dist/src/README Mon Apr 5 14:30:23 2004 -------------------------- File to patch: README patching file README Hunk #1 succeeded at 1130 (offset 30 lines). can't find file to patch at input line 48 Perhaps you used the wrong -p or --strip option? The text leading up to this was: -------------------------- |*** python-cvs-pristine/dist/src/configure.in Sun Mar 21 17:45:41 2004 |--- python/dist/src/configure.in Mon Apr 5 16:15:07 2004 -------------------------- File to patch: configure.in patching file configure.in Hunk #2 succeeded at 609 (offset 58 lines). Hunk #3 succeeded at 3072 (offset 112 lines). can't find file to patch at input line 113 Perhaps you used the wrong -p or --strip option? The text leading up to this was: -------------------------- |*** python-cvs-pristine/dist/src/Makefile.pre.in Thu Mar 18 01:51:27 2004 |--- python/dist/src/Makefile.pre.in Mon Apr 5 15:56:00 2004 -------------------------- File to patch: Makefile.pre.in patching file Makefile.pre.in Hunk #2 succeeded at 163 (offset 3 lines). Hunk #4 succeeded at 309 (offset 5 lines). Hunk #6 succeeded at 470 (offset 5 lines). Hunk #7 succeeded at 624 (offset 1 line). Hunk #8 succeeded at 839 (offset 7 lines). Hunk #9 succeeded at 923 (offset 1 line). Hunk #10 succeeded at 969 (offset 7 lines). can't find file to patch at input line 309 Perhaps you used the wrong -p or --strip option? The text leading up to this was: -------------------------- |*** python-cvs-pristine/dist/src/setup.py Sun Mar 21 12:59:46 2004 |--- python/dist/src/setup.py Mon Apr 5 15:20:55 2004 -------------------------- File to patch: setup.py patching file setup.py Hunk #1 succeeded at 198 (offset -2 lines). patching file python/dist/src/config.guess patching file python/dist/src/config.sub [dlambert at lambsys Python-2.4.2]$ [dlambert at lambsys Python-2.4.2]$ [dlambert at lambsys Python-2.4.2]$ autoconf configure.in > configure [dlambert at lambsys Python-2.4.2]$ mkdir cross-build [dlambert at lambsys Python-2.4.2]$ cd cross-build [dlambert at lambsys cross-build]$ ../configure --host=arm-linux --build=i686-pc-li nux-gnu configure: error: cannot run /bin/sh ../config.sub [dlambert at lambsys cross-build]$ ---------------------------------------------------------------------- Comment By: Daniel Goertzen (goertzen) Date: 2005-11-08 15:05 Message: Logged In: YES user_id=843814 You can't configure in the source directory with the cross compile patch. This is explained in the directions. ---------------------------------------------------------------------- Comment By: David Lambert (jdalambert) Date: 2005-11-08 03:12 Message: Logged In: YES user_id=845425 Hmm. not so much luck here. I get the following error after patching then autoconf. I am running on Fedora Core 4. Any suggestions? [dlambert at lambsys Python-2.4.2]$ autoconf configure.in >configure [dlambert at lambsys Python-2.4.2]$ ./configure configure: error: cannot run /bin/sh ./config.sub [dlambert at lambsys Python-2.4.2]$ ---------------------------------------------------------------------- Comment By: Robsa (robsa) Date: 2005-10-13 13:54 Message: Logged In: YES user_id=1277505 Just thought I'd let you know that this patch works against Python 2.4.2. I had Python running on my custom AT91RM9200 board (ARM920T core) in about 20 minutes. *snaps* for Daniel!! ---------------------------------------------------------------------- Comment By: Daniel Goertzen (goertzen) Date: 2005-04-13 19:36 Message: Logged In: YES user_id=843814 It still works for me, so I've had limited interest in working on it further. I think a "real" cross compile patch will involve significant refactoring of distutils and the main setup.py script. Should this start with a PEP? ---------------------------------------------------------------------- Comment By: Ned Ludd (solarx) Date: 2005-04-09 22:43 Message: Logged In: YES user_id=148412 Any progress with this on? python and perl are two of the last major things to overcome in the x-compile world. ---------------------------------------------------------------------- Comment By: Mike Frysinger (vapier) Date: 2004-10-26 18:00 Message: Logged In: YES user_id=114429 we've been using this with uClibc for a while now and it works great ... ive personally built (on amd64) & deployed (on x86/ppc/arm/mips/sh4) python ... would great if this finally made it into the official sources :) ---------------------------------------------------------------------- Comment By: Jeff Epler (jepler) Date: 2004-10-21 03:08 Message: Logged In: YES user_id=2772 This patch applies cleanly to today's CVS head. If building in the source directory while cross compiling fails, please make configure complain about it. This patch makes the build process invoke make recursively, which is a big minus. I'd rather see pgen built with a HOSTCC and just assume python is available on $PATH for the setup.py step. There's no reason to build all the shared modules in buildpython, either, which would speed things up a fair bit. On to how it worked for me: Not cross-compiling, this produces no unexpected test failures in "make test". (redhat9) Cross compiling for i386-pc-bsdi2.1 everything goes fine until it tries to run buildpython and make shared modules, but shared modules don't work in the first place on bsdi2. I did not test the resulting Python binary. Cross compiling for i386-redhat-linux (libc6) some extensions fail to build, but this could be because my header files for the cross-development environment are not complete. Running "make test" tries to invoke the "buildpython/python" and doesn't work. Running it manually I get some skips due to modules that did not build, but everything that did build seems to pass. (OK, so I wrote this before the tests completed, but they're off to a good start) I currently cross-compile python 2.3 for win32 (mingw), and until recently cross-compiled it for bsdi2 and redhat6. However, I did not use configure or the included makefiles to do this (in order to integrate in a non-recursive build procedure that builds several packages), so this patch is unlikely to benefit me directly. I don't think this patch is ready to be applied. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1006238&group_id=5470 From noreply at sourceforge.net Mon Mar 6 02:10:09 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 05 Mar 2006 17:10:09 -0800 Subject: [Patches] [ python-Patches-1437769 ] Size of time_t changed to 64 bits in MSVC++ 2005 CRT Message-ID: Patches item #1437769, was opened at 2006-02-23 18:18 Message generated for change (Comment added) made by tjreedy You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1437769&group_id=5470 Please note that this 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: None Priority: 5 Submitted By: Atul Varma (varmaa) Assigned to: Nobody/Anonymous (nobody) Summary: Size of time_t changed to 64 bits in MSVC++ 2005 CRT Initial Comment: As of Visual C++ 2005, the size of the time_t data type was changed from 32 bits to 64 bits. Among other things, this breaks the C API test in the Python "test" package, because Python thinks that time_t should be 32 bits large. Altering PC/pyconfig.h by conditionally defining SIZEOF_TIME_T depending on whether at least MSVC++ 2005 is being used for compilation fixes this. Attached is a very simple unified diff patch for PC/pyconfig.h, taken from revision 42382 (the most recent revision at the time of this submission). More information about this and other recent changes to the MS CRT for Visual C++ 2005 can be found here: http://msdn2.microsoft.com/en-us/library/ms235429.aspx ---------------------------------------------------------------------- >Comment By: Terry J. Reedy (tjreedy) Date: 2006-03-05 20:10 Message: Logged In: YES user_id=593130 The page specifically says "The default size for time_t is now 64 bits..." The page on breaking changes http://msdn2.microsoft.com/en-us/library/ms235497.aspx says "time_t is now a 64-bit value (unless _USE_32BIT_TIME_T is defined)." so it would appear that there is a possible alternative fix. My understanding of recent discussions is that the developers are not planning to upgrade their VC version at this time. Unless this is the only change needed, I would not be surprised if a more complete patch would be wanted at one time. Maybe someone else will say more. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1437769&group_id=5470 From noreply at sourceforge.net Mon Mar 6 02:18:52 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 05 Mar 2006 17:18:52 -0800 Subject: [Patches] [ python-Patches-1439917 ] issue syntax warning for with becoming a keyword Message-ID: Patches item #1439917, was opened at 2006-02-27 16:20 Message generated for change (Settings changed) made by tjreedy You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1439917&group_id=5470 Please note that this 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: Neal Norwitz (nnorwitz) Assigned to: Thomas Wouters (twouters) Summary: issue syntax warning for with becoming a keyword Initial Comment: Basic support for warning about with/as becoming a keyword. Incomplete, but this makes it easier to share. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2006-02-28 17:24 Message: Logged In: YES user_id=33168 Thomas integrated this. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1439917&group_id=5470 From noreply at sourceforge.net Mon Mar 6 02:50:23 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 05 Mar 2006 17:50:23 -0800 Subject: [Patches] [ python-Patches-1436368 ] PEP 357 --- adding nb_index Message-ID: Patches item #1436368, was opened at 2006-02-22 04:35 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1436368&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Core (C code) Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: Travis Oliphant (teoliphant) Assigned to: Guido van Rossum (gvanrossum) Summary: PEP 357 --- adding nb_index Initial Comment: See PEP 357 for details. ---------------------------------------------------------------------- >Comment By: Martin v. L??wis (loewis) Date: 2006-03-06 02:50 Message: Logged In: YES user_id=21627 In Objects/classobject.c, instance_index should be cast to lenfunc, not inquiry. Otherwise, it looks fine. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2006-03-03 18:45 Message: Logged In: YES user_id=33168 The doc needs \versionadded tags. I can add those after checkin. Should sequences in Modules/ be upgraded too? mmap, array, various db modules, bufferobject, rangeobject. Travis already mentioned the TP_FLAGS_HAVE_INDEX check in ceval.c. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2006-03-03 18:45 Message: Logged In: YES user_id=6380 Totally right. I have one more concern: >>> import sys >>> (sys.maxint+1).__index__() Traceback (most recent call last): File "", line 1, in OverflowError: long int too large to convert to int >>> whiile I agree that the C API ought to silently truncate values to fit within the boundaries established by ssize_t, I think that when calling __index__() from Python, it should be allowed to return an unbounded value. Anyway, I haven't had time to whip up code to implement that, but here's a new patch that adds the test to ISINDEX() -- thanks for catching that! ---------------------------------------------------------------------- Comment By: Travis Oliphant (teoliphant) Date: 2006-03-03 18:08 Message: Logged In: YES user_id=5296 I think there is still a need for a HASINDEX check in the ISINDEX definition in ceval.c ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2006-03-03 06:12 Message: Logged In: YES user_id=6380 OK, Travis, here's a new patch. It corrects the issues I mentioned before, and does some whitespace cleanup (like what Neal mentioned). The biggest change is definitely the check for Py_TPFLAGS_HAVE_INDEX whenever the nb_index slot is referenced. You don't have to do anything; but if you do have more changes, please throw away your old changes, sync to the head, and apply my patch, before doing any more work. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2006-03-03 05:32 Message: Logged In: YES user_id=6380 Travis -- I'm working on a new patch. Please don't work on one at the same time for the new few hours! (Until midnight PST.) ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2006-03-03 02:16 Message: Logged In: YES user_id=6380 I promise I'll review this further tomorrow! Feedback so far: - compilation error with svn HEAD on abstract.c:650 - all the uses of the nb_index slot must check for some Py_TPFLAGS_... bit before using that slot (see object.h) - the comment in ceval.c about the clipping of values < -PY_SSIZE_T_MAX is incorrect; they are boosted to -PY_SSIZE_T_MAX, not to zero ---------------------------------------------------------------------- Comment By: Travis Oliphant (teoliphant) Date: 2006-02-22 18:52 Message: Logged In: YES user_id=5296 I followed Neal's comments and updated a new patch. The new patch contains the tests and the documentation updates as well. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2006-02-22 09:03 Message: Logged In: YES user_id=33168 I see one problem in Modules/operator.c. This code: + if (i==-1 && PyErr_Occurred()) return NULL; + else return PyInt_FromLong((long)i); Should be: + if (i == -1 && PyErr_Occurred()) + return NULL; + return PyInt_FromSsizeT(i); There was a discussion on python-checkins recently about this. The short answer is that if Py_ssize_t's are cast to a long, that will lose precision on Win64 (size_ts are 64-bits, but longs are still 32). Since i is Py_ssize_t, the cast would lose the high order values (above 2G). In Objects/stringobject.c: - i += PyString_GET_SIZE(self); - return string_item(self,i); + i += PyList_GET_SIZE(self); + return string_item(self, i); I don't see how that (PyList) can be correct, self is a string object. I would change this code: + lenfunc func; + PyNumberMethods *nb; + if ((nb=item->ob_type->tp_as_number) && \ + (func=nb->nb_index)) { + Py_ssize_t i = func(item); to: + PyNumberMethods *nb = item->ob_type->tp_as_number; + if (nb != NULL && nb->nb_index != NULL) { + Py_ssize_t i = nb->nb_index(item); Let the compiler do the work. We can optimize later if this is a problem. I think the code is clearer this way and is more similar to the rest of the code. I don't care as much about the use of func here as the change to nb = ... If you want to keep the local variable, I would prefer a better name like nb_index instead of func. There's no need for a \ after &&. Most of these comments apply to Objects/listobject.c, Objects/tupleobject.c, Objects/unicodeobject.c, PyNumber_Index. In Objects/classobject.c, you don't check that indexstr is non-NULL after assignment. In instance_index(), remove the cast (int) of the return result outcome. In slot_nb_index() remove . from end of exception string. Note: you don't need the Py_DECREF() and return -1 in the last if as it would be the same if it fell through. Use whichever version you think is clearer. Either way is fine with me. In Include/abstract.h, do all the comments still say a C integer is returned even though a Py_ssize_t is returned? If not, can you update your comment too. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2006-02-22 08:33 Message: Logged In: YES user_id=33168 Travis, I briefly looked over the patches and have a few comments. It's easier if there's one big patch that contains all the code, tests, and doc. I noticed a second patch that contains the tests, but I didn't see any doc updates. I noticed some formatting which is not consistent with the style of the surrounding code (I think). Stuff like n=var->field (no spaces) and if (XXX) dosomething(); else return 5; Most places in the python code check for == NULL rather than the implicit check for 0. Most places in code don't do assignment in if (cond), though this last one is more variable. I'll try to look this over in more detail soon. But it probably won't be until PyCon. If you're there, maybe we can discuss in person. Also, if you have further PEP updates, feel free to send them to me and I can check them in. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1436368&group_id=5470 From noreply at sourceforge.net Mon Mar 6 05:09:37 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 05 Mar 2006 20:09:37 -0800 Subject: [Patches] [ python-Patches-1443865 ] gc.get_count() and other changes Message-ID: Patches item #1443865, was opened at 2006-03-05 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=1443865&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Core (C code) Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: Barry A. Warsaw (bwarsaw) Assigned to: Skip Montanaro (montanaro) Summary: gc.get_count() and other changes Initial Comment: This patch adds gc.get_count() as a companion to gc.get_threshold(). It also adds an optional argument to gc.collect() to allow you to specify the generation to collect. This patch also fixes a couple of gcc warnings. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1443865&group_id=5470 From noreply at sourceforge.net Mon Mar 6 05:26:46 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 05 Mar 2006 20:26:46 -0800 Subject: [Patches] [ python-Patches-1100294 ] Log gc times when DEBUG_STATS set Message-ID: Patches item #1100294, was opened at 2005-01-11 12:11 Message generated for change (Comment added) made by bwarsaw You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1100294&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Library (Lib) Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: Skip Montanaro (montanaro) Assigned to: Barry A. Warsaw (bwarsaw) Summary: Log gc times when DEBUG_STATS set Initial Comment: The attached patch adds collection time to the information the garbage collector prints when DEBUG_STATS is enabled. I was more-or-less challenged at work to show that garbage collection wouldn't cripple our long-running, high-performance servers at crucial times. This seemed the best way to demonstrate that it didn't present a problem. ---------------------------------------------------------------------- >Comment By: Barry A. Warsaw (bwarsaw) Date: 2006-03-05 23:26 Message: Logged In: YES user_id=12800 Looks pretty good. I wonder if you should call PyErr_Clear() when the import or call fails? Other than that, +1 ---------------------------------------------------------------------- Comment By: Skip Montanaro (montanaro) Date: 2006-02-23 21:22 Message: Logged In: YES user_id=44345 Must not have had the box checked. Thank goodness I almost never delete files in ~/tmp/... Skip ---------------------------------------------------------------------- Comment By: Barry A. Warsaw (bwarsaw) Date: 2006-02-23 12:01 Message: Logged In: YES user_id=12800 There's no patch here; are you sure you checked the checkbox? I'm actually putzing around in gcmodule.c atm to address some related issues and I'd be willing to review this patch if you attach it again. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1100294&group_id=5470 From noreply at sourceforge.net Mon Mar 6 05:41:31 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 05 Mar 2006 20:41:31 -0800 Subject: [Patches] [ python-Patches-1443875 ] email/charset.py convert() patch Message-ID: Patches item #1443875, was opened at 2006-03-06 04:41 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1443875&group_id=5470 Please note that this 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: Tokio Kikuchi (tkikuchi) Assigned to: Nobody/Anonymous (nobody) Summary: email/charset.py convert() patch Initial Comment: email/charset.py has convert() function to incorporate using different charset for input and output for a language like Japanese. Because the email user agent in Japan frequently use characters outside the range of legitimate JIS charset, these messages are shunted in mailman delivery. Here is a patch to handle this case by replacing the characters by '?' using the 'errors' parameter in unicode/encode functions. This patch includes the unicode string conversion patch in #1368247. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1443875&group_id=5470 From noreply at sourceforge.net Mon Mar 6 05:43:27 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 05 Mar 2006 20:43:27 -0800 Subject: [Patches] [ python-Patches-1443875 ] email/charset.py convert() patch Message-ID: Patches item #1443875, was opened at 2006-03-06 04:41 Message generated for change (Settings changed) made by tkikuchi You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1443875&group_id=5470 Please note that this 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: Tokio Kikuchi (tkikuchi) >Assigned to: Barry A. Warsaw (bwarsaw) Summary: email/charset.py convert() patch Initial Comment: email/charset.py has convert() function to incorporate using different charset for input and output for a language like Japanese. Because the email user agent in Japan frequently use characters outside the range of legitimate JIS charset, these messages are shunted in mailman delivery. Here is a patch to handle this case by replacing the characters by '?' using the 'errors' parameter in unicode/encode functions. This patch includes the unicode string conversion patch in #1368247. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1443875&group_id=5470 From noreply at sourceforge.net Mon Mar 6 11:27:10 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 06 Mar 2006 02:27:10 -0800 Subject: [Patches] [ python-Patches-1436368 ] PEP 357 --- adding nb_index Message-ID: Patches item #1436368, was opened at 2006-02-21 20:35 Message generated for change (Comment added) made by teoliphant You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1436368&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Core (C code) Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: Travis Oliphant (teoliphant) Assigned to: Guido van Rossum (gvanrossum) Summary: PEP 357 --- adding nb_index Initial Comment: See PEP 357 for details. ---------------------------------------------------------------------- >Comment By: Travis Oliphant (teoliphant) Date: 2006-03-06 03:27 Message: Logged In: YES user_id=5296 Here's a new patch that does not raise overflow error for (sys.maxint+1).__index__ This patch also cleans up the apply_slice code so to exhibit the same behavior because it uses the same code. This has one minor difference in that -PY_SSIZE_T_MAX-1 (isn't this correct?) is used instead of -PY_SSIZE_T_MAX when clipping negative numbers. Also, versionadded tags were created and applied, and the arraymodule was updated to use __index__ for slicing. ---------------------------------------------------------------------- Comment By: Martin v. L??wis (loewis) Date: 2006-03-05 18:50 Message: Logged In: YES user_id=21627 In Objects/classobject.c, instance_index should be cast to lenfunc, not inquiry. Otherwise, it looks fine. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2006-03-03 10:45 Message: Logged In: YES user_id=33168 The doc needs \versionadded tags. I can add those after checkin. Should sequences in Modules/ be upgraded too? mmap, array, various db modules, bufferobject, rangeobject. Travis already mentioned the TP_FLAGS_HAVE_INDEX check in ceval.c. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2006-03-03 10:45 Message: Logged In: YES user_id=6380 Totally right. I have one more concern: >>> import sys >>> (sys.maxint+1).__index__() Traceback (most recent call last): File "", line 1, in OverflowError: long int too large to convert to int >>> whiile I agree that the C API ought to silently truncate values to fit within the boundaries established by ssize_t, I think that when calling __index__() from Python, it should be allowed to return an unbounded value. Anyway, I haven't had time to whip up code to implement that, but here's a new patch that adds the test to ISINDEX() -- thanks for catching that! ---------------------------------------------------------------------- Comment By: Travis Oliphant (teoliphant) Date: 2006-03-03 10:08 Message: Logged In: YES user_id=5296 I think there is still a need for a HASINDEX check in the ISINDEX definition in ceval.c ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2006-03-02 22:12 Message: Logged In: YES user_id=6380 OK, Travis, here's a new patch. It corrects the issues I mentioned before, and does some whitespace cleanup (like what Neal mentioned). The biggest change is definitely the check for Py_TPFLAGS_HAVE_INDEX whenever the nb_index slot is referenced. You don't have to do anything; but if you do have more changes, please throw away your old changes, sync to the head, and apply my patch, before doing any more work. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2006-03-02 21:32 Message: Logged In: YES user_id=6380 Travis -- I'm working on a new patch. Please don't work on one at the same time for the new few hours! (Until midnight PST.) ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2006-03-02 18:16 Message: Logged In: YES user_id=6380 I promise I'll review this further tomorrow! Feedback so far: - compilation error with svn HEAD on abstract.c:650 - all the uses of the nb_index slot must check for some Py_TPFLAGS_... bit before using that slot (see object.h) - the comment in ceval.c about the clipping of values < -PY_SSIZE_T_MAX is incorrect; they are boosted to -PY_SSIZE_T_MAX, not to zero ---------------------------------------------------------------------- Comment By: Travis Oliphant (teoliphant) Date: 2006-02-22 10:52 Message: Logged In: YES user_id=5296 I followed Neal's comments and updated a new patch. The new patch contains the tests and the documentation updates as well. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2006-02-22 01:03 Message: Logged In: YES user_id=33168 I see one problem in Modules/operator.c. This code: + if (i==-1 && PyErr_Occurred()) return NULL; + else return PyInt_FromLong((long)i); Should be: + if (i == -1 && PyErr_Occurred()) + return NULL; + return PyInt_FromSsizeT(i); There was a discussion on python-checkins recently about this. The short answer is that if Py_ssize_t's are cast to a long, that will lose precision on Win64 (size_ts are 64-bits, but longs are still 32). Since i is Py_ssize_t, the cast would lose the high order values (above 2G). In Objects/stringobject.c: - i += PyString_GET_SIZE(self); - return string_item(self,i); + i += PyList_GET_SIZE(self); + return string_item(self, i); I don't see how that (PyList) can be correct, self is a string object. I would change this code: + lenfunc func; + PyNumberMethods *nb; + if ((nb=item->ob_type->tp_as_number) && \ + (func=nb->nb_index)) { + Py_ssize_t i = func(item); to: + PyNumberMethods *nb = item->ob_type->tp_as_number; + if (nb != NULL && nb->nb_index != NULL) { + Py_ssize_t i = nb->nb_index(item); Let the compiler do the work. We can optimize later if this is a problem. I think the code is clearer this way and is more similar to the rest of the code. I don't care as much about the use of func here as the change to nb = ... If you want to keep the local variable, I would prefer a better name like nb_index instead of func. There's no need for a \ after &&. Most of these comments apply to Objects/listobject.c, Objects/tupleobject.c, Objects/unicodeobject.c, PyNumber_Index. In Objects/classobject.c, you don't check that indexstr is non-NULL after assignment. In instance_index(), remove the cast (int) of the return result outcome. In slot_nb_index() remove . from end of exception string. Note: you don't need the Py_DECREF() and return -1 in the last if as it would be the same if it fell through. Use whichever version you think is clearer. Either way is fine with me. In Include/abstract.h, do all the comments still say a C integer is returned even though a Py_ssize_t is returned? If not, can you update your comment too. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2006-02-22 00:33 Message: Logged In: YES user_id=33168 Travis, I briefly looked over the patches and have a few comments. It's easier if there's one big patch that contains all the code, tests, and doc. I noticed a second patch that contains the tests, but I didn't see any doc updates. I noticed some formatting which is not consistent with the style of the surrounding code (I think). Stuff like n=var->field (no spaces) and if (XXX) dosomething(); else return 5; Most places in the python code check for == NULL rather than the implicit check for 0. Most places in code don't do assignment in if (cond), though this last one is more variable. I'll try to look this over in more detail soon. But it probably won't be until PyCon. If you're there, maybe we can discuss in person. Also, if you have further PEP updates, feel free to send them to me and I can check them in. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1436368&group_id=5470 From noreply at sourceforge.net Mon Mar 6 11:27:33 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 06 Mar 2006 02:27:33 -0800 Subject: [Patches] [ python-Patches-1436368 ] PEP 357 --- adding nb_index Message-ID: Patches item #1436368, was opened at 2006-02-21 20:35 Message generated for change (Comment added) made by teoliphant You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1436368&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Core (C code) Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: Travis Oliphant (teoliphant) Assigned to: Guido van Rossum (gvanrossum) Summary: PEP 357 --- adding nb_index Initial Comment: See PEP 357 for details. ---------------------------------------------------------------------- >Comment By: Travis Oliphant (teoliphant) Date: 2006-03-06 03:27 Message: Logged In: YES user_id=5296 Here's a new patch that does not raise overflow error for (sys.maxint+1).__index__ This patch also cleans up the apply_slice code so to exhibit the same behavior because it uses the same code. This has one minor difference in that -PY_SSIZE_T_MAX-1 (isn't this correct?) is used instead of -PY_SSIZE_T_MAX when clipping negative numbers. Also, versionadded tags were created and applied, and the arraymodule was updated to use __index__ for slicing. ---------------------------------------------------------------------- Comment By: Travis Oliphant (teoliphant) Date: 2006-03-06 03:27 Message: Logged In: YES user_id=5296 Here's a new patch that does not raise overflow error for (sys.maxint+1).__index__ This patch also cleans up the apply_slice code so to exhibit the same behavior because it uses the same code. This has one minor difference in that -PY_SSIZE_T_MAX-1 (isn't this correct?) is used instead of -PY_SSIZE_T_MAX when clipping negative numbers. Also, versionadded tags were created and applied, and the arraymodule was updated to use __index__ for slicing. ---------------------------------------------------------------------- Comment By: Martin v. L??wis (loewis) Date: 2006-03-05 18:50 Message: Logged In: YES user_id=21627 In Objects/classobject.c, instance_index should be cast to lenfunc, not inquiry. Otherwise, it looks fine. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2006-03-03 10:45 Message: Logged In: YES user_id=33168 The doc needs \versionadded tags. I can add those after checkin. Should sequences in Modules/ be upgraded too? mmap, array, various db modules, bufferobject, rangeobject. Travis already mentioned the TP_FLAGS_HAVE_INDEX check in ceval.c. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2006-03-03 10:45 Message: Logged In: YES user_id=6380 Totally right. I have one more concern: >>> import sys >>> (sys.maxint+1).__index__() Traceback (most recent call last): File "", line 1, in OverflowError: long int too large to convert to int >>> whiile I agree that the C API ought to silently truncate values to fit within the boundaries established by ssize_t, I think that when calling __index__() from Python, it should be allowed to return an unbounded value. Anyway, I haven't had time to whip up code to implement that, but here's a new patch that adds the test to ISINDEX() -- thanks for catching that! ---------------------------------------------------------------------- Comment By: Travis Oliphant (teoliphant) Date: 2006-03-03 10:08 Message: Logged In: YES user_id=5296 I think there is still a need for a HASINDEX check in the ISINDEX definition in ceval.c ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2006-03-02 22:12 Message: Logged In: YES user_id=6380 OK, Travis, here's a new patch. It corrects the issues I mentioned before, and does some whitespace cleanup (like what Neal mentioned). The biggest change is definitely the check for Py_TPFLAGS_HAVE_INDEX whenever the nb_index slot is referenced. You don't have to do anything; but if you do have more changes, please throw away your old changes, sync to the head, and apply my patch, before doing any more work. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2006-03-02 21:32 Message: Logged In: YES user_id=6380 Travis -- I'm working on a new patch. Please don't work on one at the same time for the new few hours! (Until midnight PST.) ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2006-03-02 18:16 Message: Logged In: YES user_id=6380 I promise I'll review this further tomorrow! Feedback so far: - compilation error with svn HEAD on abstract.c:650 - all the uses of the nb_index slot must check for some Py_TPFLAGS_... bit before using that slot (see object.h) - the comment in ceval.c about the clipping of values < -PY_SSIZE_T_MAX is incorrect; they are boosted to -PY_SSIZE_T_MAX, not to zero ---------------------------------------------------------------------- Comment By: Travis Oliphant (teoliphant) Date: 2006-02-22 10:52 Message: Logged In: YES user_id=5296 I followed Neal's comments and updated a new patch. The new patch contains the tests and the documentation updates as well. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2006-02-22 01:03 Message: Logged In: YES user_id=33168 I see one problem in Modules/operator.c. This code: + if (i==-1 && PyErr_Occurred()) return NULL; + else return PyInt_FromLong((long)i); Should be: + if (i == -1 && PyErr_Occurred()) + return NULL; + return PyInt_FromSsizeT(i); There was a discussion on python-checkins recently about this. The short answer is that if Py_ssize_t's are cast to a long, that will lose precision on Win64 (size_ts are 64-bits, but longs are still 32). Since i is Py_ssize_t, the cast would lose the high order values (above 2G). In Objects/stringobject.c: - i += PyString_GET_SIZE(self); - return string_item(self,i); + i += PyList_GET_SIZE(self); + return string_item(self, i); I don't see how that (PyList) can be correct, self is a string object. I would change this code: + lenfunc func; + PyNumberMethods *nb; + if ((nb=item->ob_type->tp_as_number) && \ + (func=nb->nb_index)) { + Py_ssize_t i = func(item); to: + PyNumberMethods *nb = item->ob_type->tp_as_number; + if (nb != NULL && nb->nb_index != NULL) { + Py_ssize_t i = nb->nb_index(item); Let the compiler do the work. We can optimize later if this is a problem. I think the code is clearer this way and is more similar to the rest of the code. I don't care as much about the use of func here as the change to nb = ... If you want to keep the local variable, I would prefer a better name like nb_index instead of func. There's no need for a \ after &&. Most of these comments apply to Objects/listobject.c, Objects/tupleobject.c, Objects/unicodeobject.c, PyNumber_Index. In Objects/classobject.c, you don't check that indexstr is non-NULL after assignment. In instance_index(), remove the cast (int) of the return result outcome. In slot_nb_index() remove . from end of exception string. Note: you don't need the Py_DECREF() and return -1 in the last if as it would be the same if it fell through. Use whichever version you think is clearer. Either way is fine with me. In Include/abstract.h, do all the comments still say a C integer is returned even though a Py_ssize_t is returned? If not, can you update your comment too. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2006-02-22 00:33 Message: Logged In: YES user_id=33168 Travis, I briefly looked over the patches and have a few comments. It's easier if there's one big patch that contains all the code, tests, and doc. I noticed a second patch that contains the tests, but I didn't see any doc updates. I noticed some formatting which is not consistent with the style of the surrounding code (I think). Stuff like n=var->field (no spaces) and if (XXX) dosomething(); else return 5; Most places in the python code check for == NULL rather than the implicit check for 0. Most places in code don't do assignment in if (cond), though this last one is more variable. I'll try to look this over in more detail soon. But it probably won't be until PyCon. If you're there, maybe we can discuss in person. Also, if you have further PEP updates, feel free to send them to me and I can check them in. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1436368&group_id=5470 From noreply at sourceforge.net Mon Mar 6 12:03:30 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 06 Mar 2006 03:03:30 -0800 Subject: [Patches] [ python-Patches-1444030 ] Various minor fixes for NULL checks, etc. Message-ID: Patches item #1444030, was opened at 2006-03-06 20: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=1444030&group_id=5470 Please note that this 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: Hye-Shik Chang (perky) Assigned to: Nobody/Anonymous (nobody) Summary: Various minor fixes for NULL checks, etc. Initial Comment: Attached patch includes fixes for missing NULL checks, reference leaks on minor cases found by a static analysis tool. It touches: Python/ceval.c Python/traceback.c Python/ast.c Python/modsupport.c Objects/object.c Objects/weakrefobject.c Objects/unicodeobject.c Objects/longobject.c Objects/stringobject.c Parser/firstsets.c Modules/arraymodule.c Modules/zipimport.c Modules/cStringIO.c ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1444030&group_id=5470 From noreply at sourceforge.net Mon Mar 6 12:05:58 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 06 Mar 2006 03:05:58 -0800 Subject: [Patches] [ python-Patches-1444030 ] Several minor fixes for NULL checks, etc. Message-ID: Patches item #1444030, was opened at 2006-03-06 20:03 Message generated for change (Settings changed) made by perky You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1444030&group_id=5470 Please note that this 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: 4 Submitted By: Hye-Shik Chang (perky) Assigned to: Nobody/Anonymous (nobody) >Summary: Several minor fixes for NULL checks, etc. Initial Comment: Attached patch includes fixes for missing NULL checks, reference leaks on minor cases found by a static analysis tool. It touches: Python/ceval.c Python/traceback.c Python/ast.c Python/modsupport.c Objects/object.c Objects/weakrefobject.c Objects/unicodeobject.c Objects/longobject.c Objects/stringobject.c Parser/firstsets.c Modules/arraymodule.c Modules/zipimport.c Modules/cStringIO.c ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1444030&group_id=5470 From noreply at sourceforge.net Mon Mar 6 16:12:27 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 06 Mar 2006 07:12:27 -0800 Subject: [Patches] [ python-Patches-1006238 ] cross compile patch Message-ID: Patches item #1006238, was opened at 2004-08-09 17:05 Message generated for change (Comment added) made by goertzen You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1006238&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Build Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Daniel Goertzen (goertzen) Assigned to: Nobody/Anonymous (nobody) Summary: cross compile patch Initial Comment: Here's a cross compile patch I prepared a while ago but never got around to submitting. I've been using it happily for months to cross compile python for embedded systems. Below is a descriptive excerpt from the patch. Also note that the patch modifies configure.in, but not configure. You will need to regenerate configure with something like autoconf configure.in >configure This patch is inpsired from work by Klaus Reimer at http://www.ailis.de/~k/docs/crosscompiling/python.php + Cross Compiling + --------------- + + Python can be cross compiled by supplying different --host and --build + parameters to configure. (Python is compiled on the "build" system + and executed on the "host" system, in case you forgot :). Python is + tricky to cross compile because it needs to execute parts of itself + during construction. To work around this, make's VPATH feature is + used to compile a native python in the subdirectory "buildpython". + When parts of python need to be executed during construction, the + "buildpython" versions are used. + + A consequence of using the VPATH feature is that you may not do a + cross compile build in the source directory. In other words, do this: + + mkdir mydir + cd mydir + ../Python/configure --host=powerpc-405-linux-gnu --build=i686-pc-linux-gnu + make + + Cross compiling works well under linux, mileage may vary for other + platforms. + + A few reminders on using configure to cross compile: + - Cross compile tools must be in the PATH. + - Cross compile tools must be prefixed with the host type + (ie powerpc-405-linux-gnu-cc, powerpc-405-linux-gnu-ranlib, ...) + - CC, CXX, AR, and RANLIB must be undefined when running configure and + make. Configure will detect them. + + If you need a cross compiler, check out Dan Kegel's crosstool: + http://www.kegel.com/crosstool + + ---------------------------------------------------------------------- >Comment By: Daniel Goertzen (goertzen) Date: 2006-03-06 09:12 Message: Logged In: YES user_id=843814 Hi hugo. The problems you are having are less python related and more system-building/cross-development issues, and this is the wrong forum for hashing out this stuff out. I recommend building a linux-from-scratch system (http://www.linuxfromscratch.org/) on an ordinary PC to learn how the insides of linux machine works and how to fix things when they go wrong. Good luck, Dan. ---------------------------------------------------------------------- Comment By: hugo (hugo_koopmans) Date: 2006-03-04 14:02 Message: Logged In: YES user_id=1229536 Hi there, I am trying to cross compile python on the fox board (etrax). now everything seemed to go well but when running the python binary is says: ./python: error while loading shared libraries: libstdc++.so.5: cannot load shared object file: No such file or directory I only ftp-ed the python bin not the (much bigger) libpython2.4a .... seems this is a library archive of some kind ? do i need it? how do i use it then? thanx a million if you can help me out. hugo ---------------------------------------------------------------------- Comment By: Daniel Goertzen (goertzen) Date: 2006-02-24 16:32 Message: Logged In: YES user_id=843814 You didn't apply the patch properly. See the other messages about the use of the -p option. Start with a fresh source tree and use: cd Python-2.4.2 patch -p3 <../python-patch.txt ---------------------------------------------------------------------- Comment By: Nicolas (nico0438) Date: 2006-02-24 15:37 Message: Logged In: YES user_id=1330285 If I try to aplly the patch again, I get messages saying a patch has allready been applied. To apply the patch I executed the following : cd Python-2.4.2 patch <../python-patch.txt ---------------------------------------------------------------------- Comment By: Daniel Goertzen (goertzen) Date: 2006-02-24 15:30 Message: Logged In: YES user_id=843814 The build system python should be in "MyPython/buildpython", and the host python should just be in "MyPython" Are you sure you applied the patch right? What you're getting is what would happen if you didn't apply the patch at all. ---------------------------------------------------------------------- Comment By: Nicolas (nico0438) Date: 2006-02-24 15:19 Message: Logged In: YES user_id=1330285 Yes I guess. But it seems that all I get is for the build system. If I try to execute on the build system ./python it runs. Also, there is no hostbuild subdirectory. Is it ok ? Nicolas ---------------------------------------------------------------------- Comment By: Daniel Goertzen (goertzen) Date: 2006-02-24 15:14 Message: Logged In: YES user_id=843814 > I then cd to a "MyPython" directory. > I call ../Python-2.4.2/configure ... Then your files should be in your "MyPython" directory. ---------------------------------------------------------------------- Comment By: Nicolas (nico0438) Date: 2006-02-24 14:54 Message: Logged In: YES user_id=1330285 Me again, sorry... What Should I get after compilation has finished ? Where are the files for my target ? Nicolas ---------------------------------------------------------------------- Comment By: Nicolas (nico0438) Date: 2006-02-24 13:55 Message: Logged In: YES user_id=1330285 Hi again, I finaly dad enought time to work on my project. So, I compiled autoconf tools for my system. Then, I rerun all the steps successfully. Thanks again for your help. Nicolas ---------------------------------------------------------------------- Comment By: nicolas pinault (nico38) Date: 2006-02-24 09:12 Message: Logged In: YES user_id=1081828 You are right, I have misunderstood --build and --host signification. And I also forgotten to run autoconf partialy because I don't have autoconf installed on my system. So I didn't pay attention it didn't run. Thanks for your help. I'll let you know if this works in a few days. Nicolas ---------------------------------------------------------------------- Comment By: Daniel Goertzen (goertzen) Date: 2006-02-24 08:51 Message: Logged In: YES user_id=843814 Did you run autoconf after patching as instructed? Also, your --build and --host options seem backwards. host is the arch you want python to run on, build is the arch you build python on. Cheers, Dan. ---------------------------------------------------------------------- Comment By: nicolas pinault (nico38) Date: 2006-02-24 06:38 Message: Logged In: YES user_id=1081828 Hi, I try to cross compile Python-2.4.2 for an etrax processor. I have successfully applied the patch to Python sources. I then cd to a "MyPython" directory. I call ../Python-2.4.2/configure --build cris --host i386-linux It works ok (did not see an error) I all make I get the following error after a while : make : *** No rule to make target '@BUILDPGEN@', needed by '../Python-2.4.2/Include/graminit.h'. Stop. Any Idea ? Nicolas ---------------------------------------------------------------------- Comment By: xudong (xudong888) Date: 2006-01-10 08:45 Message: Logged In: YES user_id=1420135 I have resolved my question,now I can run python on the mips machine,and can run some binary build by python.Can I also cross compile pygame for python?But the pygame source does't has 'configure' and 'Makefiel' files,setup.py instead in source package.How should I do? Thanks :-) ---------------------------------------------------------------------- Comment By: xudong (xudong888) Date: 2006-01-06 05:08 Message: Logged In: YES user_id=1420135 If you have accounts of MSN,please add me.My accounts is xudong_888 at hotmail.com. I am very impatient.I hope I can get some help from you.Thanks. ---------------------------------------------------------------------- Comment By: xudong (xudong888) Date: 2006-01-06 04:57 Message: Logged In: YES user_id=1420135 Thank you for your rapid answer.But I still can't solve my question.I can't find the whole instructions. Can you give me the whole instructions by EMAIL,my email is xudong888 at 163.com,thanks. My "host" system is mips embbed_linux,the release of the linux kernel is 2.4.xx and the CPU type is MIPS 4Kc.There are no python installed on this system.My "build" system is i86 and operate system is RedHat9.0,and has installed python2.4.1 and cross-compiling Tools mipsel-linux-gcc.I can cross compile C program for the "host" system.I have writed some program with python language.I can get the binary from python script by use freeze.py on the "build" system. Now I want to run the binary on the "host" system.Can you tell me how should I do. in addition,I don't know what parameter I should input to use this patch. finally,I'm sorry for my poor English.I like python very much,but I can't get help in chinese. ---------------------------------------------------------------------- Comment By: Daniel Goertzen (goertzen) Date: 2006-01-05 11:24 Message: Logged In: YES user_id=843814 After configure you run "make". But did you use configure as the instructions say? You cannot just use "./configure". Good luck, Dan. ---------------------------------------------------------------------- Comment By: xudong (xudong888) Date: 2006-01-05 10:55 Message: Logged In: YES user_id=1420135 I am a Chinese and my English is very poor.I'm sorry if what I said is wrong.My question is What should I do after './configure'.Before this I have done patch and autoconf. Thanks :-) ---------------------------------------------------------------------- Comment By: David Lambert (jdalambert) Date: 2005-11-08 10:06 Message: Logged In: YES user_id=845425 Oops! All works fine now. Thanks :-) ---------------------------------------------------------------------- Comment By: Daniel Goertzen (goertzen) Date: 2005-11-08 09:09 Message: Logged In: YES user_id=843814 patch isn't lying about wrong -p options. Use -p3 instead of -p0. Cheers, Dan. ---------------------------------------------------------------------- Comment By: David Lambert (jdalambert) Date: 2005-11-08 08:26 Message: Logged In: YES user_id=845425 Thanks for the quick reply, and sorry for the confusion. I DID try the cross compile in a sub directory. That failed with the same error. I then tried a non-cross build in the main directory, that also failed (which was my previous post). Here is my complete transcript after untarring Python: [dlambert at lambsys Python-2.4.2]$ patch -p0 < ../python-patch can't find file to patch at input line 3 Perhaps you used the wrong -p or --strip option? The text leading up to this was: -------------------------- |*** python-cvs-pristine/dist/src/README Fri Mar 5 08:33:21 2004 |--- python/dist/src/README Mon Apr 5 14:30:23 2004 -------------------------- File to patch: README patching file README Hunk #1 succeeded at 1130 (offset 30 lines). can't find file to patch at input line 48 Perhaps you used the wrong -p or --strip option? The text leading up to this was: -------------------------- |*** python-cvs-pristine/dist/src/configure.in Sun Mar 21 17:45:41 2004 |--- python/dist/src/configure.in Mon Apr 5 16:15:07 2004 -------------------------- File to patch: configure.in patching file configure.in Hunk #2 succeeded at 609 (offset 58 lines). Hunk #3 succeeded at 3072 (offset 112 lines). can't find file to patch at input line 113 Perhaps you used the wrong -p or --strip option? The text leading up to this was: -------------------------- |*** python-cvs-pristine/dist/src/Makefile.pre.in Thu Mar 18 01:51:27 2004 |--- python/dist/src/Makefile.pre.in Mon Apr 5 15:56:00 2004 -------------------------- File to patch: Makefile.pre.in patching file Makefile.pre.in Hunk #2 succeeded at 163 (offset 3 lines). Hunk #4 succeeded at 309 (offset 5 lines). Hunk #6 succeeded at 470 (offset 5 lines). Hunk #7 succeeded at 624 (offset 1 line). Hunk #8 succeeded at 839 (offset 7 lines). Hunk #9 succeeded at 923 (offset 1 line). Hunk #10 succeeded at 969 (offset 7 lines). can't find file to patch at input line 309 Perhaps you used the wrong -p or --strip option? The text leading up to this was: -------------------------- |*** python-cvs-pristine/dist/src/setup.py Sun Mar 21 12:59:46 2004 |--- python/dist/src/setup.py Mon Apr 5 15:20:55 2004 -------------------------- File to patch: setup.py patching file setup.py Hunk #1 succeeded at 198 (offset -2 lines). patching file python/dist/src/config.guess patching file python/dist/src/config.sub [dlambert at lambsys Python-2.4.2]$ [dlambert at lambsys Python-2.4.2]$ [dlambert at lambsys Python-2.4.2]$ autoconf configure.in > configure [dlambert at lambsys Python-2.4.2]$ mkdir cross-build [dlambert at lambsys Python-2.4.2]$ cd cross-build [dlambert at lambsys cross-build]$ ../configure --host=arm-linux --build=i686-pc-li nux-gnu configure: error: cannot run /bin/sh ../config.sub [dlambert at lambsys cross-build]$ ---------------------------------------------------------------------- Comment By: Daniel Goertzen (goertzen) Date: 2005-11-08 08:05 Message: Logged In: YES user_id=843814 You can't configure in the source directory with the cross compile patch. This is explained in the directions. ---------------------------------------------------------------------- Comment By: David Lambert (jdalambert) Date: 2005-11-07 20:12 Message: Logged In: YES user_id=845425 Hmm. not so much luck here. I get the following error after patching then autoconf. I am running on Fedora Core 4. Any suggestions? [dlambert at lambsys Python-2.4.2]$ autoconf configure.in >configure [dlambert at lambsys Python-2.4.2]$ ./configure configure: error: cannot run /bin/sh ./config.sub [dlambert at lambsys Python-2.4.2]$ ---------------------------------------------------------------------- Comment By: Robsa (robsa) Date: 2005-10-13 06:54 Message: Logged In: YES user_id=1277505 Just thought I'd let you know that this patch works against Python 2.4.2. I had Python running on my custom AT91RM9200 board (ARM920T core) in about 20 minutes. *snaps* for Daniel!! ---------------------------------------------------------------------- Comment By: Daniel Goertzen (goertzen) Date: 2005-04-13 12:36 Message: Logged In: YES user_id=843814 It still works for me, so I've had limited interest in working on it further. I think a "real" cross compile patch will involve significant refactoring of distutils and the main setup.py script. Should this start with a PEP? ---------------------------------------------------------------------- Comment By: Ned Ludd (solarx) Date: 2005-04-09 15:43 Message: Logged In: YES user_id=148412 Any progress with this on? python and perl are two of the last major things to overcome in the x-compile world. ---------------------------------------------------------------------- Comment By: Mike Frysinger (vapier) Date: 2004-10-26 11:00 Message: Logged In: YES user_id=114429 we've been using this with uClibc for a while now and it works great ... ive personally built (on amd64) & deployed (on x86/ppc/arm/mips/sh4) python ... would great if this finally made it into the official sources :) ---------------------------------------------------------------------- Comment By: Jeff Epler (jepler) Date: 2004-10-20 20:08 Message: Logged In: YES user_id=2772 This patch applies cleanly to today's CVS head. If building in the source directory while cross compiling fails, please make configure complain about it. This patch makes the build process invoke make recursively, which is a big minus. I'd rather see pgen built with a HOSTCC and just assume python is available on $PATH for the setup.py step. There's no reason to build all the shared modules in buildpython, either, which would speed things up a fair bit. On to how it worked for me: Not cross-compiling, this produces no unexpected test failures in "make test". (redhat9) Cross compiling for i386-pc-bsdi2.1 everything goes fine until it tries to run buildpython and make shared modules, but shared modules don't work in the first place on bsdi2. I did not test the resulting Python binary. Cross compiling for i386-redhat-linux (libc6) some extensions fail to build, but this could be because my header files for the cross-development environment are not complete. Running "make test" tries to invoke the "buildpython/python" and doesn't work. Running it manually I get some skips due to modules that did not build, but everything that did build seems to pass. (OK, so I wrote this before the tests completed, but they're off to a good start) I currently cross-compile python 2.3 for win32 (mingw), and until recently cross-compiled it for bsdi2 and redhat6. However, I did not use configure or the included makefiles to do this (in order to integrate in a non-recursive build procedure that builds several packages), so this patch is unlikely to benefit me directly. I don't think this patch is ready to be applied. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1006238&group_id=5470 From noreply at sourceforge.net Mon Mar 6 17:35:11 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 06 Mar 2006 08:35:11 -0800 Subject: [Patches] [ python-Patches-1437769 ] Size of time_t changed to 64 bits in MSVC++ 2005 CRT Message-ID: Patches item #1437769, was opened at 2006-02-24 00:18 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1437769&group_id=5470 Please note that this 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: 5 Submitted By: Atul Varma (varmaa) Assigned to: Nobody/Anonymous (nobody) Summary: Size of time_t changed to 64 bits in MSVC++ 2005 CRT Initial Comment: As of Visual C++ 2005, the size of the time_t data type was changed from 32 bits to 64 bits. Among other things, this breaks the C API test in the Python "test" package, because Python thinks that time_t should be 32 bits large. Altering PC/pyconfig.h by conditionally defining SIZEOF_TIME_T depending on whether at least MSVC++ 2005 is being used for compilation fixes this. Attached is a very simple unified diff patch for PC/pyconfig.h, taken from revision 42382 (the most recent revision at the time of this submission). More information about this and other recent changes to the MS CRT for Visual C++ 2005 can be found here: http://msdn2.microsoft.com/en-us/library/ms235429.aspx ---------------------------------------------------------------------- >Comment By: Martin v. L??wis (loewis) Date: 2006-03-06 17:35 Message: Logged In: YES user_id=21627 Thanks for the patch. Committed in revision 42870. Looking at the "breaking changes" list, I see nothing else that would need attention. ---------------------------------------------------------------------- Comment By: Terry J. Reedy (tjreedy) Date: 2006-03-06 02:10 Message: Logged In: YES user_id=593130 The page specifically says "The default size for time_t is now 64 bits..." The page on breaking changes http://msdn2.microsoft.com/en-us/library/ms235497.aspx says "time_t is now a 64-bit value (unless _USE_32BIT_TIME_T is defined)." so it would appear that there is a possible alternative fix. My understanding of recent discussions is that the developers are not planning to upgrade their VC version at this time. Unless this is the only change needed, I would not be surprised if a more complete patch would be wanted at one time. Maybe someone else will say more. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1437769&group_id=5470 From noreply at sourceforge.net Mon Mar 6 19:27:48 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 06 Mar 2006 10:27:48 -0800 Subject: [Patches] [ python-Patches-1436368 ] PEP 357 --- adding nb_index Message-ID: Patches item #1436368, was opened at 2006-02-21 20:35 Message generated for change (Comment added) made by teoliphant You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1436368&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Core (C code) Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: Travis Oliphant (teoliphant) Assigned to: Guido van Rossum (gvanrossum) Summary: PEP 357 --- adding nb_index Initial Comment: See PEP 357 for details. ---------------------------------------------------------------------- >Comment By: Travis Oliphant (teoliphant) Date: 2006-03-06 11:27 Message: Logged In: YES user_id=5296 This patch does not contain the bug in mmap that the last one did. All regression tests for Linux pass. ---------------------------------------------------------------------- Comment By: Travis Oliphant (teoliphant) Date: 2006-03-06 03:27 Message: Logged In: YES user_id=5296 Here's a new patch that does not raise overflow error for (sys.maxint+1).__index__ This patch also cleans up the apply_slice code so to exhibit the same behavior because it uses the same code. This has one minor difference in that -PY_SSIZE_T_MAX-1 (isn't this correct?) is used instead of -PY_SSIZE_T_MAX when clipping negative numbers. Also, versionadded tags were created and applied, and the arraymodule was updated to use __index__ for slicing. ---------------------------------------------------------------------- Comment By: Travis Oliphant (teoliphant) Date: 2006-03-06 03:27 Message: Logged In: YES user_id=5296 Here's a new patch that does not raise overflow error for (sys.maxint+1).__index__ This patch also cleans up the apply_slice code so to exhibit the same behavior because it uses the same code. This has one minor difference in that -PY_SSIZE_T_MAX-1 (isn't this correct?) is used instead of -PY_SSIZE_T_MAX when clipping negative numbers. Also, versionadded tags were created and applied, and the arraymodule was updated to use __index__ for slicing. ---------------------------------------------------------------------- Comment By: Martin v. L??wis (loewis) Date: 2006-03-05 18:50 Message: Logged In: YES user_id=21627 In Objects/classobject.c, instance_index should be cast to lenfunc, not inquiry. Otherwise, it looks fine. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2006-03-03 10:45 Message: Logged In: YES user_id=33168 The doc needs \versionadded tags. I can add those after checkin. Should sequences in Modules/ be upgraded too? mmap, array, various db modules, bufferobject, rangeobject. Travis already mentioned the TP_FLAGS_HAVE_INDEX check in ceval.c. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2006-03-03 10:45 Message: Logged In: YES user_id=6380 Totally right. I have one more concern: >>> import sys >>> (sys.maxint+1).__index__() Traceback (most recent call last): File "", line 1, in OverflowError: long int too large to convert to int >>> whiile I agree that the C API ought to silently truncate values to fit within the boundaries established by ssize_t, I think that when calling __index__() from Python, it should be allowed to return an unbounded value. Anyway, I haven't had time to whip up code to implement that, but here's a new patch that adds the test to ISINDEX() -- thanks for catching that! ---------------------------------------------------------------------- Comment By: Travis Oliphant (teoliphant) Date: 2006-03-03 10:08 Message: Logged In: YES user_id=5296 I think there is still a need for a HASINDEX check in the ISINDEX definition in ceval.c ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2006-03-02 22:12 Message: Logged In: YES user_id=6380 OK, Travis, here's a new patch. It corrects the issues I mentioned before, and does some whitespace cleanup (like what Neal mentioned). The biggest change is definitely the check for Py_TPFLAGS_HAVE_INDEX whenever the nb_index slot is referenced. You don't have to do anything; but if you do have more changes, please throw away your old changes, sync to the head, and apply my patch, before doing any more work. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2006-03-02 21:32 Message: Logged In: YES user_id=6380 Travis -- I'm working on a new patch. Please don't work on one at the same time for the new few hours! (Until midnight PST.) ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2006-03-02 18:16 Message: Logged In: YES user_id=6380 I promise I'll review this further tomorrow! Feedback so far: - compilation error with svn HEAD on abstract.c:650 - all the uses of the nb_index slot must check for some Py_TPFLAGS_... bit before using that slot (see object.h) - the comment in ceval.c about the clipping of values < -PY_SSIZE_T_MAX is incorrect; they are boosted to -PY_SSIZE_T_MAX, not to zero ---------------------------------------------------------------------- Comment By: Travis Oliphant (teoliphant) Date: 2006-02-22 10:52 Message: Logged In: YES user_id=5296 I followed Neal's comments and updated a new patch. The new patch contains the tests and the documentation updates as well. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2006-02-22 01:03 Message: Logged In: YES user_id=33168 I see one problem in Modules/operator.c. This code: + if (i==-1 && PyErr_Occurred()) return NULL; + else return PyInt_FromLong((long)i); Should be: + if (i == -1 && PyErr_Occurred()) + return NULL; + return PyInt_FromSsizeT(i); There was a discussion on python-checkins recently about this. The short answer is that if Py_ssize_t's are cast to a long, that will lose precision on Win64 (size_ts are 64-bits, but longs are still 32). Since i is Py_ssize_t, the cast would lose the high order values (above 2G). In Objects/stringobject.c: - i += PyString_GET_SIZE(self); - return string_item(self,i); + i += PyList_GET_SIZE(self); + return string_item(self, i); I don't see how that (PyList) can be correct, self is a string object. I would change this code: + lenfunc func; + PyNumberMethods *nb; + if ((nb=item->ob_type->tp_as_number) && \ + (func=nb->nb_index)) { + Py_ssize_t i = func(item); to: + PyNumberMethods *nb = item->ob_type->tp_as_number; + if (nb != NULL && nb->nb_index != NULL) { + Py_ssize_t i = nb->nb_index(item); Let the compiler do the work. We can optimize later if this is a problem. I think the code is clearer this way and is more similar to the rest of the code. I don't care as much about the use of func here as the change to nb = ... If you want to keep the local variable, I would prefer a better name like nb_index instead of func. There's no need for a \ after &&. Most of these comments apply to Objects/listobject.c, Objects/tupleobject.c, Objects/unicodeobject.c, PyNumber_Index. In Objects/classobject.c, you don't check that indexstr is non-NULL after assignment. In instance_index(), remove the cast (int) of the return result outcome. In slot_nb_index() remove . from end of exception string. Note: you don't need the Py_DECREF() and return -1 in the last if as it would be the same if it fell through. Use whichever version you think is clearer. Either way is fine with me. In Include/abstract.h, do all the comments still say a C integer is returned even though a Py_ssize_t is returned? If not, can you update your comment too. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2006-02-22 00:33 Message: Logged In: YES user_id=33168 Travis, I briefly looked over the patches and have a few comments. It's easier if there's one big patch that contains all the code, tests, and doc. I noticed a second patch that contains the tests, but I didn't see any doc updates. I noticed some formatting which is not consistent with the style of the surrounding code (I think). Stuff like n=var->field (no spaces) and if (XXX) dosomething(); else return 5; Most places in the python code check for == NULL rather than the implicit check for 0. Most places in code don't do assignment in if (cond), though this last one is more variable. I'll try to look this over in more detail soon. But it probably won't be until PyCon. If you're there, maybe we can discuss in person. Also, if you have further PEP updates, feel free to send them to me and I can check them in. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1436368&group_id=5470 From noreply at sourceforge.net Mon Mar 6 20:36:41 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 06 Mar 2006 11:36:41 -0800 Subject: [Patches] [ python-Patches-1436368 ] PEP 357 --- adding nb_index Message-ID: Patches item #1436368, was opened at 2006-02-21 22:35 Message generated for change (Comment added) made by gvanrossum You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1436368&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Core (C code) Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: Travis Oliphant (teoliphant) Assigned to: Guido van Rossum (gvanrossum) Summary: PEP 357 --- adding nb_index Initial Comment: See PEP 357 for details. ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2006-03-06 14:36 Message: Logged In: YES user_id=6380 I'm sorry, but this still doesn't do what I think __index__ ought to do for a long: it ought to return self unchanged, even if it's out of range for ssize_t. IOW I want (2**100).__index__() to return 2**100, not 2**31-1. The clipping should be done only on the conversion to ssize_t in nb_index. I reviewed the code that was new since my last patch. Apart from the above objection, it all looks good except: - You seem to have lost the diffs for test_index.py; if you do "svn add Lib/test/test_index.py" it will show up. - Style nit: you don't have to use \ to split C lines *unless* it's a multi-line CPP macro definition. - Another style nit: try to put spaces around the == operator (and other comparisons). i==-1 looks like line-noise to me; i == -1 looks much better. - _PyLong_AsSize_t() and long_index check for PyErr_Occurred() after calling _long_as_ssize_t(); they should really cal PyErr_Clear() before calling that, since otherwise they can be fooled by pre-existing errors. (Clearing pre-existing errors is *also* bad, but they are really a symptom of something bad already going on; the general rule is to pre-clear errors *if* you're going to check for PyErr_Occurred() instead of checking for error return values (NULL or -1). ---------------------------------------------------------------------- Comment By: Travis Oliphant (teoliphant) Date: 2006-03-06 13:27 Message: Logged In: YES user_id=5296 This patch does not contain the bug in mmap that the last one did. All regression tests for Linux pass. ---------------------------------------------------------------------- Comment By: Travis Oliphant (teoliphant) Date: 2006-03-06 05:27 Message: Logged In: YES user_id=5296 Here's a new patch that does not raise overflow error for (sys.maxint+1).__index__ This patch also cleans up the apply_slice code so to exhibit the same behavior because it uses the same code. This has one minor difference in that -PY_SSIZE_T_MAX-1 (isn't this correct?) is used instead of -PY_SSIZE_T_MAX when clipping negative numbers. Also, versionadded tags were created and applied, and the arraymodule was updated to use __index__ for slicing. ---------------------------------------------------------------------- Comment By: Travis Oliphant (teoliphant) Date: 2006-03-06 05:27 Message: Logged In: YES user_id=5296 Here's a new patch that does not raise overflow error for (sys.maxint+1).__index__ This patch also cleans up the apply_slice code so to exhibit the same behavior because it uses the same code. This has one minor difference in that -PY_SSIZE_T_MAX-1 (isn't this correct?) is used instead of -PY_SSIZE_T_MAX when clipping negative numbers. Also, versionadded tags were created and applied, and the arraymodule was updated to use __index__ for slicing. ---------------------------------------------------------------------- Comment By: Martin v. L??wis (loewis) Date: 2006-03-05 20:50 Message: Logged In: YES user_id=21627 In Objects/classobject.c, instance_index should be cast to lenfunc, not inquiry. Otherwise, it looks fine. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2006-03-03 12:45 Message: Logged In: YES user_id=33168 The doc needs \versionadded tags. I can add those after checkin. Should sequences in Modules/ be upgraded too? mmap, array, various db modules, bufferobject, rangeobject. Travis already mentioned the TP_FLAGS_HAVE_INDEX check in ceval.c. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2006-03-03 12:45 Message: Logged In: YES user_id=6380 Totally right. I have one more concern: >>> import sys >>> (sys.maxint+1).__index__() Traceback (most recent call last): File "", line 1, in OverflowError: long int too large to convert to int >>> whiile I agree that the C API ought to silently truncate values to fit within the boundaries established by ssize_t, I think that when calling __index__() from Python, it should be allowed to return an unbounded value. Anyway, I haven't had time to whip up code to implement that, but here's a new patch that adds the test to ISINDEX() -- thanks for catching that! ---------------------------------------------------------------------- Comment By: Travis Oliphant (teoliphant) Date: 2006-03-03 12:08 Message: Logged In: YES user_id=5296 I think there is still a need for a HASINDEX check in the ISINDEX definition in ceval.c ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2006-03-03 00:12 Message: Logged In: YES user_id=6380 OK, Travis, here's a new patch. It corrects the issues I mentioned before, and does some whitespace cleanup (like what Neal mentioned). The biggest change is definitely the check for Py_TPFLAGS_HAVE_INDEX whenever the nb_index slot is referenced. You don't have to do anything; but if you do have more changes, please throw away your old changes, sync to the head, and apply my patch, before doing any more work. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2006-03-02 23:32 Message: Logged In: YES user_id=6380 Travis -- I'm working on a new patch. Please don't work on one at the same time for the new few hours! (Until midnight PST.) ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2006-03-02 20:16 Message: Logged In: YES user_id=6380 I promise I'll review this further tomorrow! Feedback so far: - compilation error with svn HEAD on abstract.c:650 - all the uses of the nb_index slot must check for some Py_TPFLAGS_... bit before using that slot (see object.h) - the comment in ceval.c about the clipping of values < -PY_SSIZE_T_MAX is incorrect; they are boosted to -PY_SSIZE_T_MAX, not to zero ---------------------------------------------------------------------- Comment By: Travis Oliphant (teoliphant) Date: 2006-02-22 12:52 Message: Logged In: YES user_id=5296 I followed Neal's comments and updated a new patch. The new patch contains the tests and the documentation updates as well. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2006-02-22 03:03 Message: Logged In: YES user_id=33168 I see one problem in Modules/operator.c. This code: + if (i==-1 && PyErr_Occurred()) return NULL; + else return PyInt_FromLong((long)i); Should be: + if (i == -1 && PyErr_Occurred()) + return NULL; + return PyInt_FromSsizeT(i); There was a discussion on python-checkins recently about this. The short answer is that if Py_ssize_t's are cast to a long, that will lose precision on Win64 (size_ts are 64-bits, but longs are still 32). Since i is Py_ssize_t, the cast would lose the high order values (above 2G). In Objects/stringobject.c: - i += PyString_GET_SIZE(self); - return string_item(self,i); + i += PyList_GET_SIZE(self); + return string_item(self, i); I don't see how that (PyList) can be correct, self is a string object. I would change this code: + lenfunc func; + PyNumberMethods *nb; + if ((nb=item->ob_type->tp_as_number) && \ + (func=nb->nb_index)) { + Py_ssize_t i = func(item); to: + PyNumberMethods *nb = item->ob_type->tp_as_number; + if (nb != NULL && nb->nb_index != NULL) { + Py_ssize_t i = nb->nb_index(item); Let the compiler do the work. We can optimize later if this is a problem. I think the code is clearer this way and is more similar to the rest of the code. I don't care as much about the use of func here as the change to nb = ... If you want to keep the local variable, I would prefer a better name like nb_index instead of func. There's no need for a \ after &&. Most of these comments apply to Objects/listobject.c, Objects/tupleobject.c, Objects/unicodeobject.c, PyNumber_Index. In Objects/classobject.c, you don't check that indexstr is non-NULL after assignment. In instance_index(), remove the cast (int) of the return result outcome. In slot_nb_index() remove . from end of exception string. Note: you don't need the Py_DECREF() and return -1 in the last if as it would be the same if it fell through. Use whichever version you think is clearer. Either way is fine with me. In Include/abstract.h, do all the comments still say a C integer is returned even though a Py_ssize_t is returned? If not, can you update your comment too. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2006-02-22 02:33 Message: Logged In: YES user_id=33168 Travis, I briefly looked over the patches and have a few comments. It's easier if there's one big patch that contains all the code, tests, and doc. I noticed a second patch that contains the tests, but I didn't see any doc updates. I noticed some formatting which is not consistent with the style of the surrounding code (I think). Stuff like n=var->field (no spaces) and if (XXX) dosomething(); else return 5; Most places in the python code check for == NULL rather than the implicit check for 0. Most places in code don't do assignment in if (cond), though this last one is more variable. I'll try to look this over in more detail soon. But it probably won't be until PyCon. If you're there, maybe we can discuss in person. Also, if you have further PEP updates, feel free to send them to me and I can check them in. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1436368&group_id=5470 From noreply at sourceforge.net Mon Mar 6 21:33:39 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 06 Mar 2006 12:33:39 -0800 Subject: [Patches] [ python-Patches-1444398 ] Make itertools.tee participate in GC Message-ID: Patches item #1444398, was opened at 2006-03-06 21: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=1444398&group_id=5470 Please note that this 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: Thomas Wouters (twouters) Assigned to: Raymond Hettinger (rhettinger) Summary: Make itertools.tee participate in GC Initial Comment: A small patch to make itertools.tee objects participate in GC; solves the memoryleak in test_generators (and any other use of tee objects in cycles.) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1444398&group_id=5470 From noreply at sourceforge.net Mon Mar 6 23:33:29 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 06 Mar 2006 14:33:29 -0800 Subject: [Patches] [ python-Patches-1442927 ] PyLong_FromString optimization Message-ID: Patches item #1442927, was opened at 2006-03-04 01:21 Message generated for change (Comment added) made by alanmcintyre You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1442927&group_id=5470 Please note that this 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: Alan McIntyre (alanmcintyre) Assigned to: Nobody/Anonymous (nobody) Summary: PyLong_FromString optimization Initial Comment: The current implementation of PyLong_FromString in Python 2.5 uses muladd1 to add each digit of the input string into the final number. Because muladd1 creates a new long to hold the result on every call, an intermediate long object is created/destroyed for each digit in the input string. This patch improves on the current implementation of PyLong_FromString in 3 main ways: 1. Creates and manipulates (in-place) a single long object to hold the result, skipping the creation of all those intermediate long objects. 2. Multiple digits from the input string are consolidated into a single long digit before adding them into the long integer object. This greatly reduces the number of "multiply/add" cycles required to push all the digits into the long object. 3. Three chunks of code like "if (ch <= '9') k = ch - '0'" in longobject.c are replaced by a digit value lookup vector. I'm not irreversibly stuck on this idea; it doesn't measurably add to performance, but it just seems (to me, anyway) to make the code in long_from_binary_base and PyLong_FromString a little less cluttered. This is the same lookup table from patch 1335972 (an optimization for int()). I expect if both patches get accepted it would be best to make them both reference a single instance of this table; if it looks like that's what will happen I'll tweak one or both patches as necessary. My cheezy test results (included in the attached file in an OpenOffice spreadsheet) show that the patch makes long() about 50% faster than the existing implementation for decimal input strings of about 10 characters. Longer input strings show even better performance improvement, leveling off around 3x faster for very long strings. This patch passes regression tests on my machine (WinXP, Visual C++ .net Standard 2003). I plan to try out the tests on my Linux box this weekend just to make sure the performance boost still remains when Python gets compiled by a C compiler that isn't neutered (standard .net 2003 doesn't appear to allow any optimizations). The test and test data generation scripts I used for this performance comparison are included in the attached zip file. At the moment I don't have any added tests; if somebody can suggest some things that ought to be tested I'll gladly write some tests. ---------------------------------------------------------------------- >Comment By: Alan McIntyre (alanmcintyre) Date: 2006-03-06 17:33 Message: Logged In: YES user_id=1115903 Version #2 is attached. I made a couple of tweaks and tested the patch out on Linux just to make sure the performace is still as good with compiler optimizations. For short numbers (numbers that would fit into an int), long() is 10-30% *slower* than before applying the patch. For longer numbers, long() is up to 249% faster, with the peak occurring around 1000 digits. If the negative performance impact for int-sized digits is unacceptable, I will see if I can do something about it. However, one always has the option of using int() on very long strings anyway, and it will automatically fall through to PyLong_FromString if the number is too long. The performance impact on int() for small numbers is so small as to be negligible (<5%), which is to be expected since the modified code isn't called when using int() on input strings < 2**32. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1442927&group_id=5470 From noreply at sourceforge.net Mon Mar 6 23:57:12 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 06 Mar 2006 14:57:12 -0800 Subject: [Patches] [ python-Patches-1379332 ] StreamReader.readline with size reading multiple lines Message-ID: Patches item #1379332, was opened at 2005-12-13 09:54 Message generated for change (Comment added) made by doerwalter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1379332&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Library (Lib) Group: None >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Matthew Mueller (donut) Assigned to: Walter D?rwald (doerwalter) Summary: StreamReader.readline with size reading multiple lines Initial Comment: In Python 2.4.2 and trunk, when StreamReader.readline is used with a size argument, it will eventually truncate some lines, even if every line is less than the size. It works correctly in Python 2.3.5, I haven't tried other versions. >>> f=codecs.getreader('ascii')(StringIO.StringIO("hello\nworld\n")) >>> f.readline(8) u'hello\n' >>> f.readline(8) u'wo' >>> f.readline(8) u'rld\n' I've attached a patch which fixes this and modifies test_codecs.py to test this. I don't know if this is the best way to fix it, but I didn't want to make deeper changes to the caching mechanism, being unfamiliar with this code. ---------------------------------------------------------------------- >Comment By: Walter D?rwald (doerwalter) Date: 2006-03-06 23:57 Message: Logged In: YES user_id=89016 Checked in another fix as r42872 and r42873: Instead of calling read() with a chars argument read() reads from the byte stream, if less then size chars are in the charbuffer. ---------------------------------------------------------------------- Comment By: Georg Brandl (birkenfeld) Date: 2006-01-20 18:32 Message: Logged In: YES user_id=1188172 Confirmed here (2.5 HEAD, Linux box). Patch works. Walter? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1379332&group_id=5470 From noreply at sourceforge.net Tue Mar 7 00:20:37 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 06 Mar 2006 15:20:37 -0800 Subject: [Patches] [ python-Patches-1444030 ] Several minor fixes for NULL checks, etc. Message-ID: Patches item #1444030, was opened at 2006-03-06 03:03 Message generated for change (Comment added) made by nnorwitz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1444030&group_id=5470 Please note that this 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: 4 Submitted By: Hye-Shik Chang (perky) >Assigned to: Hye-Shik Chang (perky) Summary: Several minor fixes for NULL checks, etc. Initial Comment: Attached patch includes fixes for missing NULL checks, reference leaks on minor cases found by a static analysis tool. It touches: Python/ceval.c Python/traceback.c Python/ast.c Python/modsupport.c Objects/object.c Objects/weakrefobject.c Objects/unicodeobject.c Objects/longobject.c Objects/stringobject.c Parser/firstsets.c Modules/arraymodule.c Modules/zipimport.c Modules/cStringIO.c ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2006-03-06 15:20 Message: Logged In: YES user_id=33168 Thanks Perky! I haven't gotten access to the report yet. All these look fine, with the following exceptions: Python/modsupport.c: This looks like it's a false positive, presumably because of if ((v = PyList_New(n)) == NULL). I changed that code and cleaned up the conditions below. I think the original code was more complex than it needs to be. I checked in this change to modsupport.c. Objects/object.c: To be consistent with PyObject_Str() this should return u"". The current code is wrong, but the patch just returns NULL. I *think* the correct thing to do is set v instead of res, then if that result is NULL, return NULL, ie: v = PyString_FromString(""); if (v == NULL) return NULL; Objects/weakrefobject.c: Your addition is correct, but I wonder if you also need to restore the error before returning like the code below? if (restore_error) PyErr_Restore(err_type, err_value, err_tb); Objects/unicodeobject.c: [block 1945] the current code is correct, but perhaps a bit confusing. goto ucnhashError is called in 3 places I see. The first 2 places, v is not set yet. In the third place, v was already DECREF'd. Perhaps after the DECREF, we should do: v = NULL; ? All other unicode changes are correct. Objects/longobject.c: I disagree with these changes, but the code is broken. I don't believe we should be checking for a or b being NULL. I think the code should be this (the first line is just for context): z = _PyLong_New(size_z); if (z == NULL) return NULL; The callers take care of DECREF'ing a and b and we didn't allocate either of them in this function. Objects/stringobject.c: Since list is always NULL if going to onError, the DECREF is not needed. I would get rid of the whole onError label and just return NULL if the list alloc fails. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1444030&group_id=5470 From noreply at sourceforge.net Tue Mar 7 00:42:07 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 06 Mar 2006 15:42:07 -0800 Subject: [Patches] [ python-Patches-1443865 ] gc.get_count() and other changes Message-ID: Patches item #1443865, was opened at 2006-03-05 20:09 Message generated for change (Comment added) made by nnorwitz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1443865&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Core (C code) Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: Barry A. Warsaw (bwarsaw) Assigned to: Skip Montanaro (montanaro) Summary: gc.get_count() and other changes Initial Comment: This patch adds gc.get_count() as a companion to gc.get_threshold(). It also adds an optional argument to gc.collect() to allow you to specify the generation to collect. This patch also fixes a couple of gcc warnings. ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2006-03-06 15:42 Message: Logged In: YES user_id=33168 I fixed the 2 warnings with %ld, so that part of the patch isn't necessary any longer. Instead of setting genarg = -999, can't you just set it to NUM_GENERATIONS - 1 and get rid of the check for -999? Doesn't ValueError make more sense than an IndexError? Isn't ValueError typically used for invalid args? Should gc_collect be: METH_VARARGS | METH_KEYWORDS ? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1443865&group_id=5470 From noreply at sourceforge.net Tue Mar 7 00:42:49 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 06 Mar 2006 15:42:49 -0800 Subject: [Patches] [ python-Patches-1443159 ] Remove bad PREDICT in ceval.c Message-ID: Patches item #1443159, was opened at 2006-03-04 10:52 Message generated for change (Comment added) made by nnorwitz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1443159&group_id=5470 Please note that this 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: Collin Winter (collinwinter) >Assigned to: Raymond Hettinger (rhettinger) Summary: Remove bad PREDICT in ceval.c Initial Comment: The current FOR_ITER -> UNPACK_SEQUENCE prediction is only right 6.41% of the time (212 million opcodes analysed). This patch removes it. ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2006-03-06 15:42 Message: Logged In: YES user_id=33168 Raymond any comments? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1443159&group_id=5470 From noreply at sourceforge.net Tue Mar 7 00:58:23 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 06 Mar 2006 15:58:23 -0800 Subject: [Patches] [ python-Patches-1444030 ] Several minor fixes for NULL checks, etc. Message-ID: Patches item #1444030, was opened at 2006-03-06 20:03 Message generated for change (Comment added) made by perky You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1444030&group_id=5470 Please note that this 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: 4 Submitted By: Hye-Shik Chang (perky) Assigned to: Hye-Shik Chang (perky) Summary: Several minor fixes for NULL checks, etc. Initial Comment: Attached patch includes fixes for missing NULL checks, reference leaks on minor cases found by a static analysis tool. It touches: Python/ceval.c Python/traceback.c Python/ast.c Python/modsupport.c Objects/object.c Objects/weakrefobject.c Objects/unicodeobject.c Objects/longobject.c Objects/stringobject.c Parser/firstsets.c Modules/arraymodule.c Modules/zipimport.c Modules/cStringIO.c ---------------------------------------------------------------------- >Comment By: Hye-Shik Chang (perky) Date: 2006-03-07 08:58 Message: Logged In: YES user_id=55188 Thanks for the review, Neal! Object/object.c: I think a reference to v will be leaked then. Then must we add a flag variable to track v? Objects/weakrefobject.c: That sounds more attractive! Objects/unicodeobject.c: The current code have v in two places; inner scope of the ucnhash routine and the function scope. I think function scope v needs to defref'ed. (and, inner v needs to be renamed?) Objects/longobject.c: If a->ob_size < 0, long_invert() is assigned to a while the function can return NULL. So I thought some kind of NULL checking is needed. Objects/stringobject.c: A macro SPLIT_APPEND uses onError label actually. I'll update the patch with your helpful comments soon. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2006-03-07 08:20 Message: Logged In: YES user_id=33168 Thanks Perky! I haven't gotten access to the report yet. All these look fine, with the following exceptions: Python/modsupport.c: This looks like it's a false positive, presumably because of if ((v = PyList_New(n)) == NULL). I changed that code and cleaned up the conditions below. I think the original code was more complex than it needs to be. I checked in this change to modsupport.c. Objects/object.c: To be consistent with PyObject_Str() this should return u"". The current code is wrong, but the patch just returns NULL. I *think* the correct thing to do is set v instead of res, then if that result is NULL, return NULL, ie: v = PyString_FromString(""); if (v == NULL) return NULL; Objects/weakrefobject.c: Your addition is correct, but I wonder if you also need to restore the error before returning like the code below? if (restore_error) PyErr_Restore(err_type, err_value, err_tb); Objects/unicodeobject.c: [block 1945] the current code is correct, but perhaps a bit confusing. goto ucnhashError is called in 3 places I see. The first 2 places, v is not set yet. In the third place, v was already DECREF'd. Perhaps after the DECREF, we should do: v = NULL; ? All other unicode changes are correct. Objects/longobject.c: I disagree with these changes, but the code is broken. I don't believe we should be checking for a or b being NULL. I think the code should be this (the first line is just for context): z = _PyLong_New(size_z); if (z == NULL) return NULL; The callers take care of DECREF'ing a and b and we didn't allocate either of them in this function. Objects/stringobject.c: Since list is always NULL if going to onError, the DECREF is not needed. I would get rid of the whole onError label and just return NULL if the list alloc fails. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1444030&group_id=5470 From noreply at sourceforge.net Tue Mar 7 01:02:53 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 06 Mar 2006 16:02:53 -0800 Subject: [Patches] [ python-Patches-1443159 ] Remove bad PREDICT in ceval.c Message-ID: Patches item #1443159, was opened at 2006-03-04 13:52 Message generated for change (Comment added) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1443159&group_id=5470 Please note that this 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: Collin Winter (collinwinter) Assigned to: Raymond Hettinger (rhettinger) Summary: Remove bad PREDICT in ceval.c Initial Comment: The current FOR_ITER -> UNPACK_SEQUENCE prediction is only right 6.41% of the time (212 million opcodes analysed). This patch removes it. ---------------------------------------------------------------------- >Comment By: Raymond Hettinger (rhettinger) Date: 2006-03-06 19:02 Message: Logged In: YES user_id=80475 Collin, you are welcome to write to me directly to discuss the results of your dynamic analysis. I suspect your results are almost certainly incorrect. The prediction was originally added after a detailed analysis of a great deal of Python code and checking the results of multiple pieces of benchmark code. Please do not arbitrarily start removing these unless you're damned certain the original study was erronenous. Also, I suspect that the given percentage does not reflect the conditional probability of the preceding PREDICT (STORE_FAST). The overwhelming majority of cases needing optimization involve "for x in iterable" where x is a fast local. If that prediction fails, then the next most common case is "for x,y in iterable". The latter is highly likely whenever we know the former has not occured. IOW, the unpack sequence may only come up 6% of the time, but its conditional probability rises above 90% when it follows the other prediction. Also, take some case with dynamic analysis. It is always tricky because it is very difficult to find truly representative code and to not have a single anomalous case run over and over again. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2006-03-06 18:42 Message: Logged In: YES user_id=33168 Raymond any comments? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1443159&group_id=5470 From noreply at sourceforge.net Tue Mar 7 01:05:13 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 06 Mar 2006 16:05:13 -0800 Subject: [Patches] [ python-Patches-1444398 ] Make itertools.tee participate in GC Message-ID: Patches item #1444398, was opened at 2006-03-06 15:33 Message generated for change (Comment added) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1444398&group_id=5470 Please note that this 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: Thomas Wouters (twouters) Assigned to: Raymond Hettinger (rhettinger) Summary: Make itertools.tee participate in GC Initial Comment: A small patch to make itertools.tee objects participate in GC; solves the memoryleak in test_generators (and any other use of tee objects in cycles.) ---------------------------------------------------------------------- >Comment By: Raymond Hettinger (rhettinger) Date: 2006-03-06 19:05 Message: Logged In: YES user_id=80475 I will take a look at the patch soon. IIRC, there was a concious decision to not have tee engage in GC because no normal use cases created cycles (they seem to arise only when intentionally creating a cycle for test code). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1444398&group_id=5470 From noreply at sourceforge.net Tue Mar 7 01:09:32 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 06 Mar 2006 16:09:32 -0800 Subject: [Patches] [ python-Patches-1444030 ] Several minor fixes for NULL checks, etc. Message-ID: Patches item #1444030, was opened at 2006-03-06 03:03 Message generated for change (Comment added) made by nnorwitz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1444030&group_id=5470 Please note that this 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: 4 Submitted By: Hye-Shik Chang (perky) Assigned to: Hye-Shik Chang (perky) Summary: Several minor fixes for NULL checks, etc. Initial Comment: Attached patch includes fixes for missing NULL checks, reference leaks on minor cases found by a static analysis tool. It touches: Python/ceval.c Python/traceback.c Python/ast.c Python/modsupport.c Objects/object.c Objects/weakrefobject.c Objects/unicodeobject.c Objects/longobject.c Objects/stringobject.c Parser/firstsets.c Modules/arraymodule.c Modules/zipimport.c Modules/cStringIO.c ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2006-03-06 16:09 Message: Logged In: YES user_id=33168 Object/object.c: You're right, my suggestion would leak v. I originally was going to tell you to just call PyErr_BadInternalCall(), but that is not what PyObject_String() does. It's so messy to add a flag. :-( I don't see any other way at the moment. Can you think of any cleaner solution? Objects/unicodeobject.c: yuck. I didn't notice the shadowing. You're right the outer v does need a DECREF. Please rename the inner v to avoid shadowing. Objects/longobject.c: Oh, I see it now. I would prefer the checks for a == NULL (and b == NULL) to be immediately after they are set from long_invert. There's no reason to defer the check/failure is there? Thanks! ---------------------------------------------------------------------- Comment By: Hye-Shik Chang (perky) Date: 2006-03-06 15:58 Message: Logged In: YES user_id=55188 Thanks for the review, Neal! Object/object.c: I think a reference to v will be leaked then. Then must we add a flag variable to track v? Objects/weakrefobject.c: That sounds more attractive! Objects/unicodeobject.c: The current code have v in two places; inner scope of the ucnhash routine and the function scope. I think function scope v needs to defref'ed. (and, inner v needs to be renamed?) Objects/longobject.c: If a->ob_size < 0, long_invert() is assigned to a while the function can return NULL. So I thought some kind of NULL checking is needed. Objects/stringobject.c: A macro SPLIT_APPEND uses onError label actually. I'll update the patch with your helpful comments soon. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2006-03-06 15:20 Message: Logged In: YES user_id=33168 Thanks Perky! I haven't gotten access to the report yet. All these look fine, with the following exceptions: Python/modsupport.c: This looks like it's a false positive, presumably because of if ((v = PyList_New(n)) == NULL). I changed that code and cleaned up the conditions below. I think the original code was more complex than it needs to be. I checked in this change to modsupport.c. Objects/object.c: To be consistent with PyObject_Str() this should return u"". The current code is wrong, but the patch just returns NULL. I *think* the correct thing to do is set v instead of res, then if that result is NULL, return NULL, ie: v = PyString_FromString(""); if (v == NULL) return NULL; Objects/weakrefobject.c: Your addition is correct, but I wonder if you also need to restore the error before returning like the code below? if (restore_error) PyErr_Restore(err_type, err_value, err_tb); Objects/unicodeobject.c: [block 1945] the current code is correct, but perhaps a bit confusing. goto ucnhashError is called in 3 places I see. The first 2 places, v is not set yet. In the third place, v was already DECREF'd. Perhaps after the DECREF, we should do: v = NULL; ? All other unicode changes are correct. Objects/longobject.c: I disagree with these changes, but the code is broken. I don't believe we should be checking for a or b being NULL. I think the code should be this (the first line is just for context): z = _PyLong_New(size_z); if (z == NULL) return NULL; The callers take care of DECREF'ing a and b and we didn't allocate either of them in this function. Objects/stringobject.c: Since list is always NULL if going to onError, the DECREF is not needed. I would get rid of the whole onError label and just return NULL if the list alloc fails. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1444030&group_id=5470 From noreply at sourceforge.net Tue Mar 7 01:12:26 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 06 Mar 2006 16:12:26 -0800 Subject: [Patches] [ python-Patches-1444398 ] Make itertools.tee participate in GC Message-ID: Patches item #1444398, was opened at 2006-03-06 21:33 Message generated for change (Comment added) made by twouters You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1444398&group_id=5470 Please note that this 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: Thomas Wouters (twouters) Assigned to: Raymond Hettinger (rhettinger) Summary: Make itertools.tee participate in GC Initial Comment: A small patch to make itertools.tee objects participate in GC; solves the memoryleak in test_generators (and any other use of tee objects in cycles.) ---------------------------------------------------------------------- >Comment By: Thomas Wouters (twouters) Date: 2006-03-07 01:12 Message: Logged In: YES user_id=34209 Well, I'm fine with removing the scope-enclosed generator versions of _m235() and fib() from test_generators, if that's what you're implying. :> However, I think it's slightly more suitable to just have tee participate in GC. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2006-03-07 01:05 Message: Logged In: YES user_id=80475 I will take a look at the patch soon. IIRC, there was a concious decision to not have tee engage in GC because no normal use cases created cycles (they seem to arise only when intentionally creating a cycle for test code). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1444398&group_id=5470 From noreply at sourceforge.net Tue Mar 7 01:52:46 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 06 Mar 2006 16:52:46 -0800 Subject: [Patches] [ python-Patches-1444398 ] Make itertools.tee participate in GC Message-ID: Patches item #1444398, was opened at 2006-03-06 15:33 Message generated for change (Comment added) made by tim_one You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1444398&group_id=5470 Please note that this 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: Thomas Wouters (twouters) Assigned to: Raymond Hettinger (rhettinger) Summary: Make itertools.tee participate in GC Initial Comment: A small patch to make itertools.tee objects participate in GC; solves the memoryleak in test_generators (and any other use of tee objects in cycles.) ---------------------------------------------------------------------- >Comment By: Tim Peters (tim_one) Date: 2006-03-06 19:52 Message: Logged In: YES user_id=31435 If there are likely to be millions of some type of object, then avoiding gc for that type on grounds of reducing memory use may be arguable (or, as in the cases of tuples or lists, may not be arguable regardless). Else "if it points to a PyObject, it might be in a cycle, so gc-enable it" generally rules. I'll note in passing that the m235 and fib generators weren't _intended_ to stress Python in any way, but have been extremely effective at doing so since generators first went in. Think of them as a pair of canaries in the coal mine :-) ---------------------------------------------------------------------- Comment By: Thomas Wouters (twouters) Date: 2006-03-06 19:12 Message: Logged In: YES user_id=34209 Well, I'm fine with removing the scope-enclosed generator versions of _m235() and fib() from test_generators, if that's what you're implying. :> However, I think it's slightly more suitable to just have tee participate in GC. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2006-03-06 19:05 Message: Logged In: YES user_id=80475 I will take a look at the patch soon. IIRC, there was a concious decision to not have tee engage in GC because no normal use cases created cycles (they seem to arise only when intentionally creating a cycle for test code). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1444398&group_id=5470 From noreply at sourceforge.net Tue Mar 7 01:55:31 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 06 Mar 2006 16:55:31 -0800 Subject: [Patches] [ python-Patches-1444529 ] kwdargs for compile/__import__ Message-ID: Patches item #1444529, was opened at 2006-03-07 01: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=1444529&group_id=5470 Please note that this 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: Thomas Wouters (twouters) Assigned to: Neal Norwitz (nnorwitz) Summary: kwdargs for compile/__import__ Initial Comment: Keyword arguments for compile() and __import__(), as discussed at PyCon. There is a slight speed difference on my development system: __import__ is ~1% slower, compile() is ~1.5% faster. I blame both on caches, alignment and what not, so I bet they're totally different for everyone. I'd say the advantage of managing the growing set of arguments outweighs the speed impact (if any.) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1444529&group_id=5470 From noreply at sourceforge.net Tue Mar 7 04:05:11 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 06 Mar 2006 19:05:11 -0800 Subject: [Patches] [ python-Patches-1442927 ] PyLong_FromString optimization Message-ID: Patches item #1442927, was opened at 2006-03-04 01:21 Message generated for change (Comment added) made by alanmcintyre You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1442927&group_id=5470 Please note that this 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: Alan McIntyre (alanmcintyre) Assigned to: Nobody/Anonymous (nobody) Summary: PyLong_FromString optimization Initial Comment: The current implementation of PyLong_FromString in Python 2.5 uses muladd1 to add each digit of the input string into the final number. Because muladd1 creates a new long to hold the result on every call, an intermediate long object is created/destroyed for each digit in the input string. This patch improves on the current implementation of PyLong_FromString in 3 main ways: 1. Creates and manipulates (in-place) a single long object to hold the result, skipping the creation of all those intermediate long objects. 2. Multiple digits from the input string are consolidated into a single long digit before adding them into the long integer object. This greatly reduces the number of "multiply/add" cycles required to push all the digits into the long object. 3. Three chunks of code like "if (ch <= '9') k = ch - '0'" in longobject.c are replaced by a digit value lookup vector. I'm not irreversibly stuck on this idea; it doesn't measurably add to performance, but it just seems (to me, anyway) to make the code in long_from_binary_base and PyLong_FromString a little less cluttered. This is the same lookup table from patch 1335972 (an optimization for int()). I expect if both patches get accepted it would be best to make them both reference a single instance of this table; if it looks like that's what will happen I'll tweak one or both patches as necessary. My cheezy test results (included in the attached file in an OpenOffice spreadsheet) show that the patch makes long() about 50% faster than the existing implementation for decimal input strings of about 10 characters. Longer input strings show even better performance improvement, leveling off around 3x faster for very long strings. This patch passes regression tests on my machine (WinXP, Visual C++ .net Standard 2003). I plan to try out the tests on my Linux box this weekend just to make sure the performance boost still remains when Python gets compiled by a C compiler that isn't neutered (standard .net 2003 doesn't appear to allow any optimizations). The test and test data generation scripts I used for this performance comparison are included in the attached zip file. At the moment I don't have any added tests; if somebody can suggest some things that ought to be tested I'll gladly write some tests. ---------------------------------------------------------------------- >Comment By: Alan McIntyre (alanmcintyre) Date: 2006-03-06 22:05 Message: Logged In: YES user_id=1115903 Version #3 is attached; it has an across-the-board improvement of ~10% over version 2. The performance hit for calling long() on 9-digit numbers is now only about -10%, breakeven happens somewhere around 11 digits, and the best performance is about +282% in the vicinity of 1000 digits. Sorry to keep commenting on my own patch. :) I think I'm done now. ---------------------------------------------------------------------- Comment By: Alan McIntyre (alanmcintyre) Date: 2006-03-06 17:33 Message: Logged In: YES user_id=1115903 Version #2 is attached. I made a couple of tweaks and tested the patch out on Linux just to make sure the performace is still as good with compiler optimizations. For short numbers (numbers that would fit into an int), long() is 10-30% *slower* than before applying the patch. For longer numbers, long() is up to 249% faster, with the peak occurring around 1000 digits. If the negative performance impact for int-sized digits is unacceptable, I will see if I can do something about it. However, one always has the option of using int() on very long strings anyway, and it will automatically fall through to PyLong_FromString if the number is too long. The performance impact on int() for small numbers is so small as to be negligible (<5%), which is to be expected since the modified code isn't called when using int() on input strings < 2**32. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1442927&group_id=5470 From noreply at sourceforge.net Tue Mar 7 04:26:08 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 06 Mar 2006 19:26:08 -0800 Subject: [Patches] [ python-Patches-1443865 ] gc.get_count() and other changes Message-ID: Patches item #1443865, was opened at 2006-03-05 23:09 Message generated for change (Comment added) made by bwarsaw You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1443865&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Core (C code) Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: Barry A. Warsaw (bwarsaw) Assigned to: Skip Montanaro (montanaro) Summary: gc.get_count() and other changes Initial Comment: This patch adds gc.get_count() as a companion to gc.get_threshold(). It also adds an optional argument to gc.collect() to allow you to specify the generation to collect. This patch also fixes a couple of gcc warnings. ---------------------------------------------------------------------- >Comment By: Barry A. Warsaw (bwarsaw) Date: 2006-03-06 22:26 Message: Logged In: YES user_id=12800 All good points. Here's a revised patch, with test cases and doc updates. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2006-03-06 18:42 Message: Logged In: YES user_id=33168 I fixed the 2 warnings with %ld, so that part of the patch isn't necessary any longer. Instead of setting genarg = -999, can't you just set it to NUM_GENERATIONS - 1 and get rid of the check for -999? Doesn't ValueError make more sense than an IndexError? Isn't ValueError typically used for invalid args? Should gc_collect be: METH_VARARGS | METH_KEYWORDS ? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1443865&group_id=5470 From noreply at sourceforge.net Tue Mar 7 05:01:52 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 06 Mar 2006 20:01:52 -0800 Subject: [Patches] [ python-Patches-1436368 ] PEP 357 --- adding nb_index Message-ID: Patches item #1436368, was opened at 2006-02-21 20:35 Message generated for change (Comment added) made by teoliphant You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1436368&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Core (C code) Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: Travis Oliphant (teoliphant) Assigned to: Guido van Rossum (gvanrossum) Summary: PEP 357 --- adding nb_index Initial Comment: See PEP 357 for details. ---------------------------------------------------------------------- >Comment By: Travis Oliphant (teoliphant) Date: 2006-03-06 21:01 Message: Logged In: YES user_id=5296 I changed the wrap_index function so that in Pyhton the __index__ method for long returns the object itself should it be too large for a Py_ssizet. I'm sorry I didn't understand what you wanted before. * added Lib/test/test_index.py * removed '\' used to split C-lines (where I could find them) * put spaces around '==' sign * check for an error at the start of _long_as_ssize_t so that both _PyLong_AsSize_t() and long_index return an error if one was pre-existing. That way the errors are carefully controlled in _long_assize_t and different things are done (ignoring overflow or raising an error) depending on the what calls _long_as_ssize_t. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2006-03-06 12:36 Message: Logged In: YES user_id=6380 I'm sorry, but this still doesn't do what I think __index__ ought to do for a long: it ought to return self unchanged, even if it's out of range for ssize_t. IOW I want (2**100).__index__() to return 2**100, not 2**31-1. The clipping should be done only on the conversion to ssize_t in nb_index. I reviewed the code that was new since my last patch. Apart from the above objection, it all looks good except: - You seem to have lost the diffs for test_index.py; if you do "svn add Lib/test/test_index.py" it will show up. - Style nit: you don't have to use \ to split C lines *unless* it's a multi-line CPP macro definition. - Another style nit: try to put spaces around the == operator (and other comparisons). i==-1 looks like line-noise to me; i == -1 looks much better. - _PyLong_AsSize_t() and long_index check for PyErr_Occurred() after calling _long_as_ssize_t(); they should really cal PyErr_Clear() before calling that, since otherwise they can be fooled by pre-existing errors. (Clearing pre-existing errors is *also* bad, but they are really a symptom of something bad already going on; the general rule is to pre-clear errors *if* you're going to check for PyErr_Occurred() instead of checking for error return values (NULL or -1). ---------------------------------------------------------------------- Comment By: Travis Oliphant (teoliphant) Date: 2006-03-06 11:27 Message: Logged In: YES user_id=5296 This patch does not contain the bug in mmap that the last one did. All regression tests for Linux pass. ---------------------------------------------------------------------- Comment By: Travis Oliphant (teoliphant) Date: 2006-03-06 03:27 Message: Logged In: YES user_id=5296 Here's a new patch that does not raise overflow error for (sys.maxint+1).__index__ This patch also cleans up the apply_slice code so to exhibit the same behavior because it uses the same code. This has one minor difference in that -PY_SSIZE_T_MAX-1 (isn't this correct?) is used instead of -PY_SSIZE_T_MAX when clipping negative numbers. Also, versionadded tags were created and applied, and the arraymodule was updated to use __index__ for slicing. ---------------------------------------------------------------------- Comment By: Travis Oliphant (teoliphant) Date: 2006-03-06 03:27 Message: Logged In: YES user_id=5296 Here's a new patch that does not raise overflow error for (sys.maxint+1).__index__ This patch also cleans up the apply_slice code so to exhibit the same behavior because it uses the same code. This has one minor difference in that -PY_SSIZE_T_MAX-1 (isn't this correct?) is used instead of -PY_SSIZE_T_MAX when clipping negative numbers. Also, versionadded tags were created and applied, and the arraymodule was updated to use __index__ for slicing. ---------------------------------------------------------------------- Comment By: Martin v. L??wis (loewis) Date: 2006-03-05 18:50 Message: Logged In: YES user_id=21627 In Objects/classobject.c, instance_index should be cast to lenfunc, not inquiry. Otherwise, it looks fine. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2006-03-03 10:45 Message: Logged In: YES user_id=33168 The doc needs \versionadded tags. I can add those after checkin. Should sequences in Modules/ be upgraded too? mmap, array, various db modules, bufferobject, rangeobject. Travis already mentioned the TP_FLAGS_HAVE_INDEX check in ceval.c. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2006-03-03 10:45 Message: Logged In: YES user_id=6380 Totally right. I have one more concern: >>> import sys >>> (sys.maxint+1).__index__() Traceback (most recent call last): File "", line 1, in OverflowError: long int too large to convert to int >>> whiile I agree that the C API ought to silently truncate values to fit within the boundaries established by ssize_t, I think that when calling __index__() from Python, it should be allowed to return an unbounded value. Anyway, I haven't had time to whip up code to implement that, but here's a new patch that adds the test to ISINDEX() -- thanks for catching that! ---------------------------------------------------------------------- Comment By: Travis Oliphant (teoliphant) Date: 2006-03-03 10:08 Message: Logged In: YES user_id=5296 I think there is still a need for a HASINDEX check in the ISINDEX definition in ceval.c ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2006-03-02 22:12 Message: Logged In: YES user_id=6380 OK, Travis, here's a new patch. It corrects the issues I mentioned before, and does some whitespace cleanup (like what Neal mentioned). The biggest change is definitely the check for Py_TPFLAGS_HAVE_INDEX whenever the nb_index slot is referenced. You don't have to do anything; but if you do have more changes, please throw away your old changes, sync to the head, and apply my patch, before doing any more work. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2006-03-02 21:32 Message: Logged In: YES user_id=6380 Travis -- I'm working on a new patch. Please don't work on one at the same time for the new few hours! (Until midnight PST.) ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2006-03-02 18:16 Message: Logged In: YES user_id=6380 I promise I'll review this further tomorrow! Feedback so far: - compilation error with svn HEAD on abstract.c:650 - all the uses of the nb_index slot must check for some Py_TPFLAGS_... bit before using that slot (see object.h) - the comment in ceval.c about the clipping of values < -PY_SSIZE_T_MAX is incorrect; they are boosted to -PY_SSIZE_T_MAX, not to zero ---------------------------------------------------------------------- Comment By: Travis Oliphant (teoliphant) Date: 2006-02-22 10:52 Message: Logged In: YES user_id=5296 I followed Neal's comments and updated a new patch. The new patch contains the tests and the documentation updates as well. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2006-02-22 01:03 Message: Logged In: YES user_id=33168 I see one problem in Modules/operator.c. This code: + if (i==-1 && PyErr_Occurred()) return NULL; + else return PyInt_FromLong((long)i); Should be: + if (i == -1 && PyErr_Occurred()) + return NULL; + return PyInt_FromSsizeT(i); There was a discussion on python-checkins recently about this. The short answer is that if Py_ssize_t's are cast to a long, that will lose precision on Win64 (size_ts are 64-bits, but longs are still 32). Since i is Py_ssize_t, the cast would lose the high order values (above 2G). In Objects/stringobject.c: - i += PyString_GET_SIZE(self); - return string_item(self,i); + i += PyList_GET_SIZE(self); + return string_item(self, i); I don't see how that (PyList) can be correct, self is a string object. I would change this code: + lenfunc func; + PyNumberMethods *nb; + if ((nb=item->ob_type->tp_as_number) && \ + (func=nb->nb_index)) { + Py_ssize_t i = func(item); to: + PyNumberMethods *nb = item->ob_type->tp_as_number; + if (nb != NULL && nb->nb_index != NULL) { + Py_ssize_t i = nb->nb_index(item); Let the compiler do the work. We can optimize later if this is a problem. I think the code is clearer this way and is more similar to the rest of the code. I don't care as much about the use of func here as the change to nb = ... If you want to keep the local variable, I would prefer a better name like nb_index instead of func. There's no need for a \ after &&. Most of these comments apply to Objects/listobject.c, Objects/tupleobject.c, Objects/unicodeobject.c, PyNumber_Index. In Objects/classobject.c, you don't check that indexstr is non-NULL after assignment. In instance_index(), remove the cast (int) of the return result outcome. In slot_nb_index() remove . from end of exception string. Note: you don't need the Py_DECREF() and return -1 in the last if as it would be the same if it fell through. Use whichever version you think is clearer. Either way is fine with me. In Include/abstract.h, do all the comments still say a C integer is returned even though a Py_ssize_t is returned? If not, can you update your comment too. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2006-02-22 00:33 Message: Logged In: YES user_id=33168 Travis, I briefly looked over the patches and have a few comments. It's easier if there's one big patch that contains all the code, tests, and doc. I noticed a second patch that contains the tests, but I didn't see any doc updates. I noticed some formatting which is not consistent with the style of the surrounding code (I think). Stuff like n=var->field (no spaces) and if (XXX) dosomething(); else return 5; Most places in the python code check for == NULL rather than the implicit check for 0. Most places in code don't do assignment in if (cond), though this last one is more variable. I'll try to look this over in more detail soon. But it probably won't be until PyCon. If you're there, maybe we can discuss in person. Also, if you have further PEP updates, feel free to send them to me and I can check them in. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1436368&group_id=5470 From noreply at sourceforge.net Tue Mar 7 05:57:33 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 06 Mar 2006 20:57:33 -0800 Subject: [Patches] [ python-Patches-1436368 ] PEP 357 --- adding nb_index Message-ID: Patches item #1436368, was opened at 2006-02-21 22:35 Message generated for change (Comment added) made by gvanrossum You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1436368&group_id=5470 Please note that this 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: 5 Submitted By: Travis Oliphant (teoliphant) Assigned to: Guido van Rossum (gvanrossum) Summary: PEP 357 --- adding nb_index Initial Comment: See PEP 357 for details. ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2006-03-06 23:57 Message: Logged In: YES user_id=6380 You know, I can't figure out why the code in wrap_index() has the desired effect, but it does... Somehow it looks suspiciously, as if it could sometimes return a non-integral self, but I can't come up with a test case where that happens, so I think it's okay. I think this is good to go now; I'll sleep on it for a night and then check it in. Thanks for all your efforts, Travis! ---------------------------------------------------------------------- Comment By: Travis Oliphant (teoliphant) Date: 2006-03-06 23:01 Message: Logged In: YES user_id=5296 I changed the wrap_index function so that in Pyhton the __index__ method for long returns the object itself should it be too large for a Py_ssizet. I'm sorry I didn't understand what you wanted before. * added Lib/test/test_index.py * removed '\' used to split C-lines (where I could find them) * put spaces around '==' sign * check for an error at the start of _long_as_ssize_t so that both _PyLong_AsSize_t() and long_index return an error if one was pre-existing. That way the errors are carefully controlled in _long_assize_t and different things are done (ignoring overflow or raising an error) depending on the what calls _long_as_ssize_t. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2006-03-06 14:36 Message: Logged In: YES user_id=6380 I'm sorry, but this still doesn't do what I think __index__ ought to do for a long: it ought to return self unchanged, even if it's out of range for ssize_t. IOW I want (2**100).__index__() to return 2**100, not 2**31-1. The clipping should be done only on the conversion to ssize_t in nb_index. I reviewed the code that was new since my last patch. Apart from the above objection, it all looks good except: - You seem to have lost the diffs for test_index.py; if you do "svn add Lib/test/test_index.py" it will show up. - Style nit: you don't have to use \ to split C lines *unless* it's a multi-line CPP macro definition. - Another style nit: try to put spaces around the == operator (and other comparisons). i==-1 looks like line-noise to me; i == -1 looks much better. - _PyLong_AsSize_t() and long_index check for PyErr_Occurred() after calling _long_as_ssize_t(); they should really cal PyErr_Clear() before calling that, since otherwise they can be fooled by pre-existing errors. (Clearing pre-existing errors is *also* bad, but they are really a symptom of something bad already going on; the general rule is to pre-clear errors *if* you're going to check for PyErr_Occurred() instead of checking for error return values (NULL or -1). ---------------------------------------------------------------------- Comment By: Travis Oliphant (teoliphant) Date: 2006-03-06 13:27 Message: Logged In: YES user_id=5296 This patch does not contain the bug in mmap that the last one did. All regression tests for Linux pass. ---------------------------------------------------------------------- Comment By: Travis Oliphant (teoliphant) Date: 2006-03-06 05:27 Message: Logged In: YES user_id=5296 Here's a new patch that does not raise overflow error for (sys.maxint+1).__index__ This patch also cleans up the apply_slice code so to exhibit the same behavior because it uses the same code. This has one minor difference in that -PY_SSIZE_T_MAX-1 (isn't this correct?) is used instead of -PY_SSIZE_T_MAX when clipping negative numbers. Also, versionadded tags were created and applied, and the arraymodule was updated to use __index__ for slicing. ---------------------------------------------------------------------- Comment By: Travis Oliphant (teoliphant) Date: 2006-03-06 05:27 Message: Logged In: YES user_id=5296 Here's a new patch that does not raise overflow error for (sys.maxint+1).__index__ This patch also cleans up the apply_slice code so to exhibit the same behavior because it uses the same code. This has one minor difference in that -PY_SSIZE_T_MAX-1 (isn't this correct?) is used instead of -PY_SSIZE_T_MAX when clipping negative numbers. Also, versionadded tags were created and applied, and the arraymodule was updated to use __index__ for slicing. ---------------------------------------------------------------------- Comment By: Martin v. L??wis (loewis) Date: 2006-03-05 20:50 Message: Logged In: YES user_id=21627 In Objects/classobject.c, instance_index should be cast to lenfunc, not inquiry. Otherwise, it looks fine. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2006-03-03 12:45 Message: Logged In: YES user_id=33168 The doc needs \versionadded tags. I can add those after checkin. Should sequences in Modules/ be upgraded too? mmap, array, various db modules, bufferobject, rangeobject. Travis already mentioned the TP_FLAGS_HAVE_INDEX check in ceval.c. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2006-03-03 12:45 Message: Logged In: YES user_id=6380 Totally right. I have one more concern: >>> import sys >>> (sys.maxint+1).__index__() Traceback (most recent call last): File "", line 1, in OverflowError: long int too large to convert to int >>> whiile I agree that the C API ought to silently truncate values to fit within the boundaries established by ssize_t, I think that when calling __index__() from Python, it should be allowed to return an unbounded value. Anyway, I haven't had time to whip up code to implement that, but here's a new patch that adds the test to ISINDEX() -- thanks for catching that! ---------------------------------------------------------------------- Comment By: Travis Oliphant (teoliphant) Date: 2006-03-03 12:08 Message: Logged In: YES user_id=5296 I think there is still a need for a HASINDEX check in the ISINDEX definition in ceval.c ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2006-03-03 00:12 Message: Logged In: YES user_id=6380 OK, Travis, here's a new patch. It corrects the issues I mentioned before, and does some whitespace cleanup (like what Neal mentioned). The biggest change is definitely the check for Py_TPFLAGS_HAVE_INDEX whenever the nb_index slot is referenced. You don't have to do anything; but if you do have more changes, please throw away your old changes, sync to the head, and apply my patch, before doing any more work. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2006-03-02 23:32 Message: Logged In: YES user_id=6380 Travis -- I'm working on a new patch. Please don't work on one at the same time for the new few hours! (Until midnight PST.) ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2006-03-02 20:16 Message: Logged In: YES user_id=6380 I promise I'll review this further tomorrow! Feedback so far: - compilation error with svn HEAD on abstract.c:650 - all the uses of the nb_index slot must check for some Py_TPFLAGS_... bit before using that slot (see object.h) - the comment in ceval.c about the clipping of values < -PY_SSIZE_T_MAX is incorrect; they are boosted to -PY_SSIZE_T_MAX, not to zero ---------------------------------------------------------------------- Comment By: Travis Oliphant (teoliphant) Date: 2006-02-22 12:52 Message: Logged In: YES user_id=5296 I followed Neal's comments and updated a new patch. The new patch contains the tests and the documentation updates as well. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2006-02-22 03:03 Message: Logged In: YES user_id=33168 I see one problem in Modules/operator.c. This code: + if (i==-1 && PyErr_Occurred()) return NULL; + else return PyInt_FromLong((long)i); Should be: + if (i == -1 && PyErr_Occurred()) + return NULL; + return PyInt_FromSsizeT(i); There was a discussion on python-checkins recently about this. The short answer is that if Py_ssize_t's are cast to a long, that will lose precision on Win64 (size_ts are 64-bits, but longs are still 32). Since i is Py_ssize_t, the cast would lose the high order values (above 2G). In Objects/stringobject.c: - i += PyString_GET_SIZE(self); - return string_item(self,i); + i += PyList_GET_SIZE(self); + return string_item(self, i); I don't see how that (PyList) can be correct, self is a string object. I would change this code: + lenfunc func; + PyNumberMethods *nb; + if ((nb=item->ob_type->tp_as_number) && \ + (func=nb->nb_index)) { + Py_ssize_t i = func(item); to: + PyNumberMethods *nb = item->ob_type->tp_as_number; + if (nb != NULL && nb->nb_index != NULL) { + Py_ssize_t i = nb->nb_index(item); Let the compiler do the work. We can optimize later if this is a problem. I think the code is clearer this way and is more similar to the rest of the code. I don't care as much about the use of func here as the change to nb = ... If you want to keep the local variable, I would prefer a better name like nb_index instead of func. There's no need for a \ after &&. Most of these comments apply to Objects/listobject.c, Objects/tupleobject.c, Objects/unicodeobject.c, PyNumber_Index. In Objects/classobject.c, you don't check that indexstr is non-NULL after assignment. In instance_index(), remove the cast (int) of the return result outcome. In slot_nb_index() remove . from end of exception string. Note: you don't need the Py_DECREF() and return -1 in the last if as it would be the same if it fell through. Use whichever version you think is clearer. Either way is fine with me. In Include/abstract.h, do all the comments still say a C integer is returned even though a Py_ssize_t is returned? If not, can you update your comment too. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2006-02-22 02:33 Message: Logged In: YES user_id=33168 Travis, I briefly looked over the patches and have a few comments. It's easier if there's one big patch that contains all the code, tests, and doc. I noticed a second patch that contains the tests, but I didn't see any doc updates. I noticed some formatting which is not consistent with the style of the surrounding code (I think). Stuff like n=var->field (no spaces) and if (XXX) dosomething(); else return 5; Most places in the python code check for == NULL rather than the implicit check for 0. Most places in code don't do assignment in if (cond), though this last one is more variable. I'll try to look this over in more detail soon. But it probably won't be until PyCon. If you're there, maybe we can discuss in person. Also, if you have further PEP updates, feel free to send them to me and I can check them in. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1436368&group_id=5470 From noreply at sourceforge.net Tue Mar 7 06:19:14 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 06 Mar 2006 21:19:14 -0800 Subject: [Patches] [ python-Patches-1443865 ] gc.get_count() and other changes Message-ID: Patches item #1443865, was opened at 2006-03-05 20:09 Message generated for change (Comment added) made by nnorwitz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1443865&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Core (C code) Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: Barry A. Warsaw (bwarsaw) Assigned to: Skip Montanaro (montanaro) Summary: gc.get_count() and other changes Initial Comment: This patch adds gc.get_count() as a companion to gc.get_threshold(). It also adds an optional argument to gc.collect() to allow you to specify the generation to collect. This patch also fixes a couple of gcc warnings. ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2006-03-06 21:19 Message: Logged In: YES user_id=33168 Oooooo, tests and doc, very nice. Don't forget to add a NEWS entry. Also the doc should have \versionadded, \versionchanged for the new method/added param. Neil was fine with the concept and no one else objected, so I'd say check it in. ---------------------------------------------------------------------- Comment By: Barry A. Warsaw (bwarsaw) Date: 2006-03-06 19:26 Message: Logged In: YES user_id=12800 All good points. Here's a revised patch, with test cases and doc updates. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2006-03-06 15:42 Message: Logged In: YES user_id=33168 I fixed the 2 warnings with %ld, so that part of the patch isn't necessary any longer. Instead of setting genarg = -999, can't you just set it to NUM_GENERATIONS - 1 and get rid of the check for -999? Doesn't ValueError make more sense than an IndexError? Isn't ValueError typically used for invalid args? Should gc_collect be: METH_VARARGS | METH_KEYWORDS ? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1443865&group_id=5470 From noreply at sourceforge.net Tue Mar 7 06:22:38 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 06 Mar 2006 21:22:38 -0800 Subject: [Patches] [ python-Patches-1444529 ] kwdargs for compile/__import__ Message-ID: Patches item #1444529, was opened at 2006-03-06 16:55 Message generated for change (Comment added) made by nnorwitz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1444529&group_id=5470 Please note that this 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: 5 Submitted By: Thomas Wouters (twouters) >Assigned to: Thomas Wouters (twouters) Summary: kwdargs for compile/__import__ Initial Comment: Keyword arguments for compile() and __import__(), as discussed at PyCon. There is a slight speed difference on my development system: __import__ is ~1% slower, compile() is ~1.5% faster. I blame both on caches, alignment and what not, so I bet they're totally different for everyone. I'd say the advantage of managing the growing set of arguments outweighs the speed impact (if any.) ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2006-03-06 21:22 Message: Logged In: YES user_id=33168 These look good to me. Thanks Thomas. I had started a patch for import. BTW I think the new __import__ needs to be documented in libfuncs.txt or somewhere like that. If you don't get to it, I'll find my change and update the docs. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1444529&group_id=5470 From noreply at sourceforge.net Tue Mar 7 09:06:58 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 07 Mar 2006 00:06:58 -0800 Subject: [Patches] [ python-Patches-1368955 ] UUID module for Python Message-ID: Patches item #1368955, was opened at 2005-11-29 02:58 Message generated for change (Comment added) made by ianbicking You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1368955&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Library (Lib) Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: Ka-Ping Yee (ping) Assigned to: Nobody/Anonymous (nobody) Summary: UUID module for Python Initial Comment: I recently tossed off a module to generate UUIDs because i needed one. Fredrik Lundh suggested i submit it here for inclusion in the standard library. See http://zesty.ca/python/uuid.html for a pydoc page. The module provides a UUID class for representing UUIDs and can generate version 1, 3, 4, or 5 UUIDs. One drawback of the implementation is that it currently runs external programs ("ipconfig" or "ifconfig") to obtain the Ethernet hardware address used in a version 1 UUID. The version 1 UUID implementation also does not use persistent storage to determine the clock sequence number. ---------------------------------------------------------------------- Comment By: Ian Bicking (ianbicking) Date: 2006-03-07 02:06 Message: Logged In: YES user_id=210337 We had some minor problems backporting this to Python 2.3; this fixed it: - uuid = UUID(randrange(1<<32L), randrange(1<<16), randrange(1<<16), - randrange(1<<8), randrange(1<<8), randrange(1<<48L)) + uuid = UUID(randrange(1<<32), randrange(1<<16), randrange(1<<16), + randrange(1<<8), randrange(1<<8), randrange(1<<48)) I'm not sure what the most current version looks like, so this might not be a problem anymore (e.g. if the values get precalculated) ---------------------------------------------------------------------- Comment By: Michael Str?der (stroeder) Date: 2005-12-07 17:47 Message: Logged In: YES user_id=64920 I'd like to see some constants pre-calculated for gaining performance, e.g. during mass data handling. E.g. the MAC address should only determined once after startup. Or at least as key-word argument so that the caller can decide to cache the MAC address. def uuid1(node=None): [..] node = node or getaddr() ---------------------------------------------------------------------- Comment By: Ka-Ping Yee (ping) Date: 2005-11-30 05:54 Message: Logged In: YES user_id=45338 This update fixes the order of the bytes in a hash-generated UUID. With this fix, the interpretation of RFC 4122 is that "octet 0" refers to the MOST significant octet, i.e. the one printed on the left. ---------------------------------------------------------------------- Comment By: Ka-Ping Yee (ping) Date: 2005-11-29 03:14 Message: Logged In: YES user_id=45338 This update fixes __repr__ to return a proper expression and adds the use of os.urandom (if available) to generate randomness for version 4 UUIDs. ---------------------------------------------------------------------- Comment By: Ka-Ping Yee (ping) Date: 2005-11-29 03:14 Message: Logged In: YES user_id=45338 This update fixes __repr__ to return a proper expression and adds the use of os.urandom (if available) to generate randomness for version 4 UUIDs. ---------------------------------------------------------------------- Comment By: Ka-Ping Yee (ping) Date: 2005-11-29 03:14 Message: Logged In: YES user_id=45338 This update fixes __repr__ to return a proper expression and adds the use of os.urandom (if available) to generate randomness for version 4 UUIDs. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1368955&group_id=5470 From noreply at sourceforge.net Tue Mar 7 10:46:35 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 07 Mar 2006 01:46:35 -0800 Subject: [Patches] [ python-Patches-1443865 ] gc.get_count() and other changes Message-ID: Patches item #1443865, was opened at 2006-03-05 23:09 Message generated for change (Comment added) made by bwarsaw You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1443865&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Core (C code) Group: Python 2.5 >Status: Closed >Resolution: Accepted Priority: 5 Submitted By: Barry A. Warsaw (bwarsaw) Assigned to: Skip Montanaro (montanaro) Summary: gc.get_count() and other changes Initial Comment: This patch adds gc.get_count() as a companion to gc.get_threshold(). It also adds an optional argument to gc.collect() to allow you to specify the generation to collect. This patch also fixes a couple of gcc warnings. ---------------------------------------------------------------------- >Comment By: Barry A. Warsaw (bwarsaw) Date: 2006-03-07 04:46 Message: Logged In: YES user_id=12800 Thanks! Committed in r42880. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2006-03-07 00:19 Message: Logged In: YES user_id=33168 Oooooo, tests and doc, very nice. Don't forget to add a NEWS entry. Also the doc should have \versionadded, \versionchanged for the new method/added param. Neil was fine with the concept and no one else objected, so I'd say check it in. ---------------------------------------------------------------------- Comment By: Barry A. Warsaw (bwarsaw) Date: 2006-03-06 22:26 Message: Logged In: YES user_id=12800 All good points. Here's a revised patch, with test cases and doc updates. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2006-03-06 18:42 Message: Logged In: YES user_id=33168 I fixed the 2 warnings with %ld, so that part of the patch isn't necessary any longer. Instead of setting genarg = -999, can't you just set it to NUM_GENERATIONS - 1 and get rid of the check for -999? Doesn't ValueError make more sense than an IndexError? Isn't ValueError typically used for invalid args? Should gc_collect be: METH_VARARGS | METH_KEYWORDS ? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1443865&group_id=5470 From noreply at sourceforge.net Tue Mar 7 13:35:03 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 07 Mar 2006 04:35:03 -0800 Subject: [Patches] [ python-Patches-1229511 ] Zipfile fix create_system information Message-ID: Patches item #1229511, was opened at 2005-06-29 09:47 Message generated for change (Comment added) made by ronaldoussoren You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1229511&group_id=5470 Please note that this 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: Hendrik Muhs (hendriktt) Assigned to: Nobody/Anonymous (nobody) Summary: Zipfile fix create_system information Initial Comment: this patches corrects the create_system value for created zipfiles with the zipfile module, which is platform dependent (better: filesystem dependent). It fixes the following bug: if a zipfile is created with Python on Unix and the files have executable flags the file rights are correctly saved into the zipfile. But when extracting the file with unzip (from Info-zip) the filerights (executable flags) are not reassigned correctly. This is due to the wrong create_system flag. The patch is not the 100% correct way to do it, but it is better as the situation now (completly ignore the system and always set create_system to 0). The right way to fix this would be to set the create_system flag dependent on the platform and the filesystem but I do not know how to do this. ---------------------------------------------------------------------- Comment By: Ronald Oussoren (ronaldoussoren) Date: 2006-03-07 13:35 Message: Logged In: YES user_id=580910 Could you check if the trunk is acceptable to you, and if so close this patch? Patch 1412872 also sets create_system to another value on unix systems and was applied at 05 feb 2006. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1229511&group_id=5470 From noreply at sourceforge.net Tue Mar 7 16:45:38 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 07 Mar 2006 07:45:38 -0800 Subject: [Patches] [ python-Patches-1368955 ] UUID module for Python Message-ID: Patches item #1368955, was opened at 2005-11-29 03:58 Message generated for change (Comment added) made by tim_one You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1368955&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Library (Lib) Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: Ka-Ping Yee (ping) Assigned to: Nobody/Anonymous (nobody) Summary: UUID module for Python Initial Comment: I recently tossed off a module to generate UUIDs because i needed one. Fredrik Lundh suggested i submit it here for inclusion in the standard library. See http://zesty.ca/python/uuid.html for a pydoc page. The module provides a UUID class for representing UUIDs and can generate version 1, 3, 4, or 5 UUIDs. One drawback of the implementation is that it currently runs external programs ("ipconfig" or "ifconfig") to obtain the Ethernet hardware address used in a version 1 UUID. The version 1 UUID implementation also does not use persistent storage to determine the clock sequence number. ---------------------------------------------------------------------- >Comment By: Tim Peters (tim_one) Date: 2006-03-07 10:45 Message: Logged In: YES user_id=31435 On c.l.py, Thomas Heller noted: """ I haven't used this module, but: The wingetaddr() function doesn't work on a german version of windows (there is no line in the output that starts with 'physical address'). In getaddr(), what if windows is installed on the D: drive? """ ---------------------------------------------------------------------- Comment By: Ian Bicking (ianbicking) Date: 2006-03-07 03:06 Message: Logged In: YES user_id=210337 We had some minor problems backporting this to Python 2.3; this fixed it: - uuid = UUID(randrange(1<<32L), randrange(1<<16), randrange(1<<16), - randrange(1<<8), randrange(1<<8), randrange(1<<48L)) + uuid = UUID(randrange(1<<32), randrange(1<<16), randrange(1<<16), + randrange(1<<8), randrange(1<<8), randrange(1<<48)) I'm not sure what the most current version looks like, so this might not be a problem anymore (e.g. if the values get precalculated) ---------------------------------------------------------------------- Comment By: Michael Str?der (stroeder) Date: 2005-12-07 18:47 Message: Logged In: YES user_id=64920 I'd like to see some constants pre-calculated for gaining performance, e.g. during mass data handling. E.g. the MAC address should only determined once after startup. Or at least as key-word argument so that the caller can decide to cache the MAC address. def uuid1(node=None): [..] node = node or getaddr() ---------------------------------------------------------------------- Comment By: Ka-Ping Yee (ping) Date: 2005-11-30 06:54 Message: Logged In: YES user_id=45338 This update fixes the order of the bytes in a hash-generated UUID. With this fix, the interpretation of RFC 4122 is that "octet 0" refers to the MOST significant octet, i.e. the one printed on the left. ---------------------------------------------------------------------- Comment By: Ka-Ping Yee (ping) Date: 2005-11-29 04:14 Message: Logged In: YES user_id=45338 This update fixes __repr__ to return a proper expression and adds the use of os.urandom (if available) to generate randomness for version 4 UUIDs. ---------------------------------------------------------------------- Comment By: Ka-Ping Yee (ping) Date: 2005-11-29 04:14 Message: Logged In: YES user_id=45338 This update fixes __repr__ to return a proper expression and adds the use of os.urandom (if available) to generate randomness for version 4 UUIDs. ---------------------------------------------------------------------- Comment By: Ka-Ping Yee (ping) Date: 2005-11-29 04:14 Message: Logged In: YES user_id=45338 This update fixes __repr__ to return a proper expression and adds the use of os.urandom (if available) to generate randomness for version 4 UUIDs. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1368955&group_id=5470 From noreply at sourceforge.net Tue Mar 7 16:48:36 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 07 Mar 2006 07:48:36 -0800 Subject: [Patches] [ python-Patches-1436368 ] PEP 357 --- adding nb_index Message-ID: Patches item #1436368, was opened at 2006-02-21 20:35 Message generated for change (Comment added) made by teoliphant You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1436368&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Core (C code) Group: Python 2.5 Status: Open >Resolution: None Priority: 5 Submitted By: Travis Oliphant (teoliphant) Assigned to: Guido van Rossum (gvanrossum) Summary: PEP 357 --- adding nb_index Initial Comment: See PEP 357 for details. ---------------------------------------------------------------------- >Comment By: Travis Oliphant (teoliphant) Date: 2006-03-07 08:48 Message: Logged In: YES user_id=5296 Guido is right. The wrap_index function should probably contain a check for Int or Long before checking for overflow. Otherwise, it would be possible to define a type in C that when it returns PY_SSIZE_T_MAX for the nb_index method it's __index__() call from Python will return itself (i.e. a situation exists where __index__() does not return an int or a long). I'm thinking: if ((PyInt_Check(self) || PyLong_Check(self)) && ((res == PY_SSIZE_T_MAX) || (res == -PY_SSIZE_T_MAX-1)) { ... } The reason this works is because the nb_index method returns PY_SSIZE_T_MAX or -PY_SSIZE_T_MAX-1 on overflow (without setting an error). We just check for those cases and return self if they show up because it might be an overflow condition. Even if it isn't an overflow, it will still be fine because self is either PY_SSIZE_T_MAX or -PY_SSIZE_T_MAX-1 so returning self will be the same integer as PyInt_FromSsize_t will return (except it could be a long integer instead of an integer). ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2006-03-06 21:57 Message: Logged In: YES user_id=6380 You know, I can't figure out why the code in wrap_index() has the desired effect, but it does... Somehow it looks suspiciously, as if it could sometimes return a non-integral self, but I can't come up with a test case where that happens, so I think it's okay. I think this is good to go now; I'll sleep on it for a night and then check it in. Thanks for all your efforts, Travis! ---------------------------------------------------------------------- Comment By: Travis Oliphant (teoliphant) Date: 2006-03-06 21:01 Message: Logged In: YES user_id=5296 I changed the wrap_index function so that in Pyhton the __index__ method for long returns the object itself should it be too large for a Py_ssizet. I'm sorry I didn't understand what you wanted before. * added Lib/test/test_index.py * removed '\' used to split C-lines (where I could find them) * put spaces around '==' sign * check for an error at the start of _long_as_ssize_t so that both _PyLong_AsSize_t() and long_index return an error if one was pre-existing. That way the errors are carefully controlled in _long_assize_t and different things are done (ignoring overflow or raising an error) depending on the what calls _long_as_ssize_t. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2006-03-06 12:36 Message: Logged In: YES user_id=6380 I'm sorry, but this still doesn't do what I think __index__ ought to do for a long: it ought to return self unchanged, even if it's out of range for ssize_t. IOW I want (2**100).__index__() to return 2**100, not 2**31-1. The clipping should be done only on the conversion to ssize_t in nb_index. I reviewed the code that was new since my last patch. Apart from the above objection, it all looks good except: - You seem to have lost the diffs for test_index.py; if you do "svn add Lib/test/test_index.py" it will show up. - Style nit: you don't have to use \ to split C lines *unless* it's a multi-line CPP macro definition. - Another style nit: try to put spaces around the == operator (and other comparisons). i==-1 looks like line-noise to me; i == -1 looks much better. - _PyLong_AsSize_t() and long_index check for PyErr_Occurred() after calling _long_as_ssize_t(); they should really cal PyErr_Clear() before calling that, since otherwise they can be fooled by pre-existing errors. (Clearing pre-existing errors is *also* bad, but they are really a symptom of something bad already going on; the general rule is to pre-clear errors *if* you're going to check for PyErr_Occurred() instead of checking for error return values (NULL or -1). ---------------------------------------------------------------------- Comment By: Travis Oliphant (teoliphant) Date: 2006-03-06 11:27 Message: Logged In: YES user_id=5296 This patch does not contain the bug in mmap that the last one did. All regression tests for Linux pass. ---------------------------------------------------------------------- Comment By: Travis Oliphant (teoliphant) Date: 2006-03-06 03:27 Message: Logged In: YES user_id=5296 Here's a new patch that does not raise overflow error for (sys.maxint+1).__index__ This patch also cleans up the apply_slice code so to exhibit the same behavior because it uses the same code. This has one minor difference in that -PY_SSIZE_T_MAX-1 (isn't this correct?) is used instead of -PY_SSIZE_T_MAX when clipping negative numbers. Also, versionadded tags were created and applied, and the arraymodule was updated to use __index__ for slicing. ---------------------------------------------------------------------- Comment By: Travis Oliphant (teoliphant) Date: 2006-03-06 03:27 Message: Logged In: YES user_id=5296 Here's a new patch that does not raise overflow error for (sys.maxint+1).__index__ This patch also cleans up the apply_slice code so to exhibit the same behavior because it uses the same code. This has one minor difference in that -PY_SSIZE_T_MAX-1 (isn't this correct?) is used instead of -PY_SSIZE_T_MAX when clipping negative numbers. Also, versionadded tags were created and applied, and the arraymodule was updated to use __index__ for slicing. ---------------------------------------------------------------------- Comment By: Martin v. L??wis (loewis) Date: 2006-03-05 18:50 Message: Logged In: YES user_id=21627 In Objects/classobject.c, instance_index should be cast to lenfunc, not inquiry. Otherwise, it looks fine. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2006-03-03 10:45 Message: Logged In: YES user_id=33168 The doc needs \versionadded tags. I can add those after checkin. Should sequences in Modules/ be upgraded too? mmap, array, various db modules, bufferobject, rangeobject. Travis already mentioned the TP_FLAGS_HAVE_INDEX check in ceval.c. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2006-03-03 10:45 Message: Logged In: YES user_id=6380 Totally right. I have one more concern: >>> import sys >>> (sys.maxint+1).__index__() Traceback (most recent call last): File "", line 1, in OverflowError: long int too large to convert to int >>> whiile I agree that the C API ought to silently truncate values to fit within the boundaries established by ssize_t, I think that when calling __index__() from Python, it should be allowed to return an unbounded value. Anyway, I haven't had time to whip up code to implement that, but here's a new patch that adds the test to ISINDEX() -- thanks for catching that! ---------------------------------------------------------------------- Comment By: Travis Oliphant (teoliphant) Date: 2006-03-03 10:08 Message: Logged In: YES user_id=5296 I think there is still a need for a HASINDEX check in the ISINDEX definition in ceval.c ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2006-03-02 22:12 Message: Logged In: YES user_id=6380 OK, Travis, here's a new patch. It corrects the issues I mentioned before, and does some whitespace cleanup (like what Neal mentioned). The biggest change is definitely the check for Py_TPFLAGS_HAVE_INDEX whenever the nb_index slot is referenced. You don't have to do anything; but if you do have more changes, please throw away your old changes, sync to the head, and apply my patch, before doing any more work. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2006-03-02 21:32 Message: Logged In: YES user_id=6380 Travis -- I'm working on a new patch. Please don't work on one at the same time for the new few hours! (Until midnight PST.) ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2006-03-02 18:16 Message: Logged In: YES user_id=6380 I promise I'll review this further tomorrow! Feedback so far: - compilation error with svn HEAD on abstract.c:650 - all the uses of the nb_index slot must check for some Py_TPFLAGS_... bit before using that slot (see object.h) - the comment in ceval.c about the clipping of values < -PY_SSIZE_T_MAX is incorrect; they are boosted to -PY_SSIZE_T_MAX, not to zero ---------------------------------------------------------------------- Comment By: Travis Oliphant (teoliphant) Date: 2006-02-22 10:52 Message: Logged In: YES user_id=5296 I followed Neal's comments and updated a new patch. The new patch contains the tests and the documentation updates as well. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2006-02-22 01:03 Message: Logged In: YES user_id=33168 I see one problem in Modules/operator.c. This code: + if (i==-1 && PyErr_Occurred()) return NULL; + else return PyInt_FromLong((long)i); Should be: + if (i == -1 && PyErr_Occurred()) + return NULL; + return PyInt_FromSsizeT(i); There was a discussion on python-checkins recently about this. The short answer is that if Py_ssize_t's are cast to a long, that will lose precision on Win64 (size_ts are 64-bits, but longs are still 32). Since i is Py_ssize_t, the cast would lose the high order values (above 2G). In Objects/stringobject.c: - i += PyString_GET_SIZE(self); - return string_item(self,i); + i += PyList_GET_SIZE(self); + return string_item(self, i); I don't see how that (PyList) can be correct, self is a string object. I would change this code: + lenfunc func; + PyNumberMethods *nb; + if ((nb=item->ob_type->tp_as_number) && \ + (func=nb->nb_index)) { + Py_ssize_t i = func(item); to: + PyNumberMethods *nb = item->ob_type->tp_as_number; + if (nb != NULL && nb->nb_index != NULL) { + Py_ssize_t i = nb->nb_index(item); Let the compiler do the work. We can optimize later if this is a problem. I think the code is clearer this way and is more similar to the rest of the code. I don't care as much about the use of func here as the change to nb = ... If you want to keep the local variable, I would prefer a better name like nb_index instead of func. There's no need for a \ after &&. Most of these comments apply to Objects/listobject.c, Objects/tupleobject.c, Objects/unicodeobject.c, PyNumber_Index. In Objects/classobject.c, you don't check that indexstr is non-NULL after assignment. In instance_index(), remove the cast (int) of the return result outcome. In slot_nb_index() remove . from end of exception string. Note: you don't need the Py_DECREF() and return -1 in the last if as it would be the same if it fell through. Use whichever version you think is clearer. Either way is fine with me. In Include/abstract.h, do all the comments still say a C integer is returned even though a Py_ssize_t is returned? If not, can you update your comment too. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2006-02-22 00:33 Message: Logged In: YES user_id=33168 Travis, I briefly looked over the patches and have a few comments. It's easier if there's one big patch that contains all the code, tests, and doc. I noticed a second patch that contains the tests, but I didn't see any doc updates. I noticed some formatting which is not consistent with the style of the surrounding code (I think). Stuff like n=var->field (no spaces) and if (XXX) dosomething(); else return 5; Most places in the python code check for == NULL rather than the implicit check for 0. Most places in code don't do assignment in if (cond), though this last one is more variable. I'll try to look this over in more detail soon. But it probably won't be until PyCon. If you're there, maybe we can discuss in person. Also, if you have further PEP updates, feel free to send them to me and I can check them in. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1436368&group_id=5470 From noreply at sourceforge.net Tue Mar 7 17:00:07 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 07 Mar 2006 08:00:07 -0800 Subject: [Patches] [ python-Patches-1444030 ] Several minor fixes for NULL checks, etc. Message-ID: Patches item #1444030, was opened at 2006-03-06 20:03 Message generated for change (Comment added) made by perky You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1444030&group_id=5470 Please note that this 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: 4 Submitted By: Hye-Shik Chang (perky) Assigned to: Hye-Shik Chang (perky) Summary: Several minor fixes for NULL checks, etc. Initial Comment: Attached patch includes fixes for missing NULL checks, reference leaks on minor cases found by a static analysis tool. It touches: Python/ceval.c Python/traceback.c Python/ast.c Python/modsupport.c Objects/object.c Objects/weakrefobject.c Objects/unicodeobject.c Objects/longobject.c Objects/stringobject.c Parser/firstsets.c Modules/arraymodule.c Modules/zipimport.c Modules/cStringIO.c ---------------------------------------------------------------------- >Comment By: Hye-Shik Chang (perky) Date: 2006-03-08 01:00 Message: Logged In: YES user_id=55188 Committed as r42894(trunk), r42895(2.4) except a fix for object.c. I'll think about it more tomorrow. :-) Thanks! ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2006-03-07 09:09 Message: Logged In: YES user_id=33168 Object/object.c: You're right, my suggestion would leak v. I originally was going to tell you to just call PyErr_BadInternalCall(), but that is not what PyObject_String() does. It's so messy to add a flag. :-( I don't see any other way at the moment. Can you think of any cleaner solution? Objects/unicodeobject.c: yuck. I didn't notice the shadowing. You're right the outer v does need a DECREF. Please rename the inner v to avoid shadowing. Objects/longobject.c: Oh, I see it now. I would prefer the checks for a == NULL (and b == NULL) to be immediately after they are set from long_invert. There's no reason to defer the check/failure is there? Thanks! ---------------------------------------------------------------------- Comment By: Hye-Shik Chang (perky) Date: 2006-03-07 08:58 Message: Logged In: YES user_id=55188 Thanks for the review, Neal! Object/object.c: I think a reference to v will be leaked then. Then must we add a flag variable to track v? Objects/weakrefobject.c: That sounds more attractive! Objects/unicodeobject.c: The current code have v in two places; inner scope of the ucnhash routine and the function scope. I think function scope v needs to defref'ed. (and, inner v needs to be renamed?) Objects/longobject.c: If a->ob_size < 0, long_invert() is assigned to a while the function can return NULL. So I thought some kind of NULL checking is needed. Objects/stringobject.c: A macro SPLIT_APPEND uses onError label actually. I'll update the patch with your helpful comments soon. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2006-03-07 08:20 Message: Logged In: YES user_id=33168 Thanks Perky! I haven't gotten access to the report yet. All these look fine, with the following exceptions: Python/modsupport.c: This looks like it's a false positive, presumably because of if ((v = PyList_New(n)) == NULL). I changed that code and cleaned up the conditions below. I think the original code was more complex than it needs to be. I checked in this change to modsupport.c. Objects/object.c: To be consistent with PyObject_Str() this should return u"". The current code is wrong, but the patch just returns NULL. I *think* the correct thing to do is set v instead of res, then if that result is NULL, return NULL, ie: v = PyString_FromString(""); if (v == NULL) return NULL; Objects/weakrefobject.c: Your addition is correct, but I wonder if you also need to restore the error before returning like the code below? if (restore_error) PyErr_Restore(err_type, err_value, err_tb); Objects/unicodeobject.c: [block 1945] the current code is correct, but perhaps a bit confusing. goto ucnhashError is called in 3 places I see. The first 2 places, v is not set yet. In the third place, v was already DECREF'd. Perhaps after the DECREF, we should do: v = NULL; ? All other unicode changes are correct. Objects/longobject.c: I disagree with these changes, but the code is broken. I don't believe we should be checking for a or b being NULL. I think the code should be this (the first line is just for context): z = _PyLong_New(size_z); if (z == NULL) return NULL; The callers take care of DECREF'ing a and b and we didn't allocate either of them in this function. Objects/stringobject.c: Since list is always NULL if going to onError, the DECREF is not needed. I would get rid of the whole onError label and just return NULL if the list alloc fails. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1444030&group_id=5470 From noreply at sourceforge.net Tue Mar 7 17:27:39 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 07 Mar 2006 08:27:39 -0800 Subject: [Patches] [ python-Patches-1368955 ] UUID module for Python Message-ID: Patches item #1368955, was opened at 2005-11-29 17:58 Message generated for change (Comment added) made by quiver You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1368955&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Library (Lib) Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: Ka-Ping Yee (ping) Assigned to: Nobody/Anonymous (nobody) Summary: UUID module for Python Initial Comment: I recently tossed off a module to generate UUIDs because i needed one. Fredrik Lundh suggested i submit it here for inclusion in the standard library. See http://zesty.ca/python/uuid.html for a pydoc page. The module provides a UUID class for representing UUIDs and can generate version 1, 3, 4, or 5 UUIDs. One drawback of the implementation is that it currently runs external programs ("ipconfig" or "ifconfig") to obtain the Ethernet hardware address used in a version 1 UUID. The version 1 UUID implementation also does not use persistent storage to determine the clock sequence number. ---------------------------------------------------------------------- Comment By: George Yoshida (quiver) Date: 2006-03-08 01:27 Message: Logged In: YES user_id=671362 One more thing about getaddr function. On Win 2k, "C:\WINNT" is used instead of XP- like "C:\windows". (If I remember correctly, Win 2k is still supportted. Am I right?) ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2006-03-08 00:45 Message: Logged In: YES user_id=31435 On c.l.py, Thomas Heller noted: """ I haven't used this module, but: The wingetaddr() function doesn't work on a german version of windows (there is no line in the output that starts with 'physical address'). In getaddr(), what if windows is installed on the D: drive? """ ---------------------------------------------------------------------- Comment By: Ian Bicking (ianbicking) Date: 2006-03-07 17:06 Message: Logged In: YES user_id=210337 We had some minor problems backporting this to Python 2.3; this fixed it: - uuid = UUID(randrange(1<<32L), randrange(1<<16), randrange(1<<16), - randrange(1<<8), randrange(1<<8), randrange(1<<48L)) + uuid = UUID(randrange(1<<32), randrange(1<<16), randrange(1<<16), + randrange(1<<8), randrange(1<<8), randrange(1<<48)) I'm not sure what the most current version looks like, so this might not be a problem anymore (e.g. if the values get precalculated) ---------------------------------------------------------------------- Comment By: Michael Str?der (stroeder) Date: 2005-12-08 08:47 Message: Logged In: YES user_id=64920 I'd like to see some constants pre-calculated for gaining performance, e.g. during mass data handling. E.g. the MAC address should only determined once after startup. Or at least as key-word argument so that the caller can decide to cache the MAC address. def uuid1(node=None): [..] node = node or getaddr() ---------------------------------------------------------------------- Comment By: Ka-Ping Yee (ping) Date: 2005-11-30 20:54 Message: Logged In: YES user_id=45338 This update fixes the order of the bytes in a hash-generated UUID. With this fix, the interpretation of RFC 4122 is that "octet 0" refers to the MOST significant octet, i.e. the one printed on the left. ---------------------------------------------------------------------- Comment By: Ka-Ping Yee (ping) Date: 2005-11-29 18:14 Message: Logged In: YES user_id=45338 This update fixes __repr__ to return a proper expression and adds the use of os.urandom (if available) to generate randomness for version 4 UUIDs. ---------------------------------------------------------------------- Comment By: Ka-Ping Yee (ping) Date: 2005-11-29 18:14 Message: Logged In: YES user_id=45338 This update fixes __repr__ to return a proper expression and adds the use of os.urandom (if available) to generate randomness for version 4 UUIDs. ---------------------------------------------------------------------- Comment By: Ka-Ping Yee (ping) Date: 2005-11-29 18:14 Message: Logged In: YES user_id=45338 This update fixes __repr__ to return a proper expression and adds the use of os.urandom (if available) to generate randomness for version 4 UUIDs. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1368955&group_id=5470 From noreply at sourceforge.net Tue Mar 7 18:58:25 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 07 Mar 2006 09:58:25 -0800 Subject: [Patches] [ python-Patches-1368955 ] UUID module for Python Message-ID: Patches item #1368955, was opened at 2005-11-29 08:58 Message generated for change (Comment added) made by gbrandl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1368955&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Library (Lib) Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: Ka-Ping Yee (ping) Assigned to: Nobody/Anonymous (nobody) Summary: UUID module for Python Initial Comment: I recently tossed off a module to generate UUIDs because i needed one. Fredrik Lundh suggested i submit it here for inclusion in the standard library. See http://zesty.ca/python/uuid.html for a pydoc page. The module provides a UUID class for representing UUIDs and can generate version 1, 3, 4, or 5 UUIDs. One drawback of the implementation is that it currently runs external programs ("ipconfig" or "ifconfig") to obtain the Ethernet hardware address used in a version 1 UUID. The version 1 UUID implementation also does not use persistent storage to determine the clock sequence number. ---------------------------------------------------------------------- >Comment By: Georg Brandl (gbrandl) Date: 2006-03-07 17:58 Message: Logged In: YES user_id=849994 Instead of hardcoding directories for ipconfig, why not try spawnp directly on UNIX or use something like webbrowser._iscommand? Minor nit: a,b,c = [1,2,3] is better a,b,c=1,2,3 ---------------------------------------------------------------------- Comment By: George Yoshida (quiver) Date: 2006-03-07 16:27 Message: Logged In: YES user_id=671362 One more thing about getaddr function. On Win 2k, "C:\WINNT" is used instead of XP- like "C:\windows". (If I remember correctly, Win 2k is still supportted. Am I right?) ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2006-03-07 15:45 Message: Logged In: YES user_id=31435 On c.l.py, Thomas Heller noted: """ I haven't used this module, but: The wingetaddr() function doesn't work on a german version of windows (there is no line in the output that starts with 'physical address'). In getaddr(), what if windows is installed on the D: drive? """ ---------------------------------------------------------------------- Comment By: Ian Bicking (ianbicking) Date: 2006-03-07 08:06 Message: Logged In: YES user_id=210337 We had some minor problems backporting this to Python 2.3; this fixed it: - uuid = UUID(randrange(1<<32L), randrange(1<<16), randrange(1<<16), - randrange(1<<8), randrange(1<<8), randrange(1<<48L)) + uuid = UUID(randrange(1<<32), randrange(1<<16), randrange(1<<16), + randrange(1<<8), randrange(1<<8), randrange(1<<48)) I'm not sure what the most current version looks like, so this might not be a problem anymore (e.g. if the values get precalculated) ---------------------------------------------------------------------- Comment By: Michael Str?der (stroeder) Date: 2005-12-07 23:47 Message: Logged In: YES user_id=64920 I'd like to see some constants pre-calculated for gaining performance, e.g. during mass data handling. E.g. the MAC address should only determined once after startup. Or at least as key-word argument so that the caller can decide to cache the MAC address. def uuid1(node=None): [..] node = node or getaddr() ---------------------------------------------------------------------- Comment By: Ka-Ping Yee (ping) Date: 2005-11-30 11:54 Message: Logged In: YES user_id=45338 This update fixes the order of the bytes in a hash-generated UUID. With this fix, the interpretation of RFC 4122 is that "octet 0" refers to the MOST significant octet, i.e. the one printed on the left. ---------------------------------------------------------------------- Comment By: Ka-Ping Yee (ping) Date: 2005-11-29 09:14 Message: Logged In: YES user_id=45338 This update fixes __repr__ to return a proper expression and adds the use of os.urandom (if available) to generate randomness for version 4 UUIDs. ---------------------------------------------------------------------- Comment By: Ka-Ping Yee (ping) Date: 2005-11-29 09:14 Message: Logged In: YES user_id=45338 This update fixes __repr__ to return a proper expression and adds the use of os.urandom (if available) to generate randomness for version 4 UUIDs. ---------------------------------------------------------------------- Comment By: Ka-Ping Yee (ping) Date: 2005-11-29 09:14 Message: Logged In: YES user_id=45338 This update fixes __repr__ to return a proper expression and adds the use of os.urandom (if available) to generate randomness for version 4 UUIDs. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1368955&group_id=5470 From noreply at sourceforge.net Tue Mar 7 19:20:38 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 07 Mar 2006 10:20:38 -0800 Subject: [Patches] [ python-Patches-1368955 ] UUID module for Python Message-ID: Patches item #1368955, was opened at 2005-11-29 08:58 Message generated for change (Comment added) made by tmick You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1368955&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Library (Lib) Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: Ka-Ping Yee (ping) Assigned to: Nobody/Anonymous (nobody) Summary: UUID module for Python Initial Comment: I recently tossed off a module to generate UUIDs because i needed one. Fredrik Lundh suggested i submit it here for inclusion in the standard library. See http://zesty.ca/python/uuid.html for a pydoc page. The module provides a UUID class for representing UUIDs and can generate version 1, 3, 4, or 5 UUIDs. One drawback of the implementation is that it currently runs external programs ("ipconfig" or "ifconfig") to obtain the Ethernet hardware address used in a version 1 UUID. The version 1 UUID implementation also does not use persistent storage to determine the clock sequence number. ---------------------------------------------------------------------- >Comment By: Trent Mick (tmick) Date: 2006-03-07 18:20 Message: Logged In: YES user_id=34892 > On Win 2k, "C:\WINNT" is used instead of XP-like > "C:\windows". Perhaps uuid.py could use the "windir" environment variable. It is defined on (at least) WinXP, Win2k, WinMe that I could check and points to C:\WINDOWS (on WinXP and WinMe) and C:\WINNT (on Win2k). It would first be good to verify if it is defined on WinNT and Win9x. ---------------------------------------------------------------------- Comment By: Georg Brandl (gbrandl) Date: 2006-03-07 17:58 Message: Logged In: YES user_id=849994 Instead of hardcoding directories for ipconfig, why not try spawnp directly on UNIX or use something like webbrowser._iscommand? Minor nit: a,b,c = [1,2,3] is better a,b,c=1,2,3 ---------------------------------------------------------------------- Comment By: George Yoshida (quiver) Date: 2006-03-07 16:27 Message: Logged In: YES user_id=671362 One more thing about getaddr function. On Win 2k, "C:\WINNT" is used instead of XP- like "C:\windows". (If I remember correctly, Win 2k is still supportted. Am I right?) ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2006-03-07 15:45 Message: Logged In: YES user_id=31435 On c.l.py, Thomas Heller noted: """ I haven't used this module, but: The wingetaddr() function doesn't work on a german version of windows (there is no line in the output that starts with 'physical address'). In getaddr(), what if windows is installed on the D: drive? """ ---------------------------------------------------------------------- Comment By: Ian Bicking (ianbicking) Date: 2006-03-07 08:06 Message: Logged In: YES user_id=210337 We had some minor problems backporting this to Python 2.3; this fixed it: - uuid = UUID(randrange(1<<32L), randrange(1<<16), randrange(1<<16), - randrange(1<<8), randrange(1<<8), randrange(1<<48L)) + uuid = UUID(randrange(1<<32), randrange(1<<16), randrange(1<<16), + randrange(1<<8), randrange(1<<8), randrange(1<<48)) I'm not sure what the most current version looks like, so this might not be a problem anymore (e.g. if the values get precalculated) ---------------------------------------------------------------------- Comment By: Michael Str?der (stroeder) Date: 2005-12-07 23:47 Message: Logged In: YES user_id=64920 I'd like to see some constants pre-calculated for gaining performance, e.g. during mass data handling. E.g. the MAC address should only determined once after startup. Or at least as key-word argument so that the caller can decide to cache the MAC address. def uuid1(node=None): [..] node = node or getaddr() ---------------------------------------------------------------------- Comment By: Ka-Ping Yee (ping) Date: 2005-11-30 11:54 Message: Logged In: YES user_id=45338 This update fixes the order of the bytes in a hash-generated UUID. With this fix, the interpretation of RFC 4122 is that "octet 0" refers to the MOST significant octet, i.e. the one printed on the left. ---------------------------------------------------------------------- Comment By: Ka-Ping Yee (ping) Date: 2005-11-29 09:14 Message: Logged In: YES user_id=45338 This update fixes __repr__ to return a proper expression and adds the use of os.urandom (if available) to generate randomness for version 4 UUIDs. ---------------------------------------------------------------------- Comment By: Ka-Ping Yee (ping) Date: 2005-11-29 09:14 Message: Logged In: YES user_id=45338 This update fixes __repr__ to return a proper expression and adds the use of os.urandom (if available) to generate randomness for version 4 UUIDs. ---------------------------------------------------------------------- Comment By: Ka-Ping Yee (ping) Date: 2005-11-29 09:14 Message: Logged In: YES user_id=45338 This update fixes __repr__ to return a proper expression and adds the use of os.urandom (if available) to generate randomness for version 4 UUIDs. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1368955&group_id=5470 From noreply at sourceforge.net Tue Mar 7 19:54:56 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 07 Mar 2006 10:54:56 -0800 Subject: [Patches] [ python-Patches-1436368 ] PEP 357 --- adding nb_index Message-ID: Patches item #1436368, was opened at 2006-02-21 22:35 Message generated for change (Comment added) made by gvanrossum You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1436368&group_id=5470 Please note that this 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: Travis Oliphant (teoliphant) Assigned to: Guido van Rossum (gvanrossum) Summary: PEP 357 --- adding nb_index Initial Comment: See PEP 357 for details. ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2006-03-07 13:54 Message: Logged In: YES user_id=6380 Checked in as 42899 and 42900 (Misc/NEWS). ---------------------------------------------------------------------- Comment By: Travis Oliphant (teoliphant) Date: 2006-03-07 10:48 Message: Logged In: YES user_id=5296 Guido is right. The wrap_index function should probably contain a check for Int or Long before checking for overflow. Otherwise, it would be possible to define a type in C that when it returns PY_SSIZE_T_MAX for the nb_index method it's __index__() call from Python will return itself (i.e. a situation exists where __index__() does not return an int or a long). I'm thinking: if ((PyInt_Check(self) || PyLong_Check(self)) && ((res == PY_SSIZE_T_MAX) || (res == -PY_SSIZE_T_MAX-1)) { ... } The reason this works is because the nb_index method returns PY_SSIZE_T_MAX or -PY_SSIZE_T_MAX-1 on overflow (without setting an error). We just check for those cases and return self if they show up because it might be an overflow condition. Even if it isn't an overflow, it will still be fine because self is either PY_SSIZE_T_MAX or -PY_SSIZE_T_MAX-1 so returning self will be the same integer as PyInt_FromSsize_t will return (except it could be a long integer instead of an integer). ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2006-03-06 23:57 Message: Logged In: YES user_id=6380 You know, I can't figure out why the code in wrap_index() has the desired effect, but it does... Somehow it looks suspiciously, as if it could sometimes return a non-integral self, but I can't come up with a test case where that happens, so I think it's okay. I think this is good to go now; I'll sleep on it for a night and then check it in. Thanks for all your efforts, Travis! ---------------------------------------------------------------------- Comment By: Travis Oliphant (teoliphant) Date: 2006-03-06 23:01 Message: Logged In: YES user_id=5296 I changed the wrap_index function so that in Pyhton the __index__ method for long returns the object itself should it be too large for a Py_ssizet. I'm sorry I didn't understand what you wanted before. * added Lib/test/test_index.py * removed '\' used to split C-lines (where I could find them) * put spaces around '==' sign * check for an error at the start of _long_as_ssize_t so that both _PyLong_AsSize_t() and long_index return an error if one was pre-existing. That way the errors are carefully controlled in _long_assize_t and different things are done (ignoring overflow or raising an error) depending on the what calls _long_as_ssize_t. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2006-03-06 14:36 Message: Logged In: YES user_id=6380 I'm sorry, but this still doesn't do what I think __index__ ought to do for a long: it ought to return self unchanged, even if it's out of range for ssize_t. IOW I want (2**100).__index__() to return 2**100, not 2**31-1. The clipping should be done only on the conversion to ssize_t in nb_index. I reviewed the code that was new since my last patch. Apart from the above objection, it all looks good except: - You seem to have lost the diffs for test_index.py; if you do "svn add Lib/test/test_index.py" it will show up. - Style nit: you don't have to use \ to split C lines *unless* it's a multi-line CPP macro definition. - Another style nit: try to put spaces around the == operator (and other comparisons). i==-1 looks like line-noise to me; i == -1 looks much better. - _PyLong_AsSize_t() and long_index check for PyErr_Occurred() after calling _long_as_ssize_t(); they should really cal PyErr_Clear() before calling that, since otherwise they can be fooled by pre-existing errors. (Clearing pre-existing errors is *also* bad, but they are really a symptom of something bad already going on; the general rule is to pre-clear errors *if* you're going to check for PyErr_Occurred() instead of checking for error return values (NULL or -1). ---------------------------------------------------------------------- Comment By: Travis Oliphant (teoliphant) Date: 2006-03-06 13:27 Message: Logged In: YES user_id=5296 This patch does not contain the bug in mmap that the last one did. All regression tests for Linux pass. ---------------------------------------------------------------------- Comment By: Travis Oliphant (teoliphant) Date: 2006-03-06 05:27 Message: Logged In: YES user_id=5296 Here's a new patch that does not raise overflow error for (sys.maxint+1).__index__ This patch also cleans up the apply_slice code so to exhibit the same behavior because it uses the same code. This has one minor difference in that -PY_SSIZE_T_MAX-1 (isn't this correct?) is used instead of -PY_SSIZE_T_MAX when clipping negative numbers. Also, versionadded tags were created and applied, and the arraymodule was updated to use __index__ for slicing. ---------------------------------------------------------------------- Comment By: Travis Oliphant (teoliphant) Date: 2006-03-06 05:27 Message: Logged In: YES user_id=5296 Here's a new patch that does not raise overflow error for (sys.maxint+1).__index__ This patch also cleans up the apply_slice code so to exhibit the same behavior because it uses the same code. This has one minor difference in that -PY_SSIZE_T_MAX-1 (isn't this correct?) is used instead of -PY_SSIZE_T_MAX when clipping negative numbers. Also, versionadded tags were created and applied, and the arraymodule was updated to use __index__ for slicing. ---------------------------------------------------------------------- Comment By: Martin v. L??wis (loewis) Date: 2006-03-05 20:50 Message: Logged In: YES user_id=21627 In Objects/classobject.c, instance_index should be cast to lenfunc, not inquiry. Otherwise, it looks fine. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2006-03-03 12:45 Message: Logged In: YES user_id=33168 The doc needs \versionadded tags. I can add those after checkin. Should sequences in Modules/ be upgraded too? mmap, array, various db modules, bufferobject, rangeobject. Travis already mentioned the TP_FLAGS_HAVE_INDEX check in ceval.c. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2006-03-03 12:45 Message: Logged In: YES user_id=6380 Totally right. I have one more concern: >>> import sys >>> (sys.maxint+1).__index__() Traceback (most recent call last): File "", line 1, in OverflowError: long int too large to convert to int >>> whiile I agree that the C API ought to silently truncate values to fit within the boundaries established by ssize_t, I think that when calling __index__() from Python, it should be allowed to return an unbounded value. Anyway, I haven't had time to whip up code to implement that, but here's a new patch that adds the test to ISINDEX() -- thanks for catching that! ---------------------------------------------------------------------- Comment By: Travis Oliphant (teoliphant) Date: 2006-03-03 12:08 Message: Logged In: YES user_id=5296 I think there is still a need for a HASINDEX check in the ISINDEX definition in ceval.c ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2006-03-03 00:12 Message: Logged In: YES user_id=6380 OK, Travis, here's a new patch. It corrects the issues I mentioned before, and does some whitespace cleanup (like what Neal mentioned). The biggest change is definitely the check for Py_TPFLAGS_HAVE_INDEX whenever the nb_index slot is referenced. You don't have to do anything; but if you do have more changes, please throw away your old changes, sync to the head, and apply my patch, before doing any more work. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2006-03-02 23:32 Message: Logged In: YES user_id=6380 Travis -- I'm working on a new patch. Please don't work on one at the same time for the new few hours! (Until midnight PST.) ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2006-03-02 20:16 Message: Logged In: YES user_id=6380 I promise I'll review this further tomorrow! Feedback so far: - compilation error with svn HEAD on abstract.c:650 - all the uses of the nb_index slot must check for some Py_TPFLAGS_... bit before using that slot (see object.h) - the comment in ceval.c about the clipping of values < -PY_SSIZE_T_MAX is incorrect; they are boosted to -PY_SSIZE_T_MAX, not to zero ---------------------------------------------------------------------- Comment By: Travis Oliphant (teoliphant) Date: 2006-02-22 12:52 Message: Logged In: YES user_id=5296 I followed Neal's comments and updated a new patch. The new patch contains the tests and the documentation updates as well. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2006-02-22 03:03 Message: Logged In: YES user_id=33168 I see one problem in Modules/operator.c. This code: + if (i==-1 && PyErr_Occurred()) return NULL; + else return PyInt_FromLong((long)i); Should be: + if (i == -1 && PyErr_Occurred()) + return NULL; + return PyInt_FromSsizeT(i); There was a discussion on python-checkins recently about this. The short answer is that if Py_ssize_t's are cast to a long, that will lose precision on Win64 (size_ts are 64-bits, but longs are still 32). Since i is Py_ssize_t, the cast would lose the high order values (above 2G). In Objects/stringobject.c: - i += PyString_GET_SIZE(self); - return string_item(self,i); + i += PyList_GET_SIZE(self); + return string_item(self, i); I don't see how that (PyList) can be correct, self is a string object. I would change this code: + lenfunc func; + PyNumberMethods *nb; + if ((nb=item->ob_type->tp_as_number) && \ + (func=nb->nb_index)) { + Py_ssize_t i = func(item); to: + PyNumberMethods *nb = item->ob_type->tp_as_number; + if (nb != NULL && nb->nb_index != NULL) { + Py_ssize_t i = nb->nb_index(item); Let the compiler do the work. We can optimize later if this is a problem. I think the code is clearer this way and is more similar to the rest of the code. I don't care as much about the use of func here as the change to nb = ... If you want to keep the local variable, I would prefer a better name like nb_index instead of func. There's no need for a \ after &&. Most of these comments apply to Objects/listobject.c, Objects/tupleobject.c, Objects/unicodeobject.c, PyNumber_Index. In Objects/classobject.c, you don't check that indexstr is non-NULL after assignment. In instance_index(), remove the cast (int) of the return result outcome. In slot_nb_index() remove . from end of exception string. Note: you don't need the Py_DECREF() and return -1 in the last if as it would be the same if it fell through. Use whichever version you think is clearer. Either way is fine with me. In Include/abstract.h, do all the comments still say a C integer is returned even though a Py_ssize_t is returned? If not, can you update your comment too. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2006-02-22 02:33 Message: Logged In: YES user_id=33168 Travis, I briefly looked over the patches and have a few comments. It's easier if there's one big patch that contains all the code, tests, and doc. I noticed a second patch that contains the tests, but I didn't see any doc updates. I noticed some formatting which is not consistent with the style of the surrounding code (I think). Stuff like n=var->field (no spaces) and if (XXX) dosomething(); else return 5; Most places in the python code check for == NULL rather than the implicit check for 0. Most places in code don't do assignment in if (cond), though this last one is more variable. I'll try to look this over in more detail soon. But it probably won't be until PyCon. If you're there, maybe we can discuss in person. Also, if you have further PEP updates, feel free to send them to me and I can check them in. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1436368&group_id=5470 From noreply at sourceforge.net Tue Mar 7 19:57:05 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 07 Mar 2006 10:57:05 -0800 Subject: [Patches] [ python-Patches-1368955 ] UUID module for Python Message-ID: Patches item #1368955, was opened at 2005-11-29 08:58 Message generated for change (Comment added) made by tmick You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1368955&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Library (Lib) Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: Ka-Ping Yee (ping) Assigned to: Nobody/Anonymous (nobody) Summary: UUID module for Python Initial Comment: I recently tossed off a module to generate UUIDs because i needed one. Fredrik Lundh suggested i submit it here for inclusion in the standard library. See http://zesty.ca/python/uuid.html for a pydoc page. The module provides a UUID class for representing UUIDs and can generate version 1, 3, 4, or 5 UUIDs. One drawback of the implementation is that it currently runs external programs ("ipconfig" or "ifconfig") to obtain the Ethernet hardware address used in a version 1 UUID. The version 1 UUID implementation also does not use persistent storage to determine the clock sequence number. ---------------------------------------------------------------------- >Comment By: Trent Mick (tmick) Date: 2006-03-07 18:57 Message: Logged In: YES user_id=34892 Would require a C extension but perhaps this could be used to get the MAC address on Windows instead of running and grepping (unreliable for different locales as Thomas pointed out) ipconfig.exe: http://support.microsoft.com/default.aspx?scid=kb;en-us;118623 How To Get the MAC Address for an Ethernet Adapter ---------------------------------------------------------------------- Comment By: Trent Mick (tmick) Date: 2006-03-07 18:28 Message: Logged In: YES user_id=34892 > use something like webbrowser._iscommand I have a Python implementation of `which`: http://trentm.com/projects/which/ http://trentm.com/projects/which/which.py though that is likely overkill for this case. ---------------------------------------------------------------------- Comment By: Trent Mick (tmick) Date: 2006-03-07 18:20 Message: Logged In: YES user_id=34892 > On Win 2k, "C:\WINNT" is used instead of XP-like > "C:\windows". Perhaps uuid.py could use the "windir" environment variable. It is defined on (at least) WinXP, Win2k, WinMe that I could check and points to C:\WINDOWS (on WinXP and WinMe) and C:\WINNT (on Win2k). It would first be good to verify if it is defined on WinNT and Win9x. ---------------------------------------------------------------------- Comment By: Georg Brandl (gbrandl) Date: 2006-03-07 17:58 Message: Logged In: YES user_id=849994 Instead of hardcoding directories for ipconfig, why not try spawnp directly on UNIX or use something like webbrowser._iscommand? Minor nit: a,b,c = [1,2,3] is better a,b,c=1,2,3 ---------------------------------------------------------------------- Comment By: George Yoshida (quiver) Date: 2006-03-07 16:27 Message: Logged In: YES user_id=671362 One more thing about getaddr function. On Win 2k, "C:\WINNT" is used instead of XP- like "C:\windows". (If I remember correctly, Win 2k is still supportted. Am I right?) ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2006-03-07 15:45 Message: Logged In: YES user_id=31435 On c.l.py, Thomas Heller noted: """ I haven't used this module, but: The wingetaddr() function doesn't work on a german version of windows (there is no line in the output that starts with 'physical address'). In getaddr(), what if windows is installed on the D: drive? """ ---------------------------------------------------------------------- Comment By: Ian Bicking (ianbicking) Date: 2006-03-07 08:06 Message: Logged In: YES user_id=210337 We had some minor problems backporting this to Python 2.3; this fixed it: - uuid = UUID(randrange(1<<32L), randrange(1<<16), randrange(1<<16), - randrange(1<<8), randrange(1<<8), randrange(1<<48L)) + uuid = UUID(randrange(1<<32), randrange(1<<16), randrange(1<<16), + randrange(1<<8), randrange(1<<8), randrange(1<<48)) I'm not sure what the most current version looks like, so this might not be a problem anymore (e.g. if the values get precalculated) ---------------------------------------------------------------------- Comment By: Michael Str?der (stroeder) Date: 2005-12-07 23:47 Message: Logged In: YES user_id=64920 I'd like to see some constants pre-calculated for gaining performance, e.g. during mass data handling. E.g. the MAC address should only determined once after startup. Or at least as key-word argument so that the caller can decide to cache the MAC address. def uuid1(node=None): [..] node = node or getaddr() ---------------------------------------------------------------------- Comment By: Ka-Ping Yee (ping) Date: 2005-11-30 11:54 Message: Logged In: YES user_id=45338 This update fixes the order of the bytes in a hash-generated UUID. With this fix, the interpretation of RFC 4122 is that "octet 0" refers to the MOST significant octet, i.e. the one printed on the left. ---------------------------------------------------------------------- Comment By: Ka-Ping Yee (ping) Date: 2005-11-29 09:14 Message: Logged In: YES user_id=45338 This update fixes __repr__ to return a proper expression and adds the use of os.urandom (if available) to generate randomness for version 4 UUIDs. ---------------------------------------------------------------------- Comment By: Ka-Ping Yee (ping) Date: 2005-11-29 09:14 Message: Logged In: YES user_id=45338 This update fixes __repr__ to return a proper expression and adds the use of os.urandom (if available) to generate randomness for version 4 UUIDs. ---------------------------------------------------------------------- Comment By: Ka-Ping Yee (ping) Date: 2005-11-29 09:14 Message: Logged In: YES user_id=45338 This update fixes __repr__ to return a proper expression and adds the use of os.urandom (if available) to generate randomness for version 4 UUIDs. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1368955&group_id=5470 From noreply at sourceforge.net Tue Mar 7 19:28:08 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 07 Mar 2006 10:28:08 -0800 Subject: [Patches] [ python-Patches-1368955 ] UUID module for Python Message-ID: Patches item #1368955, was opened at 2005-11-29 08:58 Message generated for change (Comment added) made by tmick You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1368955&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Library (Lib) Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: Ka-Ping Yee (ping) Assigned to: Nobody/Anonymous (nobody) Summary: UUID module for Python Initial Comment: I recently tossed off a module to generate UUIDs because i needed one. Fredrik Lundh suggested i submit it here for inclusion in the standard library. See http://zesty.ca/python/uuid.html for a pydoc page. The module provides a UUID class for representing UUIDs and can generate version 1, 3, 4, or 5 UUIDs. One drawback of the implementation is that it currently runs external programs ("ipconfig" or "ifconfig") to obtain the Ethernet hardware address used in a version 1 UUID. The version 1 UUID implementation also does not use persistent storage to determine the clock sequence number. ---------------------------------------------------------------------- >Comment By: Trent Mick (tmick) Date: 2006-03-07 18:28 Message: Logged In: YES user_id=34892 > use something like webbrowser._iscommand I have a Python implementation of `which`: http://trentm.com/projects/which/ http://trentm.com/projects/which/which.py though that is likely overkill for this case. ---------------------------------------------------------------------- Comment By: Trent Mick (tmick) Date: 2006-03-07 18:20 Message: Logged In: YES user_id=34892 > On Win 2k, "C:\WINNT" is used instead of XP-like > "C:\windows". Perhaps uuid.py could use the "windir" environment variable. It is defined on (at least) WinXP, Win2k, WinMe that I could check and points to C:\WINDOWS (on WinXP and WinMe) and C:\WINNT (on Win2k). It would first be good to verify if it is defined on WinNT and Win9x. ---------------------------------------------------------------------- Comment By: Georg Brandl (gbrandl) Date: 2006-03-07 17:58 Message: Logged In: YES user_id=849994 Instead of hardcoding directories for ipconfig, why not try spawnp directly on UNIX or use something like webbrowser._iscommand? Minor nit: a,b,c = [1,2,3] is better a,b,c=1,2,3 ---------------------------------------------------------------------- Comment By: George Yoshida (quiver) Date: 2006-03-07 16:27 Message: Logged In: YES user_id=671362 One more thing about getaddr function. On Win 2k, "C:\WINNT" is used instead of XP- like "C:\windows". (If I remember correctly, Win 2k is still supportted. Am I right?) ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2006-03-07 15:45 Message: Logged In: YES user_id=31435 On c.l.py, Thomas Heller noted: """ I haven't used this module, but: The wingetaddr() function doesn't work on a german version of windows (there is no line in the output that starts with 'physical address'). In getaddr(), what if windows is installed on the D: drive? """ ---------------------------------------------------------------------- Comment By: Ian Bicking (ianbicking) Date: 2006-03-07 08:06 Message: Logged In: YES user_id=210337 We had some minor problems backporting this to Python 2.3; this fixed it: - uuid = UUID(randrange(1<<32L), randrange(1<<16), randrange(1<<16), - randrange(1<<8), randrange(1<<8), randrange(1<<48L)) + uuid = UUID(randrange(1<<32), randrange(1<<16), randrange(1<<16), + randrange(1<<8), randrange(1<<8), randrange(1<<48)) I'm not sure what the most current version looks like, so this might not be a problem anymore (e.g. if the values get precalculated) ---------------------------------------------------------------------- Comment By: Michael Str?der (stroeder) Date: 2005-12-07 23:47 Message: Logged In: YES user_id=64920 I'd like to see some constants pre-calculated for gaining performance, e.g. during mass data handling. E.g. the MAC address should only determined once after startup. Or at least as key-word argument so that the caller can decide to cache the MAC address. def uuid1(node=None): [..] node = node or getaddr() ---------------------------------------------------------------------- Comment By: Ka-Ping Yee (ping) Date: 2005-11-30 11:54 Message: Logged In: YES user_id=45338 This update fixes the order of the bytes in a hash-generated UUID. With this fix, the interpretation of RFC 4122 is that "octet 0" refers to the MOST significant octet, i.e. the one printed on the left. ---------------------------------------------------------------------- Comment By: Ka-Ping Yee (ping) Date: 2005-11-29 09:14 Message: Logged In: YES user_id=45338 This update fixes __repr__ to return a proper expression and adds the use of os.urandom (if available) to generate randomness for version 4 UUIDs. ---------------------------------------------------------------------- Comment By: Ka-Ping Yee (ping) Date: 2005-11-29 09:14 Message: Logged In: YES user_id=45338 This update fixes __repr__ to return a proper expression and adds the use of os.urandom (if available) to generate randomness for version 4 UUIDs. ---------------------------------------------------------------------- Comment By: Ka-Ping Yee (ping) Date: 2005-11-29 09:14 Message: Logged In: YES user_id=45338 This update fixes __repr__ to return a proper expression and adds the use of os.urandom (if available) to generate randomness for version 4 UUIDs. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1368955&group_id=5470 From noreply at sourceforge.net Tue Mar 7 22:30:19 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 07 Mar 2006 13:30:19 -0800 Subject: [Patches] [ python-Patches-1006238 ] cross compile patch Message-ID: Patches item #1006238, was opened at 2004-08-10 00:05 Message generated for change (Comment added) made by nico0438 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1006238&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Build Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Daniel Goertzen (goertzen) Assigned to: Nobody/Anonymous (nobody) Summary: cross compile patch Initial Comment: Here's a cross compile patch I prepared a while ago but never got around to submitting. I've been using it happily for months to cross compile python for embedded systems. Below is a descriptive excerpt from the patch. Also note that the patch modifies configure.in, but not configure. You will need to regenerate configure with something like autoconf configure.in >configure This patch is inpsired from work by Klaus Reimer at http://www.ailis.de/~k/docs/crosscompiling/python.php + Cross Compiling + --------------- + + Python can be cross compiled by supplying different --host and --build + parameters to configure. (Python is compiled on the "build" system + and executed on the "host" system, in case you forgot :). Python is + tricky to cross compile because it needs to execute parts of itself + during construction. To work around this, make's VPATH feature is + used to compile a native python in the subdirectory "buildpython". + When parts of python need to be executed during construction, the + "buildpython" versions are used. + + A consequence of using the VPATH feature is that you may not do a + cross compile build in the source directory. In other words, do this: + + mkdir mydir + cd mydir + ../Python/configure --host=powerpc-405-linux-gnu --build=i686-pc-linux-gnu + make + + Cross compiling works well under linux, mileage may vary for other + platforms. + + A few reminders on using configure to cross compile: + - Cross compile tools must be in the PATH. + - Cross compile tools must be prefixed with the host type + (ie powerpc-405-linux-gnu-cc, powerpc-405-linux-gnu-ranlib, ...) + - CC, CXX, AR, and RANLIB must be undefined when running configure and + make. Configure will detect them. + + If you need a cross compiler, check out Dan Kegel's crosstool: + http://www.kegel.com/crosstool + + ---------------------------------------------------------------------- Comment By: Nicolas (nico0438) Date: 2006-03-07 22:30 Message: Logged In: YES user_id=1330285 Hi again, It seems I'm successfull in cross-compiling python. But I'm not sure of what I have to save on the host platform. There is python executable of course. But there is no lib directory with .so files and .py files in the directory where python is built. Can you tell me what files/directories you save on your host platform ? Thanks again for your support. Nicolas ---------------------------------------------------------------------- Comment By: Daniel Goertzen (goertzen) Date: 2006-03-06 16:12 Message: Logged In: YES user_id=843814 Hi hugo. The problems you are having are less python related and more system-building/cross-development issues, and this is the wrong forum for hashing out this stuff out. I recommend building a linux-from-scratch system (http://www.linuxfromscratch.org/) on an ordinary PC to learn how the insides of linux machine works and how to fix things when they go wrong. Good luck, Dan. ---------------------------------------------------------------------- Comment By: hugo (hugo_koopmans) Date: 2006-03-04 21:02 Message: Logged In: YES user_id=1229536 Hi there, I am trying to cross compile python on the fox board (etrax). now everything seemed to go well but when running the python binary is says: ./python: error while loading shared libraries: libstdc++.so.5: cannot load shared object file: No such file or directory I only ftp-ed the python bin not the (much bigger) libpython2.4a .... seems this is a library archive of some kind ? do i need it? how do i use it then? thanx a million if you can help me out. hugo ---------------------------------------------------------------------- Comment By: Daniel Goertzen (goertzen) Date: 2006-02-24 23:32 Message: Logged In: YES user_id=843814 You didn't apply the patch properly. See the other messages about the use of the -p option. Start with a fresh source tree and use: cd Python-2.4.2 patch -p3 <../python-patch.txt ---------------------------------------------------------------------- Comment By: Nicolas (nico0438) Date: 2006-02-24 22:37 Message: Logged In: YES user_id=1330285 If I try to aplly the patch again, I get messages saying a patch has allready been applied. To apply the patch I executed the following : cd Python-2.4.2 patch <../python-patch.txt ---------------------------------------------------------------------- Comment By: Daniel Goertzen (goertzen) Date: 2006-02-24 22:30 Message: Logged In: YES user_id=843814 The build system python should be in "MyPython/buildpython", and the host python should just be in "MyPython" Are you sure you applied the patch right? What you're getting is what would happen if you didn't apply the patch at all. ---------------------------------------------------------------------- Comment By: Nicolas (nico0438) Date: 2006-02-24 22:19 Message: Logged In: YES user_id=1330285 Yes I guess. But it seems that all I get is for the build system. If I try to execute on the build system ./python it runs. Also, there is no hostbuild subdirectory. Is it ok ? Nicolas ---------------------------------------------------------------------- Comment By: Daniel Goertzen (goertzen) Date: 2006-02-24 22:14 Message: Logged In: YES user_id=843814 > I then cd to a "MyPython" directory. > I call ../Python-2.4.2/configure ... Then your files should be in your "MyPython" directory. ---------------------------------------------------------------------- Comment By: Nicolas (nico0438) Date: 2006-02-24 21:54 Message: Logged In: YES user_id=1330285 Me again, sorry... What Should I get after compilation has finished ? Where are the files for my target ? Nicolas ---------------------------------------------------------------------- Comment By: Nicolas (nico0438) Date: 2006-02-24 20:55 Message: Logged In: YES user_id=1330285 Hi again, I finaly dad enought time to work on my project. So, I compiled autoconf tools for my system. Then, I rerun all the steps successfully. Thanks again for your help. Nicolas ---------------------------------------------------------------------- Comment By: nicolas pinault (nico38) Date: 2006-02-24 16:12 Message: Logged In: YES user_id=1081828 You are right, I have misunderstood --build and --host signification. And I also forgotten to run autoconf partialy because I don't have autoconf installed on my system. So I didn't pay attention it didn't run. Thanks for your help. I'll let you know if this works in a few days. Nicolas ---------------------------------------------------------------------- Comment By: Daniel Goertzen (goertzen) Date: 2006-02-24 15:51 Message: Logged In: YES user_id=843814 Did you run autoconf after patching as instructed? Also, your --build and --host options seem backwards. host is the arch you want python to run on, build is the arch you build python on. Cheers, Dan. ---------------------------------------------------------------------- Comment By: nicolas pinault (nico38) Date: 2006-02-24 13:38 Message: Logged In: YES user_id=1081828 Hi, I try to cross compile Python-2.4.2 for an etrax processor. I have successfully applied the patch to Python sources. I then cd to a "MyPython" directory. I call ../Python-2.4.2/configure --build cris --host i386-linux It works ok (did not see an error) I all make I get the following error after a while : make : *** No rule to make target '@BUILDPGEN@', needed by '../Python-2.4.2/Include/graminit.h'. Stop. Any Idea ? Nicolas ---------------------------------------------------------------------- Comment By: xudong (xudong888) Date: 2006-01-10 15:45 Message: Logged In: YES user_id=1420135 I have resolved my question,now I can run python on the mips machine,and can run some binary build by python.Can I also cross compile pygame for python?But the pygame source does't has 'configure' and 'Makefiel' files,setup.py instead in source package.How should I do? Thanks :-) ---------------------------------------------------------------------- Comment By: xudong (xudong888) Date: 2006-01-06 12:08 Message: Logged In: YES user_id=1420135 If you have accounts of MSN,please add me.My accounts is xudong_888 at hotmail.com. I am very impatient.I hope I can get some help from you.Thanks. ---------------------------------------------------------------------- Comment By: xudong (xudong888) Date: 2006-01-06 11:57 Message: Logged In: YES user_id=1420135 Thank you for your rapid answer.But I still can't solve my question.I can't find the whole instructions. Can you give me the whole instructions by EMAIL,my email is xudong888 at 163.com,thanks. My "host" system is mips embbed_linux,the release of the linux kernel is 2.4.xx and the CPU type is MIPS 4Kc.There are no python installed on this system.My "build" system is i86 and operate system is RedHat9.0,and has installed python2.4.1 and cross-compiling Tools mipsel-linux-gcc.I can cross compile C program for the "host" system.I have writed some program with python language.I can get the binary from python script by use freeze.py on the "build" system. Now I want to run the binary on the "host" system.Can you tell me how should I do. in addition,I don't know what parameter I should input to use this patch. finally,I'm sorry for my poor English.I like python very much,but I can't get help in chinese. ---------------------------------------------------------------------- Comment By: Daniel Goertzen (goertzen) Date: 2006-01-05 18:24 Message: Logged In: YES user_id=843814 After configure you run "make". But did you use configure as the instructions say? You cannot just use "./configure". Good luck, Dan. ---------------------------------------------------------------------- Comment By: xudong (xudong888) Date: 2006-01-05 17:55 Message: Logged In: YES user_id=1420135 I am a Chinese and my English is very poor.I'm sorry if what I said is wrong.My question is What should I do after './configure'.Before this I have done patch and autoconf. Thanks :-) ---------------------------------------------------------------------- Comment By: David Lambert (jdalambert) Date: 2005-11-08 17:06 Message: Logged In: YES user_id=845425 Oops! All works fine now. Thanks :-) ---------------------------------------------------------------------- Comment By: Daniel Goertzen (goertzen) Date: 2005-11-08 16:09 Message: Logged In: YES user_id=843814 patch isn't lying about wrong -p options. Use -p3 instead of -p0. Cheers, Dan. ---------------------------------------------------------------------- Comment By: David Lambert (jdalambert) Date: 2005-11-08 15:26 Message: Logged In: YES user_id=845425 Thanks for the quick reply, and sorry for the confusion. I DID try the cross compile in a sub directory. That failed with the same error. I then tried a non-cross build in the main directory, that also failed (which was my previous post). Here is my complete transcript after untarring Python: [dlambert at lambsys Python-2.4.2]$ patch -p0 < ../python-patch can't find file to patch at input line 3 Perhaps you used the wrong -p or --strip option? The text leading up to this was: -------------------------- |*** python-cvs-pristine/dist/src/README Fri Mar 5 08:33:21 2004 |--- python/dist/src/README Mon Apr 5 14:30:23 2004 -------------------------- File to patch: README patching file README Hunk #1 succeeded at 1130 (offset 30 lines). can't find file to patch at input line 48 Perhaps you used the wrong -p or --strip option? The text leading up to this was: -------------------------- |*** python-cvs-pristine/dist/src/configure.in Sun Mar 21 17:45:41 2004 |--- python/dist/src/configure.in Mon Apr 5 16:15:07 2004 -------------------------- File to patch: configure.in patching file configure.in Hunk #2 succeeded at 609 (offset 58 lines). Hunk #3 succeeded at 3072 (offset 112 lines). can't find file to patch at input line 113 Perhaps you used the wrong -p or --strip option? The text leading up to this was: -------------------------- |*** python-cvs-pristine/dist/src/Makefile.pre.in Thu Mar 18 01:51:27 2004 |--- python/dist/src/Makefile.pre.in Mon Apr 5 15:56:00 2004 -------------------------- File to patch: Makefile.pre.in patching file Makefile.pre.in Hunk #2 succeeded at 163 (offset 3 lines). Hunk #4 succeeded at 309 (offset 5 lines). Hunk #6 succeeded at 470 (offset 5 lines). Hunk #7 succeeded at 624 (offset 1 line). Hunk #8 succeeded at 839 (offset 7 lines). Hunk #9 succeeded at 923 (offset 1 line). Hunk #10 succeeded at 969 (offset 7 lines). can't find file to patch at input line 309 Perhaps you used the wrong -p or --strip option? The text leading up to this was: -------------------------- |*** python-cvs-pristine/dist/src/setup.py Sun Mar 21 12:59:46 2004 |--- python/dist/src/setup.py Mon Apr 5 15:20:55 2004 -------------------------- File to patch: setup.py patching file setup.py Hunk #1 succeeded at 198 (offset -2 lines). patching file python/dist/src/config.guess patching file python/dist/src/config.sub [dlambert at lambsys Python-2.4.2]$ [dlambert at lambsys Python-2.4.2]$ [dlambert at lambsys Python-2.4.2]$ autoconf configure.in > configure [dlambert at lambsys Python-2.4.2]$ mkdir cross-build [dlambert at lambsys Python-2.4.2]$ cd cross-build [dlambert at lambsys cross-build]$ ../configure --host=arm-linux --build=i686-pc-li nux-gnu configure: error: cannot run /bin/sh ../config.sub [dlambert at lambsys cross-build]$ ---------------------------------------------------------------------- Comment By: Daniel Goertzen (goertzen) Date: 2005-11-08 15:05 Message: Logged In: YES user_id=843814 You can't configure in the source directory with the cross compile patch. This is explained in the directions. ---------------------------------------------------------------------- Comment By: David Lambert (jdalambert) Date: 2005-11-08 03:12 Message: Logged In: YES user_id=845425 Hmm. not so much luck here. I get the following error after patching then autoconf. I am running on Fedora Core 4. Any suggestions? [dlambert at lambsys Python-2.4.2]$ autoconf configure.in >configure [dlambert at lambsys Python-2.4.2]$ ./configure configure: error: cannot run /bin/sh ./config.sub [dlambert at lambsys Python-2.4.2]$ ---------------------------------------------------------------------- Comment By: Robsa (robsa) Date: 2005-10-13 13:54 Message: Logged In: YES user_id=1277505 Just thought I'd let you know that this patch works against Python 2.4.2. I had Python running on my custom AT91RM9200 board (ARM920T core) in about 20 minutes. *snaps* for Daniel!! ---------------------------------------------------------------------- Comment By: Daniel Goertzen (goertzen) Date: 2005-04-13 19:36 Message: Logged In: YES user_id=843814 It still works for me, so I've had limited interest in working on it further. I think a "real" cross compile patch will involve significant refactoring of distutils and the main setup.py script. Should this start with a PEP? ---------------------------------------------------------------------- Comment By: Ned Ludd (solarx) Date: 2005-04-09 22:43 Message: Logged In: YES user_id=148412 Any progress with this on? python and perl are two of the last major things to overcome in the x-compile world. ---------------------------------------------------------------------- Comment By: Mike Frysinger (vapier) Date: 2004-10-26 18:00 Message: Logged In: YES user_id=114429 we've been using this with uClibc for a while now and it works great ... ive personally built (on amd64) & deployed (on x86/ppc/arm/mips/sh4) python ... would great if this finally made it into the official sources :) ---------------------------------------------------------------------- Comment By: Jeff Epler (jepler) Date: 2004-10-21 03:08 Message: Logged In: YES user_id=2772 This patch applies cleanly to today's CVS head. If building in the source directory while cross compiling fails, please make configure complain about it. This patch makes the build process invoke make recursively, which is a big minus. I'd rather see pgen built with a HOSTCC and just assume python is available on $PATH for the setup.py step. There's no reason to build all the shared modules in buildpython, either, which would speed things up a fair bit. On to how it worked for me: Not cross-compiling, this produces no unexpected test failures in "make test". (redhat9) Cross compiling for i386-pc-bsdi2.1 everything goes fine until it tries to run buildpython and make shared modules, but shared modules don't work in the first place on bsdi2. I did not test the resulting Python binary. Cross compiling for i386-redhat-linux (libc6) some extensions fail to build, but this could be because my header files for the cross-development environment are not complete. Running "make test" tries to invoke the "buildpython/python" and doesn't work. Running it manually I get some skips due to modules that did not build, but everything that did build seems to pass. (OK, so I wrote this before the tests completed, but they're off to a good start) I currently cross-compile python 2.3 for win32 (mingw), and until recently cross-compiled it for bsdi2 and redhat6. However, I did not use configure or the included makefiles to do this (in order to integrate in a non-recursive build procedure that builds several packages), so this patch is unlikely to benefit me directly. I don't think this patch is ready to be applied. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1006238&group_id=5470 From noreply at sourceforge.net Tue Mar 7 22:45:37 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 07 Mar 2006 13:45:37 -0800 Subject: [Patches] [ python-Patches-1006238 ] cross compile patch Message-ID: Patches item #1006238, was opened at 2004-08-09 17:05 Message generated for change (Comment added) made by goertzen You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1006238&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Build Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Daniel Goertzen (goertzen) Assigned to: Nobody/Anonymous (nobody) Summary: cross compile patch Initial Comment: Here's a cross compile patch I prepared a while ago but never got around to submitting. I've been using it happily for months to cross compile python for embedded systems. Below is a descriptive excerpt from the patch. Also note that the patch modifies configure.in, but not configure. You will need to regenerate configure with something like autoconf configure.in >configure This patch is inpsired from work by Klaus Reimer at http://www.ailis.de/~k/docs/crosscompiling/python.php + Cross Compiling + --------------- + + Python can be cross compiled by supplying different --host and --build + parameters to configure. (Python is compiled on the "build" system + and executed on the "host" system, in case you forgot :). Python is + tricky to cross compile because it needs to execute parts of itself + during construction. To work around this, make's VPATH feature is + used to compile a native python in the subdirectory "buildpython". + When parts of python need to be executed during construction, the + "buildpython" versions are used. + + A consequence of using the VPATH feature is that you may not do a + cross compile build in the source directory. In other words, do this: + + mkdir mydir + cd mydir + ../Python/configure --host=powerpc-405-linux-gnu --build=i686-pc-linux-gnu + make + + Cross compiling works well under linux, mileage may vary for other + platforms. + + A few reminders on using configure to cross compile: + - Cross compile tools must be in the PATH. + - Cross compile tools must be prefixed with the host type + (ie powerpc-405-linux-gnu-cc, powerpc-405-linux-gnu-ranlib, ...) + - CC, CXX, AR, and RANLIB must be undefined when running configure and + make. Configure will detect them. + + If you need a cross compiler, check out Dan Kegel's crosstool: + http://www.kegel.com/crosstool + + ---------------------------------------------------------------------- >Comment By: Daniel Goertzen (goertzen) Date: 2006-03-07 15:45 Message: Logged In: YES user_id=843814 I use this command: make install prefix=/my/temp/dir ---------------------------------------------------------------------- Comment By: Nicolas (nico0438) Date: 2006-03-07 15:30 Message: Logged In: YES user_id=1330285 Hi again, It seems I'm successfull in cross-compiling python. But I'm not sure of what I have to save on the host platform. There is python executable of course. But there is no lib directory with .so files and .py files in the directory where python is built. Can you tell me what files/directories you save on your host platform ? Thanks again for your support. Nicolas ---------------------------------------------------------------------- Comment By: Daniel Goertzen (goertzen) Date: 2006-03-06 09:12 Message: Logged In: YES user_id=843814 Hi hugo. The problems you are having are less python related and more system-building/cross-development issues, and this is the wrong forum for hashing out this stuff out. I recommend building a linux-from-scratch system (http://www.linuxfromscratch.org/) on an ordinary PC to learn how the insides of linux machine works and how to fix things when they go wrong. Good luck, Dan. ---------------------------------------------------------------------- Comment By: hugo (hugo_koopmans) Date: 2006-03-04 14:02 Message: Logged In: YES user_id=1229536 Hi there, I am trying to cross compile python on the fox board (etrax). now everything seemed to go well but when running the python binary is says: ./python: error while loading shared libraries: libstdc++.so.5: cannot load shared object file: No such file or directory I only ftp-ed the python bin not the (much bigger) libpython2.4a .... seems this is a library archive of some kind ? do i need it? how do i use it then? thanx a million if you can help me out. hugo ---------------------------------------------------------------------- Comment By: Daniel Goertzen (goertzen) Date: 2006-02-24 16:32 Message: Logged In: YES user_id=843814 You didn't apply the patch properly. See the other messages about the use of the -p option. Start with a fresh source tree and use: cd Python-2.4.2 patch -p3 <../python-patch.txt ---------------------------------------------------------------------- Comment By: Nicolas (nico0438) Date: 2006-02-24 15:37 Message: Logged In: YES user_id=1330285 If I try to aplly the patch again, I get messages saying a patch has allready been applied. To apply the patch I executed the following : cd Python-2.4.2 patch <../python-patch.txt ---------------------------------------------------------------------- Comment By: Daniel Goertzen (goertzen) Date: 2006-02-24 15:30 Message: Logged In: YES user_id=843814 The build system python should be in "MyPython/buildpython", and the host python should just be in "MyPython" Are you sure you applied the patch right? What you're getting is what would happen if you didn't apply the patch at all. ---------------------------------------------------------------------- Comment By: Nicolas (nico0438) Date: 2006-02-24 15:19 Message: Logged In: YES user_id=1330285 Yes I guess. But it seems that all I get is for the build system. If I try to execute on the build system ./python it runs. Also, there is no hostbuild subdirectory. Is it ok ? Nicolas ---------------------------------------------------------------------- Comment By: Daniel Goertzen (goertzen) Date: 2006-02-24 15:14 Message: Logged In: YES user_id=843814 > I then cd to a "MyPython" directory. > I call ../Python-2.4.2/configure ... Then your files should be in your "MyPython" directory. ---------------------------------------------------------------------- Comment By: Nicolas (nico0438) Date: 2006-02-24 14:54 Message: Logged In: YES user_id=1330285 Me again, sorry... What Should I get after compilation has finished ? Where are the files for my target ? Nicolas ---------------------------------------------------------------------- Comment By: Nicolas (nico0438) Date: 2006-02-24 13:55 Message: Logged In: YES user_id=1330285 Hi again, I finaly dad enought time to work on my project. So, I compiled autoconf tools for my system. Then, I rerun all the steps successfully. Thanks again for your help. Nicolas ---------------------------------------------------------------------- Comment By: nicolas pinault (nico38) Date: 2006-02-24 09:12 Message: Logged In: YES user_id=1081828 You are right, I have misunderstood --build and --host signification. And I also forgotten to run autoconf partialy because I don't have autoconf installed on my system. So I didn't pay attention it didn't run. Thanks for your help. I'll let you know if this works in a few days. Nicolas ---------------------------------------------------------------------- Comment By: Daniel Goertzen (goertzen) Date: 2006-02-24 08:51 Message: Logged In: YES user_id=843814 Did you run autoconf after patching as instructed? Also, your --build and --host options seem backwards. host is the arch you want python to run on, build is the arch you build python on. Cheers, Dan. ---------------------------------------------------------------------- Comment By: nicolas pinault (nico38) Date: 2006-02-24 06:38 Message: Logged In: YES user_id=1081828 Hi, I try to cross compile Python-2.4.2 for an etrax processor. I have successfully applied the patch to Python sources. I then cd to a "MyPython" directory. I call ../Python-2.4.2/configure --build cris --host i386-linux It works ok (did not see an error) I all make I get the following error after a while : make : *** No rule to make target '@BUILDPGEN@', needed by '../Python-2.4.2/Include/graminit.h'. Stop. Any Idea ? Nicolas ---------------------------------------------------------------------- Comment By: xudong (xudong888) Date: 2006-01-10 08:45 Message: Logged In: YES user_id=1420135 I have resolved my question,now I can run python on the mips machine,and can run some binary build by python.Can I also cross compile pygame for python?But the pygame source does't has 'configure' and 'Makefiel' files,setup.py instead in source package.How should I do? Thanks :-) ---------------------------------------------------------------------- Comment By: xudong (xudong888) Date: 2006-01-06 05:08 Message: Logged In: YES user_id=1420135 If you have accounts of MSN,please add me.My accounts is xudong_888 at hotmail.com. I am very impatient.I hope I can get some help from you.Thanks. ---------------------------------------------------------------------- Comment By: xudong (xudong888) Date: 2006-01-06 04:57 Message: Logged In: YES user_id=1420135 Thank you for your rapid answer.But I still can't solve my question.I can't find the whole instructions. Can you give me the whole instructions by EMAIL,my email is xudong888 at 163.com,thanks. My "host" system is mips embbed_linux,the release of the linux kernel is 2.4.xx and the CPU type is MIPS 4Kc.There are no python installed on this system.My "build" system is i86 and operate system is RedHat9.0,and has installed python2.4.1 and cross-compiling Tools mipsel-linux-gcc.I can cross compile C program for the "host" system.I have writed some program with python language.I can get the binary from python script by use freeze.py on the "build" system. Now I want to run the binary on the "host" system.Can you tell me how should I do. in addition,I don't know what parameter I should input to use this patch. finally,I'm sorry for my poor English.I like python very much,but I can't get help in chinese. ---------------------------------------------------------------------- Comment By: Daniel Goertzen (goertzen) Date: 2006-01-05 11:24 Message: Logged In: YES user_id=843814 After configure you run "make". But did you use configure as the instructions say? You cannot just use "./configure". Good luck, Dan. ---------------------------------------------------------------------- Comment By: xudong (xudong888) Date: 2006-01-05 10:55 Message: Logged In: YES user_id=1420135 I am a Chinese and my English is very poor.I'm sorry if what I said is wrong.My question is What should I do after './configure'.Before this I have done patch and autoconf. Thanks :-) ---------------------------------------------------------------------- Comment By: David Lambert (jdalambert) Date: 2005-11-08 10:06 Message: Logged In: YES user_id=845425 Oops! All works fine now. Thanks :-) ---------------------------------------------------------------------- Comment By: Daniel Goertzen (goertzen) Date: 2005-11-08 09:09 Message: Logged In: YES user_id=843814 patch isn't lying about wrong -p options. Use -p3 instead of -p0. Cheers, Dan. ---------------------------------------------------------------------- Comment By: David Lambert (jdalambert) Date: 2005-11-08 08:26 Message: Logged In: YES user_id=845425 Thanks for the quick reply, and sorry for the confusion. I DID try the cross compile in a sub directory. That failed with the same error. I then tried a non-cross build in the main directory, that also failed (which was my previous post). Here is my complete transcript after untarring Python: [dlambert at lambsys Python-2.4.2]$ patch -p0 < ../python-patch can't find file to patch at input line 3 Perhaps you used the wrong -p or --strip option? The text leading up to this was: -------------------------- |*** python-cvs-pristine/dist/src/README Fri Mar 5 08:33:21 2004 |--- python/dist/src/README Mon Apr 5 14:30:23 2004 -------------------------- File to patch: README patching file README Hunk #1 succeeded at 1130 (offset 30 lines). can't find file to patch at input line 48 Perhaps you used the wrong -p or --strip option? The text leading up to this was: -------------------------- |*** python-cvs-pristine/dist/src/configure.in Sun Mar 21 17:45:41 2004 |--- python/dist/src/configure.in Mon Apr 5 16:15:07 2004 -------------------------- File to patch: configure.in patching file configure.in Hunk #2 succeeded at 609 (offset 58 lines). Hunk #3 succeeded at 3072 (offset 112 lines). can't find file to patch at input line 113 Perhaps you used the wrong -p or --strip option? The text leading up to this was: -------------------------- |*** python-cvs-pristine/dist/src/Makefile.pre.in Thu Mar 18 01:51:27 2004 |--- python/dist/src/Makefile.pre.in Mon Apr 5 15:56:00 2004 -------------------------- File to patch: Makefile.pre.in patching file Makefile.pre.in Hunk #2 succeeded at 163 (offset 3 lines). Hunk #4 succeeded at 309 (offset 5 lines). Hunk #6 succeeded at 470 (offset 5 lines). Hunk #7 succeeded at 624 (offset 1 line). Hunk #8 succeeded at 839 (offset 7 lines). Hunk #9 succeeded at 923 (offset 1 line). Hunk #10 succeeded at 969 (offset 7 lines). can't find file to patch at input line 309 Perhaps you used the wrong -p or --strip option? The text leading up to this was: -------------------------- |*** python-cvs-pristine/dist/src/setup.py Sun Mar 21 12:59:46 2004 |--- python/dist/src/setup.py Mon Apr 5 15:20:55 2004 -------------------------- File to patch: setup.py patching file setup.py Hunk #1 succeeded at 198 (offset -2 lines). patching file python/dist/src/config.guess patching file python/dist/src/config.sub [dlambert at lambsys Python-2.4.2]$ [dlambert at lambsys Python-2.4.2]$ [dlambert at lambsys Python-2.4.2]$ autoconf configure.in > configure [dlambert at lambsys Python-2.4.2]$ mkdir cross-build [dlambert at lambsys Python-2.4.2]$ cd cross-build [dlambert at lambsys cross-build]$ ../configure --host=arm-linux --build=i686-pc-li nux-gnu configure: error: cannot run /bin/sh ../config.sub [dlambert at lambsys cross-build]$ ---------------------------------------------------------------------- Comment By: Daniel Goertzen (goertzen) Date: 2005-11-08 08:05 Message: Logged In: YES user_id=843814 You can't configure in the source directory with the cross compile patch. This is explained in the directions. ---------------------------------------------------------------------- Comment By: David Lambert (jdalambert) Date: 2005-11-07 20:12 Message: Logged In: YES user_id=845425 Hmm. not so much luck here. I get the following error after patching then autoconf. I am running on Fedora Core 4. Any suggestions? [dlambert at lambsys Python-2.4.2]$ autoconf configure.in >configure [dlambert at lambsys Python-2.4.2]$ ./configure configure: error: cannot run /bin/sh ./config.sub [dlambert at lambsys Python-2.4.2]$ ---------------------------------------------------------------------- Comment By: Robsa (robsa) Date: 2005-10-13 06:54 Message: Logged In: YES user_id=1277505 Just thought I'd let you know that this patch works against Python 2.4.2. I had Python running on my custom AT91RM9200 board (ARM920T core) in about 20 minutes. *snaps* for Daniel!! ---------------------------------------------------------------------- Comment By: Daniel Goertzen (goertzen) Date: 2005-04-13 12:36 Message: Logged In: YES user_id=843814 It still works for me, so I've had limited interest in working on it further. I think a "real" cross compile patch will involve significant refactoring of distutils and the main setup.py script. Should this start with a PEP? ---------------------------------------------------------------------- Comment By: Ned Ludd (solarx) Date: 2005-04-09 15:43 Message: Logged In: YES user_id=148412 Any progress with this on? python and perl are two of the last major things to overcome in the x-compile world. ---------------------------------------------------------------------- Comment By: Mike Frysinger (vapier) Date: 2004-10-26 11:00 Message: Logged In: YES user_id=114429 we've been using this with uClibc for a while now and it works great ... ive personally built (on amd64) & deployed (on x86/ppc/arm/mips/sh4) python ... would great if this finally made it into the official sources :) ---------------------------------------------------------------------- Comment By: Jeff Epler (jepler) Date: 2004-10-20 20:08 Message: Logged In: YES user_id=2772 This patch applies cleanly to today's CVS head. If building in the source directory while cross compiling fails, please make configure complain about it. This patch makes the build process invoke make recursively, which is a big minus. I'd rather see pgen built with a HOSTCC and just assume python is available on $PATH for the setup.py step. There's no reason to build all the shared modules in buildpython, either, which would speed things up a fair bit. On to how it worked for me: Not cross-compiling, this produces no unexpected test failures in "make test". (redhat9) Cross compiling for i386-pc-bsdi2.1 everything goes fine until it tries to run buildpython and make shared modules, but shared modules don't work in the first place on bsdi2. I did not test the resulting Python binary. Cross compiling for i386-redhat-linux (libc6) some extensions fail to build, but this could be because my header files for the cross-development environment are not complete. Running "make test" tries to invoke the "buildpython/python" and doesn't work. Running it manually I get some skips due to modules that did not build, but everything that did build seems to pass. (OK, so I wrote this before the tests completed, but they're off to a good start) I currently cross-compile python 2.3 for win32 (mingw), and until recently cross-compiled it for bsdi2 and redhat6. However, I did not use configure or the included makefiles to do this (in order to integrate in a non-recursive build procedure that builds several packages), so this patch is unlikely to benefit me directly. I don't think this patch is ready to be applied. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1006238&group_id=5470 From noreply at sourceforge.net Wed Mar 8 16:50:55 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 08 Mar 2006 07:50:55 -0800 Subject: [Patches] [ python-Patches-1445739 ] New with semantics Message-ID: Patches item #1445739, was opened at 2006-03-08 10: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=1445739&group_id=5470 Please note that this 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: Guido van Rossum (gvanrossum) Assigned to: Guido van Rossum (gvanrossum) Summary: New with semantics Initial Comment: Here's a patch that implements the new with statement semantics: if __exit__ got passed an exception, it is only swallowed when __exit__ returns *true*. So it is no longer necessary for __exit__ handlers to re-raise the exception. This is a bit rough still -- existing unit tests have been adjusted, but there should be additional unit tests for the new functionality. Also the re-raise code in various __exit__ handlers coded in the previous patch could be removed (note that re-raising doesn't do any harm -- it's just not necessary). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1445739&group_id=5470 From noreply at sourceforge.net Wed Mar 8 18:32:54 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 08 Mar 2006 09:32:54 -0800 Subject: [Patches] [ python-Patches-1434038 ] Make property use the getter's __doc__ if no doc argument Message-ID: Patches item #1434038, was opened at 2006-02-18 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=1434038&group_id=5470 Please note that this 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: Georg Brandl (birkenfeld) Assigned to: Guido van Rossum (gvanrossum) Summary: Make property use the getter's __doc__ if no doc argument Initial Comment: As requested by Guido in http://mail.python.org/pipermail/python-dev/2006-February/061320.html. The patch adds a check that fget, fset and fdel are callable, if present. Please check for ref leaks et al. ---------------------------------------------------------------------- >Comment By: Georg Brandl (gbrandl) Date: 2006-03-08 17:32 Message: Logged In: YES user_id=849994 Ping! ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2006-02-19 20:08 Message: Logged In: YES user_id=6380 I'll try to review this ASAP. ---------------------------------------------------------------------- Comment By: Georg Brandl (birkenfeld) Date: 2006-02-18 18:51 Message: Logged In: YES user_id=1188172 Thanks for the review. Attaching new patches with your corrections. I also added a DECREF which I think is necessary. ---------------------------------------------------------------------- Comment By: Alex Martelli (aleax) Date: 2006-02-18 15:21 Message: Logged In: YES user_id=60314 in property-get-doc.diff: if doc is None and fget.__doc__ is not None: would raise a confusing TypeError when doc is fget is None -- check for that case explicitly to raise a specific exception. Also, property(fset=foo) used to work and thus must keep working. Similarly, the C code if ((get_doc = PyObject_GetAttrString(get, "__doc__"))) must reset the errorstate if get_doc is NULL. in property-get-doc-2.diff: Add unittest to check that property(fset=somecallable) keeps working. Alex ---------------------------------------------------------------------- Comment By: Georg Brandl (birkenfeld) Date: 2006-02-18 09:51 Message: Logged In: YES user_id=1188172 Adding docs and test suite changes. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1434038&group_id=5470 From noreply at sourceforge.net Wed Mar 8 18:47:28 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 08 Mar 2006 09:47:28 -0800 Subject: [Patches] [ python-Patches-1434038 ] Make property use the getter's __doc__ if no doc argument Message-ID: Patches item #1434038, was opened at 2006-02-18 03:37 Message generated for change (Comment added) made by gvanrossum You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1434038&group_id=5470 Please note that this 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: Georg Brandl (birkenfeld) Assigned to: Guido van Rossum (gvanrossum) Summary: Make property use the getter's __doc__ if no doc argument Initial Comment: As requested by Guido in http://mail.python.org/pipermail/python-dev/2006-February/061320.html. The patch adds a check that fget, fset and fdel are callable, if present. Please check for ref leaks et al. ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2006-03-08 12:47 Message: Logged In: YES user_id=6380 Sorry, I really don't like the callable checks. IMO they're for wimps. You should be testing your code anyway, and then bad property args will show up the first time they are called. Without those, I'm fine with the changes. Discuss on python-def if you disagree. ---------------------------------------------------------------------- Comment By: Georg Brandl (gbrandl) Date: 2006-03-08 12:32 Message: Logged In: YES user_id=849994 Ping! ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2006-02-19 15:08 Message: Logged In: YES user_id=6380 I'll try to review this ASAP. ---------------------------------------------------------------------- Comment By: Georg Brandl (birkenfeld) Date: 2006-02-18 13:51 Message: Logged In: YES user_id=1188172 Thanks for the review. Attaching new patches with your corrections. I also added a DECREF which I think is necessary. ---------------------------------------------------------------------- Comment By: Alex Martelli (aleax) Date: 2006-02-18 10:21 Message: Logged In: YES user_id=60314 in property-get-doc.diff: if doc is None and fget.__doc__ is not None: would raise a confusing TypeError when doc is fget is None -- check for that case explicitly to raise a specific exception. Also, property(fset=foo) used to work and thus must keep working. Similarly, the C code if ((get_doc = PyObject_GetAttrString(get, "__doc__"))) must reset the errorstate if get_doc is NULL. in property-get-doc-2.diff: Add unittest to check that property(fset=somecallable) keeps working. Alex ---------------------------------------------------------------------- Comment By: Georg Brandl (birkenfeld) Date: 2006-02-18 04:51 Message: Logged In: YES user_id=1188172 Adding docs and test suite changes. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1434038&group_id=5470 From david.w.robinson at faa.gov Wed Mar 8 18:42:28 2006 From: david.w.robinson at faa.gov (david.w.robinson at faa.gov) Date: Wed, 8 Mar 2006 12:42:28 -0500 Subject: [Patches] Gotham Alerts: Monthly stock tips Message-ID: I am interested in receiving your monthly stock alerts. thanks, Dave From noreply at sourceforge.net Wed Mar 8 19:10:03 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 08 Mar 2006 10:10:03 -0800 Subject: [Patches] [ python-Patches-1434038 ] Make property use the getter's __doc__ if no doc argument Message-ID: Patches item #1434038, was opened at 2006-02-18 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=1434038&group_id=5470 Please note that this 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: Georg Brandl (birkenfeld) >Assigned to: Georg Brandl (gbrandl) Summary: Make property use the getter's __doc__ if no doc argument Initial Comment: As requested by Guido in http://mail.python.org/pipermail/python-dev/2006-February/061320.html. The patch adds a check that fget, fset and fdel are callable, if present. Please check for ref leaks et al. ---------------------------------------------------------------------- >Comment By: Georg Brandl (gbrandl) Date: 2006-03-08 18:10 Message: Logged In: YES user_id=849994 Fine with me too. Committed patch without callable checks as revision 42916. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2006-03-08 17:47 Message: Logged In: YES user_id=6380 Sorry, I really don't like the callable checks. IMO they're for wimps. You should be testing your code anyway, and then bad property args will show up the first time they are called. Without those, I'm fine with the changes. Discuss on python-def if you disagree. ---------------------------------------------------------------------- Comment By: Georg Brandl (gbrandl) Date: 2006-03-08 17:32 Message: Logged In: YES user_id=849994 Ping! ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2006-02-19 20:08 Message: Logged In: YES user_id=6380 I'll try to review this ASAP. ---------------------------------------------------------------------- Comment By: Georg Brandl (birkenfeld) Date: 2006-02-18 18:51 Message: Logged In: YES user_id=1188172 Thanks for the review. Attaching new patches with your corrections. I also added a DECREF which I think is necessary. ---------------------------------------------------------------------- Comment By: Alex Martelli (aleax) Date: 2006-02-18 15:21 Message: Logged In: YES user_id=60314 in property-get-doc.diff: if doc is None and fget.__doc__ is not None: would raise a confusing TypeError when doc is fget is None -- check for that case explicitly to raise a specific exception. Also, property(fset=foo) used to work and thus must keep working. Similarly, the C code if ((get_doc = PyObject_GetAttrString(get, "__doc__"))) must reset the errorstate if get_doc is NULL. in property-get-doc-2.diff: Add unittest to check that property(fset=somecallable) keeps working. Alex ---------------------------------------------------------------------- Comment By: Georg Brandl (birkenfeld) Date: 2006-02-18 09:51 Message: Logged In: YES user_id=1188172 Adding docs and test suite changes. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1434038&group_id=5470 From noreply at sourceforge.net Thu Mar 9 13:38:00 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 09 Mar 2006 04:38:00 -0800 Subject: [Patches] [ python-Patches-1446372 ] new exit and quit objects Message-ID: Patches item #1446372, was opened at 2006-03-09 12: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=1446372&group_id=5470 Please note that this 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: Georg Brandl (gbrandl) Assigned to: Nobody/Anonymous (nobody) Summary: new exit and quit objects Initial Comment: As discussed on python-dev, starting with http://mail.python.org/pipermail/python-dev/2006-March/062156.html. Here I'm taking the "quit() is synonymous to sys.exit()" with a special __repr__ approach. An alternative would be the "quit() -> SystemExit("quit() called")" approach. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1446372&group_id=5470 From noreply at sourceforge.net Thu Mar 9 15:58:20 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 09 Mar 2006 06:58:20 -0800 Subject: [Patches] [ python-Patches-1446489 ] zipfile: support for ZIP64 Message-ID: Patches item #1446489, was opened at 2006-03-09 15:58 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=1446489&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Library (Lib) Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: Ronald Oussoren (ronaldoussoren) Assigned to: Nobody/Anonymous (nobody) Summary: zipfile: support for ZIP64 Initial Comment: The attached patch implements support for ZIP64, that is zipfiles containing very large (>4GByte) files and zipfiles that are larger than 4GByte themselves. The output of this patch can be read by pkzip (see below for the actual version I used for testing). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1446489&group_id=5470 From noreply at sourceforge.net Thu Mar 9 16:28:59 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 09 Mar 2006 07:28:59 -0800 Subject: [Patches] [ python-Patches-1446489 ] zipfile: support for ZIP64 Message-ID: Patches item #1446489, was opened at 2006-03-09 15:58 Message generated for change (Comment added) made by ronaldoussoren You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1446489&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Library (Lib) Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: Ronald Oussoren (ronaldoussoren) Assigned to: Nobody/Anonymous (nobody) Summary: zipfile: support for ZIP64 Initial Comment: The attached patch implements support for ZIP64, that is zipfiles containing very large (>4GByte) files and zipfiles that are larger than 4GByte themselves. The output of this patch can be read by pkzip (see below for the actual version I used for testing). ---------------------------------------------------------------------- >Comment By: Ronald Oussoren (ronaldoussoren) Date: 2006-03-09 16:28 Message: Logged In: YES user_id=580910 Oops, I've uploaded the wrong file. zipfile-zip64.patch is the correct one. I've tested the correctness of created archives using this version of pkzip: pkzipc -version PKZIP(R) Server Version 8 ZIP Compression Utility for Linux X86 Copyright (C) 1989-2005 PKWARE, Inc. All Rights Reserved. Evaluation Version PKZIP Reg. U.S. Pat. and Tm. Off. Patent No. 5,051,745 Patent Pending Version 8.40.66 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1446489&group_id=5470 From noreply at sourceforge.net Thu Mar 9 17:13:24 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 09 Mar 2006 08:13:24 -0800 Subject: [Patches] [ python-Patches-1446372 ] new exit and quit objects Message-ID: Patches item #1446372, was opened at 2006-03-09 07:37 Message generated for change (Comment added) made by jimjjewett You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1446372&group_id=5470 Please note that this 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: Georg Brandl (gbrandl) Assigned to: Nobody/Anonymous (nobody) Summary: new exit and quit objects Initial Comment: As discussed on python-dev, starting with http://mail.python.org/pipermail/python-dev/2006-March/062156.html. Here I'm taking the "quit() is synonymous to sys.exit()" with a special __repr__ approach. An alternative would be the "quit() -> SystemExit("quit() called")" approach. ---------------------------------------------------------------------- Comment By: Jim Jewett (jimjjewett) Date: 2006-03-09 11:13 Message: Logged In: YES user_id=764593 Georg -- I just assigned you RFE 1404859, because this patch would close it. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1446372&group_id=5470 From noreply at sourceforge.net Thu Mar 9 23:53:21 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 09 Mar 2006 14:53:21 -0800 Subject: [Patches] [ python-Patches-1446372 ] new exit and quit objects Message-ID: Patches item #1446372, was opened at 2006-03-09 07:37 Message generated for change (Comment added) made by gvanrossum You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1446372&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Library (Lib) Group: Python 2.5 Status: Open >Resolution: Accepted Priority: 5 Submitted By: Georg Brandl (gbrandl) >Assigned to: Georg Brandl (gbrandl) Summary: new exit and quit objects Initial Comment: As discussed on python-dev, starting with http://mail.python.org/pipermail/python-dev/2006-March/062156.html. Here I'm taking the "quit() is synonymous to sys.exit()" with a special __repr__ approach. An alternative would be the "quit() -> SystemExit("quit() called")" approach. ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2006-03-09 17:53 Message: Logged In: YES user_id=6380 Looks good. Check it in! ---------------------------------------------------------------------- Comment By: Jim Jewett (jimjjewett) Date: 2006-03-09 11:13 Message: Logged In: YES user_id=764593 Georg -- I just assigned you RFE 1404859, because this patch would close it. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1446372&group_id=5470 From noreply at sourceforge.net Fri Mar 10 00:23:21 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 09 Mar 2006 15:23:21 -0800 Subject: [Patches] [ python-Patches-1446372 ] new exit and quit objects Message-ID: Patches item #1446372, was opened at 2006-03-09 12:37 Message generated for change (Comment added) made by gbrandl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1446372&group_id=5470 Please note that this 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: Georg Brandl (gbrandl) Assigned to: Georg Brandl (gbrandl) Summary: new exit and quit objects Initial Comment: As discussed on python-dev, starting with http://mail.python.org/pipermail/python-dev/2006-March/062156.html. Here I'm taking the "quit() is synonymous to sys.exit()" with a special __repr__ approach. An alternative would be the "quit() -> SystemExit("quit() called")" approach. ---------------------------------------------------------------------- >Comment By: Georg Brandl (gbrandl) Date: 2006-03-09 23:23 Message: Logged In: YES user_id=849994 Committed in rev. 42948. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2006-03-09 22:53 Message: Logged In: YES user_id=6380 Looks good. Check it in! ---------------------------------------------------------------------- Comment By: Jim Jewett (jimjjewett) Date: 2006-03-09 16:13 Message: Logged In: YES user_id=764593 Georg -- I just assigned you RFE 1404859, because this patch would close it. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1446372&group_id=5470 From noreply at sourceforge.net Fri Mar 10 01:21:40 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 09 Mar 2006 16:21:40 -0800 Subject: [Patches] [ python-Patches-1446847 ] patch for 1441408 compiler fails to spot extended slice Message-ID: Patches item #1446847, was opened at 2006-03-09 18:21 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1446847&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Parser/Compiler Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: Grant Olson (logistix) Assigned to: Nobody/Anonymous (nobody) Summary: patch for 1441408 compiler fails to spot extended slice Initial Comment: Attached is a patch for bug 1441408 (svn head compiler fails to spot extended slicing). The problem was that the new compiler was assuming that a null step value meant that normal slicing was being used. I did have to modify the .asdl for this to work, but after trying a few approaches this seemed like the simplest. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1446847&group_id=5470 From noreply at sourceforge.net Fri Mar 10 03:33:08 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 09 Mar 2006 18:33:08 -0800 Subject: [Patches] [ python-Patches-1446922 ] Patch for bug 1441486: bad unary minus folding in compiler Message-ID: Patches item #1446922, was opened at 2006-03-09 20: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=1446922&group_id=5470 Please note that this 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: Grant Olson (logistix) Assigned to: Nobody/Anonymous (nobody) Summary: Patch for bug 1441486: bad unary minus folding in compiler Initial Comment: In the old compiler, there was a optimization in com_factor that folded a unary minus against a constant. In the new AST, it looks like numbers are converted from strings into PyObjects earlier in the pipeline. The compiler does fold a unary minus against a constant, but since the PyObject has already been created, it may return a PyLong when a PyInt is sufficient. This patch adds a check that will convert a PyLong object back into a PyInt if possible. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1446922&group_id=5470 From noreply at sourceforge.net Fri Mar 10 09:14:48 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 10 Mar 2006 00:14:48 -0800 Subject: [Patches] [ python-Patches-1446922 ] Patch for bug 1441486: bad unary minus folding in compiler Message-ID: Patches item #1446922, was opened at 2006-03-10 02:33 Message generated for change (Settings changed) made by gbrandl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1446922&group_id=5470 Please note that this 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: Grant Olson (logistix) >Assigned to: Neal Norwitz (nnorwitz) Summary: Patch for bug 1441486: bad unary minus folding in compiler Initial Comment: In the old compiler, there was a optimization in com_factor that folded a unary minus against a constant. In the new AST, it looks like numbers are converted from strings into PyObjects earlier in the pipeline. The compiler does fold a unary minus against a constant, but since the PyObject has already been created, it may return a PyLong when a PyInt is sufficient. This patch adds a check that will convert a PyLong object back into a PyInt if possible. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1446922&group_id=5470 From noreply at sourceforge.net Fri Mar 10 09:14:53 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 10 Mar 2006 00:14:53 -0800 Subject: [Patches] [ python-Patches-1446847 ] patch for 1441408 compiler fails to spot extended slice Message-ID: Patches item #1446847, was opened at 2006-03-10 00:21 Message generated for change (Settings changed) made by gbrandl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1446847&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Parser/Compiler Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: Grant Olson (logistix) >Assigned to: Neal Norwitz (nnorwitz) Summary: patch for 1441408 compiler fails to spot extended slice Initial Comment: Attached is a patch for bug 1441408 (svn head compiler fails to spot extended slicing). The problem was that the new compiler was assuming that a null step value meant that normal slicing was being used. I did have to modify the .asdl for this to work, but after trying a few approaches this seemed like the simplest. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1446847&group_id=5470 From noreply at sourceforge.net Fri Mar 10 19:12:38 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 10 Mar 2006 10:12:38 -0800 Subject: [Patches] [ python-Patches-1447410 ] logging: findCaller() sometimes raises AttributeError Message-ID: Patches item #1447410, was opened at 2006-03-10 10: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=1447410&group_id=5470 Please note that this 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: Kevin J Bluck (kbluck) Assigned to: Nobody/Anonymous (nobody) Summary: logging: findCaller() sometimes raises AttributeError Initial Comment: I am invoking the logging.log() function via the C API, using PyObject_CallFunction(). I have found that sometimes (not always) the findCaller() function raises this AttributeError: AttributeError: 'NoneType' object has no attribute 'f_code' File "C:\Program Files\Python\Lib\logging\__init__.py", line 1052, in findCaller co = f.f_code File "C:\Program Files\Python\Lib\logging\__init__.py", line 1078, in _log fn, lno, func = self.findCaller() File "C:\Program Files\Python\Lib\logging\__init__.py", line 1043, in log apply(self._log, (level, msg, args), kwargs) File "C:\Program Files\Python\Lib\logging\__init__.py", line 1319, in log apply(root It appears that sometimes, currentframe() is returning None. Attached is a patch for logging/__init__.py which guards against this possibility. Patch is generated against recent SVN head revision 42958. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1447410&group_id=5470 From noreply at sourceforge.net Sat Mar 11 15:07:57 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 11 Mar 2006 06:07:57 -0800 Subject: [Patches] [ python-Patches-1447410 ] logging: findCaller() sometimes raises AttributeError Message-ID: Patches item #1447410, was opened at 2006-03-10 18:12 Message generated for change (Settings changed) made by gbrandl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1447410&group_id=5470 Please note that this 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: Kevin J Bluck (kbluck) >Assigned to: Vinay Sajip (vsajip) Summary: logging: findCaller() sometimes raises AttributeError Initial Comment: I am invoking the logging.log() function via the C API, using PyObject_CallFunction(). I have found that sometimes (not always) the findCaller() function raises this AttributeError: AttributeError: 'NoneType' object has no attribute 'f_code' File "C:\Program Files\Python\Lib\logging\__init__.py", line 1052, in findCaller co = f.f_code File "C:\Program Files\Python\Lib\logging\__init__.py", line 1078, in _log fn, lno, func = self.findCaller() File "C:\Program Files\Python\Lib\logging\__init__.py", line 1043, in log apply(self._log, (level, msg, args), kwargs) File "C:\Program Files\Python\Lib\logging\__init__.py", line 1319, in log apply(root It appears that sometimes, currentframe() is returning None. Attached is a patch for logging/__init__.py which guards against this possibility. Patch is generated against recent SVN head revision 42958. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1447410&group_id=5470 From noreply at sourceforge.net Sun Mar 12 09:40:17 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 12 Mar 2006 00:40:17 -0800 Subject: [Patches] [ python-Patches-1448199 ] ConnectRegistry blocks all threads Message-ID: Patches item #1448199, was opened at 2006-03-12 08:40 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1448199&group_id=5470 Please note that this 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.4 Status: Open Resolution: None Priority: 5 Submitted By: Lars L (larslj) Assigned to: Nobody/Anonymous (nobody) Summary: ConnectRegistry blocks all threads Initial Comment: ConnectRegistry might take quite some time when connecting to a remote machine (especially if it's not responding). It should be possible to run other threads while waiting for this call to return. I notice that some registry calls are enclosed by Py_*_ALLOW_THREADS pairs while some aren't, is there any reason for this? The patch adds Py_*_ALLOW_THREADS around the call to RegConnectRegistry in PC/_winreg.c ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1448199&group_id=5470 From noreply at sourceforge.net Sun Mar 12 14:07:53 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 12 Mar 2006 05:07:53 -0800 Subject: [Patches] [ python-Patches-1368247 ] unicode in email.MIMEText and email/Charset.py Message-ID: Patches item #1368247, was opened at 2005-11-28 09:15 Message generated for change (Settings changed) made by bwarsaw You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1368247&group_id=5470 Please note that this 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: Damjan Georgievski (gdamjan) >Assigned to: Barry A. Warsaw (bwarsaw) Summary: unicode in email.MIMEText and email/Charset.py Initial Comment: This is the test case that fails in python 2.4.1: from email.MIMEText import MIMEText msg = MIMEText(u'\u043a\u0438\u0440\u0438\u043b\u0438\u0446\u0430') msg.set_charset('utf-8') msg.as_string() And attached is a patch to correct it. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1368247&group_id=5470 From noreply at sourceforge.net Sun Mar 12 14:09:42 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 12 Mar 2006 05:09:42 -0800 Subject: [Patches] [ python-Patches-1443875 ] email/charset.py convert() patch Message-ID: Patches item #1443875, was opened at 2006-03-05 23:41 Message generated for change (Comment added) made by bwarsaw You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1443875&group_id=5470 Please note that this 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: Tokio Kikuchi (tkikuchi) Assigned to: Barry A. Warsaw (bwarsaw) Summary: email/charset.py convert() patch Initial Comment: email/charset.py has convert() function to incorporate using different charset for input and output for a language like Japanese. Because the email user agent in Japan frequently use characters outside the range of legitimate JIS charset, these messages are shunted in mailman delivery. Here is a patch to handle this case by replacing the characters by '?' using the 'errors' parameter in unicode/encode functions. This patch includes the unicode string conversion patch in #1368247. ---------------------------------------------------------------------- >Comment By: Barry A. Warsaw (bwarsaw) Date: 2006-03-12 08:09 Message: Logged In: YES user_id=12800 Do you have a test case for this? #1368247 includes one just for the encoding of unicode strings, but not for the error argument. If you can include a simple test case, then I'll add this patch. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1443875&group_id=5470 From noreply at sourceforge.net Sun Mar 12 14:35:32 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 12 Mar 2006 05:35:32 -0800 Subject: [Patches] [ python-Patches-1448297 ] decorator module Message-ID: Patches item #1448297, was opened at 2006-03-12 13: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=1448297&group_id=5470 Please note that this 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: Georg Brandl (gbrandl) Assigned to: Nobody/Anonymous (nobody) Summary: decorator module Initial Comment: This is a first attempt to a decorator standard module containing only @decorator in a C implementation. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1448297&group_id=5470 From noreply at sourceforge.net Sun Mar 12 22:41:27 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 12 Mar 2006 13:41:27 -0800 Subject: [Patches] [ python-Patches-1448484 ] declspec for ssize_t Message-ID: Patches item #1448484, was opened at 2006-03-12 21:41 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1448484&group_id=5470 Please note that this 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: None Priority: 5 Submitted By: Zooko O'Whielacronx (zooko) Assigned to: Nobody/Anonymous (nobody) Summary: declspec for ssize_t Initial Comment: If you apply this patch (against today's SVN trunk) then the new ssize_t funcs will be exported when building a DLL with cygwin gcc 3.4.4. Then you'll hit another problem, about which more in the next patch. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1448484&group_id=5470 From noreply at sourceforge.net Sun Mar 12 22:53:23 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 12 Mar 2006 13:53:23 -0800 Subject: [Patches] [ python-Patches-1448488 ] const PyDict_Type ? Message-ID: Patches item #1448488, was opened at 2006-03-12 21:53 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1448488&group_id=5470 Please note that this 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: Zooko O'Whielacronx (zooko) Assigned to: Nobody/Anonymous (nobody) Summary: const PyDict_Type ? Initial Comment: When I try to compile SVN trunk, plus my recent declspecs-for-ssize_t patch, I get this error from Cygwin gcc 3.4.4: building 'collections' extension gcc -fno-strict-aliasing -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. -I/cygdrive/c/playground/python/trunk/./Include -I./Include -I. -I/cygdrive/c/playground/python/trunk/Include -I/cygdrive/c/playground/python/trunk -c /cygdrive/c/playground/python/trunk/Modules/collectionsmodule.c -o build/temp.cygwin-1.5.19-i686-2.5/collectionsmodule.o /cygdrive/c/playground/python/trunk/Modules/collectionsmodule.c:1314: error: initializer element is not constant /cygdrive/c/playground/python/trunk/Modules/collectionsmodule.c:1314: error: (near initialization for `defdict_type.tp_base') This is with this version of gcc: $ gcc --version gcc (GCC) 3.4.4 (cygming special) (gdc 0.12, using dmd 0.125) Copyright (C) 2004 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. So, with much uncertainty, I applied the attached patch that makes PyDict_Type be const. The whole thing then compiles fine (if you disregard one million warnings about discarding qualifiers from pointer target type), but the resulting python.exe segfaults on startup. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1448488&group_id=5470 From noreply at sourceforge.net Sun Mar 12 23:50:54 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 12 Mar 2006 14:50:54 -0800 Subject: [Patches] [ python-Patches-1448488 ] const PyDict_Type ? Message-ID: Patches item #1448488, was opened at 2006-03-12 16:53 Message generated for change (Comment added) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1448488&group_id=5470 Please note that this 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: Zooko O'Whielacronx (zooko) >Assigned to: Guido van Rossum (gvanrossum) Summary: const PyDict_Type ? Initial Comment: When I try to compile SVN trunk, plus my recent declspecs-for-ssize_t patch, I get this error from Cygwin gcc 3.4.4: building 'collections' extension gcc -fno-strict-aliasing -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. -I/cygdrive/c/playground/python/trunk/./Include -I./Include -I. -I/cygdrive/c/playground/python/trunk/Include -I/cygdrive/c/playground/python/trunk -c /cygdrive/c/playground/python/trunk/Modules/collectionsmodule.c -o build/temp.cygwin-1.5.19-i686-2.5/collectionsmodule.o /cygdrive/c/playground/python/trunk/Modules/collectionsmodule.c:1314: error: initializer element is not constant /cygdrive/c/playground/python/trunk/Modules/collectionsmodule.c:1314: error: (near initialization for `defdict_type.tp_base') This is with this version of gcc: $ gcc --version gcc (GCC) 3.4.4 (cygming special) (gdc 0.12, using dmd 0.125) Copyright (C) 2004 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. So, with much uncertainty, I applied the attached patch that makes PyDict_Type be const. The whole thing then compiles fine (if you disregard one million warnings about discarding qualifiers from pointer target type), but the resulting python.exe segfaults on startup. ---------------------------------------------------------------------- >Comment By: Raymond Hettinger (rhettinger) Date: 2006-03-12 17:50 Message: Logged In: YES user_id=80475 Cygwin seems to be somewhat sensitive to how subtypes are initialized in extensions. The collections.defaultdict PyTypeObject structure may need to be modified to comform to the example in lines 106 and 137 in xxsubtypes.c ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1448488&group_id=5470 From noreply at sourceforge.net Mon Mar 13 00:21:17 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 12 Mar 2006 15:21:17 -0800 Subject: [Patches] [ python-Patches-1448488 ] const PyDict_Type ? Message-ID: Patches item #1448488, was opened at 2006-03-12 16:53 Message generated for change (Comment added) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1448488&group_id=5470 Please note that this 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: Zooko O'Whielacronx (zooko) >Assigned to: Jack Jansen (jackjansen) Summary: const PyDict_Type ? Initial Comment: When I try to compile SVN trunk, plus my recent declspecs-for-ssize_t patch, I get this error from Cygwin gcc 3.4.4: building 'collections' extension gcc -fno-strict-aliasing -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. -I/cygdrive/c/playground/python/trunk/./Include -I./Include -I. -I/cygdrive/c/playground/python/trunk/Include -I/cygdrive/c/playground/python/trunk -c /cygdrive/c/playground/python/trunk/Modules/collectionsmodule.c -o build/temp.cygwin-1.5.19-i686-2.5/collectionsmodule.o /cygdrive/c/playground/python/trunk/Modules/collectionsmodule.c:1314: error: initializer element is not constant /cygdrive/c/playground/python/trunk/Modules/collectionsmodule.c:1314: error: (near initialization for `defdict_type.tp_base') This is with this version of gcc: $ gcc --version gcc (GCC) 3.4.4 (cygming special) (gdc 0.12, using dmd 0.125) Copyright (C) 2004 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. So, with much uncertainty, I applied the attached patch that makes PyDict_Type be const. The whole thing then compiles fine (if you disregard one million warnings about discarding qualifiers from pointer target type), but the resulting python.exe segfaults on startup. ---------------------------------------------------------------------- >Comment By: Raymond Hettinger (rhettinger) Date: 2006-03-12 18:21 Message: Logged In: YES user_id=80475 Zooko, does the code work for you if the tp_base slot is set to zero? ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2006-03-12 17:50 Message: Logged In: YES user_id=80475 Cygwin seems to be somewhat sensitive to how subtypes are initialized in extensions. The collections.defaultdict PyTypeObject structure may need to be modified to comform to the example in lines 106 and 137 in xxsubtypes.c ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1448488&group_id=5470 From noreply at sourceforge.net Mon Mar 13 01:50:59 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 12 Mar 2006 16:50:59 -0800 Subject: [Patches] [ python-Patches-1448488 ] const PyDict_Type ? Message-ID: Patches item #1448488, was opened at 2006-03-12 21:53 Message generated for change (Comment added) made by zooko You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1448488&group_id=5470 Please note that this 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: Zooko O'Whielacronx (zooko) Assigned to: Jack Jansen (jackjansen) Summary: const PyDict_Type ? Initial Comment: When I try to compile SVN trunk, plus my recent declspecs-for-ssize_t patch, I get this error from Cygwin gcc 3.4.4: building 'collections' extension gcc -fno-strict-aliasing -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. -I/cygdrive/c/playground/python/trunk/./Include -I./Include -I. -I/cygdrive/c/playground/python/trunk/Include -I/cygdrive/c/playground/python/trunk -c /cygdrive/c/playground/python/trunk/Modules/collectionsmodule.c -o build/temp.cygwin-1.5.19-i686-2.5/collectionsmodule.o /cygdrive/c/playground/python/trunk/Modules/collectionsmodule.c:1314: error: initializer element is not constant /cygdrive/c/playground/python/trunk/Modules/collectionsmodule.c:1314: error: (near initialization for `defdict_type.tp_base') This is with this version of gcc: $ gcc --version gcc (GCC) 3.4.4 (cygming special) (gdc 0.12, using dmd 0.125) Copyright (C) 2004 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. So, with much uncertainty, I applied the attached patch that makes PyDict_Type be const. The whole thing then compiles fine (if you disregard one million warnings about discarding qualifiers from pointer target type), but the resulting python.exe segfaults on startup. ---------------------------------------------------------------------- >Comment By: Zooko O'Whielacronx (zooko) Date: 2006-03-13 00:50 Message: Logged In: YES user_id=52562 The tp_base slot is zero then compilation finishes normally, and the resulting python.exe starts normally instead of segfaulting. Now running make test and I will report back if it fails. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2006-03-12 23:21 Message: Logged In: YES user_id=80475 Zooko, does the code work for you if the tp_base slot is set to zero? ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2006-03-12 22:50 Message: Logged In: YES user_id=80475 Cygwin seems to be somewhat sensitive to how subtypes are initialized in extensions. The collections.defaultdict PyTypeObject structure may need to be modified to comform to the example in lines 106 and 137 in xxsubtypes.c ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1448488&group_id=5470 From noreply at sourceforge.net Mon Mar 13 12:29:51 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 13 Mar 2006 03:29:51 -0800 Subject: [Patches] [ python-Patches-1448488 ] const PyDict_Type ? Message-ID: Patches item #1448488, was opened at 2006-03-12 21:53 Message generated for change (Comment added) made by zooko You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1448488&group_id=5470 Please note that this 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: Zooko O'Whielacronx (zooko) Assigned to: Jack Jansen (jackjansen) Summary: const PyDict_Type ? Initial Comment: When I try to compile SVN trunk, plus my recent declspecs-for-ssize_t patch, I get this error from Cygwin gcc 3.4.4: building 'collections' extension gcc -fno-strict-aliasing -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. -I/cygdrive/c/playground/python/trunk/./Include -I./Include -I. -I/cygdrive/c/playground/python/trunk/Include -I/cygdrive/c/playground/python/trunk -c /cygdrive/c/playground/python/trunk/Modules/collectionsmodule.c -o build/temp.cygwin-1.5.19-i686-2.5/collectionsmodule.o /cygdrive/c/playground/python/trunk/Modules/collectionsmodule.c:1314: error: initializer element is not constant /cygdrive/c/playground/python/trunk/Modules/collectionsmodule.c:1314: error: (near initialization for `defdict_type.tp_base') This is with this version of gcc: $ gcc --version gcc (GCC) 3.4.4 (cygming special) (gdc 0.12, using dmd 0.125) Copyright (C) 2004 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. So, with much uncertainty, I applied the attached patch that makes PyDict_Type be const. The whole thing then compiles fine (if you disregard one million warnings about discarding qualifiers from pointer target type), but the resulting python.exe segfaults on startup. ---------------------------------------------------------------------- >Comment By: Zooko O'Whielacronx (zooko) Date: 2006-03-13 11:29 Message: Logged In: YES user_id=52562 Here is the result of make test after setting the tp_base slot to 0. 266 tests OK. 3 tests failed: test_mmap test_platform test_time 40 tests skipped: test_aepack test_al test_applesingle test_bsddb test_bsddb185 test_bsddb3 test_cd test_cl test_codecmaps_cn test_codecmaps_hk test_codecmaps_jp test_codecmaps_kr test_codecmaps_tw test_ctypes test_curses test_dbm test_gl test_hashlib_speed test_imgfile test_ioctl test_linuxaudiodev test_locale test_macfs test_macostools test_nis test_normalization test_ossaudiodev test_pep277 test_plistlib test_scriptpackages test_socket_ssl test_socketserver test_sunaudiodev test_tcl test_timeout test_unicode_file test_urllib2net test_urllibnet test_winreg test_winsound 3 skips unexpected on cygwin: test_tcl test_ctypes test_bsddb ---------------------------------------------------------------------- Comment By: Zooko O'Whielacronx (zooko) Date: 2006-03-13 00:50 Message: Logged In: YES user_id=52562 The tp_base slot is zero then compilation finishes normally, and the resulting python.exe starts normally instead of segfaulting. Now running make test and I will report back if it fails. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2006-03-12 23:21 Message: Logged In: YES user_id=80475 Zooko, does the code work for you if the tp_base slot is set to zero? ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2006-03-12 22:50 Message: Logged In: YES user_id=80475 Cygwin seems to be somewhat sensitive to how subtypes are initialized in extensions. The collections.defaultdict PyTypeObject structure may need to be modified to comform to the example in lines 106 and 137 in xxsubtypes.c ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1448488&group_id=5470 From noreply at sourceforge.net Mon Mar 13 15:21:39 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 13 Mar 2006 06:21:39 -0800 Subject: [Patches] [ python-Patches-1448484 ] declspec for ssize_t Message-ID: Patches item #1448484, was opened at 2006-03-12 21:41 Message generated for change (Comment added) made by zooko You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1448484&group_id=5470 Please note that this 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: None Priority: 5 Submitted By: Zooko O'Whielacronx (zooko) Assigned to: Nobody/Anonymous (nobody) Summary: declspec for ssize_t Initial Comment: If you apply this patch (against today's SVN trunk) then the new ssize_t funcs will be exported when building a DLL with cygwin gcc 3.4.4. Then you'll hit another problem, about which more in the next patch. ---------------------------------------------------------------------- >Comment By: Zooko O'Whielacronx (zooko) Date: 2006-03-13 14:21 Message: Logged In: YES user_id=52562 I think the initial summary wasn't clear. With this patch, the new ssize_t feature that was recently merged into trunk compiles on Cygwin. Without this patch, it doesn't. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1448484&group_id=5470 From noreply at sourceforge.net Tue Mar 14 00:35:13 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 13 Mar 2006 15:35:13 -0800 Subject: [Patches] [ python-Patches-1443875 ] email/charset.py convert() patch Message-ID: Patches item #1443875, was opened at 2006-03-06 04:41 Message generated for change (Comment added) made by tkikuchi You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1443875&group_id=5470 Please note that this 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: Tokio Kikuchi (tkikuchi) Assigned to: Barry A. Warsaw (bwarsaw) Summary: email/charset.py convert() patch Initial Comment: email/charset.py has convert() function to incorporate using different charset for input and output for a language like Japanese. Because the email user agent in Japan frequently use characters outside the range of legitimate JIS charset, these messages are shunted in mailman delivery. Here is a patch to handle this case by replacing the characters by '?' using the 'errors' parameter in unicode/encode functions. This patch includes the unicode string conversion patch in #1368247. ---------------------------------------------------------------------- >Comment By: Tokio Kikuchi (tkikuchi) Date: 2006-03-13 23:35 Message: Logged In: YES user_id=67709 Thanks! Here is an example program which fails on 4.0a without the patch. ---------------------------------------------------------------------- Comment By: Barry A. Warsaw (bwarsaw) Date: 2006-03-12 13:09 Message: Logged In: YES user_id=12800 Do you have a test case for this? #1368247 includes one just for the encoding of unicode strings, but not for the error argument. If you can include a simple test case, then I'll add this patch. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1443875&group_id=5470 From noreply at sourceforge.net Tue Mar 14 00:55:15 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 13 Mar 2006 15:55:15 -0800 Subject: [Patches] [ python-Patches-1449244 ] email.message.py charset can be unicode instance Message-ID: Patches item #1449244, was opened at 2006-03-13 23: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=1449244&group_id=5470 Please note that this 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: Tokio Kikuchi (tkikuchi) Assigned to: Nobody/Anonymous (nobody) Summary: email.message.py charset can be unicode instance Initial Comment: *_charset in Charset become unicode instance in email-4.0a. message.py should add this for type test. --- email-4.0a2/email/message.py Mon Mar 6 04:58:33 2006 +++ email/message.py Mon Mar 6 14:59:04 2006 @@ -238,7 +238,7 @@ self.del_param('charset') self._charset = None return - if isinstance(charset, str): + if isinstance(charset, str) or isinstance(charset, unicode): charset = email.charset.Charset(charset) if not isinstance(charset, email.charset.Charset): raise TypeError(charset) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1449244&group_id=5470 From noreply at sourceforge.net Tue Mar 14 00:56:11 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 13 Mar 2006 15:56:11 -0800 Subject: [Patches] [ python-Patches-1449244 ] email.message.py charset can be unicode instance Message-ID: Patches item #1449244, was opened at 2006-03-13 23:55 Message generated for change (Settings changed) made by tkikuchi You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1449244&group_id=5470 Please note that this 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: Tokio Kikuchi (tkikuchi) >Assigned to: Barry A. Warsaw (bwarsaw) Summary: email.message.py charset can be unicode instance Initial Comment: *_charset in Charset become unicode instance in email-4.0a. message.py should add this for type test. --- email-4.0a2/email/message.py Mon Mar 6 04:58:33 2006 +++ email/message.py Mon Mar 6 14:59:04 2006 @@ -238,7 +238,7 @@ self.del_param('charset') self._charset = None return - if isinstance(charset, str): + if isinstance(charset, str) or isinstance(charset, unicode): charset = email.charset.Charset(charset) if not isinstance(charset, email.charset.Charset): raise TypeError(charset) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1449244&group_id=5470 From noreply at sourceforge.net Tue Mar 14 07:11:10 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 13 Mar 2006 22:11:10 -0800 Subject: [Patches] [ python-Patches-1444030 ] Several minor fixes for NULL checks, etc. Message-ID: Patches item #1444030, was opened at 2006-03-06 03:03 Message generated for change (Comment added) made by nnorwitz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1444030&group_id=5470 Please note that this 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: 4 Submitted By: Hye-Shik Chang (perky) Assigned to: Hye-Shik Chang (perky) Summary: Several minor fixes for NULL checks, etc. Initial Comment: Attached patch includes fixes for missing NULL checks, reference leaks on minor cases found by a static analysis tool. It touches: Python/ceval.c Python/traceback.c Python/ast.c Python/modsupport.c Objects/object.c Objects/weakrefobject.c Objects/unicodeobject.c Objects/longobject.c Objects/stringobject.c Parser/firstsets.c Modules/arraymodule.c Modules/zipimport.c Modules/cStringIO.c ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2006-03-13 22:11 Message: Logged In: YES user_id=33168 Ok, I fixed the object.c one, so everything's done here AFAIK. ---------------------------------------------------------------------- Comment By: Hye-Shik Chang (perky) Date: 2006-03-07 08:00 Message: Logged In: YES user_id=55188 Committed as r42894(trunk), r42895(2.4) except a fix for object.c. I'll think about it more tomorrow. :-) Thanks! ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2006-03-06 16:09 Message: Logged In: YES user_id=33168 Object/object.c: You're right, my suggestion would leak v. I originally was going to tell you to just call PyErr_BadInternalCall(), but that is not what PyObject_String() does. It's so messy to add a flag. :-( I don't see any other way at the moment. Can you think of any cleaner solution? Objects/unicodeobject.c: yuck. I didn't notice the shadowing. You're right the outer v does need a DECREF. Please rename the inner v to avoid shadowing. Objects/longobject.c: Oh, I see it now. I would prefer the checks for a == NULL (and b == NULL) to be immediately after they are set from long_invert. There's no reason to defer the check/failure is there? Thanks! ---------------------------------------------------------------------- Comment By: Hye-Shik Chang (perky) Date: 2006-03-06 15:58 Message: Logged In: YES user_id=55188 Thanks for the review, Neal! Object/object.c: I think a reference to v will be leaked then. Then must we add a flag variable to track v? Objects/weakrefobject.c: That sounds more attractive! Objects/unicodeobject.c: The current code have v in two places; inner scope of the ucnhash routine and the function scope. I think function scope v needs to defref'ed. (and, inner v needs to be renamed?) Objects/longobject.c: If a->ob_size < 0, long_invert() is assigned to a while the function can return NULL. So I thought some kind of NULL checking is needed. Objects/stringobject.c: A macro SPLIT_APPEND uses onError label actually. I'll update the patch with your helpful comments soon. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2006-03-06 15:20 Message: Logged In: YES user_id=33168 Thanks Perky! I haven't gotten access to the report yet. All these look fine, with the following exceptions: Python/modsupport.c: This looks like it's a false positive, presumably because of if ((v = PyList_New(n)) == NULL). I changed that code and cleaned up the conditions below. I think the original code was more complex than it needs to be. I checked in this change to modsupport.c. Objects/object.c: To be consistent with PyObject_Str() this should return u"". The current code is wrong, but the patch just returns NULL. I *think* the correct thing to do is set v instead of res, then if that result is NULL, return NULL, ie: v = PyString_FromString(""); if (v == NULL) return NULL; Objects/weakrefobject.c: Your addition is correct, but I wonder if you also need to restore the error before returning like the code below? if (restore_error) PyErr_Restore(err_type, err_value, err_tb); Objects/unicodeobject.c: [block 1945] the current code is correct, but perhaps a bit confusing. goto ucnhashError is called in 3 places I see. The first 2 places, v is not set yet. In the third place, v was already DECREF'd. Perhaps after the DECREF, we should do: v = NULL; ? All other unicode changes are correct. Objects/longobject.c: I disagree with these changes, but the code is broken. I don't believe we should be checking for a or b being NULL. I think the code should be this (the first line is just for context): z = _PyLong_New(size_z); if (z == NULL) return NULL; The callers take care of DECREF'ing a and b and we didn't allocate either of them in this function. Objects/stringobject.c: Since list is always NULL if going to onError, the DECREF is not needed. I would get rid of the whole onError label and just return NULL if the list alloc fails. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1444030&group_id=5470 From noreply at sourceforge.net Tue Mar 14 08:45:49 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 13 Mar 2006 23:45:49 -0800 Subject: [Patches] [ python-Patches-1432399 ] Missing HCI sockets in bluetooth code from socketmodule Message-ID: Patches item #1432399, was opened at 2006-02-15 11:26 Message generated for change (Comment added) made by nnorwitz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1432399&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Modules Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Philippe Biondi (drphil) Assigned to: Nobody/Anonymous (nobody) Summary: Missing HCI sockets in bluetooth code from socketmodule Initial Comment: Bluetooth code in socketmodule does not implement BTPROTO_HCI. This small patch adds the missing code. ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2006-03-13 23:45 Message: Logged In: YES user_id=33168 This patch is missing a return 1; in case BTPROTO_HCI: around line 1310. I don't know if there are other problems or if this code is portable. There are no tests or doc updates. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1432399&group_id=5470 From noreply at sourceforge.net Tue Mar 14 11:18:37 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 14 Mar 2006 02:18:37 -0800 Subject: [Patches] [ python-Patches-1449471 ] Splitting CJK codecs from pythoncore dll Message-ID: Patches item #1449471, was opened at 2006-03-14 19:18 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=1449471&group_id=5470 Please note that this 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: Hye-Shik Chang (perky) Assigned to: Nobody/Anonymous (nobody) Summary: Splitting CJK codecs from pythoncore dll Initial Comment: As many of western language natives have requested it, this patch splits CJK codecs from pythoncore dll. python25.dll shrinks from 2024KB to 1364KB by this. Even some of CJK users would take some advantages for domestic py2exe-ed releases. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1449471&group_id=5470 From noreply at sourceforge.net Wed Mar 15 06:31:38 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 14 Mar 2006 21:31:38 -0800 Subject: [Patches] [ python-Patches-1359365 ] Iterating closed StringIO.StringIO Message-ID: Patches item #1359365, was opened at 2005-11-17 19:03 Message generated for change (Comment added) made by gvanrossum You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1359365&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Library (Lib) Group: None Status: Open Resolution: None Priority: 5 Submitted By: Walter D?rwald (doerwalter) >Assigned to: Walter D?rwald (doerwalter) Summary: Iterating closed StringIO.StringIO Initial Comment: This patch changes StringIO.StringIO.next to raise a ValueError when the stream is closed. This is the same behaviour as for cStringIO.StringIO and real files. ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2006-03-15 00:31 Message: Logged In: YES user_id=6380 Please check this in if you haven't already done so. I need to shed load! ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2005-11-29 11:36 Message: Logged In: YES user_id=89016 There are other discrepancies between StringIO.StringIO and cString.StringIO: isatty() raises a ValueError() for a closed StringIO.StringIO and a closed file, but not for a closed cStringIO.StringIO. And the truncate() method when called with a negative argument raised an IOError for StringIO.StringIO and real files, but not for cStringIO.StringIO. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1359365&group_id=5470 From noreply at sourceforge.net Wed Mar 15 08:59:28 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 14 Mar 2006 23:59:28 -0800 Subject: [Patches] [ python-Patches-1445739 ] New with semantics Message-ID: Patches item #1445739, was opened at 2006-03-08 07:50 Message generated for change (Comment added) made by nnorwitz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1445739&group_id=5470 Please note that this 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: Guido van Rossum (gvanrossum) Assigned to: Guido van Rossum (gvanrossum) Summary: New with semantics Initial Comment: Here's a patch that implements the new with statement semantics: if __exit__ got passed an exception, it is only swallowed when __exit__ returns *true*. So it is no longer necessary for __exit__ handlers to re-raise the exception. This is a bit rough still -- existing unit tests have been adjusted, but there should be additional unit tests for the new functionality. Also the re-raise code in various __exit__ handlers coded in the previous patch could be removed (note that re-raising doesn't do any harm -- it's just not necessary). ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2006-03-14 23:59 Message: Logged In: YES user_id=33168 Guido checked this in a few days ago AFAIK, so closing. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1445739&group_id=5470 From noreply at sourceforge.net Wed Mar 15 09:01:54 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 15 Mar 2006 00:01:54 -0800 Subject: [Patches] [ python-Patches-1436130 ] Incremental codecs Message-ID: Patches item #1436130, was opened at 2006-02-21 11:32 Message generated for change (Comment added) made by nnorwitz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1436130&group_id=5470 Please note that this 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: Walter D?rwald (doerwalter) Assigned to: M.-A. Lemburg (lemburg) Summary: Incremental codecs Initial Comment: This patch extends the codec machinery to add incremental codecs: stateful codecs that don't use a stream API. It adds the following stuff: a class codecs.CodecInfo (a subclass of tuple), that is used as the return value of codecs.lookup(); codecs.IncrementalEncoder and codecs.IncrementalDecoder (the basic interface classes), codecs.BufferedIncrementalDecoder (a class that can be used to implement decoders that must handle incomplete input); codecs.iterencode() and codecs.iterdecode() (generators that use the incremental codecs for encoding/decoding an input iterable). On the C level PyCodec_IncrementalEncoder() and PyCodec_IncrementalDecoder() are added. ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2006-03-15 00:01 Message: Logged In: YES user_id=33168 MAL, do you have any more issues with this patch? Should it be assigned to Martin? MAL, Walter, can you review these patches 1443155 1449471 which I think are related? Should they go in? The first alpha is coming up soon and I'd like to get these patches in ASAP. ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2006-03-03 09:39 Message: Logged In: YES user_id=89016 This fourth version of the patch removes the changes to Lib/encodings/idna.py (only the addition of the IncrementalEncoder/IncrementalDecoder and the changed getregentry() remain). This patch to idna.py probably only makes sense once this patch is in. > Is it possible to make IncrementalEncoder/Decoder > instances iterable per-se (without the need to go > through the helper functions iterencode/iterdecode) ? For IncrementalEncoder/Decoder to be iterable it would have to have some iterable from which it gets the input. But this has the same limitation as the stream API: The user is forced to provide the input as a service that the encoder/decoder uses, which requires support for a certain API. The only change would be that now it's an iterator API instead of a stream API. The incremental codecs invert the call logic: The user no longer has to provide a callback service to the codec, but calls the codec directly. This gives much more flexibility. ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2006-03-02 15:03 Message: Logged In: YES user_id=38388 Very nice ! This is a much better approach than the feed style path you wanted to take previously. Minor nits: Please separate out the non-related changes to the IDNA codec into a new patch and assign that to Martin for review. Is it possible to make IncrementalEncoder/Decoder instances iterable per-se (without the need to go through the helper functions iterencode/iterdecode) ? Thanks. ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2006-03-01 06:47 Message: Logged In: YES user_id=89016 This third version of the patch fixes the bug when the iterator in iterencode() or iterdecode() is empty and updates the docstring in encodings/__init__.py. ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2006-02-28 04:08 Message: Logged In: YES user_id=89016 This second version of the patch enhances codecs.iterencode() and codecs.iterdecode(), so that additional keyword arguments are passed through to the Incremental(De|En)coder constructor. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1436130&group_id=5470 From noreply at sourceforge.net Wed Mar 15 09:25:22 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 15 Mar 2006 00:25:22 -0800 Subject: [Patches] [ python-Patches-1359365 ] Iterating closed StringIO.StringIO Message-ID: Patches item #1359365, was opened at 2005-11-18 01:03 Message generated for change (Comment added) made by doerwalter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1359365&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Library (Lib) Group: None Status: Open Resolution: None Priority: 5 Submitted By: Walter D?rwald (doerwalter) Assigned to: Walter D?rwald (doerwalter) Summary: Iterating closed StringIO.StringIO Initial Comment: This patch changes StringIO.StringIO.next to raise a ValueError when the stream is closed. This is the same behaviour as for cStringIO.StringIO and real files. ---------------------------------------------------------------------- >Comment By: Walter D?rwald (doerwalter) Date: 2006-03-15 09:25 Message: Logged In: YES user_id=89016 Checked in as r43039. What do we do with the other discrepancies. Change cStringIO for both the isatty() and the truncate() problems? ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2006-03-15 06:31 Message: Logged In: YES user_id=6380 Please check this in if you haven't already done so. I need to shed load! ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2005-11-29 17:36 Message: Logged In: YES user_id=89016 There are other discrepancies between StringIO.StringIO and cString.StringIO: isatty() raises a ValueError() for a closed StringIO.StringIO and a closed file, but not for a closed cStringIO.StringIO. And the truncate() method when called with a negative argument raised an IOError for StringIO.StringIO and real files, but not for cStringIO.StringIO. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1359365&group_id=5470 From noreply at sourceforge.net Wed Mar 15 12:13:13 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 15 Mar 2006 03:13:13 -0800 Subject: [Patches] [ python-Patches-1436130 ] Incremental codecs Message-ID: Patches item #1436130, was opened at 2006-02-21 20:32 Message generated for change (Comment added) made by lemburg You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1436130&group_id=5470 Please note that this 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: Walter D?rwald (doerwalter) >Assigned to: Walter D?rwald (doerwalter) Summary: Incremental codecs Initial Comment: This patch extends the codec machinery to add incremental codecs: stateful codecs that don't use a stream API. It adds the following stuff: a class codecs.CodecInfo (a subclass of tuple), that is used as the return value of codecs.lookup(); codecs.IncrementalEncoder and codecs.IncrementalDecoder (the basic interface classes), codecs.BufferedIncrementalDecoder (a class that can be used to implement decoders that must handle incomplete input); codecs.iterencode() and codecs.iterdecode() (generators that use the incremental codecs for encoding/decoding an input iterable). On the C level PyCodec_IncrementalEncoder() and PyCodec_IncrementalDecoder() are added. ---------------------------------------------------------------------- >Comment By: M.-A. Lemburg (lemburg) Date: 2006-03-15 12:13 Message: Logged In: YES user_id=38388 The patch looks OK, accept for some minor glitches such as this mess :-) ... + if not isinstance(entry, codecs.CodecInfo): + if not 4 <= len(entry) <= 7: + raise CodecRegistryError,\ + 'module "%s" (%s) failed to register' % \ + (mod.__name__, mod.__file__) + if not callable(entry[0]) or \ + not callable(entry[1]) or \ + (entry[2] is not None and not callable(entry[2])) or \ + (entry[3] is not None and not callable(entry[3])) or \ + (len(entry) > 4 and entry[4] is not None and not callable(entry[4])) or \ + (len(entry) > 5 and entry[5] is not None and not callable(entry[5])): raise CodecRegistryError,\ - 'incompatible codecs in module "%s" (%s)' % \ - (mod.__name__, mod.__file__) + 'incompatible codecs in module "%s" (%s)' % \ + (mod.__name__, mod.__file__) + if len(entry)<7 or entry[6] is None: + entry += (None,)*(6-len(entry)) + (mod.__name__.split(".", 1)[1],) + entry = codecs.CodecInfo(*entry) Nevertheless, it can be cleaned up after checkin, so please go ahead with it. Regarding the idna.py patch, I think you should create a new patch item for it and assign it to Martin. Thanks. Neal, I don't have time to review the two CJK patches. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2006-03-15 09:01 Message: Logged In: YES user_id=33168 MAL, do you have any more issues with this patch? Should it be assigned to Martin? MAL, Walter, can you review these patches 1443155 1449471 which I think are related? Should they go in? The first alpha is coming up soon and I'd like to get these patches in ASAP. ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2006-03-03 18:39 Message: Logged In: YES user_id=89016 This fourth version of the patch removes the changes to Lib/encodings/idna.py (only the addition of the IncrementalEncoder/IncrementalDecoder and the changed getregentry() remain). This patch to idna.py probably only makes sense once this patch is in. > Is it possible to make IncrementalEncoder/Decoder > instances iterable per-se (without the need to go > through the helper functions iterencode/iterdecode) ? For IncrementalEncoder/Decoder to be iterable it would have to have some iterable from which it gets the input. But this has the same limitation as the stream API: The user is forced to provide the input as a service that the encoder/decoder uses, which requires support for a certain API. The only change would be that now it's an iterator API instead of a stream API. The incremental codecs invert the call logic: The user no longer has to provide a callback service to the codec, but calls the codec directly. This gives much more flexibility. ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2006-03-03 00:03 Message: Logged In: YES user_id=38388 Very nice ! This is a much better approach than the feed style path you wanted to take previously. Minor nits: Please separate out the non-related changes to the IDNA codec into a new patch and assign that to Martin for review. Is it possible to make IncrementalEncoder/Decoder instances iterable per-se (without the need to go through the helper functions iterencode/iterdecode) ? Thanks. ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2006-03-01 15:47 Message: Logged In: YES user_id=89016 This third version of the patch fixes the bug when the iterator in iterencode() or iterdecode() is empty and updates the docstring in encodings/__init__.py. ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2006-02-28 13:08 Message: Logged In: YES user_id=89016 This second version of the patch enhances codecs.iterencode() and codecs.iterdecode(), so that additional keyword arguments are passed through to the Incremental(De|En)coder constructor. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1436130&group_id=5470 From noreply at sourceforge.net Wed Mar 15 12:13:39 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 15 Mar 2006 03:13:39 -0800 Subject: [Patches] [ python-Patches-1436130 ] Incremental codecs Message-ID: Patches item #1436130, was opened at 2006-02-21 20:32 Message generated for change (Settings changed) made by lemburg You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1436130&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. >Category: Library (Lib) Group: Python 2.5 Status: Open Resolution: Accepted Priority: 5 Submitted By: Walter D?rwald (doerwalter) Assigned to: Walter D?rwald (doerwalter) Summary: Incremental codecs Initial Comment: This patch extends the codec machinery to add incremental codecs: stateful codecs that don't use a stream API. It adds the following stuff: a class codecs.CodecInfo (a subclass of tuple), that is used as the return value of codecs.lookup(); codecs.IncrementalEncoder and codecs.IncrementalDecoder (the basic interface classes), codecs.BufferedIncrementalDecoder (a class that can be used to implement decoders that must handle incomplete input); codecs.iterencode() and codecs.iterdecode() (generators that use the incremental codecs for encoding/decoding an input iterable). On the C level PyCodec_IncrementalEncoder() and PyCodec_IncrementalDecoder() are added. ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2006-03-15 12:13 Message: Logged In: YES user_id=38388 The patch looks OK, accept for some minor glitches such as this mess :-) ... + if not isinstance(entry, codecs.CodecInfo): + if not 4 <= len(entry) <= 7: + raise CodecRegistryError,\ + 'module "%s" (%s) failed to register' % \ + (mod.__name__, mod.__file__) + if not callable(entry[0]) or \ + not callable(entry[1]) or \ + (entry[2] is not None and not callable(entry[2])) or \ + (entry[3] is not None and not callable(entry[3])) or \ + (len(entry) > 4 and entry[4] is not None and not callable(entry[4])) or \ + (len(entry) > 5 and entry[5] is not None and not callable(entry[5])): raise CodecRegistryError,\ - 'incompatible codecs in module "%s" (%s)' % \ - (mod.__name__, mod.__file__) + 'incompatible codecs in module "%s" (%s)' % \ + (mod.__name__, mod.__file__) + if len(entry)<7 or entry[6] is None: + entry += (None,)*(6-len(entry)) + (mod.__name__.split(".", 1)[1],) + entry = codecs.CodecInfo(*entry) Nevertheless, it can be cleaned up after checkin, so please go ahead with it. Regarding the idna.py patch, I think you should create a new patch item for it and assign it to Martin. Thanks. Neal, I don't have time to review the two CJK patches. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2006-03-15 09:01 Message: Logged In: YES user_id=33168 MAL, do you have any more issues with this patch? Should it be assigned to Martin? MAL, Walter, can you review these patches 1443155 1449471 which I think are related? Should they go in? The first alpha is coming up soon and I'd like to get these patches in ASAP. ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2006-03-03 18:39 Message: Logged In: YES user_id=89016 This fourth version of the patch removes the changes to Lib/encodings/idna.py (only the addition of the IncrementalEncoder/IncrementalDecoder and the changed getregentry() remain). This patch to idna.py probably only makes sense once this patch is in. > Is it possible to make IncrementalEncoder/Decoder > instances iterable per-se (without the need to go > through the helper functions iterencode/iterdecode) ? For IncrementalEncoder/Decoder to be iterable it would have to have some iterable from which it gets the input. But this has the same limitation as the stream API: The user is forced to provide the input as a service that the encoder/decoder uses, which requires support for a certain API. The only change would be that now it's an iterator API instead of a stream API. The incremental codecs invert the call logic: The user no longer has to provide a callback service to the codec, but calls the codec directly. This gives much more flexibility. ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2006-03-03 00:03 Message: Logged In: YES user_id=38388 Very nice ! This is a much better approach than the feed style path you wanted to take previously. Minor nits: Please separate out the non-related changes to the IDNA codec into a new patch and assign that to Martin for review. Is it possible to make IncrementalEncoder/Decoder instances iterable per-se (without the need to go through the helper functions iterencode/iterdecode) ? Thanks. ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2006-03-01 15:47 Message: Logged In: YES user_id=89016 This third version of the patch fixes the bug when the iterator in iterencode() or iterdecode() is empty and updates the docstring in encodings/__init__.py. ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2006-02-28 13:08 Message: Logged In: YES user_id=89016 This second version of the patch enhances codecs.iterencode() and codecs.iterdecode(), so that additional keyword arguments are passed through to the Incremental(De|En)coder constructor. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1436130&group_id=5470 From noreply at sourceforge.net Wed Mar 15 12:28:27 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 15 Mar 2006 03:28:27 -0800 Subject: [Patches] [ python-Patches-1436130 ] Incremental codecs Message-ID: Patches item #1436130, was opened at 2006-02-22 04:32 Message generated for change (Comment added) made by perky You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1436130&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Library (Lib) Group: Python 2.5 Status: Open Resolution: Accepted Priority: 5 Submitted By: Walter D?rwald (doerwalter) Assigned to: Walter D?rwald (doerwalter) Summary: Incremental codecs Initial Comment: This patch extends the codec machinery to add incremental codecs: stateful codecs that don't use a stream API. It adds the following stuff: a class codecs.CodecInfo (a subclass of tuple), that is used as the return value of codecs.lookup(); codecs.IncrementalEncoder and codecs.IncrementalDecoder (the basic interface classes), codecs.BufferedIncrementalDecoder (a class that can be used to implement decoders that must handle incomplete input); codecs.iterencode() and codecs.iterdecode() (generators that use the incremental codecs for encoding/decoding an input iterable). On the C level PyCodec_IncrementalEncoder() and PyCodec_IncrementalDecoder() are added. ---------------------------------------------------------------------- >Comment By: Hye-Shik Chang (perky) Date: 2006-03-15 20:28 Message: Logged In: YES user_id=55188 1449471 isn't related to incremental codecs. It includes a simple patch to visual studio project file. I think Walter is right person to review 1443155 whether it conforms his interface design. :-) (Thank you in advance!) ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2006-03-15 20:13 Message: Logged In: YES user_id=38388 The patch looks OK, accept for some minor glitches such as this mess :-) ... + if not isinstance(entry, codecs.CodecInfo): + if not 4 <= len(entry) <= 7: + raise CodecRegistryError,\ + 'module "%s" (%s) failed to register' % \ + (mod.__name__, mod.__file__) + if not callable(entry[0]) or \ + not callable(entry[1]) or \ + (entry[2] is not None and not callable(entry[2])) or \ + (entry[3] is not None and not callable(entry[3])) or \ + (len(entry) > 4 and entry[4] is not None and not callable(entry[4])) or \ + (len(entry) > 5 and entry[5] is not None and not callable(entry[5])): raise CodecRegistryError,\ - 'incompatible codecs in module "%s" (%s)' % \ - (mod.__name__, mod.__file__) + 'incompatible codecs in module "%s" (%s)' % \ + (mod.__name__, mod.__file__) + if len(entry)<7 or entry[6] is None: + entry += (None,)*(6-len(entry)) + (mod.__name__.split(".", 1)[1],) + entry = codecs.CodecInfo(*entry) Nevertheless, it can be cleaned up after checkin, so please go ahead with it. Regarding the idna.py patch, I think you should create a new patch item for it and assign it to Martin. Thanks. Neal, I don't have time to review the two CJK patches. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2006-03-15 17:01 Message: Logged In: YES user_id=33168 MAL, do you have any more issues with this patch? Should it be assigned to Martin? MAL, Walter, can you review these patches 1443155 1449471 which I think are related? Should they go in? The first alpha is coming up soon and I'd like to get these patches in ASAP. ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2006-03-04 02:39 Message: Logged In: YES user_id=89016 This fourth version of the patch removes the changes to Lib/encodings/idna.py (only the addition of the IncrementalEncoder/IncrementalDecoder and the changed getregentry() remain). This patch to idna.py probably only makes sense once this patch is in. > Is it possible to make IncrementalEncoder/Decoder > instances iterable per-se (without the need to go > through the helper functions iterencode/iterdecode) ? For IncrementalEncoder/Decoder to be iterable it would have to have some iterable from which it gets the input. But this has the same limitation as the stream API: The user is forced to provide the input as a service that the encoder/decoder uses, which requires support for a certain API. The only change would be that now it's an iterator API instead of a stream API. The incremental codecs invert the call logic: The user no longer has to provide a callback service to the codec, but calls the codec directly. This gives much more flexibility. ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2006-03-03 08:03 Message: Logged In: YES user_id=38388 Very nice ! This is a much better approach than the feed style path you wanted to take previously. Minor nits: Please separate out the non-related changes to the IDNA codec into a new patch and assign that to Martin for review. Is it possible to make IncrementalEncoder/Decoder instances iterable per-se (without the need to go through the helper functions iterencode/iterdecode) ? Thanks. ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2006-03-01 23:47 Message: Logged In: YES user_id=89016 This third version of the patch fixes the bug when the iterator in iterencode() or iterdecode() is empty and updates the docstring in encodings/__init__.py. ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2006-02-28 21:08 Message: Logged In: YES user_id=89016 This second version of the patch enhances codecs.iterencode() and codecs.iterdecode(), so that additional keyword arguments are passed through to the Incremental(De|En)coder constructor. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1436130&group_id=5470 From noreply at sourceforge.net Wed Mar 15 12:43:03 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 15 Mar 2006 03:43:03 -0800 Subject: [Patches] [ python-Patches-1436130 ] Incremental codecs Message-ID: Patches item #1436130, was opened at 2006-02-21 20:32 Message generated for change (Comment added) made by doerwalter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1436130&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Library (Lib) Group: Python 2.5 Status: Open Resolution: Accepted Priority: 5 Submitted By: Walter D?rwald (doerwalter) Assigned to: Walter D?rwald (doerwalter) Summary: Incremental codecs Initial Comment: This patch extends the codec machinery to add incremental codecs: stateful codecs that don't use a stream API. It adds the following stuff: a class codecs.CodecInfo (a subclass of tuple), that is used as the return value of codecs.lookup(); codecs.IncrementalEncoder and codecs.IncrementalDecoder (the basic interface classes), codecs.BufferedIncrementalDecoder (a class that can be used to implement decoders that must handle incomplete input); codecs.iterencode() and codecs.iterdecode() (generators that use the incremental codecs for encoding/decoding an input iterable). On the C level PyCodec_IncrementalEncoder() and PyCodec_IncrementalDecoder() are added. ---------------------------------------------------------------------- >Comment By: Walter D?rwald (doerwalter) Date: 2006-03-15 12:43 Message: Logged In: YES user_id=89016 Checked in as r43045. Now what do we do with the funny code in encoding.search_function()? Of course we could always *require* the search function to return a CodecInfo object. (but only after the CJK codecs are updated, and even then we should have some form of backwards compatibility). ---------------------------------------------------------------------- Comment By: Hye-Shik Chang (perky) Date: 2006-03-15 12:28 Message: Logged In: YES user_id=55188 1449471 isn't related to incremental codecs. It includes a simple patch to visual studio project file. I think Walter is right person to review 1443155 whether it conforms his interface design. :-) (Thank you in advance!) ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2006-03-15 12:13 Message: Logged In: YES user_id=38388 The patch looks OK, accept for some minor glitches such as this mess :-) ... + if not isinstance(entry, codecs.CodecInfo): + if not 4 <= len(entry) <= 7: + raise CodecRegistryError,\ + 'module "%s" (%s) failed to register' % \ + (mod.__name__, mod.__file__) + if not callable(entry[0]) or \ + not callable(entry[1]) or \ + (entry[2] is not None and not callable(entry[2])) or \ + (entry[3] is not None and not callable(entry[3])) or \ + (len(entry) > 4 and entry[4] is not None and not callable(entry[4])) or \ + (len(entry) > 5 and entry[5] is not None and not callable(entry[5])): raise CodecRegistryError,\ - 'incompatible codecs in module "%s" (%s)' % \ - (mod.__name__, mod.__file__) + 'incompatible codecs in module "%s" (%s)' % \ + (mod.__name__, mod.__file__) + if len(entry)<7 or entry[6] is None: + entry += (None,)*(6-len(entry)) + (mod.__name__.split(".", 1)[1],) + entry = codecs.CodecInfo(*entry) Nevertheless, it can be cleaned up after checkin, so please go ahead with it. Regarding the idna.py patch, I think you should create a new patch item for it and assign it to Martin. Thanks. Neal, I don't have time to review the two CJK patches. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2006-03-15 09:01 Message: Logged In: YES user_id=33168 MAL, do you have any more issues with this patch? Should it be assigned to Martin? MAL, Walter, can you review these patches 1443155 1449471 which I think are related? Should they go in? The first alpha is coming up soon and I'd like to get these patches in ASAP. ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2006-03-03 18:39 Message: Logged In: YES user_id=89016 This fourth version of the patch removes the changes to Lib/encodings/idna.py (only the addition of the IncrementalEncoder/IncrementalDecoder and the changed getregentry() remain). This patch to idna.py probably only makes sense once this patch is in. > Is it possible to make IncrementalEncoder/Decoder > instances iterable per-se (without the need to go > through the helper functions iterencode/iterdecode) ? For IncrementalEncoder/Decoder to be iterable it would have to have some iterable from which it gets the input. But this has the same limitation as the stream API: The user is forced to provide the input as a service that the encoder/decoder uses, which requires support for a certain API. The only change would be that now it's an iterator API instead of a stream API. The incremental codecs invert the call logic: The user no longer has to provide a callback service to the codec, but calls the codec directly. This gives much more flexibility. ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2006-03-03 00:03 Message: Logged In: YES user_id=38388 Very nice ! This is a much better approach than the feed style path you wanted to take previously. Minor nits: Please separate out the non-related changes to the IDNA codec into a new patch and assign that to Martin for review. Is it possible to make IncrementalEncoder/Decoder instances iterable per-se (without the need to go through the helper functions iterencode/iterdecode) ? Thanks. ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2006-03-01 15:47 Message: Logged In: YES user_id=89016 This third version of the patch fixes the bug when the iterator in iterencode() or iterdecode() is empty and updates the docstring in encodings/__init__.py. ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2006-02-28 13:08 Message: Logged In: YES user_id=89016 This second version of the patch enhances codecs.iterencode() and codecs.iterdecode(), so that additional keyword arguments are passed through to the Incremental(De|En)coder constructor. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1436130&group_id=5470 From noreply at sourceforge.net Wed Mar 15 13:08:36 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 15 Mar 2006 04:08:36 -0800 Subject: [Patches] [ python-Patches-1443155 ] Incremental codecs for CJKCodecs Message-ID: Patches item #1443155, was opened at 2006-03-04 19:45 Message generated for change (Comment added) made by doerwalter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1443155&group_id=5470 Please note that this 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: Hye-Shik Chang (perky) >Assigned to: Hye-Shik Chang (perky) Summary: Incremental codecs for CJKCodecs Initial Comment: Here's a supplemental patch for SF #1436130 to implement CJKCodecs part of the Incremental codec specification. This patch is implemented in an interface of Walter's fourth patch on #1436130. Please test this whether it agrees the design. ---------------------------------------------------------------------- >Comment By: Walter D?rwald (doerwalter) Date: 2006-03-15 13:08 Message: Logged In: YES user_id=89016 The patch doesn't apply cleanly (conflicts in Lib/test/test_multibytecodec.py and Tools/unicode/Makefile). Could you update the patch? I haven't looked at the C code to closely yet. Two notes: 1) The tests often call incencoder.encode() or incdecoder.decode() again after the method has been called with final=True before. I'm not sure that this should be allowed. If we allow it, it should be documented in what state the codec is after calling with final=True (probably it should be back to the initial state (i.e. like calling reset())). 2) It seems to me that it isn't possible to change the error handling during the lifetime of a codec. Anyway, thanks for the quick patch. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1443155&group_id=5470 From noreply at sourceforge.net Wed Mar 15 13:14:55 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 15 Mar 2006 04:14:55 -0800 Subject: [Patches] [ python-Patches-1436130 ] Incremental codecs Message-ID: Patches item #1436130, was opened at 2006-02-21 20:32 Message generated for change (Comment added) made by lemburg You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1436130&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Library (Lib) Group: Python 2.5 Status: Open Resolution: Accepted Priority: 5 Submitted By: Walter D?rwald (doerwalter) Assigned to: Walter D?rwald (doerwalter) Summary: Incremental codecs Initial Comment: This patch extends the codec machinery to add incremental codecs: stateful codecs that don't use a stream API. It adds the following stuff: a class codecs.CodecInfo (a subclass of tuple), that is used as the return value of codecs.lookup(); codecs.IncrementalEncoder and codecs.IncrementalDecoder (the basic interface classes), codecs.BufferedIncrementalDecoder (a class that can be used to implement decoders that must handle incomplete input); codecs.iterencode() and codecs.iterdecode() (generators that use the incremental codecs for encoding/decoding an input iterable). On the C level PyCodec_IncrementalEncoder() and PyCodec_IncrementalDecoder() are added. ---------------------------------------------------------------------- >Comment By: M.-A. Lemburg (lemburg) Date: 2006-03-15 13:14 Message: Logged In: YES user_id=38388 It's only the coding style that looks a bit funny. Requiring CodecInfo objects is not a good idea: that way you'd make it impossible to write codecs that work in both Python 2.5 and 2.4. ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2006-03-15 12:43 Message: Logged In: YES user_id=89016 Checked in as r43045. Now what do we do with the funny code in encoding.search_function()? Of course we could always *require* the search function to return a CodecInfo object. (but only after the CJK codecs are updated, and even then we should have some form of backwards compatibility). ---------------------------------------------------------------------- Comment By: Hye-Shik Chang (perky) Date: 2006-03-15 12:28 Message: Logged In: YES user_id=55188 1449471 isn't related to incremental codecs. It includes a simple patch to visual studio project file. I think Walter is right person to review 1443155 whether it conforms his interface design. :-) (Thank you in advance!) ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2006-03-15 12:13 Message: Logged In: YES user_id=38388 The patch looks OK, accept for some minor glitches such as this mess :-) ... + if not isinstance(entry, codecs.CodecInfo): + if not 4 <= len(entry) <= 7: + raise CodecRegistryError,\ + 'module "%s" (%s) failed to register' % \ + (mod.__name__, mod.__file__) + if not callable(entry[0]) or \ + not callable(entry[1]) or \ + (entry[2] is not None and not callable(entry[2])) or \ + (entry[3] is not None and not callable(entry[3])) or \ + (len(entry) > 4 and entry[4] is not None and not callable(entry[4])) or \ + (len(entry) > 5 and entry[5] is not None and not callable(entry[5])): raise CodecRegistryError,\ - 'incompatible codecs in module "%s" (%s)' % \ - (mod.__name__, mod.__file__) + 'incompatible codecs in module "%s" (%s)' % \ + (mod.__name__, mod.__file__) + if len(entry)<7 or entry[6] is None: + entry += (None,)*(6-len(entry)) + (mod.__name__.split(".", 1)[1],) + entry = codecs.CodecInfo(*entry) Nevertheless, it can be cleaned up after checkin, so please go ahead with it. Regarding the idna.py patch, I think you should create a new patch item for it and assign it to Martin. Thanks. Neal, I don't have time to review the two CJK patches. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2006-03-15 09:01 Message: Logged In: YES user_id=33168 MAL, do you have any more issues with this patch? Should it be assigned to Martin? MAL, Walter, can you review these patches 1443155 1449471 which I think are related? Should they go in? The first alpha is coming up soon and I'd like to get these patches in ASAP. ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2006-03-03 18:39 Message: Logged In: YES user_id=89016 This fourth version of the patch removes the changes to Lib/encodings/idna.py (only the addition of the IncrementalEncoder/IncrementalDecoder and the changed getregentry() remain). This patch to idna.py probably only makes sense once this patch is in. > Is it possible to make IncrementalEncoder/Decoder > instances iterable per-se (without the need to go > through the helper functions iterencode/iterdecode) ? For IncrementalEncoder/Decoder to be iterable it would have to have some iterable from which it gets the input. But this has the same limitation as the stream API: The user is forced to provide the input as a service that the encoder/decoder uses, which requires support for a certain API. The only change would be that now it's an iterator API instead of a stream API. The incremental codecs invert the call logic: The user no longer has to provide a callback service to the codec, but calls the codec directly. This gives much more flexibility. ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2006-03-03 00:03 Message: Logged In: YES user_id=38388 Very nice ! This is a much better approach than the feed style path you wanted to take previously. Minor nits: Please separate out the non-related changes to the IDNA codec into a new patch and assign that to Martin for review. Is it possible to make IncrementalEncoder/Decoder instances iterable per-se (without the need to go through the helper functions iterencode/iterdecode) ? Thanks. ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2006-03-01 15:47 Message: Logged In: YES user_id=89016 This third version of the patch fixes the bug when the iterator in iterencode() or iterdecode() is empty and updates the docstring in encodings/__init__.py. ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2006-02-28 13:08 Message: Logged In: YES user_id=89016 This second version of the patch enhances codecs.iterencode() and codecs.iterdecode(), so that additional keyword arguments are passed through to the Incremental(De|En)coder constructor. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1436130&group_id=5470 From noreply at sourceforge.net Wed Mar 15 13:46:31 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 15 Mar 2006 04:46:31 -0800 Subject: [Patches] [ python-Patches-1447410 ] logging: findCaller() sometimes raises AttributeError Message-ID: Patches item #1447410, was opened at 2006-03-10 18:12 Message generated for change (Comment added) made by vsajip You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1447410&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Library (Lib) Group: Python 2.4 >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Kevin J Bluck (kbluck) Assigned to: Vinay Sajip (vsajip) Summary: logging: findCaller() sometimes raises AttributeError Initial Comment: I am invoking the logging.log() function via the C API, using PyObject_CallFunction(). I have found that sometimes (not always) the findCaller() function raises this AttributeError: AttributeError: 'NoneType' object has no attribute 'f_code' File "C:\Program Files\Python\Lib\logging\__init__.py", line 1052, in findCaller co = f.f_code File "C:\Program Files\Python\Lib\logging\__init__.py", line 1078, in _log fn, lno, func = self.findCaller() File "C:\Program Files\Python\Lib\logging\__init__.py", line 1043, in log apply(self._log, (level, msg, args), kwargs) File "C:\Program Files\Python\Lib\logging\__init__.py", line 1319, in log apply(root It appears that sometimes, currentframe() is returning None. Attached is a patch for logging/__init__.py which guards against this possibility. Patch is generated against recent SVN head revision 42958. ---------------------------------------------------------------------- >Comment By: Vinay Sajip (vsajip) Date: 2006-03-15 12:46 Message: Logged In: YES user_id=308438 A version of this patch is in SVN revision 43048. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1447410&group_id=5470 From noreply at sourceforge.net Wed Mar 15 18:37:24 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 15 Mar 2006 09:37:24 -0800 Subject: [Patches] [ python-Patches-1359365 ] Iterating closed StringIO.StringIO Message-ID: Patches item #1359365, was opened at 2005-11-17 19:03 Message generated for change (Comment added) made by gvanrossum You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1359365&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Library (Lib) Group: None Status: Open Resolution: None Priority: 5 Submitted By: Walter D?rwald (doerwalter) Assigned to: Walter D?rwald (doerwalter) Summary: Iterating closed StringIO.StringIO Initial Comment: This patch changes StringIO.StringIO.next to raise a ValueError when the stream is closed. This is the same behaviour as for cStringIO.StringIO and real files. ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2006-03-15 12:37 Message: Logged In: YES user_id=6380 Sure. ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2006-03-15 03:25 Message: Logged In: YES user_id=89016 Checked in as r43039. What do we do with the other discrepancies. Change cStringIO for both the isatty() and the truncate() problems? ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2006-03-15 00:31 Message: Logged In: YES user_id=6380 Please check this in if you haven't already done so. I need to shed load! ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2005-11-29 11:36 Message: Logged In: YES user_id=89016 There are other discrepancies between StringIO.StringIO and cString.StringIO: isatty() raises a ValueError() for a closed StringIO.StringIO and a closed file, but not for a closed cStringIO.StringIO. And the truncate() method when called with a negative argument raised an IOError for StringIO.StringIO and real files, but not for cStringIO.StringIO. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1359365&group_id=5470 From noreply at sourceforge.net Wed Mar 15 23:14:09 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 15 Mar 2006 14:14:09 -0800 Subject: [Patches] [ python-Patches-1359365 ] Iterating closed StringIO.StringIO Message-ID: Patches item #1359365, was opened at 2005-11-18 01:03 Message generated for change (Comment added) made by doerwalter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1359365&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Library (Lib) Group: None Status: Open Resolution: None Priority: 5 Submitted By: Walter D?rwald (doerwalter) Assigned to: Walter D?rwald (doerwalter) Summary: Iterating closed StringIO.StringIO Initial Comment: This patch changes StringIO.StringIO.next to raise a ValueError when the stream is closed. This is the same behaviour as for cStringIO.StringIO and real files. ---------------------------------------------------------------------- >Comment By: Walter D?rwald (doerwalter) Date: 2006-03-15 23:14 Message: Logged In: YES user_id=89016 Checked in a fix for cStringIO.StringIO.isatty() as r43054. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2006-03-15 18:37 Message: Logged In: YES user_id=6380 Sure. ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2006-03-15 09:25 Message: Logged In: YES user_id=89016 Checked in as r43039. What do we do with the other discrepancies. Change cStringIO for both the isatty() and the truncate() problems? ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2006-03-15 06:31 Message: Logged In: YES user_id=6380 Please check this in if you haven't already done so. I need to shed load! ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2005-11-29 17:36 Message: Logged In: YES user_id=89016 There are other discrepancies between StringIO.StringIO and cString.StringIO: isatty() raises a ValueError() for a closed StringIO.StringIO and a closed file, but not for a closed cStringIO.StringIO. And the truncate() method when called with a negative argument raised an IOError for StringIO.StringIO and real files, but not for cStringIO.StringIO. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1359365&group_id=5470 From noreply at sourceforge.net Thu Mar 16 02:17:30 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 15 Mar 2006 17:17:30 -0800 Subject: [Patches] [ python-Patches-1123430 ] Python memory allocator: Free memory Message-ID: Patches item #1123430, was opened at 2005-02-15 16:27 Message generated for change (Comment added) made by tim_one You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1123430&group_id=5470 Please note that this 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: Evan Jones (vulturex) Assigned to: Tim Peters (tim_one) Summary: Python memory allocator: Free memory Initial Comment: This is the second version of my Python memory allocator patch. The first version was discussed on the python-dev mailing list here: http://mail.python.org/pipermail/python-dev/2005-January/ 051255.html This patch enables Python to actually return memory to the system. The current version's memory usage will only grow. This version maintains the same backwards compatability guarantees as the previous version: Calling PyObject_Free with a pointer that was returned by malloc() while NOT holding the GIL will work, and will not corrupt the state of the memory allocator. The patch modifies obmalloc.c. If it is accepted, other modifications to that file are required. In particular, I have not yet updated the WITH_MEMORY_LIMITS implementation, nor have I looked closely at the PYMALLOC_DEBUG code to see what changes (if any) are required. ---------------------------------------------------------------------- >Comment By: Tim Peters (tim_one) Date: 2006-03-15 20:17 Message: Logged In: YES user_id=31435 The tim-obmalloc branch was merged to the trunk (for Python 2.5a1) in revision 43059. Thank you again for your hard work and patience, Evan! ---------------------------------------------------------------------- Comment By: Evan Jones (vulturex) Date: 2006-02-23 09:29 Message: Logged In: YES user_id=539295 Great news! If you need any assistance, I would be more than happy to help. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2006-02-22 20:25 Message: Logged In: YES user_id=31435 The patch here is out of date, but that's OK. I created branch tim-obmalloc, with a working version of the patch, extensively reformatted to Python's C style, and with some minor changes to squash compiler warnings. I plan to finish this during PyCon. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2005-09-05 18:43 Message: Logged In: YES user_id=31435 Assigned to me. ---------------------------------------------------------------------- Comment By: Evan Jones (vulturex) Date: 2005-05-10 00:31 Message: Logged In: YES user_id=539295 Whoops! I uploaded a "fixed" version a while ago, but I guess I didn't update the comments. The patch currently attached to this is the most up- to-date version. Sorry about that. ---------------------------------------------------------------------- Comment By: Evan Jones (vulturex) Date: 2005-02-19 09:07 Message: Logged In: YES user_id=539295 As per the discussion on python-dev, I've removed the concurrency hack. The routines in obmalloc.c now *must* be called while holding the GIL, even if the pointer was allocated with malloc(). I also finally fixed the PYMALLOC_DEBUG routines, so I believe this patch is now "complete." ---------------------------------------------------------------------- Comment By: Evan Jones (vulturex) Date: 2005-02-18 17:08 Message: Logged In: YES user_id=539295 Please ignore this patch for the moment: I'm in the process of making some fixes. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1123430&group_id=5470 From noreply at sourceforge.net Thu Mar 16 08:08:10 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 15 Mar 2006 23:08:10 -0800 Subject: [Patches] [ python-Patches-1447410 ] logging: findCaller() sometimes raises AttributeError Message-ID: Patches item #1447410, was opened at 2006-03-10 10:12 Message generated for change (Comment added) made by nnorwitz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1447410&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Library (Lib) Group: Python 2.4 Status: Closed Resolution: Fixed Priority: 5 Submitted By: Kevin J Bluck (kbluck) Assigned to: Vinay Sajip (vsajip) Summary: logging: findCaller() sometimes raises AttributeError Initial Comment: I am invoking the logging.log() function via the C API, using PyObject_CallFunction(). I have found that sometimes (not always) the findCaller() function raises this AttributeError: AttributeError: 'NoneType' object has no attribute 'f_code' File "C:\Program Files\Python\Lib\logging\__init__.py", line 1052, in findCaller co = f.f_code File "C:\Program Files\Python\Lib\logging\__init__.py", line 1078, in _log fn, lno, func = self.findCaller() File "C:\Program Files\Python\Lib\logging\__init__.py", line 1043, in log apply(self._log, (level, msg, args), kwargs) File "C:\Program Files\Python\Lib\logging\__init__.py", line 1319, in log apply(root It appears that sometimes, currentframe() is returning None. Attached is a patch for logging/__init__.py which guards against this possibility. Patch is generated against recent SVN head revision 42958. ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2006-03-15 23:08 Message: Logged In: YES user_id=33168 Vinay, should this be backported? ---------------------------------------------------------------------- Comment By: Vinay Sajip (vsajip) Date: 2006-03-15 04:46 Message: Logged In: YES user_id=308438 A version of this patch is in SVN revision 43048. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1447410&group_id=5470 From noreply at sourceforge.net Thu Mar 16 13:32:00 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 16 Mar 2006 04:32:00 -0800 Subject: [Patches] [ python-Patches-1443155 ] Incremental codecs for CJKCodecs Message-ID: Patches item #1443155, was opened at 2006-03-05 03:45 Message generated for change (Comment added) made by perky You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1443155&group_id=5470 Please note that this 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: Hye-Shik Chang (perky) Assigned to: Hye-Shik Chang (perky) Summary: Incremental codecs for CJKCodecs Initial Comment: Here's a supplemental patch for SF #1436130 to implement CJKCodecs part of the Incremental codec specification. This patch is implemented in an interface of Walter's fourth patch on #1436130. Please test this whether it agrees the design. ---------------------------------------------------------------------- >Comment By: Hye-Shik Chang (perky) Date: 2006-03-16 21:32 Message: Logged In: YES user_id=55188 1) Because CJKCodecs had an internal stateful framework, I implemented just an interface using it for IncrementalCodec. It treats final=True as a simple `flush' message(which doesn't reset or terminate the codec). The behavior is quite useful for real-time stream processing such as sockets and tail log watchers. If we disallow that, such usages may require its own sequence detectors. For "to reset or not" issue, I think we can simply follow how iconv does. iconv doesn't reset the internal state for iconv(ic, NULL, NULL, ..). 2) Aah. I didn't notice that .errors is a part of public API. The current CJKCodecs can't support it easily yet. I'll fix it and upload a updated patch soon. Thank you for your review! ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2006-03-15 21:08 Message: Logged In: YES user_id=89016 The patch doesn't apply cleanly (conflicts in Lib/test/test_multibytecodec.py and Tools/unicode/Makefile). Could you update the patch? I haven't looked at the C code to closely yet. Two notes: 1) The tests often call incencoder.encode() or incdecoder.decode() again after the method has been called with final=True before. I'm not sure that this should be allowed. If we allow it, it should be documented in what state the codec is after calling with final=True (probably it should be back to the initial state (i.e. like calling reset())). 2) It seems to me that it isn't possible to change the error handling during the lifetime of a codec. Anyway, thanks for the quick patch. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1443155&group_id=5470 From noreply at sourceforge.net Fri Mar 17 11:06:29 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 17 Mar 2006 02:06:29 -0800 Subject: [Patches] [ python-Patches-1429601 ] PEP 338 implementation Message-ID: Patches item #1429601, was opened at 2006-02-11 19:04 Message generated for change (Comment added) made by ncoghlan You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1429601&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None >Status: Closed Resolution: None Priority: 5 Submitted By: Nick Coghlan (ncoghlan) Assigned to: Nobody/Anonymous (nobody) Summary: PEP 338 implementation Initial Comment: This PEP implementation contains three parts - a separate Python module (runpy.py) that implements the PEP 338 functionality, a corresponding test module (test_runpy.py) and a patch against current subversion to integrate the module with the -m command line switch. The documentation for the new module will be submitted as a separate patch (since the review cycle is a bit different). ---------------------------------------------------------------------- >Comment By: Nick Coghlan (ncoghlan) Date: 2006-03-17 20:06 Message: Logged In: YES user_id=1038590 Slightly updated version of patch committed in SVN ---------------------------------------------------------------------- Comment By: Nick Coghlan (ncoghlan) Date: 2006-02-19 03:56 Message: Logged In: YES user_id=1038590 Updated unit tests to match Feb 18 version of PEP and to cover executing both source and compiled files from the file system. (version 2 of test_runpy module) ---------------------------------------------------------------------- Comment By: Nick Coghlan (ncoghlan) Date: 2006-02-19 03:52 Message: Logged In: YES user_id=1038590 Updated module to match Feb 18 version of PEP (version 6 of module) ---------------------------------------------------------------------- Comment By: Nick Coghlan (ncoghlan) Date: 2006-02-18 01:19 Message: Logged In: YES user_id=1038590 PEP 338 has been updated as of 18-Feb-2006. Those changes are still to be incorporated into this implementation. ---------------------------------------------------------------------- Comment By: Nick Coghlan (ncoghlan) Date: 2006-02-12 13:33 Message: Logged In: YES user_id=1038590 Fixed error handling in main.c when the function call results in an exception. (version 2 of integration diff). ---------------------------------------------------------------------- Comment By: Nick Coghlan (ncoghlan) Date: 2006-02-12 13:29 Message: Logged In: YES user_id=1038590 I've attached a zip archive of the directory tree I've been using to check that the runpy module works correctly. For each of these command lines: python -m runpy_demo.test python -m runpy_demo.pkg.test python -m runpy_demo.pkg.pkg.test python -m runpy_demo.pkg.zip_pkg.test The message "Running runpy_demo.test" should then print to the console (with the second part of the message changing as appropriate for the other 3 modules). The last one obviously won't work if zlib isn't installed, and all 4 require that both runpy and runpy_demo be on sys.path (e.g in site-packages, or in the Lib directory). On older Python versions (or without applying the patch), invoking runpy directly is enough to make it work python -m runpy runpy_demo.test python -m runpy runpy_demo.pkg.test python -m runpy runpy_demo.pkg.pkg.test python -m runpy runpy_demo.pkg.zip_pkg.test ---------------------------------------------------------------------- Comment By: Nick Coghlan (ncoghlan) Date: 2006-02-12 13:12 Message: Logged In: YES user_id=1038590 Added patch to main.c for integration with command line switch. ---------------------------------------------------------------------- Comment By: Nick Coghlan (ncoghlan) Date: 2006-02-12 12:12 Message: Logged In: YES user_id=1038590 Version 5. Removed an import that is now redundant, added a comment header with author information. ---------------------------------------------------------------------- Comment By: Nick Coghlan (ncoghlan) Date: 2006-02-12 02:50 Message: Logged In: YES user_id=1038590 Version 4 of implementation. Fixes problem with not handling nested packages and raises ImportError in run_module when no loader is found. ---------------------------------------------------------------------- Comment By: Nick Coghlan (ncoghlan) Date: 2006-02-12 01:35 Message: Logged In: YES user_id=1038590 Added basic test suite. Could use beefing up in the area of actually checking that running modules inside packages works correctly (I'm currently checking that bit manually). ---------------------------------------------------------------------- Comment By: Nick Coghlan (ncoghlan) Date: 2006-02-12 01:29 Message: Logged In: YES user_id=1038590 Version 3 of implementation. Fixed emulator to generate an ImportError for non-packages (instead of an AttributeError in some cases). Removed extraneous print statements from emulator. ---------------------------------------------------------------------- Comment By: Nick Coghlan (ncoghlan) Date: 2006-02-12 00:28 Message: Logged In: YES user_id=1038590 Updated to avoid trying to hide exec's quirks. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1429601&group_id=5470 From noreply at sourceforge.net Fri Mar 17 13:34:11 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 17 Mar 2006 04:34:11 -0800 Subject: [Patches] [ python-Patches-1446847 ] patch for 1441408 compiler fails to spot extended slice Message-ID: Patches item #1446847, was opened at 2006-03-10 10:21 Message generated for change (Comment added) made by ncoghlan You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1446847&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Parser/Compiler Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: Grant Olson (logistix) Assigned to: Neal Norwitz (nnorwitz) Summary: patch for 1441408 compiler fails to spot extended slice Initial Comment: Attached is a patch for bug 1441408 (svn head compiler fails to spot extended slicing). The problem was that the new compiler was assuming that a null step value meant that normal slicing was being used. I did have to modify the .asdl for this to work, but after trying a few approaches this seemed like the simplest. ---------------------------------------------------------------------- >Comment By: Nick Coghlan (ncoghlan) Date: 2006-03-17 22:34 Message: Logged In: YES user_id=1038590 Is changing the AST for this is really necessary? Why not simply insert "None" as the step subexpression in the generated AST? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1446847&group_id=5470 From noreply at sourceforge.net Fri Mar 17 14:41:01 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 17 Mar 2006 05:41:01 -0800 Subject: [Patches] [ python-Patches-1452332 ] Minimalist fix for bug 1446847 Message-ID: Patches item #1452332, was opened at 2006-03-17 23:41 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1452332&group_id=5470 Please note that this 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: Nick Coghlan (ncoghlan) Assigned to: Nobody/Anonymous (nobody) Summary: Minimalist fix for bug 1446847 Initial Comment: Address bug 1446847 without modifying the AST - simply explicitly set the slice step to None when a second colon is present but no step expression is provided. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1452332&group_id=5470 From noreply at sourceforge.net Fri Mar 17 14:44:14 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 17 Mar 2006 05:44:14 -0800 Subject: [Patches] [ python-Patches-1452332 ] Minimalist fix for bug 1441408 Message-ID: Patches item #1452332, was opened at 2006-03-17 23:41 Message generated for change (Comment added) made by ncoghlan You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1452332&group_id=5470 Please note that this 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: Nick Coghlan (ncoghlan) Assigned to: Nobody/Anonymous (nobody) >Summary: Minimalist fix for bug 1441408 Initial Comment: Address bug 1446847 without modifying the AST - simply explicitly set the slice step to None when a second colon is present but no step expression is provided. ---------------------------------------------------------------------- >Comment By: Nick Coghlan (ncoghlan) Date: 2006-03-17 23:44 Message: Logged In: YES user_id=1038590 The identifier in the description is for the proposed patch that modifies the AST - title has been fixed to refer to actual bug report (1441408) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1452332&group_id=5470 From noreply at sourceforge.net Fri Mar 17 15:02:58 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 17 Mar 2006 06:02:58 -0800 Subject: [Patches] [ python-Patches-1429605 ] PEP 338 documentation Message-ID: Patches item #1429605, was opened at 2006-02-11 19:18 Message generated for change (Comment added) made by ncoghlan You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1429605&group_id=5470 Please note that this 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: Nick Coghlan (ncoghlan) >Assigned to: Fred L. Drake, Jr. (fdrake) Summary: PEP 338 documentation Initial Comment: The attached Latex file (librunpy.tex) contains the documentation for PEP 338's proposed runpy module. I haven't included a patch for lib.tex or Makefile.deps, since those changes are fairly trivial and I'm not too particular about where the module gets slotted into the Library reference. ---------------------------------------------------------------------- >Comment By: Nick Coghlan (ncoghlan) Date: 2006-03-18 00:02 Message: Logged In: YES user_id=1038590 Kicking in Fred's direction to check my formatting isn't too horrible and to decide where to include it in the Library Reference table of contents. ---------------------------------------------------------------------- Comment By: Nick Coghlan (ncoghlan) Date: 2006-02-19 01:07 Message: Logged In: YES user_id=1038590 Updated to match Feb 18 version of PEP. ---------------------------------------------------------------------- Comment By: Nick Coghlan (ncoghlan) Date: 2006-02-18 01:20 Message: Logged In: YES user_id=1038590 PEP 338 has been updated as of 18-Feb-2006. Those changes are still to be incorporated into this documentation. ---------------------------------------------------------------------- Comment By: Nick Coghlan (ncoghlan) Date: 2006-02-12 00:44 Message: Logged In: YES user_id=1038590 Updated to avoid trying to hide exec's quirks ---------------------------------------------------------------------- Comment By: Nick Coghlan (ncoghlan) Date: 2006-02-11 21:03 Message: Logged In: YES user_id=1038590 Minor tweak to run_function_code to clarify the problem with resolving names when the locals and globals dictionaries are different. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1429605&group_id=5470 From noreply at sourceforge.net Fri Mar 17 15:29:54 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 17 Mar 2006 06:29:54 -0800 Subject: [Patches] [ python-Patches-1452332 ] Minimalist fix for bug 1441408 Message-ID: Patches item #1452332, was opened at 2006-03-17 07:41 Message generated for change (Comment added) made by logistix You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1452332&group_id=5470 Please note that this 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: Nick Coghlan (ncoghlan) Assigned to: Nobody/Anonymous (nobody) Summary: Minimalist fix for bug 1441408 Initial Comment: Address bug 1446847 without modifying the AST - simply explicitly set the slice step to None when a second colon is present but no step expression is provided. ---------------------------------------------------------------------- Comment By: Grant Olson (logistix) Date: 2006-03-17 08:29 Message: Logged In: YES user_id=699438 Does this generate the right bytecode if you're not using extended notation (a[:])? If so, it's better than my patch. ---------------------------------------------------------------------- Comment By: Nick Coghlan (ncoghlan) Date: 2006-03-17 07:44 Message: Logged In: YES user_id=1038590 The identifier in the description is for the proposed patch that modifies the AST - title has been fixed to refer to actual bug report (1441408) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1452332&group_id=5470 From noreply at sourceforge.net Fri Mar 17 19:00:27 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 17 Mar 2006 10:00:27 -0800 Subject: [Patches] [ python-Patches-1452332 ] Minimalist fix for bug 1441408 Message-ID: Patches item #1452332, was opened at 2006-03-17 23:41 Message generated for change (Comment added) made by ncoghlan You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1452332&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None >Status: Closed >Resolution: Accepted Priority: 5 Submitted By: Nick Coghlan (ncoghlan) Assigned to: Nobody/Anonymous (nobody) Summary: Minimalist fix for bug 1441408 Initial Comment: Address bug 1446847 without modifying the AST - simply explicitly set the slice step to None when a second colon is present but no step expression is provided. ---------------------------------------------------------------------- >Comment By: Nick Coghlan (ncoghlan) Date: 2006-03-18 04:00 Message: Logged In: YES user_id=1038590 It does (confirmed by comparing dis.dis() output from my patched build against Python 2.4). This makes sense, since the generation of the implicit None step is inside the "sliceop" guard, so its only executed when the second colon is present. Checked in as rev 43121. ---------------------------------------------------------------------- Comment By: Grant Olson (logistix) Date: 2006-03-18 00:29 Message: Logged In: YES user_id=699438 Does this generate the right bytecode if you're not using extended notation (a[:])? If so, it's better than my patch. ---------------------------------------------------------------------- Comment By: Nick Coghlan (ncoghlan) Date: 2006-03-17 23:44 Message: Logged In: YES user_id=1038590 The identifier in the description is for the proposed patch that modifies the AST - title has been fixed to refer to actual bug report (1441408) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1452332&group_id=5470 From noreply at sourceforge.net Fri Mar 17 19:01:56 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 17 Mar 2006 10:01:56 -0800 Subject: [Patches] [ python-Patches-1446847 ] patch for 1441408 compiler fails to spot extended slice Message-ID: Patches item #1446847, was opened at 2006-03-10 10:21 Message generated for change (Comment added) made by ncoghlan You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1446847&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Parser/Compiler Group: Python 2.5 >Status: Closed >Resolution: Duplicate Priority: 5 Submitted By: Grant Olson (logistix) >Assigned to: Nobody/Anonymous (nobody) Summary: patch for 1441408 compiler fails to spot extended slice Initial Comment: Attached is a patch for bug 1441408 (svn head compiler fails to spot extended slicing). The problem was that the new compiler was assuming that a null step value meant that normal slicing was being used. I did have to modify the .asdl for this to work, but after trying a few approaches this seemed like the simplest. ---------------------------------------------------------------------- >Comment By: Nick Coghlan (ncoghlan) Date: 2006-03-18 04:01 Message: Logged In: YES user_id=1038590 Applied patch 1452332 instead (simpler fix to same problem) ---------------------------------------------------------------------- Comment By: Nick Coghlan (ncoghlan) Date: 2006-03-17 22:34 Message: Logged In: YES user_id=1038590 Is changing the AST for this is really necessary? Why not simply insert "None" as the step subexpression in the generated AST? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1446847&group_id=5470 From noreply at sourceforge.net Fri Mar 17 20:05:52 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 17 Mar 2006 11:05:52 -0800 Subject: [Patches] [ python-Patches-1445505 ] error checking after PyXXX_New Message-ID: Patches item #1445505, was opened at 2006-03-08 09:47 Message generated for change (Comment added) made by gbrandl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1445505&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Core (C code) Group: None >Status: Closed >Resolution: Accepted Priority: 5 Submitted By: Georg Brandl (gbrandl) Assigned to: Thomas Wouters (twouters) Summary: error checking after PyXXX_New Initial Comment: This patch adds a great couple of NULL checks after PyList_New, PyTuple_New and PyDict_New. Thomas, can you review that I didn't make an obvious mistake? ---------------------------------------------------------------------- >Comment By: Georg Brandl (gbrandl) Date: 2006-03-17 19:05 Message: Logged In: YES user_id=849994 Checked in as rev. 43124, backported most as rev. 43125. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1445505&group_id=5470 From noreply at sourceforge.net Fri Mar 17 20:35:50 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 17 Mar 2006 11:35:50 -0800 Subject: [Patches] [ python-Patches-1229511 ] Zipfile fix create_system information Message-ID: Patches item #1229511, was opened at 2005-06-29 07:47 Message generated for change (Comment added) made by gbrandl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1229511&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None >Status: Pending Resolution: None Priority: 5 Submitted By: Hendrik Muhs (hendriktt) Assigned to: Nobody/Anonymous (nobody) Summary: Zipfile fix create_system information Initial Comment: this patches corrects the create_system value for created zipfiles with the zipfile module, which is platform dependent (better: filesystem dependent). It fixes the following bug: if a zipfile is created with Python on Unix and the files have executable flags the file rights are correctly saved into the zipfile. But when extracting the file with unzip (from Info-zip) the filerights (executable flags) are not reassigned correctly. This is due to the wrong create_system flag. The patch is not the 100% correct way to do it, but it is better as the situation now (completly ignore the system and always set create_system to 0). The right way to fix this would be to set the create_system flag dependent on the platform and the filesystem but I do not know how to do this. ---------------------------------------------------------------------- >Comment By: Georg Brandl (gbrandl) Date: 2006-03-17 19:35 Message: Logged In: YES user_id=849994 Waiting for input from OP. ---------------------------------------------------------------------- Comment By: Ronald Oussoren (ronaldoussoren) Date: 2006-03-07 12:35 Message: Logged In: YES user_id=580910 Could you check if the trunk is acceptable to you, and if so close this patch? Patch 1412872 also sets create_system to another value on unix systems and was applied at 05 feb 2006. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1229511&group_id=5470 From noreply at sourceforge.net Fri Mar 17 22:07:21 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 17 Mar 2006 13:07:21 -0800 Subject: [Patches] [ python-Patches-1231053 ] audioop - alaw encoding/decoding added, code updated Message-ID: Patches item #1231053, was opened at 2005-07-01 16:04 Message generated for change (Comment added) made by gbrandl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1231053&group_id=5470 Please note that this 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: Lars Immisch (larsimmisch) Assigned to: Anthony Baxter (anthonybaxter) Summary: audioop - alaw encoding/decoding added, code updated Initial Comment: This patch adds a-LAW encoding to audioop and replaces[1] the old u-LAW encoding/decoding code with the current code from sox. If audioop has an ulaw codec, it should also have an alaw codec. Besides, shtoom wants/needs it. Tests and documentation are updated with this patch too. The patch is a unified diff against CVS that can be applied in one piece frrom the root of the python tree. Beyond the cursory tests in the unittests, I have done successful tests with real-life data. Possible issues: the code from sox uses int16_t. [1] Rationale for the replacement of existing code: the alaw code would have been different in style from the ulaw code and attribution of the code would have been less clear. ---------------------------------------------------------------------- >Comment By: Georg Brandl (gbrandl) Date: 2006-03-17 21:07 Message: Logged In: YES user_id=849994 Patch looks good and has docs and tests. ---------------------------------------------------------------------- Comment By: Florian Schmidt (fastflo) Date: 2006-01-28 01:25 Message: Logged In: YES user_id=182876 me and the company i'm working for are very interested in this patch. as a german telecomunication service provider we have to deal with alaw all the time... (headerless data) the patch works for us, would be great if it would come into one of the next release's... ---------------------------------------------------------------------- Comment By: Anthony Baxter (anthonybaxter) Date: 2005-08-12 21:52 Message: Logged In: YES user_id=29957 I'll look at this shortly. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1231053&group_id=5470 From noreply at sourceforge.net Sat Mar 18 02:50:58 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 17 Mar 2006 17:50:58 -0800 Subject: [Patches] [ python-Patches-1452906 ] N-d array interface for array object Message-ID: Patches item #1452906, was opened at 2006-03-17 20: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=1452906&group_id=5470 Please note that this 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: Alexander Belopolsky (belopolsky) Assigned to: Nobody/Anonymous (nobody) Summary: N-d array interface for array object Initial Comment: This patch implements the "required" methods of N-d array interface. See http://numeric.scipy.org/array_interface.html . ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1452906&group_id=5470 From noreply at sourceforge.net Sat Mar 18 08:06:07 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 17 Mar 2006 23:06:07 -0800 Subject: [Patches] [ python-Patches-1031213 ] Patch for bug #780725 Message-ID: Patches item #1031213, was opened at 2004-09-20 22:37 Message generated for change (Comment added) made by ishimoto You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1031213&group_id=5470 Please note that this 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: 5 Submitted By: atsuo ishimoto (ishimoto) Assigned to: Neal Norwitz (nnorwitz) Summary: Patch for bug #780725 Initial Comment: When SyntaxError occurs and the module contains source encodings definition, current implementation prints error line in UTF8. This patch reverts the line into original encoding for printing. This patch calls some memory-allocation APIs such as PyUnicode_DecodeUTF8. I'm not sure I can (or should) call PyErr_Clear() here if error happened. ---------------------------------------------------------------------- >Comment By: atsuo ishimoto (ishimoto) Date: 2006-03-18 16:06 Message: Logged In: YES user_id=463672 Sorry for my laziness. I revised a patch for current trunk. - Use "replace" for recoding source - Reports error with PyErr_Print() - Test case ---------------------------------------------------------------------- Comment By: atsuo ishimoto (ishimoto) Date: 2005-10-13 15:38 Message: Logged In: YES user_id=463672 Thanks for your comments. I'll post a revised patch and test case later. ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2005-10-03 03:08 Message: Logged In: YES user_id=38388 Please use the "replace" error handler when recoding the source line to Unicode - this will reduce the probability of the conversion failing. If you do get an error, it's likely going to be an unknown encoding or less likely a memory problem. Please add some logic to deal with these errors as well - currently you don't call PyError_Clear() or take some other action which may lead to confusing error reports (e.g. error popping up randomly during program execution due to the set error). ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2005-10-02 14:45 Message: Logged In: YES user_id=33168 I'm hoping that someone more familiar with unicode could take a look at this. The patch looks ok to me, but I don't know how to test that it works. I'm inclined to accept it, unless I hear otherwise. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1031213&group_id=5470 From noreply at sourceforge.net Sat Mar 18 09:01:35 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 18 Mar 2006 00:01:35 -0800 Subject: [Patches] [ python-Patches-1170323 ] Method for cell objects to access contents Message-ID: Patches item #1170323, was opened at 2005-03-25 03:40 Message generated for change (Comment added) made by gbrandl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1170323&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Core (C code) Group: None >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: paul cannon (paulcannon) Assigned to: Nobody/Anonymous (nobody) Summary: Method for cell objects to access contents Initial Comment: Having poked around a little bit, I found it's not simple to get at the contents of a cell object from Python. It's not the sort of thing that one needs to be doing very frequently, but I've run into a few situations recently where it would be really useful from a debugging standpoint. You can get at a cell object containing a given value by making a quick closure and looking at the func_closure attribute: (lambda x: lambda: x)(some_value).func_closure[0] but there's not anything we can easily do with that object to find out what it's pointing at. The str() representation only tells us the id of the contained value. This trivial patch creates a "value()" method for cell objects that returns a new reference to the contained object, for introspection purposes. I should mention it's not the only way to accomplish this; you can also get at the contents of a cell by creating a new function from a code object and manufacturing its func_closures tuple from the cell you already have: def get_cell_value(cell): return type(lambda: 0)( (lambda x: lambda: x)(0).func_code, {}, None, None, (cell,) )() ..but that's non-obvious and not particularly convenient. ---------------------------------------------------------------------- >Comment By: Georg Brandl (gbrandl) Date: 2006-03-18 08:01 Message: Logged In: YES user_id=849994 Added a "cell_contents" attribute to cell objects in rev. 43131. ---------------------------------------------------------------------- Comment By: Armin Rigo (arigo) Date: 2005-04-03 14:43 Message: Logged In: YES user_id=4771 I guess this can be safely sneaked in 2.5, as cells are quite undocumented internal objects anyway. I believe it would be more natural to access the value as an attribute "c.value", though. (Possibly even a read-write attribute?) Probably not in 2.4, though; there is a no-new-feature policy. ---------------------------------------------------------------------- Comment By: paul cannon (paulcannon) Date: 2005-03-25 03:42 Message: Logged In: YES user_id=222090 I should mention the patch applies against both 2.4 and the latest 2.5 from CVS. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1170323&group_id=5470 From noreply at sourceforge.net Sat Mar 18 16:24:28 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 18 Mar 2006 07:24:28 -0800 Subject: [Patches] [ python-Patches-1443155 ] Incremental codecs for CJKCodecs Message-ID: Patches item #1443155, was opened at 2006-03-04 19:45 Message generated for change (Comment added) made by doerwalter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1443155&group_id=5470 Please note that this 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: Hye-Shik Chang (perky) Assigned to: Hye-Shik Chang (perky) Summary: Incremental codecs for CJKCodecs Initial Comment: Here's a supplemental patch for SF #1436130 to implement CJKCodecs part of the Incremental codec specification. This patch is implemented in an interface of Walter's fourth patch on #1436130. Please test this whether it agrees the design. ---------------------------------------------------------------------- >Comment By: Walter D?rwald (doerwalter) Date: 2006-03-18 16:24 Message: Logged In: YES user_id=89016 What other interpretation of the final parameter can we use that doesn't make it completely useless? What about the following: "If final is true the codec must encode/decode the input completely and must flush all buffers. If this isn't possible (e.g. because of incomplete byte sequences on decoding) it must raise an exception (unless prevented by an error handler)"? ---------------------------------------------------------------------- Comment By: Hye-Shik Chang (perky) Date: 2006-03-16 13:32 Message: Logged In: YES user_id=55188 1) Because CJKCodecs had an internal stateful framework, I implemented just an interface using it for IncrementalCodec. It treats final=True as a simple `flush' message(which doesn't reset or terminate the codec). The behavior is quite useful for real-time stream processing such as sockets and tail log watchers. If we disallow that, such usages may require its own sequence detectors. For "to reset or not" issue, I think we can simply follow how iconv does. iconv doesn't reset the internal state for iconv(ic, NULL, NULL, ..). 2) Aah. I didn't notice that .errors is a part of public API. The current CJKCodecs can't support it easily yet. I'll fix it and upload a updated patch soon. Thank you for your review! ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2006-03-15 13:08 Message: Logged In: YES user_id=89016 The patch doesn't apply cleanly (conflicts in Lib/test/test_multibytecodec.py and Tools/unicode/Makefile). Could you update the patch? I haven't looked at the C code to closely yet. Two notes: 1) The tests often call incencoder.encode() or incdecoder.decode() again after the method has been called with final=True before. I'm not sure that this should be allowed. If we allow it, it should be documented in what state the codec is after calling with final=True (probably it should be back to the initial state (i.e. like calling reset())). 2) It seems to me that it isn't possible to change the error handling during the lifetime of a codec. Anyway, thanks for the quick patch. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1443155&group_id=5470 From noreply at sourceforge.net Sat Mar 18 16:26:29 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 18 Mar 2006 07:26:29 -0800 Subject: [Patches] [ python-Patches-1436130 ] Incremental codecs Message-ID: Patches item #1436130, was opened at 2006-02-21 20:32 Message generated for change (Comment added) made by doerwalter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1436130&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Library (Lib) Group: Python 2.5 Status: Open Resolution: Accepted Priority: 5 Submitted By: Walter D?rwald (doerwalter) Assigned to: Walter D?rwald (doerwalter) Summary: Incremental codecs Initial Comment: This patch extends the codec machinery to add incremental codecs: stateful codecs that don't use a stream API. It adds the following stuff: a class codecs.CodecInfo (a subclass of tuple), that is used as the return value of codecs.lookup(); codecs.IncrementalEncoder and codecs.IncrementalDecoder (the basic interface classes), codecs.BufferedIncrementalDecoder (a class that can be used to implement decoders that must handle incomplete input); codecs.iterencode() and codecs.iterdecode() (generators that use the incremental codecs for encoding/decoding an input iterable). On the C level PyCodec_IncrementalEncoder() and PyCodec_IncrementalDecoder() are added. ---------------------------------------------------------------------- >Comment By: Walter D?rwald (doerwalter) Date: 2006-03-18 16:26 Message: Logged In: YES user_id=89016 MAL, do you have any suggestions on improving the code in encodings.search_function()? ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2006-03-15 13:14 Message: Logged In: YES user_id=38388 It's only the coding style that looks a bit funny. Requiring CodecInfo objects is not a good idea: that way you'd make it impossible to write codecs that work in both Python 2.5 and 2.4. ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2006-03-15 12:43 Message: Logged In: YES user_id=89016 Checked in as r43045. Now what do we do with the funny code in encoding.search_function()? Of course we could always *require* the search function to return a CodecInfo object. (but only after the CJK codecs are updated, and even then we should have some form of backwards compatibility). ---------------------------------------------------------------------- Comment By: Hye-Shik Chang (perky) Date: 2006-03-15 12:28 Message: Logged In: YES user_id=55188 1449471 isn't related to incremental codecs. It includes a simple patch to visual studio project file. I think Walter is right person to review 1443155 whether it conforms his interface design. :-) (Thank you in advance!) ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2006-03-15 12:13 Message: Logged In: YES user_id=38388 The patch looks OK, accept for some minor glitches such as this mess :-) ... + if not isinstance(entry, codecs.CodecInfo): + if not 4 <= len(entry) <= 7: + raise CodecRegistryError,\ + 'module "%s" (%s) failed to register' % \ + (mod.__name__, mod.__file__) + if not callable(entry[0]) or \ + not callable(entry[1]) or \ + (entry[2] is not None and not callable(entry[2])) or \ + (entry[3] is not None and not callable(entry[3])) or \ + (len(entry) > 4 and entry[4] is not None and not callable(entry[4])) or \ + (len(entry) > 5 and entry[5] is not None and not callable(entry[5])): raise CodecRegistryError,\ - 'incompatible codecs in module "%s" (%s)' % \ - (mod.__name__, mod.__file__) + 'incompatible codecs in module "%s" (%s)' % \ + (mod.__name__, mod.__file__) + if len(entry)<7 or entry[6] is None: + entry += (None,)*(6-len(entry)) + (mod.__name__.split(".", 1)[1],) + entry = codecs.CodecInfo(*entry) Nevertheless, it can be cleaned up after checkin, so please go ahead with it. Regarding the idna.py patch, I think you should create a new patch item for it and assign it to Martin. Thanks. Neal, I don't have time to review the two CJK patches. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2006-03-15 09:01 Message: Logged In: YES user_id=33168 MAL, do you have any more issues with this patch? Should it be assigned to Martin? MAL, Walter, can you review these patches 1443155 1449471 which I think are related? Should they go in? The first alpha is coming up soon and I'd like to get these patches in ASAP. ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2006-03-03 18:39 Message: Logged In: YES user_id=89016 This fourth version of the patch removes the changes to Lib/encodings/idna.py (only the addition of the IncrementalEncoder/IncrementalDecoder and the changed getregentry() remain). This patch to idna.py probably only makes sense once this patch is in. > Is it possible to make IncrementalEncoder/Decoder > instances iterable per-se (without the need to go > through the helper functions iterencode/iterdecode) ? For IncrementalEncoder/Decoder to be iterable it would have to have some iterable from which it gets the input. But this has the same limitation as the stream API: The user is forced to provide the input as a service that the encoder/decoder uses, which requires support for a certain API. The only change would be that now it's an iterator API instead of a stream API. The incremental codecs invert the call logic: The user no longer has to provide a callback service to the codec, but calls the codec directly. This gives much more flexibility. ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2006-03-03 00:03 Message: Logged In: YES user_id=38388 Very nice ! This is a much better approach than the feed style path you wanted to take previously. Minor nits: Please separate out the non-related changes to the IDNA codec into a new patch and assign that to Martin for review. Is it possible to make IncrementalEncoder/Decoder instances iterable per-se (without the need to go through the helper functions iterencode/iterdecode) ? Thanks. ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2006-03-01 15:47 Message: Logged In: YES user_id=89016 This third version of the patch fixes the bug when the iterator in iterencode() or iterdecode() is empty and updates the docstring in encodings/__init__.py. ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2006-02-28 13:08 Message: Logged In: YES user_id=89016 This second version of the patch enhances codecs.iterencode() and codecs.iterdecode(), so that additional keyword arguments are passed through to the Incremental(De|En)coder constructor. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1436130&group_id=5470 From noreply at sourceforge.net Sat Mar 18 16:52:55 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 18 Mar 2006 07:52:55 -0800 Subject: [Patches] [ python-Patches-1453235 ] IDNA codec simplification Message-ID: Patches item #1453235, was opened at 2006-03-18 16:52 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1453235&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Library (Lib) Group: None Status: Open Resolution: None Priority: 5 Submitted By: Walter D?rwald (doerwalter) Assigned to: Martin v. L??wis (loewis) Summary: IDNA codec simplification Initial Comment: This patch simplifies the idna codec. It moves the encode and decode functionality out of the Codec class, so that it can be reused by the stateless and the incremental codecs. (See patch #1436130 for the history of this patch). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1453235&group_id=5470 From noreply at sourceforge.net Sat Mar 18 16:53:30 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 18 Mar 2006 07:53:30 -0800 Subject: [Patches] [ python-Patches-1436130 ] Incremental codecs Message-ID: Patches item #1436130, was opened at 2006-02-21 20:32 Message generated for change (Comment added) made by doerwalter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1436130&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Library (Lib) Group: Python 2.5 Status: Open Resolution: Accepted Priority: 5 Submitted By: Walter D?rwald (doerwalter) Assigned to: Walter D?rwald (doerwalter) Summary: Incremental codecs Initial Comment: This patch extends the codec machinery to add incremental codecs: stateful codecs that don't use a stream API. It adds the following stuff: a class codecs.CodecInfo (a subclass of tuple), that is used as the return value of codecs.lookup(); codecs.IncrementalEncoder and codecs.IncrementalDecoder (the basic interface classes), codecs.BufferedIncrementalDecoder (a class that can be used to implement decoders that must handle incomplete input); codecs.iterencode() and codecs.iterdecode() (generators that use the incremental codecs for encoding/decoding an input iterable). On the C level PyCodec_IncrementalEncoder() and PyCodec_IncrementalDecoder() are added. ---------------------------------------------------------------------- >Comment By: Walter D?rwald (doerwalter) Date: 2006-03-18 16:53 Message: Logged In: YES user_id=89016 OK, I've submitted a new patch (#1453235) for the idna simplification. ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2006-03-18 16:26 Message: Logged In: YES user_id=89016 MAL, do you have any suggestions on improving the code in encodings.search_function()? ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2006-03-15 13:14 Message: Logged In: YES user_id=38388 It's only the coding style that looks a bit funny. Requiring CodecInfo objects is not a good idea: that way you'd make it impossible to write codecs that work in both Python 2.5 and 2.4. ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2006-03-15 12:43 Message: Logged In: YES user_id=89016 Checked in as r43045. Now what do we do with the funny code in encoding.search_function()? Of course we could always *require* the search function to return a CodecInfo object. (but only after the CJK codecs are updated, and even then we should have some form of backwards compatibility). ---------------------------------------------------------------------- Comment By: Hye-Shik Chang (perky) Date: 2006-03-15 12:28 Message: Logged In: YES user_id=55188 1449471 isn't related to incremental codecs. It includes a simple patch to visual studio project file. I think Walter is right person to review 1443155 whether it conforms his interface design. :-) (Thank you in advance!) ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2006-03-15 12:13 Message: Logged In: YES user_id=38388 The patch looks OK, accept for some minor glitches such as this mess :-) ... + if not isinstance(entry, codecs.CodecInfo): + if not 4 <= len(entry) <= 7: + raise CodecRegistryError,\ + 'module "%s" (%s) failed to register' % \ + (mod.__name__, mod.__file__) + if not callable(entry[0]) or \ + not callable(entry[1]) or \ + (entry[2] is not None and not callable(entry[2])) or \ + (entry[3] is not None and not callable(entry[3])) or \ + (len(entry) > 4 and entry[4] is not None and not callable(entry[4])) or \ + (len(entry) > 5 and entry[5] is not None and not callable(entry[5])): raise CodecRegistryError,\ - 'incompatible codecs in module "%s" (%s)' % \ - (mod.__name__, mod.__file__) + 'incompatible codecs in module "%s" (%s)' % \ + (mod.__name__, mod.__file__) + if len(entry)<7 or entry[6] is None: + entry += (None,)*(6-len(entry)) + (mod.__name__.split(".", 1)[1],) + entry = codecs.CodecInfo(*entry) Nevertheless, it can be cleaned up after checkin, so please go ahead with it. Regarding the idna.py patch, I think you should create a new patch item for it and assign it to Martin. Thanks. Neal, I don't have time to review the two CJK patches. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2006-03-15 09:01 Message: Logged In: YES user_id=33168 MAL, do you have any more issues with this patch? Should it be assigned to Martin? MAL, Walter, can you review these patches 1443155 1449471 which I think are related? Should they go in? The first alpha is coming up soon and I'd like to get these patches in ASAP. ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2006-03-03 18:39 Message: Logged In: YES user_id=89016 This fourth version of the patch removes the changes to Lib/encodings/idna.py (only the addition of the IncrementalEncoder/IncrementalDecoder and the changed getregentry() remain). This patch to idna.py probably only makes sense once this patch is in. > Is it possible to make IncrementalEncoder/Decoder > instances iterable per-se (without the need to go > through the helper functions iterencode/iterdecode) ? For IncrementalEncoder/Decoder to be iterable it would have to have some iterable from which it gets the input. But this has the same limitation as the stream API: The user is forced to provide the input as a service that the encoder/decoder uses, which requires support for a certain API. The only change would be that now it's an iterator API instead of a stream API. The incremental codecs invert the call logic: The user no longer has to provide a callback service to the codec, but calls the codec directly. This gives much more flexibility. ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2006-03-03 00:03 Message: Logged In: YES user_id=38388 Very nice ! This is a much better approach than the feed style path you wanted to take previously. Minor nits: Please separate out the non-related changes to the IDNA codec into a new patch and assign that to Martin for review. Is it possible to make IncrementalEncoder/Decoder instances iterable per-se (without the need to go through the helper functions iterencode/iterdecode) ? Thanks. ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2006-03-01 15:47 Message: Logged In: YES user_id=89016 This third version of the patch fixes the bug when the iterator in iterencode() or iterdecode() is empty and updates the docstring in encodings/__init__.py. ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2006-02-28 13:08 Message: Logged In: YES user_id=89016 This second version of the patch enhances codecs.iterencode() and codecs.iterdecode(), so that additional keyword arguments are passed through to the Incremental(De|En)coder constructor. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1436130&group_id=5470 From noreply at sourceforge.net Sat Mar 18 19:32:51 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 18 Mar 2006 10:32:51 -0800 Subject: [Patches] [ python-Patches-1443155 ] Incremental codecs for CJKCodecs Message-ID: Patches item #1443155, was opened at 2006-03-05 03:45 Message generated for change (Comment added) made by perky You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1443155&group_id=5470 Please note that this 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: Hye-Shik Chang (perky) Assigned to: Hye-Shik Chang (perky) Summary: Incremental codecs for CJKCodecs Initial Comment: Here's a supplemental patch for SF #1436130 to implement CJKCodecs part of the Incremental codec specification. This patch is implemented in an interface of Walter's fourth patch on #1436130. Please test this whether it agrees the design. ---------------------------------------------------------------------- >Comment By: Hye-Shik Chang (perky) Date: 2006-03-19 03:32 Message: Logged In: YES user_id=55188 I updated the patch for the .errors visibility. I like the statement. But the current implementation of the patch is slightly different for a corner case; the current implementation keeps buffers if an error is occurred. That is somewhat natural because error cases doesn't make side-effects usually. But in other side, I agree to your statement in a view of a direct interpretation of final=True. What do you think about this? ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2006-03-19 00:24 Message: Logged In: YES user_id=89016 What other interpretation of the final parameter can we use that doesn't make it completely useless? What about the following: "If final is true the codec must encode/decode the input completely and must flush all buffers. If this isn't possible (e.g. because of incomplete byte sequences on decoding) it must raise an exception (unless prevented by an error handler)"? ---------------------------------------------------------------------- Comment By: Hye-Shik Chang (perky) Date: 2006-03-16 21:32 Message: Logged In: YES user_id=55188 1) Because CJKCodecs had an internal stateful framework, I implemented just an interface using it for IncrementalCodec. It treats final=True as a simple `flush' message(which doesn't reset or terminate the codec). The behavior is quite useful for real-time stream processing such as sockets and tail log watchers. If we disallow that, such usages may require its own sequence detectors. For "to reset or not" issue, I think we can simply follow how iconv does. iconv doesn't reset the internal state for iconv(ic, NULL, NULL, ..). 2) Aah. I didn't notice that .errors is a part of public API. The current CJKCodecs can't support it easily yet. I'll fix it and upload a updated patch soon. Thank you for your review! ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2006-03-15 21:08 Message: Logged In: YES user_id=89016 The patch doesn't apply cleanly (conflicts in Lib/test/test_multibytecodec.py and Tools/unicode/Makefile). Could you update the patch? I haven't looked at the C code to closely yet. Two notes: 1) The tests often call incencoder.encode() or incdecoder.decode() again after the method has been called with final=True before. I'm not sure that this should be allowed. If we allow it, it should be documented in what state the codec is after calling with final=True (probably it should be back to the initial state (i.e. like calling reset())). 2) It seems to me that it isn't possible to change the error handling during the lifetime of a codec. Anyway, thanks for the quick patch. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1443155&group_id=5470 From noreply at sourceforge.net Sat Mar 18 19:35:29 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 18 Mar 2006 10:35:29 -0800 Subject: [Patches] [ python-Patches-1170323 ] Method for cell objects to access contents Message-ID: Patches item #1170323, was opened at 2005-03-24 22:40 Message generated for change (Comment added) made by tim_one You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1170323&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Core (C code) Group: None Status: Closed Resolution: Fixed Priority: 5 Submitted By: paul cannon (paulcannon) >Assigned to: Jeremy Hylton (jhylton) Summary: Method for cell objects to access contents Initial Comment: Having poked around a little bit, I found it's not simple to get at the contents of a cell object from Python. It's not the sort of thing that one needs to be doing very frequently, but I've run into a few situations recently where it would be really useful from a debugging standpoint. You can get at a cell object containing a given value by making a quick closure and looking at the func_closure attribute: (lambda x: lambda: x)(some_value).func_closure[0] but there's not anything we can easily do with that object to find out what it's pointing at. The str() representation only tells us the id of the contained value. This trivial patch creates a "value()" method for cell objects that returns a new reference to the contained object, for introspection purposes. I should mention it's not the only way to accomplish this; you can also get at the contents of a cell by creating a new function from a code object and manufacturing its func_closures tuple from the cell you already have: def get_cell_value(cell): return type(lambda: 0)( (lambda x: lambda: x)(0).func_code, {}, None, None, (cell,) )() ..but that's non-obvious and not particularly convenient. ---------------------------------------------------------------------- >Comment By: Tim Peters (tim_one) Date: 2006-03-18 13:35 Message: Logged In: YES user_id=31435 Jeremy, I vaguely recall that you deliberately made cell objects non-inspectable. Is that right? If so and you still care about that, note that it's no longer true. ---------------------------------------------------------------------- Comment By: Georg Brandl (gbrandl) Date: 2006-03-18 03:01 Message: Logged In: YES user_id=849994 Added a "cell_contents" attribute to cell objects in rev. 43131. ---------------------------------------------------------------------- Comment By: Armin Rigo (arigo) Date: 2005-04-03 10:43 Message: Logged In: YES user_id=4771 I guess this can be safely sneaked in 2.5, as cells are quite undocumented internal objects anyway. I believe it would be more natural to access the value as an attribute "c.value", though. (Possibly even a read-write attribute?) Probably not in 2.4, though; there is a no-new-feature policy. ---------------------------------------------------------------------- Comment By: paul cannon (paulcannon) Date: 2005-03-24 22:42 Message: Logged In: YES user_id=222090 I should mention the patch applies against both 2.4 and the latest 2.5 from CVS. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1170323&group_id=5470 From noreply at sourceforge.net Sat Mar 18 21:47:29 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 18 Mar 2006 12:47:29 -0800 Subject: [Patches] [ python-Patches-1443155 ] Incremental codecs for CJKCodecs Message-ID: Patches item #1443155, was opened at 2006-03-04 19:45 Message generated for change (Comment added) made by doerwalter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1443155&group_id=5470 Please note that this 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: Hye-Shik Chang (perky) Assigned to: Hye-Shik Chang (perky) Summary: Incremental codecs for CJKCodecs Initial Comment: Here's a supplemental patch for SF #1436130 to implement CJKCodecs part of the Incremental codec specification. This patch is implemented in an interface of Walter's fourth patch on #1436130. Please test this whether it agrees the design. ---------------------------------------------------------------------- >Comment By: Walter D?rwald (doerwalter) Date: 2006-03-18 21:47 Message: Logged In: YES user_id=89016 Maybe the statement is a bit misleading in its current form. I didn't mean that error handling prevents the flushing of the buffers, just that error handling prevents raising an error. I hope the following is clearer: "If final is true the codec must encode/decode the input completely and must flush all buffers. If this isn't possible (e.g. because of incomplete byte sequences still remaining in the buffer on decoding) it must initiate error handling just like in the stateless case (which might raise an exception)." I'll take a look at the patch in the next few days. ---------------------------------------------------------------------- Comment By: Hye-Shik Chang (perky) Date: 2006-03-18 19:32 Message: Logged In: YES user_id=55188 I updated the patch for the .errors visibility. I like the statement. But the current implementation of the patch is slightly different for a corner case; the current implementation keeps buffers if an error is occurred. That is somewhat natural because error cases doesn't make side-effects usually. But in other side, I agree to your statement in a view of a direct interpretation of final=True. What do you think about this? ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2006-03-18 16:24 Message: Logged In: YES user_id=89016 What other interpretation of the final parameter can we use that doesn't make it completely useless? What about the following: "If final is true the codec must encode/decode the input completely and must flush all buffers. If this isn't possible (e.g. because of incomplete byte sequences on decoding) it must raise an exception (unless prevented by an error handler)"? ---------------------------------------------------------------------- Comment By: Hye-Shik Chang (perky) Date: 2006-03-16 13:32 Message: Logged In: YES user_id=55188 1) Because CJKCodecs had an internal stateful framework, I implemented just an interface using it for IncrementalCodec. It treats final=True as a simple `flush' message(which doesn't reset or terminate the codec). The behavior is quite useful for real-time stream processing such as sockets and tail log watchers. If we disallow that, such usages may require its own sequence detectors. For "to reset or not" issue, I think we can simply follow how iconv does. iconv doesn't reset the internal state for iconv(ic, NULL, NULL, ..). 2) Aah. I didn't notice that .errors is a part of public API. The current CJKCodecs can't support it easily yet. I'll fix it and upload a updated patch soon. Thank you for your review! ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2006-03-15 13:08 Message: Logged In: YES user_id=89016 The patch doesn't apply cleanly (conflicts in Lib/test/test_multibytecodec.py and Tools/unicode/Makefile). Could you update the patch? I haven't looked at the C code to closely yet. Two notes: 1) The tests often call incencoder.encode() or incdecoder.decode() again after the method has been called with final=True before. I'm not sure that this should be allowed. If we allow it, it should be documented in what state the codec is after calling with final=True (probably it should be back to the initial state (i.e. like calling reset())). 2) It seems to me that it isn't possible to change the error handling during the lifetime of a codec. Anyway, thanks for the quick patch. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1443155&group_id=5470 From noreply at sourceforge.net Sat Mar 18 23:18:43 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 18 Mar 2006 14:18:43 -0800 Subject: [Patches] [ python-Patches-1309579 ] A wait4() implementation Message-ID: Patches item #1309579, was opened at 2005-09-30 08:32 Message generated for change (Comment added) made by nnorwitz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1309579&group_id=5470 Please note that this 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: chads (cjschr) >Assigned to: Neal Norwitz (nnorwitz) Summary: A wait4() implementation Initial Comment: Implementation of a BSD-style wait4() function, which is similar to waitpid, but it also returns resource usage information about the child process. wait4(pid, options) -> (pid, status, rusage) Chad ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2006-03-18 14:18 Message: Logged In: YES user_id=33168 I think I recall spotting the docs after your comment. I plan to get this in before alpha1. ---------------------------------------------------------------------- Comment By: chads (cjschr) Date: 2006-01-19 05:47 Message: Logged In: YES user_id=1093928 Neil Check the diff. Doc updates are already there. Thanks. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2006-01-18 22:58 Message: Logged In: YES user_id=33168 I looked over the patch. It looks pretty good. Can your provide doc too? If you can't do latex, just text will do and I'll convert. Doc/lib/libos.tex ---------------------------------------------------------------------- Comment By: chads (cjschr) Date: 2006-01-17 14:52 Message: Logged In: YES user_id=1093928 Took a different approach with implementation. Also includes wait3 implementation. LMK how it looks. Thanks. Chad ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2005-10-02 14:56 Message: Logged In: YES user_id=33168 Comments from author received in mail: It is a duplicate of my original post, but it was diff'ed against the latest CVS tree. The usage example is for those who haven't had experience with wait4 before, hence the name. It's an FYI, nothing more. I'll also update the documentation accordingly. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2005-09-30 20:16 Message: Logged In: YES user_id=33168 Chad, I'm starting to look at this now, but it seems to be a duplicate of your original patch # 1000267. Can this be closed as a duplicate? I don't know if the attachments are the same. It would be easier to have all the changes in a single file. Since you are adding a new file, you will need to use -N option to cvs diff. Something like this: cvs diff -Nu ... (you can list the specific files that changed if necessary). >From what I looked at so far, there were a couple of things I didn't like. Though it looks like you addressed many (perhaps all) of the previous comments. I don't like the code in resourcemodule.h. I would prefer a public API in resourcemodule that posixmodule can call. If you think that no other modules outside python should call this, you can prefix the name with _, ie _PyResourceModule_...(). There are some un-prefixed names in resourcemodule.h. I think these may all go away if you move the code into the .c file. I would prefer to not have resourcemodule_h_author & resourcemodule_h_rcsid. The comment with your name and email is fine. I didn't look at the test or usage example. What should be done with the usage example? In the doc, could you remove the ", ?" for availability. We can leave it as Unix for now. If we find out definitive info about other platforms (Windows, Mac), we can add that later. Please add a \versionadded{2.5} at the end of the new doc (before the end). That's all my comments. This looks close to being ready. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1309579&group_id=5470 From noreply at sourceforge.net Sun Mar 19 04:08:56 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 18 Mar 2006 19:08:56 -0800 Subject: [Patches] [ python-Patches-1324770 ] Adding redblack tree to collections module Message-ID: Patches item #1324770, was opened at 2005-10-12 20:58 Message generated for change (Comment added) made by perky You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1324770&group_id=5470 Please note that this 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: Hye-Shik Chang (perky) Assigned to: Nobody/Anonymous (nobody) Summary: Adding redblack tree to collections module Initial Comment: This patch drafts a new type "rbtree" implementing Redblack Tree for collections module. It's just a preliminary material for the future discussion and includes a least working code. Usage: [basic list-like tree operations] >>> from collections import rbtree >>> r = rbtree() >>> map(r.insert, [9, 3, 4, 100, 'dalki', 'subak', -51]) [None, None, None, None, None, None, None] >>> r.values() [-51, 3, 4, 9, 100, 'dalki', 'subak'] >>> r.remove(100) >>> r.values() [-51, 3, 4, 9, 'dalki', 'subak'] >>> r.insert('snisni') >>> r.values() [-51, 3, 4, 9, 'dalki', 'snisni', 'subak'] >>> 9 in r True >>> 8 in r False [labeled nodes operations] >>> r = rbtree() >>> r['dalki'] = 5; r['subak'] = 1; r['spam'] = 7 >>> r.values() [1, 5, 7] >>> r.keys() ['subak', 'dalki', 'spam'] >>> r['egg'] = 1 >>> r.items() [('egg', 1), ('dalki', 5), ('spam', 7)] >>> del r['spam'] >>> r.items() [('egg', 1), ('dalki', 5)] [mixed altogether] >>> r.insert(7) >>> r.insert(0) >>> r.items() [(None, 0), ('egg', 1), ('dalki', 5), (None, 7)] >>> r['dalki'] = 7 >>> r.items() [(None, 0), ('egg', 1), ('dalki', 7)] [heapq-like stuff] >>> r = rbtree() >>> map(r.insert, range(20)) [None, None, None, None, None, None, None, None, None, None, None, None, None, None, None, None, None, None, None, None] >>> r.nfirst(3) [0, 1, 2] >>> r.nfirst(10) [0, 1, 2, 3, 4, 5, 6, 7, 8, 9] >>> r.nlast(5) [19, 18, 17, 16, 15] >>> r.popleft(5) [0, 1, 2, 3, 4] >>> r.values() [5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16, 17, 18, 19] >>> r.popright(15) [19, 18, 17, 16] >>> r.values() [5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15] >>> r['ham'] = 14 >>> r.poprightitems(14, True) [(None, 15), ('ham', 14)] [cmp, key and reverse are also supported] >>> r = rbtree(key=lambda x: x%10) >>> map(r.insert, range(30)) [None, None, None, None, None, None, None, None, None, None, None, None, None, None, None, None, None, None, None, None, None, None, None, None, None, None, None, None, None, None] >>> r.values() [20, 21, 22, 23, 24, 25, 26, 27, 28, 29] >>> r['yay'] = 78 >>> r.values() [20, 21, 22, 23, 24, 25, 26, 27, 78, 29] >>> r.items() [(None, 20), (None, 21), (None, 22), (None, 23), (None, 24), (None, 25), (None, 26), (None, 27), ('yay', 78), (None, 29)] >>> r.clear() >>> r.values() [] >>> r = rbtree(reverse=True) >>> map(r.insert, range(10)) [None, None, None, None, None, None, None, None, None, None] >>> r.values() [9, 8, 7, 6, 5, 4, 3, 2, 1, 0] ---------------------------------------------------------------------- >Comment By: Hye-Shik Chang (perky) Date: 2006-03-19 12:08 Message: Logged In: YES user_id=55188 Updated the patch for the current svn. ---------------------------------------------------------------------- Comment By: Hye-Shik Chang (perky) Date: 2005-10-16 16:42 Message: Logged In: YES user_id=55188 Added iterator and reverse iterator implementations and __copy__ method. ---------------------------------------------------------------------- Comment By: Hye-Shik Chang (perky) Date: 2005-10-15 00:55 Message: Logged In: YES user_id=55188 Added a unittest and fixed a bug on initcollection() calling PyType_Ready(&rbtree_type). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1324770&group_id=5470 From noreply at sourceforge.net Sun Mar 19 05:20:14 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 18 Mar 2006 20:20:14 -0800 Subject: [Patches] [ python-Patches-1429605 ] PEP 338 documentation Message-ID: Patches item #1429605, was opened at 2006-02-11 18:18 Message generated for change (Comment added) made by quiver You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1429605&group_id=5470 Please note that this 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: Nick Coghlan (ncoghlan) Assigned to: Fred L. Drake, Jr. (fdrake) Summary: PEP 338 documentation Initial Comment: The attached Latex file (librunpy.tex) contains the documentation for PEP 338's proposed runpy module. I haven't included a patch for lib.tex or Makefile.deps, since those changes are fairly trivial and I'm not too particular about where the module gets slotted into the Library reference. ---------------------------------------------------------------------- Comment By: George Yoshida (quiver) Date: 2006-03-19 13:20 Message: Logged In: YES user_id=671362 amk has committed his PEP328 to whatsnew, so that should be helpful. Following his style: - use \programopt for "-m" option - use \pep{} for PEP links - add seealso section And as for your document, - s/initialised/initialized > where to include it in the Library Reference table of contents. I'd like to give my vote to: - imp - zipimport - *runpy* - pkgutil - modulefinder -- george ---------------------------------------------------------------------- Comment By: Nick Coghlan (ncoghlan) Date: 2006-03-17 23:02 Message: Logged In: YES user_id=1038590 Kicking in Fred's direction to check my formatting isn't too horrible and to decide where to include it in the Library Reference table of contents. ---------------------------------------------------------------------- Comment By: Nick Coghlan (ncoghlan) Date: 2006-02-19 00:07 Message: Logged In: YES user_id=1038590 Updated to match Feb 18 version of PEP. ---------------------------------------------------------------------- Comment By: Nick Coghlan (ncoghlan) Date: 2006-02-18 00:20 Message: Logged In: YES user_id=1038590 PEP 338 has been updated as of 18-Feb-2006. Those changes are still to be incorporated into this documentation. ---------------------------------------------------------------------- Comment By: Nick Coghlan (ncoghlan) Date: 2006-02-11 23:44 Message: Logged In: YES user_id=1038590 Updated to avoid trying to hide exec's quirks ---------------------------------------------------------------------- Comment By: Nick Coghlan (ncoghlan) Date: 2006-02-11 20:03 Message: Logged In: YES user_id=1038590 Minor tweak to run_function_code to clarify the problem with resolving names when the locals and globals dictionaries are different. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1429605&group_id=5470 From noreply at sourceforge.net Sun Mar 19 09:02:09 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 19 Mar 2006 00:02:09 -0800 Subject: [Patches] [ python-Patches-1444398 ] Make itertools.tee participate in GC Message-ID: Patches item #1444398, was opened at 2006-03-06 15:33 Message generated for change (Comment added) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1444398&group_id=5470 Please note that this 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: Thomas Wouters (twouters) >Assigned to: Thomas Wouters (twouters) Summary: Make itertools.tee participate in GC Initial Comment: A small patch to make itertools.tee objects participate in GC; solves the memoryleak in test_generators (and any other use of tee objects in cycles.) ---------------------------------------------------------------------- >Comment By: Raymond Hettinger (rhettinger) Date: 2006-03-19 03:02 Message: Logged In: YES user_id=80475 Okay, go ahead and add GC to itertools.tee(). The test_generators examples make it clear that there are valid use cases for feeding a teeobject back into itself. Tim, the original rationale did not have to do with millions of tee objects; rather, it posited that a tee could contain many objects of some other type and that traversing it during GC was simply a waste of time. Thomas, the patch needs work, but I don't currently have time to go through it. Do your best to model after the other tools which have gc. That includes setting the tp_flags slot, doing an untrack before dealloc starts, replacing PyObject_Del and PyObject_New with their GC counterparts. See section 2.1.3 in Extending and Embedding for the details and examples. Offhand, I think it may also need a tp_clear entry but I'm not sure. If you can work out a good patch, go ahead an apply it for the alpha 1 release. If not, assign back to me and I'll get to it when I can (possibly for the second alpha). ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2006-03-06 19:52 Message: Logged In: YES user_id=31435 If there are likely to be millions of some type of object, then avoiding gc for that type on grounds of reducing memory use may be arguable (or, as in the cases of tuples or lists, may not be arguable regardless). Else "if it points to a PyObject, it might be in a cycle, so gc-enable it" generally rules. I'll note in passing that the m235 and fib generators weren't _intended_ to stress Python in any way, but have been extremely effective at doing so since generators first went in. Think of them as a pair of canaries in the coal mine :-) ---------------------------------------------------------------------- Comment By: Thomas Wouters (twouters) Date: 2006-03-06 19:12 Message: Logged In: YES user_id=34209 Well, I'm fine with removing the scope-enclosed generator versions of _m235() and fib() from test_generators, if that's what you're implying. :> However, I think it's slightly more suitable to just have tee participate in GC. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2006-03-06 19:05 Message: Logged In: YES user_id=80475 I will take a look at the patch soon. IIRC, there was a concious decision to not have tee engage in GC because no normal use cases created cycles (they seem to arise only when intentionally creating a cycle for test code). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1444398&group_id=5470 From noreply at sourceforge.net Sun Mar 19 11:00:12 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 19 Mar 2006 02:00:12 -0800 Subject: [Patches] [ python-Patches-1449471 ] Splitting CJK codecs from pythoncore dll Message-ID: Patches item #1449471, was opened at 2006-03-14 11:18 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1449471&group_id=5470 Please note that this 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: Accepted Priority: 5 Submitted By: Hye-Shik Chang (perky) >Assigned to: Hye-Shik Chang (perky) Summary: Splitting CJK codecs from pythoncore dll Initial Comment: As many of western language natives have requested it, this patch splits CJK codecs from pythoncore dll. python25.dll shrinks from 2024KB to 1364KB by this. Even some of CJK users would take some advantages for domestic py2exe-ed releases. ---------------------------------------------------------------------- >Comment By: Martin v. L??wis (loewis) Date: 2006-03-19 11:00 Message: Logged In: YES user_id=21627 I must say that I find this splitting arbitrary. Why are these modules moved out of pythonxy.dll, when, say, multibytecodec, mmap, parser, xxsubtype, sha512 stay. I really wish there was some policy guiding this. That said, as the author of the code, it is certainly your decision to make that split that way. So please go ahead and apply that patch. Please also add the new modules to Tool/msi/msi.py. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1449471&group_id=5470 From noreply at sourceforge.net Sun Mar 19 11:13:52 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 19 Mar 2006 02:13:52 -0800 Subject: [Patches] [ python-Patches-1453235 ] IDNA codec simplification Message-ID: Patches item #1453235, was opened at 2006-03-18 16:52 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1453235&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Library (Lib) Group: None Status: Open Resolution: None Priority: 5 Submitted By: Walter D?rwald (doerwalter) Assigned to: Martin v. L??wis (loewis) Summary: IDNA codec simplification Initial Comment: This patch simplifies the idna codec. It moves the encode and decode functionality out of the Codec class, so that it can be reused by the stateless and the incremental codecs. (See patch #1436130 for the history of this patch). ---------------------------------------------------------------------- >Comment By: Martin v. L??wis (loewis) Date: 2006-03-19 11:13 Message: Logged In: YES user_id=21627 This patch is wrong (AFAICT). If I understand the incremental API correctly, it should be possible to pass chunks of the input to the incremental encoder; concatenating the results should give the same string as if I had passed the entire input at once. This doesn't work for this patch: py> u"d??rwald.de".encode("idna") 'xn--drwald-wxa.de' py> c = codecs.getincrementalencoder("idna")() py> c.encode(u"d??r") 'xn--dr-fka' py> c.encode(u"wald.de") 'wald.de' So in the first case, I get the (correct) result 'xn--drwald-wxa.de'; in the second case, I get the incorrect result 'xn--dr-fkawald.de'. To properly encode IDNA incrementally, you need to process an entire label at a time (i.e. between two dots, ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1453235&group_id=5470 From noreply at sourceforge.net Sun Mar 19 11:20:32 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 19 Mar 2006 02:20:32 -0800 Subject: [Patches] [ python-Patches-1449471 ] Splitting CJK codecs from pythoncore dll Message-ID: Patches item #1449471, was opened at 2006-03-14 19:18 Message generated for change (Comment added) made by perky You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1449471&group_id=5470 Please note that this 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: Accepted Priority: 5 Submitted By: Hye-Shik Chang (perky) Assigned to: Hye-Shik Chang (perky) Summary: Splitting CJK codecs from pythoncore dll Initial Comment: As many of western language natives have requested it, this patch splits CJK codecs from pythoncore dll. python25.dll shrinks from 2024KB to 1364KB by this. Even some of CJK users would take some advantages for domestic py2exe-ed releases. ---------------------------------------------------------------------- >Comment By: Hye-Shik Chang (perky) Date: 2006-03-19 19:20 Message: Logged In: YES user_id=55188 Yes. I agree about the arbitrariness where to modules go. I thought that some dll size was concerned looking "unicodedata" module case; which is only 396KB. It would be clearer if we use same scheme for Windows distribution as specified in Modules/Setup.dist. (what drawbacks are expected then?) Thank you for the review! ---------------------------------------------------------------------- Comment By: Martin v. L??wis (loewis) Date: 2006-03-19 19:00 Message: Logged In: YES user_id=21627 I must say that I find this splitting arbitrary. Why are these modules moved out of pythonxy.dll, when, say, multibytecodec, mmap, parser, xxsubtype, sha512 stay. I really wish there was some policy guiding this. That said, as the author of the code, it is certainly your decision to make that split that way. So please go ahead and apply that patch. Please also add the new modules to Tool/msi/msi.py. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1449471&group_id=5470 From noreply at sourceforge.net Sun Mar 19 11:24:58 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 19 Mar 2006 02:24:58 -0800 Subject: [Patches] [ python-Patches-1448484 ] declspec for ssize_t Message-ID: Patches item #1448484, was opened at 2006-03-12 22:41 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1448484&group_id=5470 Please note that this 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: None Priority: 5 Submitted By: Zooko O'Whielacronx (zooko) Assigned to: Nobody/Anonymous (nobody) Summary: declspec for ssize_t Initial Comment: If you apply this patch (against today's SVN trunk) then the new ssize_t funcs will be exported when building a DLL with cygwin gcc 3.4.4. Then you'll hit another problem, about which more in the next patch. ---------------------------------------------------------------------- >Comment By: Martin v. L??wis (loewis) Date: 2006-03-19 11:24 Message: Logged In: YES user_id=21627 Can you please explain what the problem is? PyArg_Parse is declared dllexport already in Include/modsupport.h, so declaring it dllexport in getargs.c should not be necessary. Also, please don't declare _PyArg_Parse_SizeT dllexport in the implementation file; instead, add a prototype in the header file and declare that as dllexport. IOW, there shouldn't be any changes to getargs.c. ---------------------------------------------------------------------- Comment By: Zooko O'Whielacronx (zooko) Date: 2006-03-13 15:21 Message: Logged In: YES user_id=52562 I think the initial summary wasn't clear. With this patch, the new ssize_t feature that was recently merged into trunk compiles on Cygwin. Without this patch, it doesn't. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1448484&group_id=5470 From noreply at sourceforge.net Sun Mar 19 11:52:59 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 19 Mar 2006 02:52:59 -0800 Subject: [Patches] [ python-Patches-1453235 ] IDNA codec simplification Message-ID: Patches item #1453235, was opened at 2006-03-18 16:52 Message generated for change (Comment added) made by doerwalter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1453235&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Library (Lib) Group: None Status: Open Resolution: None Priority: 5 Submitted By: Walter D?rwald (doerwalter) Assigned to: Martin v. L??wis (loewis) Summary: IDNA codec simplification Initial Comment: This patch simplifies the idna codec. It moves the encode and decode functionality out of the Codec class, so that it can be reused by the stateless and the incremental codecs. (See patch #1436130 for the history of this patch). ---------------------------------------------------------------------- >Comment By: Walter D?rwald (doerwalter) Date: 2006-03-19 11:52 Message: Logged In: YES user_id=89016 You're right, this patch doesn't change the codecs behaviour at all (the StreamWriter has to same problem: import sys, codecs w = codecs.getwriter("idna")(sys.stdout) w.write(u"d??r") w.write(u"wald.de") ) I'll try to come up with a patch that implements a real incremental encoder and decoder. ---------------------------------------------------------------------- Comment By: Martin v. L??wis (loewis) Date: 2006-03-19 11:13 Message: Logged In: YES user_id=21627 This patch is wrong (AFAICT). If I understand the incremental API correctly, it should be possible to pass chunks of the input to the incremental encoder; concatenating the results should give the same string as if I had passed the entire input at once. This doesn't work for this patch: py> u"d??rwald.de".encode("idna") 'xn--drwald-wxa.de' py> c = codecs.getincrementalencoder("idna")() py> c.encode(u"d??r") 'xn--dr-fka' py> c.encode(u"wald.de") 'wald.de' So in the first case, I get the (correct) result 'xn--drwald-wxa.de'; in the second case, I get the incorrect result 'xn--dr-fkawald.de'. To properly encode IDNA incrementally, you need to process an entire label at a time (i.e. between two dots, ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1453235&group_id=5470 From noreply at sourceforge.net Sun Mar 19 12:56:47 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 19 Mar 2006 03:56:47 -0800 Subject: [Patches] [ python-Patches-1449471 ] Splitting CJK codecs from pythoncore dll Message-ID: Patches item #1449471, was opened at 2006-03-14 11:18 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1449471&group_id=5470 Please note that this 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: Accepted Priority: 5 Submitted By: Hye-Shik Chang (perky) Assigned to: Hye-Shik Chang (perky) Summary: Splitting CJK codecs from pythoncore dll Initial Comment: As many of western language natives have requested it, this patch splits CJK codecs from pythoncore dll. python25.dll shrinks from 2024KB to 1364KB by this. Even some of CJK users would take some advantages for domestic py2exe-ed releases. ---------------------------------------------------------------------- >Comment By: Martin v. L??wis (loewis) Date: 2006-03-19 12:56 Message: Logged In: YES user_id=21627 The main issue is maintainability. Everytime a module is added, a project file needs to be created, which is more tedious than adding a few lines to setup.py (although one also has to remember editing Modules/Setup.dist); in addition, Tools/msi/msi.py needs to be edited. Everytime a "global" change is made to the compilation options of Python (e.g. adding AMD64 configurations), it needs to be applied to all project files individually. ---------------------------------------------------------------------- Comment By: Hye-Shik Chang (perky) Date: 2006-03-19 11:20 Message: Logged In: YES user_id=55188 Yes. I agree about the arbitrariness where to modules go. I thought that some dll size was concerned looking "unicodedata" module case; which is only 396KB. It would be clearer if we use same scheme for Windows distribution as specified in Modules/Setup.dist. (what drawbacks are expected then?) Thank you for the review! ---------------------------------------------------------------------- Comment By: Martin v. L??wis (loewis) Date: 2006-03-19 11:00 Message: Logged In: YES user_id=21627 I must say that I find this splitting arbitrary. Why are these modules moved out of pythonxy.dll, when, say, multibytecodec, mmap, parser, xxsubtype, sha512 stay. I really wish there was some policy guiding this. That said, as the author of the code, it is certainly your decision to make that split that way. So please go ahead and apply that patch. Please also add the new modules to Tool/msi/msi.py. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1449471&group_id=5470 From noreply at sourceforge.net Sun Mar 19 14:22:15 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 19 Mar 2006 05:22:15 -0800 Subject: [Patches] [ python-Patches-1449471 ] Splitting CJK codecs from pythoncore dll Message-ID: Patches item #1449471, was opened at 2006-03-14 19:18 Message generated for change (Comment added) made by perky You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1449471&group_id=5470 Please note that this 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: Accepted Priority: 5 Submitted By: Hye-Shik Chang (perky) Assigned to: Hye-Shik Chang (perky) Summary: Splitting CJK codecs from pythoncore dll Initial Comment: As many of western language natives have requested it, this patch splits CJK codecs from pythoncore dll. python25.dll shrinks from 2024KB to 1364KB by this. Even some of CJK users would take some advantages for domestic py2exe-ed releases. ---------------------------------------------------------------------- >Comment By: Hye-Shik Chang (perky) Date: 2006-03-19 22:22 Message: Logged In: YES user_id=55188 Aah. Then, how about to use a way how the PuTTY project does? They maintain a relatively simple perl script to generate various types of build files including MSVC6 dsw, MSVC7.1 sln, Dev-Cpp project, MinGW Makefile, MS nmake Makefile and Borland C++ project file at a time. If we make a simliar thing, keeping PC/VC6 up-to-date would become a bit easy. I'll try it in my spare time before the first alpha of 2.5. ---------------------------------------------------------------------- Comment By: Martin v. L??wis (loewis) Date: 2006-03-19 20:56 Message: Logged In: YES user_id=21627 The main issue is maintainability. Everytime a module is added, a project file needs to be created, which is more tedious than adding a few lines to setup.py (although one also has to remember editing Modules/Setup.dist); in addition, Tools/msi/msi.py needs to be edited. Everytime a "global" change is made to the compilation options of Python (e.g. adding AMD64 configurations), it needs to be applied to all project files individually. ---------------------------------------------------------------------- Comment By: Hye-Shik Chang (perky) Date: 2006-03-19 19:20 Message: Logged In: YES user_id=55188 Yes. I agree about the arbitrariness where to modules go. I thought that some dll size was concerned looking "unicodedata" module case; which is only 396KB. It would be clearer if we use same scheme for Windows distribution as specified in Modules/Setup.dist. (what drawbacks are expected then?) Thank you for the review! ---------------------------------------------------------------------- Comment By: Martin v. L??wis (loewis) Date: 2006-03-19 19:00 Message: Logged In: YES user_id=21627 I must say that I find this splitting arbitrary. Why are these modules moved out of pythonxy.dll, when, say, multibytecodec, mmap, parser, xxsubtype, sha512 stay. I really wish there was some policy guiding this. That said, as the author of the code, it is certainly your decision to make that split that way. So please go ahead and apply that patch. Please also add the new modules to Tool/msi/msi.py. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1449471&group_id=5470 From noreply at sourceforge.net Mon Mar 20 05:08:30 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 19 Mar 2006 20:08:30 -0800 Subject: [Patches] [ python-Patches-1445431 ] more leaky, leaky Message-ID: Patches item #1445431, was opened at 2006-03-07 23:43 Message generated for change (Comment added) made by nnorwitz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1445431&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Modules Group: None >Status: Closed >Resolution: Accepted Priority: 5 Submitted By: Neal Norwitz (nnorwitz) Assigned to: Thomas Wouters (twouters) Summary: more leaky, leaky Initial Comment: Thomas, when I saw your changes in bsddb.c I grepped for some more occurrences of similar constructs (PyErr_SetObject(PyExc_XXX, Py_BuildValue(...))) I only found these 4. I'm too tired to check this in and ensure they are correct. Feel free to check in if it all looks correct. Or assign back to me and i'll do it later. Thanks. ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2006-03-19 20:08 Message: Logged In: YES user_id=33168 Committed revision 43151. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1445431&group_id=5470 From noreply at sourceforge.net Mon Mar 20 05:11:05 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 19 Mar 2006 20:11:05 -0800 Subject: [Patches] [ python-Patches-1416559 ] Configure patch for Mac OS X 10.3 Message-ID: Patches item #1416559, was opened at 2006-01-27 07:50 Message generated for change (Comment added) made by nnorwitz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1416559&group_id=5470 Please note that this 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: Accepted Priority: 5 Submitted By: Ronald Oussoren (ronaldoussoren) Assigned to: Nobody/Anonymous (nobody) Summary: Configure patch for Mac OS X 10.3 Initial Comment: This patch makes sure that _POSIX_SOURCE and friends won't get defined when you build on Panther. Defining those have no effect on Panther, but will make it impossible to build extensions on a Tiger system when Python itself was build on Panther. ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2006-03-19 20:11 Message: Logged In: YES user_id=33168 Ronald, this looks fine, go ahead and checkin. ---------------------------------------------------------------------- Comment By: Ronald Oussoren (ronaldoussoren) Date: 2006-02-21 01:23 Message: Logged In: YES user_id=580910 I don't suppose this helps, but yes this patch is save. I use this in production and haven't found an extension yet that wouldn't work when this patch is applied. I've also looked at the platform header files to determine if the patch is save. We (Bob Ippolitto and myself) are using a simular patch in our ongoing work to create an universal build of python. ---------------------------------------------------------------------- Comment By: Georg Brandl (birkenfeld) Date: 2006-02-19 07:54 Message: Logged In: YES user_id=1188172 Can any OS X expert confirm that not defining _XOPEN_SOURCE and _POSIX_C_SOURCE hasn't a negative effect on OSX 10.3? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1416559&group_id=5470 From noreply at sourceforge.net Mon Mar 20 05:13:08 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 19 Mar 2006 20:13:08 -0800 Subject: [Patches] [ python-Patches-1380777 ] Some fixes for the binary distribution builder Message-ID: Patches item #1380777, was opened at 2005-12-14 12:25 Message generated for change (Comment added) made by nnorwitz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1380777&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Macintosh Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Ronald Oussoren (ronaldoussoren) Assigned to: Jack Jansen (jackjansen) Summary: Some fixes for the binary distribution builder Initial Comment: The attached patch fixes some problems with the build script for binary distributions on Mac OS X 1) the builder used to unconditionally replace parts of Apple's python installation. This is needed on OSX 10.3, but not on later versions. 2) corrects version numbers in several places, and verifies the correct version in the build script 3) the builddocs script usually crashes on my system after correctly building the documentation, workaround this in the build script 4) Some hacks w.r.t. a pyconfig.h file that works on 10.3 and 10.4 (see below) There is a problem with pyconfig.h in a binary distribution on OSX: there are some header file regressions between 10.3 and 10.4. This means that you cannot build extensions with a python that was build on 10.3 while running on 10.4 (unless you're lucky). My first workaround was a pyconfig.h that #include-d pyconfig-10.3.h or pyconfig-10.4.h after testing the current platform (by misusing some feature macros in AvailabilityMacros.h). This doesn't work because distutils reads pyconfig.h and makes that available to setup.py authors. A second, untested approach is to merge the two pyconfig.h files. I guess it would be good enough to just surpress the #defines for _POSIX_SOURCE, _XOPEN_SOURCE and _XOPEN_SOURCE_EXTENDED on Tiger. ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2006-03-19 20:13 Message: Logged In: YES user_id=33168 Ronald, this patch looks out of date due to your patch #1416559. If that's true, please close this patch. ---------------------------------------------------------------------- Comment By: Ronald Oussoren (ronaldoussoren) Date: 2005-12-14 12:55 Message: Logged In: YES user_id=580910 I'm currently testing the obvious (in hindsight) solution for my pyconfig.h problems: $ diff -u Python-2.4.2-orig/configure.in Python-2.4.2/configure.in --- Python-2.4.2-orig/configure.in Sun Aug 7 23:08:53 2005 +++ Python-2.4.2/configure.in Wed Dec 14 21:41:32 2005 @@ -173,7 +173,7 @@ ;; # On Mac OS X 10.4, defining _POSIX_C_SOURCE or _XOPEN_SOURCE # disables platform specific features beyond repair. - Darwin/8.*) + Darwin/8.*|Darwin/7.*) define_xopen_source=no ;; That is, tell configure not to bother trying _POSIX_SOURCE on Darwin 7.x (aka Panther). So far this doesn't seem to cause regressions, but I haven't run the tests yet nor did I perform a full comparison between this build and a build without the patch above. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1380777&group_id=5470 From noreply at sourceforge.net Mon Mar 20 06:28:13 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 19 Mar 2006 21:28:13 -0800 Subject: [Patches] [ python-Patches-1231053 ] audioop - alaw encoding/decoding added, code updated Message-ID: Patches item #1231053, was opened at 2005-07-02 02:04 Message generated for change (Comment added) made by anthonybaxter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1231053&group_id=5470 Please note that this 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: Lars Immisch (larsimmisch) Assigned to: Anthony Baxter (anthonybaxter) Summary: audioop - alaw encoding/decoding added, code updated Initial Comment: This patch adds a-LAW encoding to audioop and replaces[1] the old u-LAW encoding/decoding code with the current code from sox. If audioop has an ulaw codec, it should also have an alaw codec. Besides, shtoom wants/needs it. Tests and documentation are updated with this patch too. The patch is a unified diff against CVS that can be applied in one piece frrom the root of the python tree. Beyond the cursory tests in the unittests, I have done successful tests with real-life data. Possible issues: the code from sox uses int16_t. [1] Rationale for the replacement of existing code: the alaw code would have been different in style from the ulaw code and attribution of the code would have been less clear. ---------------------------------------------------------------------- >Comment By: Anthony Baxter (anthonybaxter) Date: 2006-03-20 16:28 Message: Logged In: YES user_id=29957 Patch has been applied to the trunk. Thanks for the patch, and sorry about the delay in applying it. ---------------------------------------------------------------------- Comment By: Georg Brandl (gbrandl) Date: 2006-03-18 08:07 Message: Logged In: YES user_id=849994 Patch looks good and has docs and tests. ---------------------------------------------------------------------- Comment By: Florian Schmidt (fastflo) Date: 2006-01-28 12:25 Message: Logged In: YES user_id=182876 me and the company i'm working for are very interested in this patch. as a german telecomunication service provider we have to deal with alaw all the time... (headerless data) the patch works for us, would be great if it would come into one of the next release's... ---------------------------------------------------------------------- Comment By: Anthony Baxter (anthonybaxter) Date: 2005-08-13 07:52 Message: Logged In: YES user_id=29957 I'll look at this shortly. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1231053&group_id=5470 From noreply at sourceforge.net Mon Mar 20 07:31:46 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 19 Mar 2006 22:31:46 -0800 Subject: [Patches] [ python-Patches-1309579 ] A wait4() implementation Message-ID: Patches item #1309579, was opened at 2005-09-30 08:32 Message generated for change (Comment added) made by nnorwitz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1309579&group_id=5470 Please note that this 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: chads (cjschr) Assigned to: Neal Norwitz (nnorwitz) Summary: A wait4() implementation Initial Comment: Implementation of a BSD-style wait4() function, which is similar to waitpid, but it also returns resource usage information about the child process. wait4(pid, options) -> (pid, status, rusage) Chad ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2006-03-19 22:31 Message: Logged In: YES user_id=33168 Thanks for the patch! Finally applied (with mods). Committed revision 43158. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2006-03-18 14:18 Message: Logged In: YES user_id=33168 I think I recall spotting the docs after your comment. I plan to get this in before alpha1. ---------------------------------------------------------------------- Comment By: chads (cjschr) Date: 2006-01-19 05:47 Message: Logged In: YES user_id=1093928 Neil Check the diff. Doc updates are already there. Thanks. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2006-01-18 22:58 Message: Logged In: YES user_id=33168 I looked over the patch. It looks pretty good. Can your provide doc too? If you can't do latex, just text will do and I'll convert. Doc/lib/libos.tex ---------------------------------------------------------------------- Comment By: chads (cjschr) Date: 2006-01-17 14:52 Message: Logged In: YES user_id=1093928 Took a different approach with implementation. Also includes wait3 implementation. LMK how it looks. Thanks. Chad ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2005-10-02 14:56 Message: Logged In: YES user_id=33168 Comments from author received in mail: It is a duplicate of my original post, but it was diff'ed against the latest CVS tree. The usage example is for those who haven't had experience with wait4 before, hence the name. It's an FYI, nothing more. I'll also update the documentation accordingly. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2005-09-30 20:16 Message: Logged In: YES user_id=33168 Chad, I'm starting to look at this now, but it seems to be a duplicate of your original patch # 1000267. Can this be closed as a duplicate? I don't know if the attachments are the same. It would be easier to have all the changes in a single file. Since you are adding a new file, you will need to use -N option to cvs diff. Something like this: cvs diff -Nu ... (you can list the specific files that changed if necessary). >From what I looked at so far, there were a couple of things I didn't like. Though it looks like you addressed many (perhaps all) of the previous comments. I don't like the code in resourcemodule.h. I would prefer a public API in resourcemodule that posixmodule can call. If you think that no other modules outside python should call this, you can prefix the name with _, ie _PyResourceModule_...(). There are some un-prefixed names in resourcemodule.h. I think these may all go away if you move the code into the .c file. I would prefer to not have resourcemodule_h_author & resourcemodule_h_rcsid. The comment with your name and email is fine. I didn't look at the test or usage example. What should be done with the usage example? In the doc, could you remove the ", ?" for availability. We can leave it as Unix for now. If we find out definitive info about other platforms (Windows, Mac), we can add that later. Please add a \versionadded{2.5} at the end of the new doc (before the end). That's all my comments. This looks close to being ready. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1309579&group_id=5470 From noreply at sourceforge.net Mon Mar 20 08:39:41 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 19 Mar 2006 23:39:41 -0800 Subject: [Patches] [ python-Patches-1446922 ] Patch for bug 1441486: bad unary minus folding in compiler Message-ID: Patches item #1446922, was opened at 2006-03-09 18:33 Message generated for change (Comment added) made by nnorwitz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1446922&group_id=5470 Please note that this 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: Grant Olson (logistix) Assigned to: Neal Norwitz (nnorwitz) Summary: Patch for bug 1441486: bad unary minus folding in compiler Initial Comment: In the old compiler, there was a optimization in com_factor that folded a unary minus against a constant. In the new AST, it looks like numbers are converted from strings into PyObjects earlier in the pipeline. The compiler does fold a unary minus against a constant, but since the PyObject has already been created, it may return a PyLong when a PyInt is sufficient. This patch adds a check that will convert a PyLong object back into a PyInt if possible. ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2006-03-19 23:39 Message: Logged In: YES user_id=33168 Thanks! Unfortunately, this patch leaves the long in co_consts: >>> def foo(): ... x = -9223372036854775808 ... >>> foo.func_code.co_consts (None, 9223372036854775808L, -9223372036854775808) This is a 64-bit system. On 2.4, there is only sys.minint: Python 2.4.2 (#1, Oct 30 2005, 21:35:48) >>> def foo(): ... x = -9223372036854775808 ... >>> foo.func_code.co_consts (None, -9223372036854775808) Can you revise the patch to fix this? I cleaned up some things. Attached is an updated version I was using. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1446922&group_id=5470 From noreply at sourceforge.net Mon Mar 20 09:18:34 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 20 Mar 2006 00:18:34 -0800 Subject: [Patches] [ python-Patches-1380777 ] Some fixes for the binary distribution builder Message-ID: Patches item #1380777, was opened at 2005-12-14 21:25 Message generated for change (Comment added) made by ronaldoussoren You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1380777&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Macintosh Group: Python 2.4 >Status: Closed >Resolution: Out of Date Priority: 5 Submitted By: Ronald Oussoren (ronaldoussoren) Assigned to: Jack Jansen (jackjansen) Summary: Some fixes for the binary distribution builder Initial Comment: The attached patch fixes some problems with the build script for binary distributions on Mac OS X 1) the builder used to unconditionally replace parts of Apple's python installation. This is needed on OSX 10.3, but not on later versions. 2) corrects version numbers in several places, and verifies the correct version in the build script 3) the builddocs script usually crashes on my system after correctly building the documentation, workaround this in the build script 4) Some hacks w.r.t. a pyconfig.h file that works on 10.3 and 10.4 (see below) There is a problem with pyconfig.h in a binary distribution on OSX: there are some header file regressions between 10.3 and 10.4. This means that you cannot build extensions with a python that was build on 10.3 while running on 10.4 (unless you're lucky). My first workaround was a pyconfig.h that #include-d pyconfig-10.3.h or pyconfig-10.4.h after testing the current platform (by misusing some feature macros in AvailabilityMacros.h). This doesn't work because distutils reads pyconfig.h and makes that available to setup.py authors. A second, untested approach is to merge the two pyconfig.h files. I guess it would be good enough to just surpress the #defines for _POSIX_SOURCE, _XOPEN_SOURCE and _XOPEN_SOURCE_EXTENDED on Tiger. ---------------------------------------------------------------------- >Comment By: Ronald Oussoren (ronaldoussoren) Date: 2006-03-20 09:18 Message: Logged In: YES user_id=580910 This patch is still valid, but applying it would be a waste of time: I want to replace the entire build script by something better. I have a better script as part of the python24-fat tree, I'm going to make some time to merge that tree. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2006-03-20 05:13 Message: Logged In: YES user_id=33168 Ronald, this patch looks out of date due to your patch #1416559. If that's true, please close this patch. ---------------------------------------------------------------------- Comment By: Ronald Oussoren (ronaldoussoren) Date: 2005-12-14 21:55 Message: Logged In: YES user_id=580910 I'm currently testing the obvious (in hindsight) solution for my pyconfig.h problems: $ diff -u Python-2.4.2-orig/configure.in Python-2.4.2/configure.in --- Python-2.4.2-orig/configure.in Sun Aug 7 23:08:53 2005 +++ Python-2.4.2/configure.in Wed Dec 14 21:41:32 2005 @@ -173,7 +173,7 @@ ;; # On Mac OS X 10.4, defining _POSIX_C_SOURCE or _XOPEN_SOURCE # disables platform specific features beyond repair. - Darwin/8.*) + Darwin/8.*|Darwin/7.*) define_xopen_source=no ;; That is, tell configure not to bother trying _POSIX_SOURCE on Darwin 7.x (aka Panther). So far this doesn't seem to cause regressions, but I haven't run the tests yet nor did I perform a full comparison between this build and a build without the patch above. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1380777&group_id=5470 From noreply at sourceforge.net Mon Mar 20 10:25:14 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 20 Mar 2006 01:25:14 -0800 Subject: [Patches] [ python-Patches-1447410 ] logging: findCaller() sometimes raises AttributeError Message-ID: Patches item #1447410, was opened at 2006-03-10 18:12 Message generated for change (Comment added) made by vsajip You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1447410&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Library (Lib) Group: Python 2.4 Status: Closed Resolution: Fixed Priority: 5 Submitted By: Kevin J Bluck (kbluck) Assigned to: Vinay Sajip (vsajip) Summary: logging: findCaller() sometimes raises AttributeError Initial Comment: I am invoking the logging.log() function via the C API, using PyObject_CallFunction(). I have found that sometimes (not always) the findCaller() function raises this AttributeError: AttributeError: 'NoneType' object has no attribute 'f_code' File "C:\Program Files\Python\Lib\logging\__init__.py", line 1052, in findCaller co = f.f_code File "C:\Program Files\Python\Lib\logging\__init__.py", line 1078, in _log fn, lno, func = self.findCaller() File "C:\Program Files\Python\Lib\logging\__init__.py", line 1043, in log apply(self._log, (level, msg, args), kwargs) File "C:\Program Files\Python\Lib\logging\__init__.py", line 1319, in log apply(root It appears that sometimes, currentframe() is returning None. Attached is a patch for logging/__init__.py which guards against this possibility. Patch is generated against recent SVN head revision 42958. ---------------------------------------------------------------------- >Comment By: Vinay Sajip (vsajip) Date: 2006-03-20 09:25 Message: Logged In: YES user_id=308438 Neal, Thanks for the reminder. I've updated the release24-maint branch, too. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2006-03-16 07:08 Message: Logged In: YES user_id=33168 Vinay, should this be backported? ---------------------------------------------------------------------- Comment By: Vinay Sajip (vsajip) Date: 2006-03-15 12:46 Message: Logged In: YES user_id=308438 A version of this patch is in SVN revision 43048. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1447410&group_id=5470 From noreply at sourceforge.net Mon Mar 20 12:11:39 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 20 Mar 2006 03:11:39 -0800 Subject: [Patches] [ python-Patches-1454425 ] popen2 new parameter and setpgid Message-ID: Patches item #1454425, was opened at 2006-03-20 11:11 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1454425&group_id=5470 Please note that this 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: Oskar Ander? (oskar_andero) Assigned to: Nobody/Anonymous (nobody) Summary: popen2 new parameter and setpgid Initial Comment: This patch adds a new parameter to the popen2 library functions: a dictionary called options. This provides a way to add options to the calls and avoiding compatibility issues as in missing parameters etc. I have implemented an option called "pgid" which sets the process group ID of the spawned process. I really would like to move bufsize and mode to this dictionary too, but this would give backward compatibility problems. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1454425&group_id=5470 From noreply at sourceforge.net Mon Mar 20 12:24:48 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 20 Mar 2006 03:24:48 -0800 Subject: [Patches] [ python-Patches-1449471 ] Splitting CJK codecs from pythoncore dll Message-ID: Patches item #1449471, was opened at 2006-03-14 11:18 Message generated for change (Comment added) made by kxroberto You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1449471&group_id=5470 Please note that this 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: Accepted Priority: 5 Submitted By: Hye-Shik Chang (perky) Assigned to: Hye-Shik Chang (perky) Summary: Splitting CJK codecs from pythoncore dll Initial Comment: As many of western language natives have requested it, this patch splits CJK codecs from pythoncore dll. python25.dll shrinks from 2024KB to 1364KB by this. Even some of CJK users would take some advantages for domestic py2exe-ed releases. ---------------------------------------------------------------------- Comment By: kxroberto (kxroberto) Date: 2006-03-20 12:24 Message: Logged In: YES user_id=972995 good decision. otherwise, once we learn the codecs of Marsians, they would have probably gone into the core as well :-) ---------------------------------------------------------------------- Comment By: Hye-Shik Chang (perky) Date: 2006-03-19 14:22 Message: Logged In: YES user_id=55188 Aah. Then, how about to use a way how the PuTTY project does? They maintain a relatively simple perl script to generate various types of build files including MSVC6 dsw, MSVC7.1 sln, Dev-Cpp project, MinGW Makefile, MS nmake Makefile and Borland C++ project file at a time. If we make a simliar thing, keeping PC/VC6 up-to-date would become a bit easy. I'll try it in my spare time before the first alpha of 2.5. ---------------------------------------------------------------------- Comment By: Martin v. L??wis (loewis) Date: 2006-03-19 12:56 Message: Logged In: YES user_id=21627 The main issue is maintainability. Everytime a module is added, a project file needs to be created, which is more tedious than adding a few lines to setup.py (although one also has to remember editing Modules/Setup.dist); in addition, Tools/msi/msi.py needs to be edited. Everytime a "global" change is made to the compilation options of Python (e.g. adding AMD64 configurations), it needs to be applied to all project files individually. ---------------------------------------------------------------------- Comment By: Hye-Shik Chang (perky) Date: 2006-03-19 11:20 Message: Logged In: YES user_id=55188 Yes. I agree about the arbitrariness where to modules go. I thought that some dll size was concerned looking "unicodedata" module case; which is only 396KB. It would be clearer if we use same scheme for Windows distribution as specified in Modules/Setup.dist. (what drawbacks are expected then?) Thank you for the review! ---------------------------------------------------------------------- Comment By: Martin v. L??wis (loewis) Date: 2006-03-19 11:00 Message: Logged In: YES user_id=21627 I must say that I find this splitting arbitrary. Why are these modules moved out of pythonxy.dll, when, say, multibytecodec, mmap, parser, xxsubtype, sha512 stay. I really wish there was some policy guiding this. That said, as the author of the code, it is certainly your decision to make that split that way. So please go ahead and apply that patch. Please also add the new modules to Tool/msi/msi.py. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1449471&group_id=5470 From noreply at sourceforge.net Mon Mar 20 12:46:29 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 20 Mar 2006 03:46:29 -0800 Subject: [Patches] [ python-Patches-1454452 ] 2 Tools for easy inter-thread communication->Queue, threading Message-ID: Patches item #1454452, was opened at 2006-03-20 12:46 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1454452&group_id=5470 Please note that this 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: kxroberto (kxroberto) Assigned to: Nobody/Anonymous (nobody) Summary: 2 Tools for easy inter-thread communication->Queue,threading Initial Comment: Using bare Queue.Queue in an inter-process manner by passing data is often tedious low-level style and overkill and leads to non-cohesive style of coding. Also threading up to now doesn't support a simply framework for non-blocking call execution _with_ result/end - a frequent need in GUI programming and easy load balancing for jerky resources. The attachment contains 2 tools for that: CallQueue and BackgroundCall. I think they fit well into the standard Python (2.5) lib. The attachment is in the form of a standalone Python module and can be tested directly, the 2 things can be easily copied to the target modules Queue / threading. Robert PS: fast atomic list.append / list.pop(0) / obj.var=.. assumed ; commented out use of Queue.Queue ; threading/Queue should maybe last of all do paranoid locking after all other stuff in the lib does so, in case Python would really go towards CPU level memory/time atoms, what in my opinion would destroy a VHL language. In case, I missed something, Queue should be uncommented. of the bare list. (The tests in all my apps raised no problems - I used that like tools since years, just reshaped them a little for this posting) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1454452&group_id=5470 From noreply at sourceforge.net Mon Mar 20 13:37:36 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 20 Mar 2006 04:37:36 -0800 Subject: [Patches] [ python-Patches-1454481 ] Make thread stack size runtime tunable Message-ID: Patches item #1454481, was opened at 2006-03-20 23: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=1454481&group_id=5470 Please note that this 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: Andrew I MacIntyre (aimacintyre) Assigned to: Nobody/Anonymous (nobody) Summary: Make thread stack size runtime tunable Initial Comment: Platform default thread stack sizes vary considerably. Some are very generous (Win32: usually 1MB; Linux: 1MB, sometimes 8MB). Others are not (FreeBSD: 64k). Some platforms have restricted virtual address space OS/2: 512M less overhead) which makes hard coding a generous default thread stack size problematic. Some platforms thread commit stack address space, even though the memory backing it may not be committed (Windows, OS/2 at least). Some applications have a thirst for stack space in threads (Zope). Some programmers want to be able to use lots of threads, even in the face of sound advice about the lack of wisdom in this approach. The current approach to stack space management in threads in Python uses a hard coded strategy, relying on the platform having a useful default or relying on the system administrator or distribution builder over-riding the default at compile time. This patch is intended to allow developers some control over managing this resource from within Python code by way of a function in the thread module. As written, it is not intended to provide unlimited flexibility; that would probably require exposing the underlying mechanism as an option on the creation of each thread. An alternative approach to providing the functionality would be to use an environment variable to provide the information to the thread module. This has its pros and cons, in terms of flexibility and ease of use, and could be complementary to the approach implemented. The patch has been tested on OS/2 and FreeBSD 4.8. I have no means of testing the code on Win32 or Linux, though Linux is a pthread environment as is FreeBSD. Code base is SVN head from a few hours ago. A doc update is included. While I would like to see this functionality in Python 2.5, it is not a critical issue. Critique of the approach and implementation welcome. Something not addressed is the issue of tests, primarily because I haven't been able to think of a viable testing strategy - I'm all ears to suggestions for this. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1454481&group_id=5470 From noreply at sourceforge.net Mon Mar 20 13:44:33 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 20 Mar 2006 04:44:33 -0800 Subject: [Patches] [ python-Patches-1454485 ] patch for SIGSEGV in arraymodule.c Message-ID: Patches item #1454485, was opened at 2006-03-20 14: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=1454485&group_id=5470 Please note that this 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: Baris Metin (tbmetin) Assigned to: Nobody/Anonymous (nobody) Summary: patch for SIGSEGV in arraymodule.c Initial Comment: Array module fails handling utf-8 strings giving a SIGSEGV. Attached patch seems to do the trick... gdb> run (no debugging symbols found) (no debugging symbols found) [Thread debugging using libthread_db enabled] [New Thread -1480337216 (LWP 31303)] Python 2.4.2 (#1, Mar 20 2006, 12:08:06) [GCC 3.4.5] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> import array >>> x = array.array("u") >>> x.append(u"bar????") Traceback (most recent call last): File "", line 1, in ? TypeError: array item must be unicode character >>> x.append("bar????") >>> x Program received signal SIGSEGV, Segmentation fault. [Switching to Thread -1480337216 (LWP 31303)] Error while running hook_stop: Invalid type combination in ordering comparison. 0xa7ee0799 in PyUnicodeUCS4_FromUnicode () from /usr/lib/libpython2.4.so.1.0 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1454485&group_id=5470 From noreply at sourceforge.net Mon Mar 20 13:45:42 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 20 Mar 2006 04:45:42 -0800 Subject: [Patches] [ python-Patches-1454425 ] popen2 new parameter and setpgid Message-ID: Patches item #1454425, was opened at 2006-03-20 22:11 Message generated for change (Comment added) made by aimacintyre You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1454425&group_id=5470 Please note that this 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: Oskar Ander? (oskar_andero) Assigned to: Nobody/Anonymous (nobody) Summary: popen2 new parameter and setpgid Initial Comment: This patch adds a new parameter to the popen2 library functions: a dictionary called options. This provides a way to add options to the calls and avoiding compatibility issues as in missing parameters etc. I have implemented an option called "pgid" which sets the process group ID of the spawned process. I really would like to move bufsize and mode to this dictionary too, but this would give backward compatibility problems. ---------------------------------------------------------------------- >Comment By: Andrew I MacIntyre (aimacintyre) Date: 2006-03-20 23:45 Message: Logged In: YES user_id=250749 Doesn't the subprocess module provide these facilities? I just wonder about the value of changing the signatures of the popen*() family at this point when subprocess effectively supercedes popen*(). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1454425&group_id=5470 From noreply at sourceforge.net Mon Mar 20 14:58:13 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 20 Mar 2006 05:58:13 -0800 Subject: [Patches] [ python-Patches-1454425 ] popen2 new parameter and setpgid Message-ID: Patches item #1454425, was opened at 2006-03-20 11:11 Message generated for change (Comment added) made by oskar_andero You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1454425&group_id=5470 Please note that this 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: None Priority: 5 Submitted By: Oskar Ander? (oskar_andero) Assigned to: Nobody/Anonymous (nobody) Summary: popen2 new parameter and setpgid Initial Comment: This patch adds a new parameter to the popen2 library functions: a dictionary called options. This provides a way to add options to the calls and avoiding compatibility issues as in missing parameters etc. I have implemented an option called "pgid" which sets the process group ID of the spawned process. I really would like to move bufsize and mode to this dictionary too, but this would give backward compatibility problems. ---------------------------------------------------------------------- >Comment By: Oskar Ander? (oskar_andero) Date: 2006-03-20 13:58 Message: Logged In: YES user_id=1355975 aimacintyre: True. Sorry for my bad research. Case closed! ---------------------------------------------------------------------- Comment By: Andrew I MacIntyre (aimacintyre) Date: 2006-03-20 12:45 Message: Logged In: YES user_id=250749 Doesn't the subprocess module provide these facilities? I just wonder about the value of changing the signatures of the popen*() family at this point when subprocess effectively supercedes popen*(). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1454425&group_id=5470 From noreply at sourceforge.net Mon Mar 20 14:58:31 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 20 Mar 2006 05:58:31 -0800 Subject: [Patches] [ python-Patches-1454481 ] Make thread stack size runtime tunable Message-ID: Patches item #1454481, was opened at 2006-03-20 21:37 Message generated for change (Comment added) made by perky You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1454481&group_id=5470 Please note that this 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: Andrew I MacIntyre (aimacintyre) Assigned to: Nobody/Anonymous (nobody) Summary: Make thread stack size runtime tunable Initial Comment: Platform default thread stack sizes vary considerably. Some are very generous (Win32: usually 1MB; Linux: 1MB, sometimes 8MB). Others are not (FreeBSD: 64k). Some platforms have restricted virtual address space OS/2: 512M less overhead) which makes hard coding a generous default thread stack size problematic. Some platforms thread commit stack address space, even though the memory backing it may not be committed (Windows, OS/2 at least). Some applications have a thirst for stack space in threads (Zope). Some programmers want to be able to use lots of threads, even in the face of sound advice about the lack of wisdom in this approach. The current approach to stack space management in threads in Python uses a hard coded strategy, relying on the platform having a useful default or relying on the system administrator or distribution builder over-riding the default at compile time. This patch is intended to allow developers some control over managing this resource from within Python code by way of a function in the thread module. As written, it is not intended to provide unlimited flexibility; that would probably require exposing the underlying mechanism as an option on the creation of each thread. An alternative approach to providing the functionality would be to use an environment variable to provide the information to the thread module. This has its pros and cons, in terms of flexibility and ease of use, and could be complementary to the approach implemented. The patch has been tested on OS/2 and FreeBSD 4.8. I have no means of testing the code on Win32 or Linux, though Linux is a pthread environment as is FreeBSD. Code base is SVN head from a few hours ago. A doc update is included. While I would like to see this functionality in Python 2.5, it is not a critical issue. Critique of the approach and implementation welcome. Something not addressed is the issue of tests, primarily because I haven't been able to think of a viable testing strategy - I'm all ears to suggestions for this. ---------------------------------------------------------------------- >Comment By: Hye-Shik Chang (perky) Date: 2006-03-20 22:58 Message: Logged In: YES user_id=55188 I'm all for this! The FreeBSD port have maintained a local patch to bump THREAD_STACK_SIZE. The patch will lighten FreeBSD users' burden around thread stack size. BTW, the naming, "thread.stack_size" seems to miss a verb while all the other functions on the thread module have it. How about set_stack_size() or set_stacksize()? Or, how about in sys module? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1454481&group_id=5470 From noreply at sourceforge.net Mon Mar 20 20:41:13 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 20 Mar 2006 11:41:13 -0800 Subject: [Patches] [ python-Patches-1454844 ] Use dlopen() to load extensions on Darwin, where possible Message-ID: Patches item #1454844, was opened at 2006-03-20 19:41 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1454844&group_id=5470 Please note that this 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: Zach Pincus (zpincus) Assigned to: Nobody/Anonymous (nobody) Summary: Use dlopen() to load extensions on Darwin, where possible Initial Comment: Here is a patch to make Python on OS X 10.3 and above use dlopen() (via dynload_shlib.c) to load extension modules, and to make the dl module avaliable. The patch was generated against the SVN head as of yesterday, but can be applied (and I have done so with success) to Python 2.4.2. RATIONALE --------- On most unix-like operating systems, Python uses the dlopen() call to load extension modules. In addition, the way that these modules are opened can be modified via 'sys.setdlopenflags(...)'. Modifications of how extensions are loaded are useful for several reasons (enough so that the standard Python docs (e.g. http:// docs.python.org/lib/module-sys.html ). In particular, if multiple modules need to share symbols, a call to sys.setdlopenflags is necessary. Symbol sharing is especially important for interoperability of modules which wrap C++ classes, because GCC creates classes that resolve their run-time type identification by symbol identity. Thus, symbols must be shared globally for many C++ features to work properly for objects passed between modules. On OS X / Darwin, Python uses some NeXT-derived APIs to load modules. Though these APIs provide analogues to the dlopenflags used to control how dlopen() loads modules, this interface is *not* exposed to the Python interpreter. Worse, sys.setdlopenflags remains available on Darwin, though calls to it are never heeded. Fortunately, on OS X 10.3 and above, Apple has included dlopen as a standard function. In 10.3, this call is provided by a compatibility API; in 10.4, the dlopen() call is written to interface directly with the library loading mechanism and is now the recommended method for libraries to be opened for non Carbon/Cocoa tools. IMPLEMENTATION -------------- This (trivial) patch instructs the Python build process to use dynload_shlib.c (which uses dlopen) instead of dynload_next.c (which uses the NeXT-derived APIs). It also allows for the dl module to be built in order to provide access to the proper values for the various dlopen flags. TESTING ------- This patch can be configured and built into executables that build and test correctly on 10.3 and 10.4. Because Python 2.5 and 2.4 do not currently compile properly on OS X 10.2, I have not built or tested this patch on that OS version. However, the configure and compile process does select the appropriate dynload_next.c file to use, and compiles that correctly before breaking elsewhere. Thus, if the other errors are fixed for 10.2, these patches will work fine. (This is because they only change Python's behavior for 10.3 and up.) PATCHES ------- There are three main components to the attached patch. The first is a patch the 'configure.in' file to use dynload_shlib.c when it can, and a patch to the 'configure' file to sync it up with 'configure.in'. The second is a minor change to 'setup.py' and the dl module test to allow the dl module to be built and tested on OS X systems where dlfcn is available. (10.3 and above.) The last part of the patchfile should be considered optional. This patch applies to 'Lib/test/regrtest.py', and it tells the testing suite that the dl test is not expected to be skipped anymore. This is optional because if Python is ever built on 10.2, the test script will expect dl to work, when it only works on 10.3 and above. However, if Python on 10.2 is officially not supported, then this change should be made to properly test the dl functionality on all supported OS X platforms. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1454844&group_id=5470 From noreply at sourceforge.net Mon Mar 20 21:53:57 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 20 Mar 2006 12:53:57 -0800 Subject: [Patches] [ python-Patches-1449471 ] Splitting CJK codecs from pythoncore dll Message-ID: Patches item #1449471, was opened at 2006-03-14 11:18 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1449471&group_id=5470 Please note that this 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: Accepted Priority: 5 Submitted By: Hye-Shik Chang (perky) Assigned to: Hye-Shik Chang (perky) Summary: Splitting CJK codecs from pythoncore dll Initial Comment: As many of western language natives have requested it, this patch splits CJK codecs from pythoncore dll. python25.dll shrinks from 2024KB to 1364KB by this. Even some of CJK users would take some advantages for domestic py2exe-ed releases. ---------------------------------------------------------------------- >Comment By: Martin v. L??wis (loewis) Date: 2006-03-20 21:53 Message: Logged In: YES user_id=21627 I personally think the codec from the Marsians is more important to be part of the core than _hotshot module. ---------------------------------------------------------------------- Comment By: kxroberto (kxroberto) Date: 2006-03-20 12:24 Message: Logged In: YES user_id=972995 good decision. otherwise, once we learn the codecs of Marsians, they would have probably gone into the core as well :-) ---------------------------------------------------------------------- Comment By: Hye-Shik Chang (perky) Date: 2006-03-19 14:22 Message: Logged In: YES user_id=55188 Aah. Then, how about to use a way how the PuTTY project does? They maintain a relatively simple perl script to generate various types of build files including MSVC6 dsw, MSVC7.1 sln, Dev-Cpp project, MinGW Makefile, MS nmake Makefile and Borland C++ project file at a time. If we make a simliar thing, keeping PC/VC6 up-to-date would become a bit easy. I'll try it in my spare time before the first alpha of 2.5. ---------------------------------------------------------------------- Comment By: Martin v. L??wis (loewis) Date: 2006-03-19 12:56 Message: Logged In: YES user_id=21627 The main issue is maintainability. Everytime a module is added, a project file needs to be created, which is more tedious than adding a few lines to setup.py (although one also has to remember editing Modules/Setup.dist); in addition, Tools/msi/msi.py needs to be edited. Everytime a "global" change is made to the compilation options of Python (e.g. adding AMD64 configurations), it needs to be applied to all project files individually. ---------------------------------------------------------------------- Comment By: Hye-Shik Chang (perky) Date: 2006-03-19 11:20 Message: Logged In: YES user_id=55188 Yes. I agree about the arbitrariness where to modules go. I thought that some dll size was concerned looking "unicodedata" module case; which is only 396KB. It would be clearer if we use same scheme for Windows distribution as specified in Modules/Setup.dist. (what drawbacks are expected then?) Thank you for the review! ---------------------------------------------------------------------- Comment By: Martin v. L??wis (loewis) Date: 2006-03-19 11:00 Message: Logged In: YES user_id=21627 I must say that I find this splitting arbitrary. Why are these modules moved out of pythonxy.dll, when, say, multibytecodec, mmap, parser, xxsubtype, sha512 stay. I really wish there was some policy guiding this. That said, as the author of the code, it is certainly your decision to make that split that way. So please go ahead and apply that patch. Please also add the new modules to Tool/msi/msi.py. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1449471&group_id=5470 From noreply at sourceforge.net Mon Mar 20 22:25:16 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 20 Mar 2006 13:25:16 -0800 Subject: [Patches] [ python-Patches-709744 ] CALL_ATTR opcode Message-ID: Patches item #709744, was opened at 2003-03-26 00:16 Message generated for change (Comment added) made by twouters You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=709744&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Core (C code) Group: Python 2.3 >Status: Closed >Resolution: Rejected Priority: 5 Submitted By: Thomas Wouters (twouters) Assigned to: Nobody/Anonymous (nobody) Summary: CALL_ATTR opcode Initial Comment: The result of the PyCore sprint of me and Brett: the CALL_ATTR opcode (LOAD_ATTR and CALL_FUNCTION combined) that skips the PyMethod creation and destruction for classic classes (but not newstyle classes, yet.) The code is somewhat rough yet, it needs commenting, some renaming, and most importantly testing. It seems to work, however, and provides between a 35% and 5% speedup. (5% in 'average' code, up to 35% in instance method calls and instance creation alone.) It also needs to be updated to include newstyle classes. I will likely work on this on the flight home. ---------------------------------------------------------------------- >Comment By: Thomas Wouters (twouters) Date: 2006-03-20 22:25 Message: Logged In: YES user_id=34209 Closing this ancient patch, I don't think it applies anymore ;) ---------------------------------------------------------------------- Comment By: Armin Rigo (arigo) Date: 2005-02-27 19:58 Message: Logged In: YES user_id=4771 By the way, I didn't see discussed anywhere the fact that the present optimization introduces a semantic change: in 'x.name(expr)' it evaluates 'expr' before calling 'x.__getattribute__("name")'. If we don't care, fine. If we do, it seems to me the whole approach is doomed... ---------------------------------------------------------------------- Comment By: Thomas Wouters (twouters) Date: 2003-05-02 14:53 Message: Logged In: YES user_id=34209 Well, I just re-used the call-profiling stuff that Jeremy (I think) already put in, but I don't see much use for getting people to run it. It shows the expected number of CALL_ATTR uses in e.g. pystone, no unexpected overheads inside modules or anything. The problem with the code isn't mispredicted branches, but general slowdown if *none* of the branches are taken. The only result I can think of of having people run with call-profiling on would be to find out we need to special-case other common tp_getattro functions -- which would result in more code and thus likely more general slowdown. However, patch with CALL_PROFILEing atatched. The call profile code changed somewhat, as this code returns a dict of counters, instead of a tuple. I found a 21-element tuple somewhat unwieldy :) I use a code snippet like: print "Call stats:" items = sys.callstats().items() items = [(value, key) for key, value in items] items.sort() items.reverse() for value,key in items: print "%30s: %30s"%(key, value) at the end of testing code (pystone, regrtest, etc.) Don't forget to #define CALL_PROFILE somewhere. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2003-04-23 20:11 Message: Logged In: YES user_id=6380 A suggestion: put some static global counters in the new code that count how many times each of the significant branches are taken, and a little routine that prints out the counts on exit. Then people can run various benchmarks and report the numbers, and that may help you decide which paths are worth more work... ---------------------------------------------------------------------- Comment By: Thomas Wouters (twouters) Date: 2003-04-23 13:43 Message: Logged In: YES user_id=34209 I'd not be proud in any case; neither the concept nor most of the implementation was my idea :-) But my questions still stand; the 3% slowdown in pystone is a lot if all you see is a 1.5% gain in Zope3 startup time, but I can't think of any ways to fix that before next friday, or before 2.3 is released. (The problem is either code size or switch length, which can be 'fixed' by culling code, re-ordering the switch again or changing the switch into a computed-goto.) And I'd need to find me a machine with less cache to actually notice the slowdown :-) ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2003-04-22 14:38 Message: Logged In: YES user_id=6380 However, you should be proud of yourself nevertheless. On the same Zope3 startup "benchmark", Raymond Hettinger's bytecode optimizations scored 0% improvement. Python -O didn't make any difference either. So it's a touch benchmark! (And yes, I did remove the .pyc/.pyo files each time.) (And no, I can't test -OO because Zope uses the docstrings.) ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2003-04-22 14:20 Message: Logged In: YES user_id=6380 OK, I did a more realistic benchmark: startup time of Zope3. With more or less current CVS Python 2.3 (but not Raymond H's bytecode optimizations), it took 3.52 seconds. With your patch (and all .pyc files rebuilt) it took 3.47 seconds. That's about a percent and a half. (With Python 2.2 it took 4.08 seconds.) ---------------------------------------------------------------------- Comment By: Thomas Wouters (twouters) Date: 2003-04-22 00:48 Message: Logged In: YES user_id=34209 Pystone is not likely to show much speedup, as it contains exactly 2 instances of CALL_ATTR, only barely in the main loop. However, it should not slow down because of CALL_ATTR either; the two CALL_ATTRs are of the most optimized sort, old-style instance methods, and none of the other code paths have changed *at all* (in the fast-and-ugly mode of the patch, which is the default.) There are only two reasons I can think of that explain a slower pystone: code cache and the switch statement layout. This apparently does not influence my (somewhat high-end-ish) test machines, but does yours (and others.) Both are more or less outside my control. They might be fixed by switch reordering or rearranging of the code so the compiler optimizes it better, but that's very platform specific and lacking a proper test-bed for that situation, I can't do it. Alternatively, there may be some funk with regards to bytecode version. If bytecode wasn't properly regenerated, I can imagine not seeing *any* speedup. Have you tried something as simple as ./python timeit.py -s 'class X:' -s ' def spam(self): pass' -s 'x = X()' 'x.spam()' ? This gives a good 30% speedup on my home PC. Bytecode problems wouldn't influence pystone though. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2003-04-19 20:42 Message: Logged In: YES user_id=6380 Alas, like others, I see a tiny slowdown on pystone (maybe 3 percent). This is with the default version of patch version 4 (fixed). ---------------------------------------------------------------------- Comment By: Thomas Wouters (twouters) Date: 2003-04-19 00:48 Message: Logged In: YES user_id=34209 Oops, that patch contained a C++-ism, ceval.c:3504 and 3505 needed to be swapped. Uploaded a new version. ---------------------------------------------------------------------- Comment By: Thomas Wouters (twouters) Date: 2003-04-19 00:22 Message: Logged In: YES user_id=34209 Alright, here is a re-worked patch, with a toggle to choose between a blatant copy-paste and some refactoring; see below. The patch works by creating a new opcode, CALL_ATTR, which is used for all <expression>.<name>(<args>) occurances. What <expression> and <args> are, is not important, they are compiled separately. The CALL_ATTR opcode implementation is optimized for two special cases: one where <expression> resulted in an (old-style) instance, and one where <expression> resulted in an instance of a new-style type of which the tp_getattro is PyObject_GenericGetAttr. The PyInstance part is done by savagely short-cutting the usual getattr dance for instances; if it sees anything but a PyFunction, it will fall back to a slow path. The rationale is that if X in 'X.spam(' is an old-style class, and that expression is not going to raise an exception, it is very rare for 'spam' to be anything but a PyFunction. Trying to cope with all the idiosyncracies of would slow down the common case too much. The PyObject_GenericGetAttr version uses a slightly modified version of PyObject_GenericGetAttr that, when finding a descr of the desired name, doesn't call the 'descr_get' method but returns a status flag. The caller (call_attr) then decides based on the type of the descr whether to call descr_get or not. It currently only specialcases PyFunctions. PyCFunctions, PyStaticMethods and PyClassMethods are tricky to specialcase and/or need some of the massaging that descr_get would do. I have not yet looked at other callable descr's. I had initially rewritten PyObject_GenericGetAttr() to use the modified version, but this appears to be a significant performance hit in normal attribute retrieval (quite common, on newstyle classes.) Likewise, Brett and I had refactored the call_function part of call_attr and call_function into a separate function, but that, too, was a big hit in the common function-calling case. Unfortunately, not doing that refactoring means a lot of copied code, so I included both in the patch. It may be that the slow path can be optimized by simplyfying the refactored parts so that the compiler understands how to inline them (e.g. the stackpointer fudging call_function/call_callable does.) The default is the ugly-but-fast way, define CALL_ATTR_SLOW_BUT_PRETTY_PATH to use the slow(er) path. The slow(er) path is enough slower to nullify the benefit of the patch in most of the benchmarks I ran; the fast path is only slightly slower in some areas (probably due to cache dynamics) but faster in every other situations, including unexpected areas (that's not cache dynamics, of course, that's just coder brilliance. :-) However, finding a good benchmark is near impossible. I added some newstyle-classes tests to PyBench, but even normal tests were giving bizarrely negative results. Checking those results with small scripts of timeit.py showed entirely different results. And when pybench reported a total 2% slowdown in the 'slow path' new code, it managed to report that about 5% faster, consistently. timeit.py is more consistent, and helped me determine the 'slow path' was really slowing things down. Calling an empty method with no arguments is about 20% faster for newstyle classes and about 30% for oldstyle classes, according to timeit.py. Still no test for call_attr though. I would love for people to test the code, both paths, and give me input. I also welcome ideas on handling more descr's, I may have missed a few unwritten rules about them. ---------------------------------------------------------------------- Comment By: Thomas Wouters (twouters) Date: 2003-04-18 02:42 Message: Logged In: YES user_id=34209 Well, currently, the neutered getattr functions just bail out and return NULL whenever they don't get what they expect. I guess they go back to being 'full' getattr's, with the exception that they 'return' two values: the retrieved object, and a status indicator (to indicate found-method and found-thing-but-not-method) Maybe the real getattr functions should be implemented in terms of the neutered version then, that would at least solve some maintenance issues :-) But time enough for that tomorrow or this weekend (if the weather doesn't keep being so terribly sunny and warm.) ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2003-04-18 02:29 Message: Logged In: YES user_id=6380 I would think that you should avoid the double lookups somehow... How difficult is that? ---------------------------------------------------------------------- Comment By: Thomas Wouters (twouters) Date: 2003-04-18 01:41 Message: Logged In: YES user_id=34209 Revised patch that includes avoiding the wrapping of (Python) methods on newstyle classes as well as oldstyle classes. The patch checks to see if a particular type uses PyObject_GenericGetAttr, and if so, uses a near-copy of that function to get an unwrapped PyFunction object. PyCFunctionObject objects are not magically treated, and fall back to the slow path... PyCFunction's descr's don't have direct access to an 'unwrapped' version, they create PyCFunctionObjectss on demand based on a PyCFunction -- a function pointer. Some simple testing (using timeit.py) suggests about a 20% increase in speed for 'x.foo()' where 'x' is a newstyle class instance. However, a real-world-ish benchmark (very hard to find, for newstyle classes) suggests otherwise: running 'timeit.py' on "pass" consistently takes about 3% longer. I'm certain the problem lies in the fact that the patch doesn't consider PyCFunctions, which forces part of the slow MRO lookup and instnace-dict checking to be re-done for C-functions on newstyle types (of which there are a heck of a lot.) Either handling PyMethodDescrs the same way as PyFunctionObjects, or circumventing the slow path in some way (by returning non-method-but-found objects) will probably fix that. ---------------------------------------------------------------------- Comment By: Thomas Wouters (twouters) Date: 2003-03-26 00:18 Message: Logged In: YES user_id=34209 attaching patch. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=709744&group_id=5470 From noreply at sourceforge.net Mon Mar 20 22:25:40 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 20 Mar 2006 13:25:40 -0800 Subject: [Patches] [ python-Patches-1453235 ] IDNA codec simplification Message-ID: Patches item #1453235, was opened at 2006-03-18 16:52 Message generated for change (Settings changed) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1453235&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Library (Lib) Group: None Status: Open Resolution: None Priority: 5 Submitted By: Walter D?rwald (doerwalter) >Assigned to: Walter D?rwald (doerwalter) Summary: IDNA codec simplification Initial Comment: This patch simplifies the idna codec. It moves the encode and decode functionality out of the Codec class, so that it can be reused by the stateless and the incremental codecs. (See patch #1436130 for the history of this patch). ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2006-03-19 11:52 Message: Logged In: YES user_id=89016 You're right, this patch doesn't change the codecs behaviour at all (the StreamWriter has to same problem: import sys, codecs w = codecs.getwriter("idna")(sys.stdout) w.write(u"d??r") w.write(u"wald.de") ) I'll try to come up with a patch that implements a real incremental encoder and decoder. ---------------------------------------------------------------------- Comment By: Martin v. L??wis (loewis) Date: 2006-03-19 11:13 Message: Logged In: YES user_id=21627 This patch is wrong (AFAICT). If I understand the incremental API correctly, it should be possible to pass chunks of the input to the incremental encoder; concatenating the results should give the same string as if I had passed the entire input at once. This doesn't work for this patch: py> u"d??rwald.de".encode("idna") 'xn--drwald-wxa.de' py> c = codecs.getincrementalencoder("idna")() py> c.encode(u"d??r") 'xn--dr-fka' py> c.encode(u"wald.de") 'wald.de' So in the first case, I get the (correct) result 'xn--drwald-wxa.de'; in the second case, I get the incorrect result 'xn--dr-fkawald.de'. To properly encode IDNA incrementally, you need to process an entire label at a time (i.e. between two dots, ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1453235&group_id=5470 From noreply at sourceforge.net Mon Mar 20 22:34:15 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 20 Mar 2006 13:34:15 -0800 Subject: [Patches] [ python-Patches-1444398 ] Make itertools.tee participate in GC Message-ID: Patches item #1444398, was opened at 2006-03-06 21:33 Message generated for change (Comment added) made by twouters You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1444398&group_id=5470 Please note that this 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: Thomas Wouters (twouters) Assigned to: Thomas Wouters (twouters) Summary: Make itertools.tee participate in GC Initial Comment: A small patch to make itertools.tee objects participate in GC; solves the memoryleak in test_generators (and any other use of tee objects in cycles.) ---------------------------------------------------------------------- >Comment By: Thomas Wouters (twouters) Date: 2006-03-20 22:34 Message: Logged In: YES user_id=34209 Hmm. An alternative fix would be to make itertools.tee only partially participate in GC. That is, not have it traverse over all the stored items, but just the iterator. It would prevent the (potentially rather heavy) cost of going over all cached items, but still leaves a potential for unfindable cycles. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2006-03-19 09:02 Message: Logged In: YES user_id=80475 Okay, go ahead and add GC to itertools.tee(). The test_generators examples make it clear that there are valid use cases for feeding a teeobject back into itself. Tim, the original rationale did not have to do with millions of tee objects; rather, it posited that a tee could contain many objects of some other type and that traversing it during GC was simply a waste of time. Thomas, the patch needs work, but I don't currently have time to go through it. Do your best to model after the other tools which have gc. That includes setting the tp_flags slot, doing an untrack before dealloc starts, replacing PyObject_Del and PyObject_New with their GC counterparts. See section 2.1.3 in Extending and Embedding for the details and examples. Offhand, I think it may also need a tp_clear entry but I'm not sure. If you can work out a good patch, go ahead an apply it for the alpha 1 release. If not, assign back to me and I'll get to it when I can (possibly for the second alpha). ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2006-03-07 01:52 Message: Logged In: YES user_id=31435 If there are likely to be millions of some type of object, then avoiding gc for that type on grounds of reducing memory use may be arguable (or, as in the cases of tuples or lists, may not be arguable regardless). Else "if it points to a PyObject, it might be in a cycle, so gc-enable it" generally rules. I'll note in passing that the m235 and fib generators weren't _intended_ to stress Python in any way, but have been extremely effective at doing so since generators first went in. Think of them as a pair of canaries in the coal mine :-) ---------------------------------------------------------------------- Comment By: Thomas Wouters (twouters) Date: 2006-03-07 01:12 Message: Logged In: YES user_id=34209 Well, I'm fine with removing the scope-enclosed generator versions of _m235() and fib() from test_generators, if that's what you're implying. :> However, I think it's slightly more suitable to just have tee participate in GC. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2006-03-07 01:05 Message: Logged In: YES user_id=80475 I will take a look at the patch soon. IIRC, there was a concious decision to not have tee engage in GC because no normal use cases created cycles (they seem to arise only when intentionally creating a cycle for test code). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1444398&group_id=5470 From noreply at sourceforge.net Wed Mar 22 03:31:28 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 21 Mar 2006 18:31:28 -0800 Subject: [Patches] [ python-Patches-1454844 ] Use dlopen() to load extensions on Darwin, where possible Message-ID: Patches item #1454844, was opened at 2006-03-20 11:41 Message generated for change (Comment added) made by barnert You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1454844&group_id=5470 Please note that this 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: Zach Pincus (zpincus) Assigned to: Nobody/Anonymous (nobody) Summary: Use dlopen() to load extensions on Darwin, where possible Initial Comment: Here is a patch to make Python on OS X 10.3 and above use dlopen() (via dynload_shlib.c) to load extension modules, and to make the dl module avaliable. The patch was generated against the SVN head as of yesterday, but can be applied (and I have done so with success) to Python 2.4.2. RATIONALE --------- On most unix-like operating systems, Python uses the dlopen() call to load extension modules. In addition, the way that these modules are opened can be modified via 'sys.setdlopenflags(...)'. Modifications of how extensions are loaded are useful for several reasons (enough so that the standard Python docs (e.g. http:// docs.python.org/lib/module-sys.html ). In particular, if multiple modules need to share symbols, a call to sys.setdlopenflags is necessary. Symbol sharing is especially important for interoperability of modules which wrap C++ classes, because GCC creates classes that resolve their run-time type identification by symbol identity. Thus, symbols must be shared globally for many C++ features to work properly for objects passed between modules. On OS X / Darwin, Python uses some NeXT-derived APIs to load modules. Though these APIs provide analogues to the dlopenflags used to control how dlopen() loads modules, this interface is *not* exposed to the Python interpreter. Worse, sys.setdlopenflags remains available on Darwin, though calls to it are never heeded. Fortunately, on OS X 10.3 and above, Apple has included dlopen as a standard function. In 10.3, this call is provided by a compatibility API; in 10.4, the dlopen() call is written to interface directly with the library loading mechanism and is now the recommended method for libraries to be opened for non Carbon/Cocoa tools. IMPLEMENTATION -------------- This (trivial) patch instructs the Python build process to use dynload_shlib.c (which uses dlopen) instead of dynload_next.c (which uses the NeXT-derived APIs). It also allows for the dl module to be built in order to provide access to the proper values for the various dlopen flags. TESTING ------- This patch can be configured and built into executables that build and test correctly on 10.3 and 10.4. Because Python 2.5 and 2.4 do not currently compile properly on OS X 10.2, I have not built or tested this patch on that OS version. However, the configure and compile process does select the appropriate dynload_next.c file to use, and compiles that correctly before breaking elsewhere. Thus, if the other errors are fixed for 10.2, these patches will work fine. (This is because they only change Python's behavior for 10.3 and up.) PATCHES ------- There are three main components to the attached patch. The first is a patch the 'configure.in' file to use dynload_shlib.c when it can, and a patch to the 'configure' file to sync it up with 'configure.in'. The second is a minor change to 'setup.py' and the dl module test to allow the dl module to be built and tested on OS X systems where dlfcn is available. (10.3 and above.) The last part of the patchfile should be considered optional. This patch applies to 'Lib/test/regrtest.py', and it tells the testing suite that the dl test is not expected to be skipped anymore. This is optional because if Python is ever built on 10.2, the test script will expect dl to work, when it only works on 10.3 and above. However, if Python on 10.2 is officially not supported, then this change should be made to properly test the dl functionality on all supported OS X platforms. ---------------------------------------------------------------------- Comment By: Andrew Barnert (barnert) Date: 2006-03-21 18:31 Message: Logged In: YES user_id=1473180 One minor issue: Your pattern will match Darwin 10.0, which will come out in a few years as part of OS X 10.7, by which time nobody will remember why this script is written this way. Since it's easy to handle now, we might as well do so. On a side note, there are no 2.x-4.x versions (1.5 was renamed 5.1), so anyone who matches Darwin/2.* will be a false match. Here's what I'd suggest: + Darwin/[0156]\..*) DYNLOADFILE="dynload_next.o";; Meanwhile, your patch seems to work for me on an Intel iMac, but I haven't tried anything too sophisticated. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1454844&group_id=5470 From noreply at sourceforge.net Wed Mar 22 08:31:47 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 21 Mar 2006 23:31:47 -0800 Subject: [Patches] [ python-Patches-1455898 ] patch for mbcs codecs Message-ID: Patches item #1455898, was opened at 2006-03-22 16: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=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.4 Status: Open Resolution: None Priority: 5 Submitted By: ocean-city (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. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1455898&group_id=5470 From noreply at sourceforge.net Wed Mar 22 08:42:45 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 21 Mar 2006 23:42:45 -0800 Subject: [Patches] [ python-Patches-1455898 ] patch for mbcs codecs Message-ID: Patches item #1455898, was opened at 2006-03-22 16:31 Message generated for change (Comment added) made by ocean-city 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.4 Status: Open Resolution: None Priority: 5 Submitted By: ocean-city (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: ocean-city (ocean-city) Date: 2006-03-22 16: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 Mar 22 08:48:46 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 21 Mar 2006 23:48:46 -0800 Subject: [Patches] [ python-Patches-1455898 ] patch for mbcs codecs Message-ID: Patches item #1455898, was opened at 2006-03-22 07:31 Message generated for change (Settings changed) made by gbrandl 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.4 Status: Open Resolution: None >Priority: 7 Submitted By: ocean-city (ocean-city) >Assigned to: Walter D?rwald (doerwalter) 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: ocean-city (ocean-city) Date: 2006-03-22 07: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 Mar 22 08:51:01 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 21 Mar 2006 23:51:01 -0800 Subject: [Patches] [ python-Patches-1454452 ] 2 Tools for easy inter-thread communication->Queue, threading Message-ID: Patches item #1454452, was opened at 2006-03-20 11:46 Message generated for change (Settings changed) made by gbrandl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1454452&group_id=5470 Please note that this 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: kxroberto (kxroberto) >Assigned to: Raymond Hettinger (rhettinger) Summary: 2 Tools for easy inter-thread communication->Queue,threading Initial Comment: Using bare Queue.Queue in an inter-process manner by passing data is often tedious low-level style and overkill and leads to non-cohesive style of coding. Also threading up to now doesn't support a simply framework for non-blocking call execution _with_ result/end - a frequent need in GUI programming and easy load balancing for jerky resources. The attachment contains 2 tools for that: CallQueue and BackgroundCall. I think they fit well into the standard Python (2.5) lib. The attachment is in the form of a standalone Python module and can be tested directly, the 2 things can be easily copied to the target modules Queue / threading. Robert PS: fast atomic list.append / list.pop(0) / obj.var=.. assumed ; commented out use of Queue.Queue ; threading/Queue should maybe last of all do paranoid locking after all other stuff in the lib does so, in case Python would really go towards CPU level memory/time atoms, what in my opinion would destroy a VHL language. In case, I missed something, Queue should be uncommented. of the bare list. (The tests in all my apps raised no problems - I used that like tools since years, just reshaped them a little for this posting) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1454452&group_id=5470 From noreply at sourceforge.net Wed Mar 22 09:28:25 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 22 Mar 2006 00:28:25 -0800 Subject: [Patches] [ python-Patches-1454481 ] Make thread stack size runtime tunable Message-ID: Patches item #1454481, was opened at 2006-03-20 23:37 Message generated for change (Comment added) made by aimacintyre You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1454481&group_id=5470 Please note that this 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: Andrew I MacIntyre (aimacintyre) Assigned to: Nobody/Anonymous (nobody) Summary: Make thread stack size runtime tunable Initial Comment: Platform default thread stack sizes vary considerably. Some are very generous (Win32: usually 1MB; Linux: 1MB, sometimes 8MB). Others are not (FreeBSD: 64k). Some platforms have restricted virtual address space OS/2: 512M less overhead) which makes hard coding a generous default thread stack size problematic. Some platforms thread commit stack address space, even though the memory backing it may not be committed (Windows, OS/2 at least). Some applications have a thirst for stack space in threads (Zope). Some programmers want to be able to use lots of threads, even in the face of sound advice about the lack of wisdom in this approach. The current approach to stack space management in threads in Python uses a hard coded strategy, relying on the platform having a useful default or relying on the system administrator or distribution builder over-riding the default at compile time. This patch is intended to allow developers some control over managing this resource from within Python code by way of a function in the thread module. As written, it is not intended to provide unlimited flexibility; that would probably require exposing the underlying mechanism as an option on the creation of each thread. An alternative approach to providing the functionality would be to use an environment variable to provide the information to the thread module. This has its pros and cons, in terms of flexibility and ease of use, and could be complementary to the approach implemented. The patch has been tested on OS/2 and FreeBSD 4.8. I have no means of testing the code on Win32 or Linux, though Linux is a pthread environment as is FreeBSD. Code base is SVN head from a few hours ago. A doc update is included. While I would like to see this functionality in Python 2.5, it is not a critical issue. Critique of the approach and implementation welcome. Something not addressed is the issue of tests, primarily because I haven't been able to think of a viable testing strategy - I'm all ears to suggestions for this. ---------------------------------------------------------------------- >Comment By: Andrew I MacIntyre (aimacintyre) Date: 2006-03-22 19:28 Message: Logged In: YES user_id=250749 Thanks for the comments. As implemented, the function is both a getter and (optionally) a setter which makes attempting to use a "get"/"set" prefix awkward. I chose this approach to make it a little simpler to support temporary changes. I did consider using a module attribute/variable, but it is slightly more unwieldy for this case: old_size = thread.stack_size(new_size) ... thread.stack_size(old_size) vs old_size = thread.stack_size thread.stack_size = new_size ... thread.stack_size = old_size or (using get/set accessors) old_size = thread.get_stacksize() thread.set_stacksize(new_size) ... thread.set_stacksize(old_size) I think an argument can be made for passing on the "get"/"set" naming consistency based on the guidelines in PEP 8. While I have a preference for what I've implemented, I'm more interested in getting the functionality in than debating its decor. If there's a strong view about these issues, I'm prepared to revise the patch accordingly. I don't believe that the functionality belongs anywhere else than the thread module, except possibly shadowing it in the threading module, as it is highly specific to thread support. The sys module seems more appropriate for general knobs, and only for specific knobs when there is no other choice IMO. Doing it outside the thread module also complicates the implementation, which I was trying to keep as simple as I could. ---------------------------------------------------------------------- Comment By: Hye-Shik Chang (perky) Date: 2006-03-21 00:58 Message: Logged In: YES user_id=55188 I'm all for this! The FreeBSD port have maintained a local patch to bump THREAD_STACK_SIZE. The patch will lighten FreeBSD users' burden around thread stack size. BTW, the naming, "thread.stack_size" seems to miss a verb while all the other functions on the thread module have it. How about set_stack_size() or set_stacksize()? Or, how about in sys module? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1454481&group_id=5470 From noreply at sourceforge.net Wed Mar 22 09:34:00 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 22 Mar 2006 00:34:00 -0800 Subject: [Patches] [ python-Patches-1454844 ] Use dlopen() to load extensions on Darwin, where possible Message-ID: Patches item #1454844, was opened at 2006-03-20 19:41 Message generated for change (Comment added) made by zpincus You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1454844&group_id=5470 Please note that this 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: Zach Pincus (zpincus) Assigned to: Nobody/Anonymous (nobody) Summary: Use dlopen() to load extensions on Darwin, where possible Initial Comment: Here is a patch to make Python on OS X 10.3 and above use dlopen() (via dynload_shlib.c) to load extension modules, and to make the dl module avaliable. The patch was generated against the SVN head as of yesterday, but can be applied (and I have done so with success) to Python 2.4.2. RATIONALE --------- On most unix-like operating systems, Python uses the dlopen() call to load extension modules. In addition, the way that these modules are opened can be modified via 'sys.setdlopenflags(...)'. Modifications of how extensions are loaded are useful for several reasons (enough so that the standard Python docs (e.g. http:// docs.python.org/lib/module-sys.html ). In particular, if multiple modules need to share symbols, a call to sys.setdlopenflags is necessary. Symbol sharing is especially important for interoperability of modules which wrap C++ classes, because GCC creates classes that resolve their run-time type identification by symbol identity. Thus, symbols must be shared globally for many C++ features to work properly for objects passed between modules. On OS X / Darwin, Python uses some NeXT-derived APIs to load modules. Though these APIs provide analogues to the dlopenflags used to control how dlopen() loads modules, this interface is *not* exposed to the Python interpreter. Worse, sys.setdlopenflags remains available on Darwin, though calls to it are never heeded. Fortunately, on OS X 10.3 and above, Apple has included dlopen as a standard function. In 10.3, this call is provided by a compatibility API; in 10.4, the dlopen() call is written to interface directly with the library loading mechanism and is now the recommended method for libraries to be opened for non Carbon/Cocoa tools. IMPLEMENTATION -------------- This (trivial) patch instructs the Python build process to use dynload_shlib.c (which uses dlopen) instead of dynload_next.c (which uses the NeXT-derived APIs). It also allows for the dl module to be built in order to provide access to the proper values for the various dlopen flags. TESTING ------- This patch can be configured and built into executables that build and test correctly on 10.3 and 10.4. Because Python 2.5 and 2.4 do not currently compile properly on OS X 10.2, I have not built or tested this patch on that OS version. However, the configure and compile process does select the appropriate dynload_next.c file to use, and compiles that correctly before breaking elsewhere. Thus, if the other errors are fixed for 10.2, these patches will work fine. (This is because they only change Python's behavior for 10.3 and up.) PATCHES ------- There are three main components to the attached patch. The first is a patch the 'configure.in' file to use dynload_shlib.c when it can, and a patch to the 'configure' file to sync it up with 'configure.in'. The second is a minor change to 'setup.py' and the dl module test to allow the dl module to be built and tested on OS X systems where dlfcn is available. (10.3 and above.) The last part of the patchfile should be considered optional. This patch applies to 'Lib/test/regrtest.py', and it tells the testing suite that the dl test is not expected to be skipped anymore. This is optional because if Python is ever built on 10.2, the test script will expect dl to work, when it only works on 10.3 and above. However, if Python on 10.2 is officially not supported, then this change should be made to properly test the dl functionality on all supported OS X platforms. ---------------------------------------------------------------------- >Comment By: Zach Pincus (zpincus) Date: 2006-03-22 08:34 Message: Logged In: YES user_id=748718 I just uploaded a new patch which addresses this issue, and fixes this same problem in a few other locations in the configure script. ---------------------------------------------------------------------- Comment By: Andrew Barnert (barnert) Date: 2006-03-22 02:31 Message: Logged In: YES user_id=1473180 One minor issue: Your pattern will match Darwin 10.0, which will come out in a few years as part of OS X 10.7, by which time nobody will remember why this script is written this way. Since it's easy to handle now, we might as well do so. On a side note, there are no 2.x-4.x versions (1.5 was renamed 5.1), so anyone who matches Darwin/2.* will be a false match. Here's what I'd suggest: + Darwin/[0156]\..*) DYNLOADFILE="dynload_next.o";; Meanwhile, your patch seems to work for me on an Intel iMac, but I haven't tried anything too sophisticated. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1454844&group_id=5470 From noreply at sourceforge.net Wed Mar 22 10:11:57 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 22 Mar 2006 01:11:57 -0800 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 lemburg 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.4 Status: Open Resolution: None Priority: 7 Submitted By: ocean-city (ocean-city) Assigned to: Walter D?rwald (doerwalter) 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: 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: ocean-city (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 Mar 22 10:12:42 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 22 Mar 2006 01:12:42 -0800 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 lemburg 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.4 Status: Open Resolution: None Priority: 7 Submitted By: ocean-city (ocean-city) Assigned to: Walter D?rwald (doerwalter) 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: 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: ocean-city (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 Mar 22 11:13:49 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 22 Mar 2006 02:13:49 -0800 Subject: [Patches] [ python-Patches-1455898 ] patch for mbcs codecs Message-ID: Patches item #1455898, was opened at 2006-03-22 16:31 Message generated for change (Comment added) made by ocean-city 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.4 Status: Open Resolution: None Priority: 7 Submitted By: ocean-city (ocean-city) Assigned to: Walter D?rwald (doerwalter) 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: ocean-city (ocean-city) Date: 2006-03-22 19: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 18: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 18: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: ocean-city (ocean-city) Date: 2006-03-22 16: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 Mar 22 11:31:19 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 22 Mar 2006 02:31:19 -0800 Subject: [Patches] [ python-Patches-1455898 ] patch for mbcs codecs Message-ID: Patches item #1455898, was opened at 2006-03-22 16:31 Message generated for change (Comment added) made by ocean-city 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.4 Status: Open Resolution: None Priority: 7 Submitted By: ocean-city (ocean-city) Assigned to: Walter D?rwald (doerwalter) 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: ocean-city (ocean-city) Date: 2006-03-22 19: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: ocean-city (ocean-city) Date: 2006-03-22 19: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 18: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 18: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: ocean-city (ocean-city) Date: 2006-03-22 16: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 Mar 22 11:43:24 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 22 Mar 2006 02:43:24 -0800 Subject: [Patches] [ python-Patches-1454452 ] 2 Tools for easy inter-thread communication->Queue, threading Message-ID: Patches item #1454452, was opened at 2006-03-20 12:46 Message generated for change (Comment added) made by kxroberto You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1454452&group_id=5470 Please note that this 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: kxroberto (kxroberto) Assigned to: Raymond Hettinger (rhettinger) Summary: 2 Tools for easy inter-thread communication->Queue,threading Initial Comment: Using bare Queue.Queue in an inter-process manner by passing data is often tedious low-level style and overkill and leads to non-cohesive style of coding. Also threading up to now doesn't support a simply framework for non-blocking call execution _with_ result/end - a frequent need in GUI programming and easy load balancing for jerky resources. The attachment contains 2 tools for that: CallQueue and BackgroundCall. I think they fit well into the standard Python (2.5) lib. The attachment is in the form of a standalone Python module and can be tested directly, the 2 things can be easily copied to the target modules Queue / threading. Robert PS: fast atomic list.append / list.pop(0) / obj.var=.. assumed ; commented out use of Queue.Queue ; threading/Queue should maybe last of all do paranoid locking after all other stuff in the lib does so, in case Python would really go towards CPU level memory/time atoms, what in my opinion would destroy a VHL language. In case, I missed something, Queue should be uncommented. of the bare list. (The tests in all my apps raised no problems - I used that like tools since years, just reshaped them a little for this posting) ---------------------------------------------------------------------- >Comment By: kxroberto (kxroberto) Date: 2006-03-22 11:43 Message: Logged In: YES user_id=972995 ->attachment (new version and diff): an update which addes options for exception handling (which I needed recently) and resolves one bug. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1454452&group_id=5470 From noreply at sourceforge.net Wed Mar 22 15:36:07 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 22 Mar 2006 06:36:07 -0800 Subject: [Patches] [ python-Patches-1455898 ] patch for mbcs codecs Message-ID: Patches item #1455898, was opened at 2006-03-22 16:31 Message generated for change (Comment added) made by ocean-city 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.4 Status: Open Resolution: None Priority: 7 Submitted By: ocean-city (ocean-city) Assigned to: Walter D?rwald (doerwalter) 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: ocean-city (ocean-city) Date: 2006-03-22 23: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: ocean-city (ocean-city) Date: 2006-03-22 19: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: ocean-city (ocean-city) Date: 2006-03-22 19: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 18: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 18: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: ocean-city (ocean-city) Date: 2006-03-22 16: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 Thu Mar 23 03:51:26 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 22 Mar 2006 18:51:26 -0800 Subject: [Patches] [ python-Patches-1455898 ] patch for mbcs codecs Message-ID: Patches item #1455898, was opened at 2006-03-22 16:31 Message generated for change (Comment added) made by ocean-city 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.4 Status: Open Resolution: None Priority: 7 Submitted By: ocean-city (ocean-city) Assigned to: Walter D?rwald (doerwalter) 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: ocean-city (ocean-city) Date: 2006-03-23 11: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: ocean-city (ocean-city) Date: 2006-03-22 23: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: ocean-city (ocean-city) Date: 2006-03-22 19: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: ocean-city (ocean-city) Date: 2006-03-22 19: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 18: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 18: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: ocean-city (ocean-city) Date: 2006-03-22 16: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 Thu Mar 23 13:36:48 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 23 Mar 2006 04:36:48 -0800 Subject: [Patches] [ python-Patches-1396919 ] FreeBSD is system scope threads capable Message-ID: Patches item #1396919, was opened at 2006-01-04 23:53 Message generated for change (Comment added) made by perky You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1396919&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Build Group: Python 2.4 >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Valts (valdiic) Assigned to: Hye-Shik Chang (perky) Summary: FreeBSD is system scope threads capable Initial Comment: I was a little bit disapointed when I mentioned that Python 2.4 uses libpthread library on FreeBSD 5 but avoids using system scope threads. I tried digging google to clarify why it is so and found out that it was because one of threading regression tests (test_threaded_import) failed on FreeBSD 5 (https:// sourceforge.net/tracker/? func=detail&atid=305470&aid=902444&group_id=5470). I compiled Python on my FreeBSD 5.4-RELEASE-p8 and ran all the regression tests (I executed regrtest.py) and saw no errors at all. I tried test_threaded_import and the test was successful. I don't see any reason why to avoid using system scope threads specially on FreeBSD. I know that using userland scope threads is quite faster because there is no need for kernel activities in context switching. But as far as I know most of servers (where speed is important) are SMP boxes. Userland scope threads don't use capabilities of multiple CPU's, so it should be reasonable to use system scope threads. To make it even better it could be good idea to make use of configuration parameter which determines which kind of threads has to be used. Since I'm not autoconf guru I made a patch which just removes checking against FreeBSD in thread_pthread.h Regards, Valts. mailto:valdiic at one.lv ---------------------------------------------------------------------- >Comment By: Hye-Shik Chang (perky) Date: 2006-03-23 21:36 Message: Logged In: YES user_id=55188 Fixed in r43249. Thank you for the report! ---------------------------------------------------------------------- Comment By: Martin v. L??wis (loewis) Date: 2006-01-15 03:27 Message: Logged In: YES user_id=21627 perky, you created the original patch. can you please review this one? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1396919&group_id=5470 From noreply at sourceforge.net Thu Mar 23 21:06:08 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 23 Mar 2006 12:06:08 -0800 Subject: [Patches] [ python-Patches-1457227 ] timestamp() method for datetime objects Message-ID: Patches item #1457227, was opened at 2006-03-23 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=1457227&group_id=5470 Please note that this 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: Chris AtLee (catlee) Assigned to: Nobody/Anonymous (nobody) Summary: timestamp() method for datetime objects Initial Comment: This patch adds a timestamp() method to datetime objects. It is equivalent to: time.mktime(self.timetuple()) I pulled out the dstflag calculation code from datetime_timetuple into a new function, get_dstflag, so that datetime_timestamp can make use of the same code. The patch also includes updates to the datetime documentation, and a simple unit test. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1457227&group_id=5470 From noreply at sourceforge.net Thu Mar 23 21:23:04 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 23 Mar 2006 12:23:04 -0800 Subject: [Patches] [ python-Patches-1457227 ] timestamp() method for datetime objects Message-ID: Patches item #1457227, was opened at 2006-03-23 15:06 Message generated for change (Comment added) made by gvanrossum You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1457227&group_id=5470 Please note that this 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: Chris AtLee (catlee) Assigned to: Nobody/Anonymous (nobody) Summary: timestamp() method for datetime objects Initial Comment: This patch adds a timestamp() method to datetime objects. It is equivalent to: time.mktime(self.timetuple()) I pulled out the dstflag calculation code from datetime_timetuple into a new function, get_dstflag, so that datetime_timestamp can make use of the same code. The patch also includes updates to the datetime documentation, and a simple unit test. ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2006-03-23 15:23 Message: Logged In: YES user_id=6380 I'm against this functionality. It suggests an linkage between the "naive" (timezone-unaware) time carried in the datetime object, and the UTC space that posix timestamps represent. The entire point of the datetime type (unless an explicit tzinfo is passed) is that it doesn't know which timezone it represents. When you call time.mktime(self.timetuple()), you as the application make the determination that the timetuple (which is still tz-unaware!) represents your current local time. That's a fine decision for the app to make. But I don't think users should be lured into believing there's an equivalency inherent in the datetime type -- there isn't. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1457227&group_id=5470 From noreply at sourceforge.net Thu Mar 23 22:37:35 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 23 Mar 2006 13:37:35 -0800 Subject: [Patches] [ python-Patches-1457227 ] timestamp() method for datetime objects Message-ID: Patches item #1457227, was opened at 2006-03-23 15:06 Message generated for change (Comment added) made by catlee You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1457227&group_id=5470 Please note that this 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: Chris AtLee (catlee) Assigned to: Nobody/Anonymous (nobody) Summary: timestamp() method for datetime objects Initial Comment: This patch adds a timestamp() method to datetime objects. It is equivalent to: time.mktime(self.timetuple()) I pulled out the dstflag calculation code from datetime_timetuple into a new function, get_dstflag, so that datetime_timestamp can make use of the same code. The patch also includes updates to the datetime documentation, and a simple unit test. ---------------------------------------------------------------------- >Comment By: Chris AtLee (catlee) Date: 2006-03-23 16:37 Message: Logged In: YES user_id=186532 The .fromtimestamp and .utcfromtimestamp class methods already imply this linkage, don't they? What if timestamp() only works if the datetime object isn't "naive"? ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2006-03-23 15:23 Message: Logged In: YES user_id=6380 I'm against this functionality. It suggests an linkage between the "naive" (timezone-unaware) time carried in the datetime object, and the UTC space that posix timestamps represent. The entire point of the datetime type (unless an explicit tzinfo is passed) is that it doesn't know which timezone it represents. When you call time.mktime(self.timetuple()), you as the application make the determination that the timetuple (which is still tz-unaware!) represents your current local time. That's a fine decision for the app to make. But I don't think users should be lured into believing there's an equivalency inherent in the datetime type -- there isn't. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1457227&group_id=5470 From noreply at sourceforge.net Thu Mar 23 22:40:11 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 23 Mar 2006 13:40:11 -0800 Subject: [Patches] [ python-Patches-1457316 ] Support different GPG keys in upload --sign Message-ID: Patches item #1457316, was opened at 2006-03-23 22:40 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1457316&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Distutils and setup.py Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: Stefan Behnel (scoder) Assigned to: Nobody/Anonymous (nobody) Summary: Support different GPG keys in upload --sign Initial Comment: This patch adds a new option "--identity" to the upload command that selects the GPG identity the package is signed with. Needed if the default key is not the key used for signing software. Usage example: setup.py sdist upload --sign --identity some at user.org ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1457316&group_id=5470 From noreply at sourceforge.net Thu Mar 23 22:41:52 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 23 Mar 2006 13:41:52 -0800 Subject: [Patches] [ python-Patches-1457227 ] timestamp() method for datetime objects Message-ID: Patches item #1457227, was opened at 2006-03-23 15:06 Message generated for change (Comment added) made by gvanrossum You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1457227&group_id=5470 Please note that this 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: Chris AtLee (catlee) Assigned to: Nobody/Anonymous (nobody) Summary: timestamp() method for datetime objects Initial Comment: This patch adds a timestamp() method to datetime objects. It is equivalent to: time.mktime(self.timetuple()) I pulled out the dstflag calculation code from datetime_timetuple into a new function, get_dstflag, so that datetime_timestamp can make use of the same code. The patch also includes updates to the datetime documentation, and a simple unit test. ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2006-03-23 16:41 Message: Logged In: YES user_id=6380 Well, that they both exist implies that the linkage is ambiguous... I think it's just not worth the new API given that it's (as you admit) just a shorthand for two other calls. There's also the problem that the range for timestamps is much smaller than the range of datetime -- this isn't a problem for .[utc]fromtimestamp() but is a problem for the reverse API. ---------------------------------------------------------------------- Comment By: Chris AtLee (catlee) Date: 2006-03-23 16:37 Message: Logged In: YES user_id=186532 The .fromtimestamp and .utcfromtimestamp class methods already imply this linkage, don't they? What if timestamp() only works if the datetime object isn't "naive"? ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2006-03-23 15:23 Message: Logged In: YES user_id=6380 I'm against this functionality. It suggests an linkage between the "naive" (timezone-unaware) time carried in the datetime object, and the UTC space that posix timestamps represent. The entire point of the datetime type (unless an explicit tzinfo is passed) is that it doesn't know which timezone it represents. When you call time.mktime(self.timetuple()), you as the application make the determination that the timetuple (which is still tz-unaware!) represents your current local time. That's a fine decision for the app to make. But I don't think users should be lured into believing there's an equivalency inherent in the datetime type -- there isn't. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1457227&group_id=5470 From noreply at sourceforge.net Thu Mar 23 22:44:48 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 23 Mar 2006 13:44:48 -0800 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 doerwalter 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.4 Status: Open Resolution: None Priority: 7 Submitted By: ocean-city (ocean-city) Assigned to: Walter D?rwald (doerwalter) 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: 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: ocean-city (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: ocean-city (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: ocean-city (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: ocean-city (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: ocean-city (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 Fri Mar 24 07:02:16 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 23 Mar 2006 22:02:16 -0800 Subject: [Patches] [ python-Patches-1435422 ] Add copy() method to zlib's compress and decompress objects Message-ID: Patches item #1435422, was opened at 2006-02-20 12:17 Message generated for change (Comment added) made by nnorwitz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1435422&group_id=5470 Please note that this 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: Chris AtLee (catlee) Assigned to: Nobody/Anonymous (nobody) Summary: Add copy() method to zlib's compress and decompress objects Initial Comment: The attached patch adds a copy() method to zlib's compressobj and decompressobj. Copying a (de)compression object allows a developer to store the state of the (de)compressor at a certain point of the input stream in order to more efficiently compress data sharing some identical header, or to more efficiently seek inside compressed data. Doc/lib/libzlib.tex is updated with descriptions for the new methods. Lib/test/test_zlib.py is updated to test the new functionality. The patch is against revision 42524 in http://svn.python.org/projects/python/trunk ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2006-03-23 22:02 Message: Logged In: YES user_id=33168 You need to check the return result of newcompobject(). This would crash if it returns NULL. You also need to change METH_VARARGS to METH_NOARGS since these methods don't take any arguments. The doc should contain \versionadded{2.5} before the end markers for new methods. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1435422&group_id=5470 From noreply at sourceforge.net Fri Mar 24 07:11:18 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 23 Mar 2006 22:11:18 -0800 Subject: [Patches] [ python-Patches-1454485 ] patch for SIGSEGV in arraymodule.c Message-ID: Patches item #1454485, was opened at 2006-03-20 04:44 Message generated for change (Comment added) made by nnorwitz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1454485&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Core (C code) Group: Python 2.4 >Status: Pending >Resolution: Works For Me Priority: 5 Submitted By: Baris Metin (tbmetin) >Assigned to: Neal Norwitz (nnorwitz) Summary: patch for SIGSEGV in arraymodule.c Initial Comment: Array module fails handling utf-8 strings giving a SIGSEGV. Attached patch seems to do the trick... gdb> run (no debugging symbols found) (no debugging symbols found) [Thread debugging using libthread_db enabled] [New Thread -1480337216 (LWP 31303)] Python 2.4.2 (#1, Mar 20 2006, 12:08:06) [GCC 3.4.5] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> import array >>> x = array.array("u") >>> x.append(u"bar????") Traceback (most recent call last): File "", line 1, in ? TypeError: array item must be unicode character >>> x.append("bar????") >>> x Program received signal SIGSEGV, Segmentation fault. [Switching to Thread -1480337216 (LWP 31303)] Error while running hook_stop: Invalid type combination in ordering comparison. 0xa7ee0799 in PyUnicodeUCS4_FromUnicode () from /usr/lib/libpython2.4.so.1.0 ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2006-03-23 22:11 Message: Logged In: YES user_id=33168 With the stock 2.4.2 on my linux box I was able to reproduce this. I couldn't reproduce with 2.4.3c1. Can you verify this is fixed in 2.4.3? Sagol. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1454485&group_id=5470 From noreply at sourceforge.net Fri Mar 24 10:19:34 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 24 Mar 2006 01:19:34 -0800 Subject: [Patches] [ python-Patches-1454485 ] patch for SIGSEGV in arraymodule.c Message-ID: Patches item #1454485, was opened at 2006-03-20 14:44 Message generated for change (Comment added) made by tbmetin You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1454485&group_id=5470 Please note that this 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: Works For Me Priority: 5 Submitted By: Baris Metin (tbmetin) Assigned to: Neal Norwitz (nnorwitz) Summary: patch for SIGSEGV in arraymodule.c Initial Comment: Array module fails handling utf-8 strings giving a SIGSEGV. Attached patch seems to do the trick... gdb> run (no debugging symbols found) (no debugging symbols found) [Thread debugging using libthread_db enabled] [New Thread -1480337216 (LWP 31303)] Python 2.4.2 (#1, Mar 20 2006, 12:08:06) [GCC 3.4.5] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> import array >>> x = array.array("u") >>> x.append(u"bar????") Traceback (most recent call last): File "", line 1, in ? TypeError: array item must be unicode character >>> x.append("bar????") >>> x Program received signal SIGSEGV, Segmentation fault. [Switching to Thread -1480337216 (LWP 31303)] Error while running hook_stop: Invalid type combination in ordering comparison. 0xa7ee0799 in PyUnicodeUCS4_FromUnicode () from /usr/lib/libpython2.4.so.1.0 ---------------------------------------------------------------------- >Comment By: Baris Metin (tbmetin) Date: 2006-03-24 11:19 Message: Logged In: YES user_id=1045504 I'm able to reproduce the bug with 2.5a0 SVN (r43289). Please try with --enable-unicode=ucs4 The patch is against svn too.. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2006-03-24 08:11 Message: Logged In: YES user_id=33168 With the stock 2.4.2 on my linux box I was able to reproduce this. I couldn't reproduce with 2.4.3c1. Can you verify this is fixed in 2.4.3? Sagol. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1454485&group_id=5470 From noreply at sourceforge.net Fri Mar 24 14:13:34 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 24 Mar 2006 05:13:34 -0800 Subject: [Patches] [ python-Patches-1161819 ] Add method to function objects to simplify decoration Message-ID: Patches item #1161819, was opened at 2005-03-12 14:21 Message generated for change (Comment added) made by ncoghlan You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1161819&group_id=5470 Please note that this 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: Add method to function objects to simplify decoration Initial Comment: When decorating a function without changing the signature, it is generally appropriate to preserve the metadata from original function. This currently involves copying the docstring and name and updating the function attribute dict manually. This patch adds an "update_meta" method to function objects which modifies the current function to masquerade as the original function. Test & documentation patches still to come. (Although the docstring text could also be used for the documentation) ---------------------------------------------------------------------- >Comment By: Nick Coghlan (ncoghlan) Date: 2006-03-24 23:13 Message: Logged In: YES user_id=1038590 We're not going to do it this way - most likely will be a standard decorator for creating well-behaved decorators. ---------------------------------------------------------------------- Comment By: Anders J. Munch (andersjm) Date: 2005-03-23 07:12 Message: Logged In: YES user_id=384806 Taken as behind-the-scenes infrastructure, not intended to be used directly, why not a pure-Python standalone function instead, for easier maintenance? Also, that would avoid discriminating against non-function callables. Although you can't use decorator syntax with non-function callables, the decorator functions themselves need not have that limitation. The case for decorator-style: 1) When used as a decorator there is no risk of getting the argument order wrong, even if it does change the argument. 2) It plays better with the open-closed principle, allowing decoratees to provide custom meta-updaters. Of course "update" in the name would be misleading, better (supply|imbue|impress)_meta. ---------------------------------------------------------------------- Comment By: Nick Coghlan (ncoghlan) Date: 2005-03-22 23:15 Message: Logged In: YES user_id=1038590 It's an interesting idea, but I'm extremely uncomfortable with the idea of a method that mutates the argument instance passed in rather than the instance that owns the method. Instead, I'd prefer to keep the current signature, and view func.update_metadata() as infrastructure that things like @simple_decorator and @decorating can build on top of. So long as the method is kept in sync with additions to the set of metadata, those two decorators would then be kept in sync for free (which is the whole point). ---------------------------------------------------------------------- Comment By: Anders J. Munch (andersjm) Date: 2005-03-22 22:19 Message: Logged In: YES user_id=384806 If self and argument are swapped, making update_meta a method on the source of information instead of the target, then the bound method will be usable as a decorator. See "Decorator decorator" in http://www.python.org/moin/PythonDecoratorLibrary for the same idea as a free function. ---------------------------------------------------------------------- Comment By: Michael Chermside (mcherm) Date: 2005-03-14 23:34 Message: Logged In: YES user_id=99874 Nice... thanks. But I have to ask: is this really the right set of metadata to be updating? Here are a few things that perhaps ought be copied by update_meta: f.__name__ (already included) f.__doc__ (already included) f.__dict__ (already included) f.__module__ (probably should include) f.func_code.co_filename (to match f.__name__, but I'd leave it alone) there's also the annoying fact that in IDLE (and in some other python-aware IDEs) one can see the argument signature for a function as a "tool tip" or other hint. Very handy that, but if a decorator is applied then all you will see is "func(*args, **kwargs)" which is less than helpful. I'm not sure whether this CAN be duplicated... I believe it is generated by examining the following: f.func_code.co_argcount f.func_code.co_varnames f.func_code.co_flags & 0x4 f.func_code.co_flags & 0x8 ...and I suspect (experimentation seems to confirm this) that if you mangle these then the code object won't work correctly. If anyone's got a suggestion for fixing this, I'd love to hear it. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1161819&group_id=5470 From noreply at sourceforge.net Fri Mar 24 14:37:34 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 24 Mar 2006 05:37:34 -0800 Subject: [Patches] [ python-Patches-1429605 ] PEP 338 documentation Message-ID: Patches item #1429605, was opened at 2006-02-11 19:18 Message generated for change (Comment added) made by ncoghlan You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1429605&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None >Status: Closed >Resolution: Accepted Priority: 5 Submitted By: Nick Coghlan (ncoghlan) Assigned to: Fred L. Drake, Jr. (fdrake) Summary: PEP 338 documentation Initial Comment: The attached Latex file (librunpy.tex) contains the documentation for PEP 338's proposed runpy module. I haven't included a patch for lib.tex or Makefile.deps, since those changes are fairly trivial and I'm not too particular about where the module gets slotted into the Library reference. ---------------------------------------------------------------------- >Comment By: Nick Coghlan (ncoghlan) Date: 2006-03-24 23:37 Message: Logged In: YES user_id=1038590 Incorporated George's suggestions, and placed immediately after modulefinder in the Table of Contents. Checked in as rev 43294. ---------------------------------------------------------------------- Comment By: George Yoshida (quiver) Date: 2006-03-19 14:20 Message: Logged In: YES user_id=671362 amk has committed his PEP328 to whatsnew, so that should be helpful. Following his style: - use \programopt for "-m" option - use \pep{} for PEP links - add seealso section And as for your document, - s/initialised/initialized > where to include it in the Library Reference table of contents. I'd like to give my vote to: - imp - zipimport - *runpy* - pkgutil - modulefinder -- george ---------------------------------------------------------------------- Comment By: Nick Coghlan (ncoghlan) Date: 2006-03-18 00:02 Message: Logged In: YES user_id=1038590 Kicking in Fred's direction to check my formatting isn't too horrible and to decide where to include it in the Library Reference table of contents. ---------------------------------------------------------------------- Comment By: Nick Coghlan (ncoghlan) Date: 2006-02-19 01:07 Message: Logged In: YES user_id=1038590 Updated to match Feb 18 version of PEP. ---------------------------------------------------------------------- Comment By: Nick Coghlan (ncoghlan) Date: 2006-02-18 01:20 Message: Logged In: YES user_id=1038590 PEP 338 has been updated as of 18-Feb-2006. Those changes are still to be incorporated into this documentation. ---------------------------------------------------------------------- Comment By: Nick Coghlan (ncoghlan) Date: 2006-02-12 00:44 Message: Logged In: YES user_id=1038590 Updated to avoid trying to hide exec's quirks ---------------------------------------------------------------------- Comment By: Nick Coghlan (ncoghlan) Date: 2006-02-11 21:03 Message: Logged In: YES user_id=1038590 Minor tweak to run_function_code to clarify the problem with resolving names when the locals and globals dictionaries are different. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1429605&group_id=5470 From noreply at sourceforge.net Fri Mar 24 14:40:50 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 24 Mar 2006 05:40:50 -0800 Subject: [Patches] [ python-Patches-1457736 ] patch for building trunk with VC6 Message-ID: Patches item #1457736, was opened at 2006-03-24 22:40 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1457736&group_id=5470 Please note that this 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: ocean-city (ocean-city) Assigned to: Nobody/Anonymous (nobody) Summary: patch for building trunk with VC6 Initial Comment: Hello. I tried to build trunk with VC6, but failed. The reasons are - _W64 is not defined on VC6. (PC/pyconfig.h) - intptr_t and uintptr_t are not decleared on VC6. (should use Py_intptr_t and Py_uintptr_t respectively) I'll submit the patch for these two issues as "build_trunk_for_vc6.patch". And more two issues. - zlib was make built into pythoncore, but PC/VC6/pythoncore.dsp is not updated for it yet. I'll submit the file itself. - long long cannot be used on VC6, so 0xFFFFULL is failed to compile with "invalid suffix" error. I workarounded this replaced ULL with UI64 (_int64's suffix) but I don't know how to make the patch. maybe can this tequnique be used? #define Py_ULL(x) x##ULL /* non VC6 */ #define Py_ULL(x) x##UI64 /* VC6 */ Py_ULL(0xFFFFFFFFFFFFFFFF) instead of 0xFFF...FULL ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1457736&group_id=5470 From noreply at sourceforge.net Fri Mar 24 15:02:08 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 24 Mar 2006 06:02:08 -0800 Subject: [Patches] [ python-Patches-1455898 ] patch for mbcs codecs Message-ID: Patches item #1455898, was opened at 2006-03-22 16:31 Message generated for change (Comment added) made by ocean-city 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.4 Status: Open Resolution: None Priority: 7 Submitted By: ocean-city (ocean-city) Assigned to: Walter D?rwald (doerwalter) 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: ocean-city (ocean-city) Date: 2006-03-24 23:02 Message: Logged In: YES user_id=1200846 OK, I'll try. ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2006-03-24 06: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: ocean-city (ocean-city) Date: 2006-03-23 11: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: ocean-city (ocean-city) Date: 2006-03-22 23: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: ocean-city (ocean-city) Date: 2006-03-22 19: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: ocean-city (ocean-city) Date: 2006-03-22 19: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 18: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 18: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: ocean-city (ocean-city) Date: 2006-03-22 16: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 Fri Mar 24 15:43:31 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 24 Mar 2006 06:43:31 -0800 Subject: [Patches] [ python-Patches-1454485 ] patch for SIGSEGV in arraymodule.c Message-ID: Patches item #1454485, was opened at 2006-03-20 22:44 Message generated for change (Comment added) made by ncoghlan You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1454485&group_id=5470 Please note that this 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: Works For Me Priority: 5 Submitted By: Baris Metin (tbmetin) Assigned to: Neal Norwitz (nnorwitz) Summary: patch for SIGSEGV in arraymodule.c Initial Comment: Array module fails handling utf-8 strings giving a SIGSEGV. Attached patch seems to do the trick... gdb> run (no debugging symbols found) (no debugging symbols found) [Thread debugging using libthread_db enabled] [New Thread -1480337216 (LWP 31303)] Python 2.4.2 (#1, Mar 20 2006, 12:08:06) [GCC 3.4.5] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> import array >>> x = array.array("u") >>> x.append(u"bar????") Traceback (most recent call last): File "", line 1, in ? TypeError: array item must be unicode character >>> x.append("bar????") >>> x Program received signal SIGSEGV, Segmentation fault. [Switching to Thread -1480337216 (LWP 31303)] Error while running hook_stop: Invalid type combination in ordering comparison. 0xa7ee0799 in PyUnicodeUCS4_FromUnicode () from /usr/lib/libpython2.4.so.1.0 ---------------------------------------------------------------------- >Comment By: Nick Coghlan (ncoghlan) Date: 2006-03-25 00:43 Message: Logged In: YES user_id=1038590 To get the effect of the patch, it should be sufficient to just change the format character to an uppercase U. That doesn't seem like the right fix though - the actual explosion isn't happening until later when the array elements are being converted to Unicode for output. ---------------------------------------------------------------------- Comment By: Baris Metin (tbmetin) Date: 2006-03-24 19:19 Message: Logged In: YES user_id=1045504 I'm able to reproduce the bug with 2.5a0 SVN (r43289). Please try with --enable-unicode=ucs4 The patch is against svn too.. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2006-03-24 16:11 Message: Logged In: YES user_id=33168 With the stock 2.4.2 on my linux box I was able to reproduce this. I couldn't reproduce with 2.4.3c1. Can you verify this is fixed in 2.4.3? Sagol. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1454485&group_id=5470 From noreply at sourceforge.net Fri Mar 24 21:44:07 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 24 Mar 2006 12:44:07 -0800 Subject: [Patches] [ python-Patches-1455676 ] Simplify using Queues with consumer threads Message-ID: Patches item #1455676, was opened at 2006-03-21 16:36 Message generated for change (Comment added) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1455676&group_id=5470 Please note that this 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: Raymond Hettinger (rhettinger) Assigned to: Raymond Hettinger (rhettinger) Summary: Simplify using Queues with consumer threads Initial Comment: When Queues are used to communicate between producer and consumer threads, there is often a need to determine when all of the enqueued tasks have been completed. With this small patch, determining when all work is done is as simple as adding q.task_done() to each consumer thread and q.join() to the main thread. Without the patch, the next best approach is to count the number of puts, create a second queue filled by the consumer when a task is done, and for the main thread to call successive blocking gets on the result queue until all of the puts have been accounted for: def worker(): while 1: task = tasks_in.get() do_work(task) tasks_out.put(None) tasks_in = Queue() tasks_out = Queue() for i in range(num_worker_threads): Thread(target=worker).start() n = 0 for elem in source(): n += 1 tasks_in.put(elem) # block until tasks are done for i in range(n): tasks_out.get() That approach is not complicated but it does entail more lines of code and tracking some auxiliary data. This becomes cumersome and error-prone when an app has multiple occurences of q.put() and q.get(). The patch essentially encapsulates this approach into two methods, making it effortless to use and easy to graft on to existing uses of Queue. So, the above code simplies to: def worker(): while 1: task = q.get() do_work(task) q.task_done() q = Queue() for i in range(num_worker_threads): Thread(target=worker).start() for elem in source(): q.put(elem) # block until tasks are done q.join() The put counting is automatic, there is no need for a separate queue object, the code readably expresses its intent with clarity. Also, it is easy to inpect for accuracy, each get() followed by a task_done(). The ease of inspection remains even when there are multiple gets and puts scattered through the code (a situtation which would become complicated for the two Queue approach). If accepted, will add docs with an example. Besides being a fast, lean, elegant solution, the other reason to accept the patch is that the underlying problem appears again and again, requiring some measure to invention to solve it each time. There are a number of approaches but none as simple, fast, or as broadly applicable as having the queue itself track items loaded and items completed. ---------------------------------------------------------------------- >Comment By: Raymond Hettinger (rhettinger) Date: 2006-03-24 15:44 Message: Logged In: YES user_id=80475 Committed as revision 43298. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2006-03-23 19:17 Message: Logged In: YES user_id=31435 I marked this as Accepted, but there are some things I'd like to see changed: - A Condition is best named after the predicate it represents. So, e.g., instead of the generic "waiter", a better name would be "all_tasks_done". When you eventually .notify() the Condition, you're notifing its wait()er that "all tasks (may be) done", and "all tasks (may be) done" is what the wait()er is waiting _for_. "all_tasks_done.wait()" makes that much clearer than "waiter.wait()". - A Condition.wait() can be interrupted by (at least) KeyboardInterrupt, so the acquire/release around a Condition.wait() call should always be in a try/finally (so that the Condition is release()d no matter what). All other Condition.wait()s in Queue do protect themselves this way. I don't see a need for try/finally around other uses, except possibly that: - Given the intended semantics, it would be good to raise an exception if .unfinished_tasks becomes negative; i.e., make it a detected programmer error if task_done() is called "too often" (although again the Condition needs to be release()d no matter what, and a try/finally may be expedient toward that end). - Since any number of threads _may_ be waiting in Queue.join(), yes, .notifyAll() is better. The other conditions in Queue don't do that because there's a key difference: at most one thread waiting on not_full or not_empty can make progress when one of those is "signaled", so it would be wasteful to wake up more than one thread waiting on those. In contrast, all threads waiting on .waiter can make progress when all tasks are in fact done. You can do that with a notifyAll() in task_done(), or by adding a notify() near the end of join() (then all threads waiting on this condition will get notified in domino fashion). The notifyAll() way is "purer". - It's inevitable that someone will ask Queue.join() to grow an optional timeout argument. OK by me if that waits ;-). ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2006-03-22 01:02 Message: Logged In: YES user_id=80475 Thanks. There are two particular areas for extra attention. First, should the waiter acquire/release pairs be in a try/finally (iow, is there some behavior in notify() or release() that potentially needs to be trapped)? Second, should the notify() in task_done() really be a notifyAll() (iow, does it make sense that multiple joins may be pending)? Thanks again. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2006-03-21 20:42 Message: Logged In: YES user_id=31435 Yup, I'll try to make time tomorrow (can't today). _Offhand_ it sounds like a nice addition to me. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2006-03-21 17:27 Message: Logged In: YES user_id=80475 Tim, do you have a chance to look at this? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1455676&group_id=5470 From noreply at sourceforge.net Sat Mar 25 00:52:34 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 24 Mar 2006 15:52:34 -0800 Subject: [Patches] [ python-Patches-670390 ] Patched test harness for logging Message-ID: Patches item #670390, was opened at 2003-01-18 19:32 Message generated for change (Comment added) made by paulicka You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=670390&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Library (Lib) Group: Python 2.3 Status: Closed Resolution: Accepted Priority: 5 Submitted By: Vinay Sajip (vsajip) Assigned to: Nobody/Anonymous (nobody) Summary: Patched test harness for logging Initial Comment: I've attached test_logging.zip which contains a new version of test_logging.py as well as a new version of the output file (test_logging). This moves the closing of a stream till after all the threads have completed. Tested under ActivePython 2.1.1 build 212 under WinXP Home, the script now runs correctly both when run from the command line and when run under regrtest. The script uses threads and so imports threading at the top. The script was causing a hang *only* when run via regrtest or the Python command prompt if run using import; I tracked the problem down to the ThreadingMixin's process_request method. When I copied this into the body of my derived class, it still failed; but commenting out the line "import threading" solved the problem, at least under WinXP Home/ActivePython 2.1.1 build 212. Can anyone shed any light on this? ---------------------------------------------------------------------- Comment By: Christopher K. Paulicka (paulicka) Date: 2006-03-24 23:52 Message: Logged In: YES user_id=45461 I have a similar problem running under Windows XP. When I run my code, which uses the logger, in a separate thread under the cmd console, I get the ValueError: I/O operation bug. If I run the code in the same thread under the cmd console, no problem. If I run the code still in the background, but under cygwin bash shell, no problem. I am running: ActivePython 2.4.2 Build 10 (ActiveState Corp.) based on Python 2.4.2 (#67, Jan 17 2006, 15:36:03) [MSC v.1310 32 bit (Intel)] on win32 I am going to try to make a simple code example that demonstrates this bug/problem. christopher at idealab.com ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2003-01-21 21:07 Message: Logged In: YES user_id=6380 OK, checked in. ---------------------------------------------------------------------- Comment By: Vinay Sajip (vsajip) Date: 2003-01-19 00:27 Message: Logged In: YES user_id=308438 Aaarrrgh! Sorry about the missing upload. Here it is (hopefully) ---------------------------------------------------------------------- Comment By: Martin v. L??wis (loewis) Date: 2003-01-18 22:43 Message: Logged In: YES user_id=21627 There's no uploaded file! You have to check the checkbox labeled "Check to Upload & Attach File" when you upload a file. Please try again. (This is a SourceForge annoyance that we can do nothing about. :-( ) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=670390&group_id=5470 From noreply at sourceforge.net Sat Mar 25 08:29:24 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 24 Mar 2006 23:29:24 -0800 Subject: [Patches] [ python-Patches-1454485 ] patch for SIGSEGV in arraymodule.c Message-ID: Patches item #1454485, was opened at 2006-03-20 04:44 Message generated for change (Comment added) made by nnorwitz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1454485&group_id=5470 Please note that this 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: 7 Submitted By: Baris Metin (tbmetin) >Assigned to: Martin v. L??wis (loewis) Summary: patch for SIGSEGV in arraymodule.c Initial Comment: Array module fails handling utf-8 strings giving a SIGSEGV. Attached patch seems to do the trick... gdb> run (no debugging symbols found) (no debugging symbols found) [Thread debugging using libthread_db enabled] [New Thread -1480337216 (LWP 31303)] Python 2.4.2 (#1, Mar 20 2006, 12:08:06) [GCC 3.4.5] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> import array >>> x = array.array("u") >>> x.append(u"bar????") Traceback (most recent call last): File "", line 1, in ? TypeError: array item must be unicode character >>> x.append("bar????") >>> x Program received signal SIGSEGV, Segmentation fault. [Switching to Thread -1480337216 (LWP 31303)] Error while running hook_stop: Invalid type combination in ordering comparison. 0xa7ee0799 in PyUnicodeUCS4_FromUnicode () from /usr/lib/libpython2.4.so.1.0 ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2006-03-24 23:29 Message: Logged In: YES user_id=33168 Verified for 2.4 and head. The probably could exist w/ucs2 also if you use 'bar' (I think). I agree with Nick, this patch doesn't really solve the problem. The attached patch fixes the crash more generally, but I'm think there is a better solution. I hope Martin has time to review this and suggest a better fix. Martin, the change in getargs ensures that we don't try to convert an 8-bit string of length 5 to unicode. The change in unicodeobject ensures that we don't reference the array with a negative offset as happens if the buffer conversion succeeds with an invalid unicode character. ---------------------------------------------------------------------- Comment By: Nick Coghlan (ncoghlan) Date: 2006-03-24 06:43 Message: Logged In: YES user_id=1038590 To get the effect of the patch, it should be sufficient to just change the format character to an uppercase U. That doesn't seem like the right fix though - the actual explosion isn't happening until later when the array elements are being converted to Unicode for output. ---------------------------------------------------------------------- Comment By: Baris Metin (tbmetin) Date: 2006-03-24 01:19 Message: Logged In: YES user_id=1045504 I'm able to reproduce the bug with 2.5a0 SVN (r43289). Please try with --enable-unicode=ucs4 The patch is against svn too.. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2006-03-23 22:11 Message: Logged In: YES user_id=33168 With the stock 2.4.2 on my linux box I was able to reproduce this. I couldn't reproduce with 2.4.3c1. Can you verify this is fixed in 2.4.3? Sagol. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1454485&group_id=5470 From noreply at sourceforge.net Sat Mar 25 12:13:38 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 25 Mar 2006 03:13:38 -0800 Subject: [Patches] [ python-Patches-1457736 ] patch for building trunk with VC6 Message-ID: Patches item #1457736, was opened at 2006-03-24 22:40 Message generated for change (Settings changed) made by ocean-city You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1457736&group_id=5470 Please note that this 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: None Priority: 5 Submitted By: ocean-city (ocean-city) Assigned to: Nobody/Anonymous (nobody) Summary: patch for building trunk with VC6 Initial Comment: Hello. I tried to build trunk with VC6, but failed. The reasons are - _W64 is not defined on VC6. (PC/pyconfig.h) - intptr_t and uintptr_t are not decleared on VC6. (should use Py_intptr_t and Py_uintptr_t respectively) I'll submit the patch for these two issues as "build_trunk_for_vc6.patch". And more two issues. - zlib was make built into pythoncore, but PC/VC6/pythoncore.dsp is not updated for it yet. I'll submit the file itself. - long long cannot be used on VC6, so 0xFFFFULL is failed to compile with "invalid suffix" error. I workarounded this replaced ULL with UI64 (_int64's suffix) but I don't know how to make the patch. maybe can this tequnique be used? #define Py_ULL(x) x##ULL /* non VC6 */ #define Py_ULL(x) x##UI64 /* VC6 */ Py_ULL(0xFFFFFFFFFFFFFFFF) instead of 0xFFF...FULL ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1457736&group_id=5470 From noreply at sourceforge.net Sat Mar 25 13:47:26 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 25 Mar 2006 04:47:26 -0800 Subject: [Patches] [ python-Patches-670390 ] Patched test harness for logging Message-ID: Patches item #670390, was opened at 2003-01-18 20:32 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=670390&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Library (Lib) Group: Python 2.3 Status: Closed Resolution: Accepted Priority: 5 Submitted By: Vinay Sajip (vsajip) Assigned to: Nobody/Anonymous (nobody) Summary: Patched test harness for logging Initial Comment: I've attached test_logging.zip which contains a new version of test_logging.py as well as a new version of the output file (test_logging). This moves the closing of a stream till after all the threads have completed. Tested under ActivePython 2.1.1 build 212 under WinXP Home, the script now runs correctly both when run from the command line and when run under regrtest. The script uses threads and so imports threading at the top. The script was causing a hang *only* when run via regrtest or the Python command prompt if run using import; I tracked the problem down to the ThreadingMixin's process_request method. When I copied this into the body of my derived class, it still failed; but commenting out the line "import threading" solved the problem, at least under WinXP Home/ActivePython 2.1.1 build 212. Can anyone shed any light on this? ---------------------------------------------------------------------- >Comment By: Martin v. L??wis (loewis) Date: 2006-03-25 13:47 Message: Logged In: YES user_id=21627 This issue is closed. Please submit your issue as a new report. ---------------------------------------------------------------------- Comment By: Christopher K. Paulicka (paulicka) Date: 2006-03-25 00:52 Message: Logged In: YES user_id=45461 I have a similar problem running under Windows XP. When I run my code, which uses the logger, in a separate thread under the cmd console, I get the ValueError: I/O operation bug. If I run the code in the same thread under the cmd console, no problem. If I run the code still in the background, but under cygwin bash shell, no problem. I am running: ActivePython 2.4.2 Build 10 (ActiveState Corp.) based on Python 2.4.2 (#67, Jan 17 2006, 15:36:03) [MSC v.1310 32 bit (Intel)] on win32 I am going to try to make a simple code example that demonstrates this bug/problem. christopher at idealab.com ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2003-01-21 22:07 Message: Logged In: YES user_id=6380 OK, checked in. ---------------------------------------------------------------------- Comment By: Vinay Sajip (vsajip) Date: 2003-01-19 01:27 Message: Logged In: YES user_id=308438 Aaarrrgh! Sorry about the missing upload. Here it is (hopefully) ---------------------------------------------------------------------- Comment By: Martin v. L??wis (loewis) Date: 2003-01-18 23:43 Message: Logged In: YES user_id=21627 There's no uploaded file! You have to check the checkbox labeled "Check to Upload & Attach File" when you upload a file. Please try again. (This is a SourceForge annoyance that we can do nothing about. :-( ) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=670390&group_id=5470 From noreply at sourceforge.net Sat Mar 25 17:17:26 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 25 Mar 2006 08:17:26 -0800 Subject: [Patches] [ python-Patches-1444398 ] Make itertools.tee participate in GC Message-ID: Patches item #1444398, was opened at 2006-03-06 15:33 Message generated for change (Comment added) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1444398&group_id=5470 Please note that this 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: Thomas Wouters (twouters) >Assigned to: Georg Brandl (gbrandl) Summary: Make itertools.tee participate in GC Initial Comment: A small patch to make itertools.tee objects participate in GC; solves the memoryleak in test_generators (and any other use of tee objects in cycles.) ---------------------------------------------------------------------- >Comment By: Raymond Hettinger (rhettinger) Date: 2006-03-25 11:17 Message: Logged In: YES user_id=80475 Georg, do you have time to fix-up this patch and check it in? ---------------------------------------------------------------------- Comment By: Thomas Wouters (twouters) Date: 2006-03-20 16:34 Message: Logged In: YES user_id=34209 Hmm. An alternative fix would be to make itertools.tee only partially participate in GC. That is, not have it traverse over all the stored items, but just the iterator. It would prevent the (potentially rather heavy) cost of going over all cached items, but still leaves a potential for unfindable cycles. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2006-03-19 03:02 Message: Logged In: YES user_id=80475 Okay, go ahead and add GC to itertools.tee(). The test_generators examples make it clear that there are valid use cases for feeding a teeobject back into itself. Tim, the original rationale did not have to do with millions of tee objects; rather, it posited that a tee could contain many objects of some other type and that traversing it during GC was simply a waste of time. Thomas, the patch needs work, but I don't currently have time to go through it. Do your best to model after the other tools which have gc. That includes setting the tp_flags slot, doing an untrack before dealloc starts, replacing PyObject_Del and PyObject_New with their GC counterparts. See section 2.1.3 in Extending and Embedding for the details and examples. Offhand, I think it may also need a tp_clear entry but I'm not sure. If you can work out a good patch, go ahead an apply it for the alpha 1 release. If not, assign back to me and I'll get to it when I can (possibly for the second alpha). ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2006-03-06 19:52 Message: Logged In: YES user_id=31435 If there are likely to be millions of some type of object, then avoiding gc for that type on grounds of reducing memory use may be arguable (or, as in the cases of tuples or lists, may not be arguable regardless). Else "if it points to a PyObject, it might be in a cycle, so gc-enable it" generally rules. I'll note in passing that the m235 and fib generators weren't _intended_ to stress Python in any way, but have been extremely effective at doing so since generators first went in. Think of them as a pair of canaries in the coal mine :-) ---------------------------------------------------------------------- Comment By: Thomas Wouters (twouters) Date: 2006-03-06 19:12 Message: Logged In: YES user_id=34209 Well, I'm fine with removing the scope-enclosed generator versions of _m235() and fib() from test_generators, if that's what you're implying. :> However, I think it's slightly more suitable to just have tee participate in GC. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2006-03-06 19:05 Message: Logged In: YES user_id=80475 I will take a look at the patch soon. IIRC, there was a concious decision to not have tee engage in GC because no normal use cases created cycles (they seem to arise only when intentionally creating a cycle for test code). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1444398&group_id=5470 From noreply at sourceforge.net Sat Mar 25 17:39:19 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 25 Mar 2006 08:39:19 -0800 Subject: [Patches] [ python-Patches-1444398 ] Make itertools.tee participate in GC Message-ID: Patches item #1444398, was opened at 2006-03-06 21:33 Message generated for change (Comment added) made by twouters You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1444398&group_id=5470 Please note that this 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: Thomas Wouters (twouters) Assigned to: Georg Brandl (gbrandl) Summary: Make itertools.tee participate in GC Initial Comment: A small patch to make itertools.tee objects participate in GC; solves the memoryleak in test_generators (and any other use of tee objects in cycles.) ---------------------------------------------------------------------- >Comment By: Thomas Wouters (twouters) Date: 2006-03-25 17:39 Message: Logged In: YES user_id=34209 I cleaned up my patch (attached), but for some reason, it isn't resolving the refleaks in test_generators. I swear my patch was resolving them before, but I guess I must've done something else (maybe in addition to this) that fixed the leaks. Or maybe I'm just going cross-eyed. I do believe I implemented GC correctly, and I do believe the leaks are uncleanable circular references. I haven't had time to debug it more; if someone else wants to, feel free. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2006-03-25 17:17 Message: Logged In: YES user_id=80475 Georg, do you have time to fix-up this patch and check it in? ---------------------------------------------------------------------- Comment By: Thomas Wouters (twouters) Date: 2006-03-20 22:34 Message: Logged In: YES user_id=34209 Hmm. An alternative fix would be to make itertools.tee only partially participate in GC. That is, not have it traverse over all the stored items, but just the iterator. It would prevent the (potentially rather heavy) cost of going over all cached items, but still leaves a potential for unfindable cycles. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2006-03-19 09:02 Message: Logged In: YES user_id=80475 Okay, go ahead and add GC to itertools.tee(). The test_generators examples make it clear that there are valid use cases for feeding a teeobject back into itself. Tim, the original rationale did not have to do with millions of tee objects; rather, it posited that a tee could contain many objects of some other type and that traversing it during GC was simply a waste of time. Thomas, the patch needs work, but I don't currently have time to go through it. Do your best to model after the other tools which have gc. That includes setting the tp_flags slot, doing an untrack before dealloc starts, replacing PyObject_Del and PyObject_New with their GC counterparts. See section 2.1.3 in Extending and Embedding for the details and examples. Offhand, I think it may also need a tp_clear entry but I'm not sure. If you can work out a good patch, go ahead an apply it for the alpha 1 release. If not, assign back to me and I'll get to it when I can (possibly for the second alpha). ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2006-03-07 01:52 Message: Logged In: YES user_id=31435 If there are likely to be millions of some type of object, then avoiding gc for that type on grounds of reducing memory use may be arguable (or, as in the cases of tuples or lists, may not be arguable regardless). Else "if it points to a PyObject, it might be in a cycle, so gc-enable it" generally rules. I'll note in passing that the m235 and fib generators weren't _intended_ to stress Python in any way, but have been extremely effective at doing so since generators first went in. Think of them as a pair of canaries in the coal mine :-) ---------------------------------------------------------------------- Comment By: Thomas Wouters (twouters) Date: 2006-03-07 01:12 Message: Logged In: YES user_id=34209 Well, I'm fine with removing the scope-enclosed generator versions of _m235() and fib() from test_generators, if that's what you're implying. :> However, I think it's slightly more suitable to just have tee participate in GC. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2006-03-07 01:05 Message: Logged In: YES user_id=80475 I will take a look at the patch soon. IIRC, there was a concious decision to not have tee engage in GC because no normal use cases created cycles (they seem to arise only when intentionally creating a cycle for test code). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1444398&group_id=5470 From noreply at sourceforge.net Sat Mar 25 18:14:19 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 25 Mar 2006 09:14:19 -0800 Subject: [Patches] [ python-Patches-1444398 ] Make itertools.tee participate in GC Message-ID: Patches item #1444398, was opened at 2006-03-06 15:33 Message generated for change (Comment added) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1444398&group_id=5470 Please note that this 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: Thomas Wouters (twouters) Assigned to: Georg Brandl (gbrandl) Summary: Make itertools.tee participate in GC Initial Comment: A small patch to make itertools.tee objects participate in GC; solves the memoryleak in test_generators (and any other use of tee objects in cycles.) ---------------------------------------------------------------------- >Comment By: Raymond Hettinger (rhettinger) Date: 2006-03-25 12:14 Message: Logged In: YES user_id=80475 In teedataobject_new(), try adding PyObject_GC_Track(tdo) just before the return statement. ---------------------------------------------------------------------- Comment By: Thomas Wouters (twouters) Date: 2006-03-25 11:39 Message: Logged In: YES user_id=34209 I cleaned up my patch (attached), but for some reason, it isn't resolving the refleaks in test_generators. I swear my patch was resolving them before, but I guess I must've done something else (maybe in addition to this) that fixed the leaks. Or maybe I'm just going cross-eyed. I do believe I implemented GC correctly, and I do believe the leaks are uncleanable circular references. I haven't had time to debug it more; if someone else wants to, feel free. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2006-03-25 11:17 Message: Logged In: YES user_id=80475 Georg, do you have time to fix-up this patch and check it in? ---------------------------------------------------------------------- Comment By: Thomas Wouters (twouters) Date: 2006-03-20 16:34 Message: Logged In: YES user_id=34209 Hmm. An alternative fix would be to make itertools.tee only partially participate in GC. That is, not have it traverse over all the stored items, but just the iterator. It would prevent the (potentially rather heavy) cost of going over all cached items, but still leaves a potential for unfindable cycles. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2006-03-19 03:02 Message: Logged In: YES user_id=80475 Okay, go ahead and add GC to itertools.tee(). The test_generators examples make it clear that there are valid use cases for feeding a teeobject back into itself. Tim, the original rationale did not have to do with millions of tee objects; rather, it posited that a tee could contain many objects of some other type and that traversing it during GC was simply a waste of time. Thomas, the patch needs work, but I don't currently have time to go through it. Do your best to model after the other tools which have gc. That includes setting the tp_flags slot, doing an untrack before dealloc starts, replacing PyObject_Del and PyObject_New with their GC counterparts. See section 2.1.3 in Extending and Embedding for the details and examples. Offhand, I think it may also need a tp_clear entry but I'm not sure. If you can work out a good patch, go ahead an apply it for the alpha 1 release. If not, assign back to me and I'll get to it when I can (possibly for the second alpha). ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2006-03-06 19:52 Message: Logged In: YES user_id=31435 If there are likely to be millions of some type of object, then avoiding gc for that type on grounds of reducing memory use may be arguable (or, as in the cases of tuples or lists, may not be arguable regardless). Else "if it points to a PyObject, it might be in a cycle, so gc-enable it" generally rules. I'll note in passing that the m235 and fib generators weren't _intended_ to stress Python in any way, but have been extremely effective at doing so since generators first went in. Think of them as a pair of canaries in the coal mine :-) ---------------------------------------------------------------------- Comment By: Thomas Wouters (twouters) Date: 2006-03-06 19:12 Message: Logged In: YES user_id=34209 Well, I'm fine with removing the scope-enclosed generator versions of _m235() and fib() from test_generators, if that's what you're implying. :> However, I think it's slightly more suitable to just have tee participate in GC. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2006-03-06 19:05 Message: Logged In: YES user_id=80475 I will take a look at the patch soon. IIRC, there was a concious decision to not have tee engage in GC because no normal use cases created cycles (they seem to arise only when intentionally creating a cycle for test code). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1444398&group_id=5470 From noreply at sourceforge.net Sat Mar 25 20:54:28 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 25 Mar 2006 11:54:28 -0800 Subject: [Patches] [ python-Patches-1458419 ] floor division Message-ID: Patches item #1458419, was opened at 2006-03-25 19:54 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1458419&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Documentation Group: None Status: Open Resolution: None Priority: 5 Submitted By: Andy (lemonkandy) Assigned to: Nobody/Anonymous (nobody) Summary: floor division Initial Comment: This is a patch filed in response to cito's bug, 1457358. A description for the floor division operator // was missing. I wasn't sure if I should have been a little more descriptive, I thought this might have been patronising. This is my first ever patch to an open source project. I'm starting _really_ small. This patch was made against revision 43311, from the root directory of the trunk. Andy ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1458419&group_id=5470 From noreply at sourceforge.net Sat Mar 25 20:56:43 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 25 Mar 2006 11:56:43 -0800 Subject: [Patches] [ python-Patches-1443155 ] Incremental codecs for CJKCodecs Message-ID: Patches item #1443155, was opened at 2006-03-04 19:45 Message generated for change (Comment added) made by doerwalter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1443155&group_id=5470 Please note that this 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: Hye-Shik Chang (perky) Assigned to: Hye-Shik Chang (perky) Summary: Incremental codecs for CJKCodecs Initial Comment: Here's a supplemental patch for SF #1436130 to implement CJKCodecs part of the Incremental codec specification. This patch is implemented in an interface of Walter's fourth patch on #1436130. Please test this whether it agrees the design. ---------------------------------------------------------------------- >Comment By: Walter D?rwald (doerwalter) Date: 2006-03-25 20:56 Message: Logged In: YES user_id=89016 OK, a few notes on the patch: In the test "c = codecs.lookup('utf-8')[3](s)" should be written as "c = codecs.getwriter('utf-8')(s)". Someday in the future CodecInfo may no longer be a tuple. Instead of htmlentitydefs.entitydefs, the test could use htmlentitydefs.name2codepoint. I'd like to see a few tests for error callbacks that return the wrong objects and for callbacks that return an offset that is not exc.end. The ERROR_ISCUSTOM() macro looks wrong to me: smaller than 1 *and* greater that 3? In mbiencoder_encode() r = encoder_encode_stateful(STATEFUL_ECTX(self), data, final); if (r == NULL) return NULL; return r; can be simplified to: return encoder_encode_stateful(STATEFUL_ECTX(self), data, final); Apart from that the patch looks good to me, so go ahead and check it in. ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2006-03-18 21:47 Message: Logged In: YES user_id=89016 Maybe the statement is a bit misleading in its current form. I didn't mean that error handling prevents the flushing of the buffers, just that error handling prevents raising an error. I hope the following is clearer: "If final is true the codec must encode/decode the input completely and must flush all buffers. If this isn't possible (e.g. because of incomplete byte sequences still remaining in the buffer on decoding) it must initiate error handling just like in the stateless case (which might raise an exception)." I'll take a look at the patch in the next few days. ---------------------------------------------------------------------- Comment By: Hye-Shik Chang (perky) Date: 2006-03-18 19:32 Message: Logged In: YES user_id=55188 I updated the patch for the .errors visibility. I like the statement. But the current implementation of the patch is slightly different for a corner case; the current implementation keeps buffers if an error is occurred. That is somewhat natural because error cases doesn't make side-effects usually. But in other side, I agree to your statement in a view of a direct interpretation of final=True. What do you think about this? ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2006-03-18 16:24 Message: Logged In: YES user_id=89016 What other interpretation of the final parameter can we use that doesn't make it completely useless? What about the following: "If final is true the codec must encode/decode the input completely and must flush all buffers. If this isn't possible (e.g. because of incomplete byte sequences on decoding) it must raise an exception (unless prevented by an error handler)"? ---------------------------------------------------------------------- Comment By: Hye-Shik Chang (perky) Date: 2006-03-16 13:32 Message: Logged In: YES user_id=55188 1) Because CJKCodecs had an internal stateful framework, I implemented just an interface using it for IncrementalCodec. It treats final=True as a simple `flush' message(which doesn't reset or terminate the codec). The behavior is quite useful for real-time stream processing such as sockets and tail log watchers. If we disallow that, such usages may require its own sequence detectors. For "to reset or not" issue, I think we can simply follow how iconv does. iconv doesn't reset the internal state for iconv(ic, NULL, NULL, ..). 2) Aah. I didn't notice that .errors is a part of public API. The current CJKCodecs can't support it easily yet. I'll fix it and upload a updated patch soon. Thank you for your review! ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2006-03-15 13:08 Message: Logged In: YES user_id=89016 The patch doesn't apply cleanly (conflicts in Lib/test/test_multibytecodec.py and Tools/unicode/Makefile). Could you update the patch? I haven't looked at the C code to closely yet. Two notes: 1) The tests often call incencoder.encode() or incdecoder.decode() again after the method has been called with final=True before. I'm not sure that this should be allowed. If we allow it, it should be documented in what state the codec is after calling with final=True (probably it should be back to the initial state (i.e. like calling reset())). 2) It seems to me that it isn't possible to change the error handling during the lifetime of a codec. Anyway, thanks for the quick patch. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1443155&group_id=5470 From noreply at sourceforge.net Sat Mar 25 22:28:05 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 25 Mar 2006 13:28:05 -0800 Subject: [Patches] [ python-Patches-1458419 ] floor division Message-ID: Patches item #1458419, was opened at 2006-03-25 11:54 Message generated for change (Comment added) made by nnorwitz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1458419&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Documentation Group: None >Status: Closed >Resolution: Accepted Priority: 5 Submitted By: Andy (lemonkandy) >Assigned to: Neal Norwitz (nnorwitz) Summary: floor division Initial Comment: This is a patch filed in response to cito's bug, 1457358. A description for the floor division operator // was missing. I wasn't sure if I should have been a little more descriptive, I thought this might have been patronising. This is my first ever patch to an open source project. I'm starting _really_ small. This patch was made against revision 43311, from the root directory of the trunk. Andy ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2006-03-25 13:28 Message: Logged In: YES user_id=33168 Thanks! I added a note about it also being referred to as integer division. The change should appear within 12 hours in both places: http://docs.python.org/dev/ http://docs.python.org/dev/2.4/ Committed revision 43312. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1458419&group_id=5470 From noreply at sourceforge.net Sat Mar 25 23:48:57 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 25 Mar 2006 14:48:57 -0800 Subject: [Patches] [ python-Patches-1458476 ] Improved PySet C API Message-ID: Patches item #1458476, was opened at 2006-03-25 17: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=1458476&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Core (C code) Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: Barry A. Warsaw (bwarsaw) Assigned to: Nobody/Anonymous (nobody) Summary: Improved PySet C API Initial Comment: This patch adds PySet_Next(), PySet_Update(), and PySet_Clear(), three very useful API calls when you're dealing with concrete PySet objects. Patch includes tests and documentation. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1458476&group_id=5470 From noreply at sourceforge.net Sun Mar 26 00:56:27 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 25 Mar 2006 15:56:27 -0800 Subject: [Patches] [ python-Patches-1458476 ] Improved PySet C API Message-ID: Patches item #1458476, was opened at 2006-03-25 17:48 Message generated for change (Comment added) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1458476&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Core (C code) Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: Barry A. Warsaw (bwarsaw) >Assigned to: Guido van Rossum (gvanrossum) Summary: Improved PySet C API Initial Comment: This patch adds PySet_Next(), PySet_Update(), and PySet_Clear(), three very useful API calls when you're dealing with concrete PySet objects. Patch includes tests and documentation. ---------------------------------------------------------------------- >Comment By: Raymond Hettinger (rhettinger) Date: 2006-03-25 18:56 Message: Logged In: YES user_id=80475 Guido, please reject this patch. I laid-out my reasoning in these two posts: http://mail.python.org/pipermail/python-dev/2006- March/062652.html http://mail.python.org/pipermail/python-dev/2006- March/062737.html In particular, I've found PySet_Next() to be disasterously error-prone (and have had to fix several hard-to-find bugs directly attributable this function). There was some need for it in the PyDict API because it fetched key and value pointers at the same time and allowed direct modification of values. This of course does not apply to sets which do not have a value field. The PySet_Clear() function should be PyObject_Clear() like other functions that have tp_slots. There is no more of a case for this function than there would be for PySet_Repr, PySet_Len, PySet_IsTrue, or PySet_Print. The PySet_Update() function gets in the way of my future development plans for this module. None of these functions are necessary. They simply reflect Barry's programming style and views on having fat, overly-concrete APIs. This patch is against my wishes for the module. As the module author and principal maintainer, if I still have a say in the module's development, I strongly prefer rejection of this patch. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1458476&group_id=5470 From noreply at sourceforge.net Sun Mar 26 04:35:58 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 25 Mar 2006 18:35:58 -0800 Subject: [Patches] [ python-Patches-1443155 ] Incremental codecs for CJKCodecs Message-ID: Patches item #1443155, was opened at 2006-03-05 03:45 Message generated for change (Comment added) made by perky You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1443155&group_id=5470 Please note that this 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: Hye-Shik Chang (perky) Assigned to: Hye-Shik Chang (perky) Summary: Incremental codecs for CJKCodecs Initial Comment: Here's a supplemental patch for SF #1436130 to implement CJKCodecs part of the Incremental codec specification. This patch is implemented in an interface of Walter's fourth patch on #1436130. Please test this whether it agrees the design. ---------------------------------------------------------------------- >Comment By: Hye-Shik Chang (perky) Date: 2006-03-26 11:35 Message: Logged In: YES user_id=55188 Committed as r43320. Thank you for the kind reviews! :) ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2006-03-26 04:56 Message: Logged In: YES user_id=89016 OK, a few notes on the patch: In the test "c = codecs.lookup('utf-8')[3](s)" should be written as "c = codecs.getwriter('utf-8')(s)". Someday in the future CodecInfo may no longer be a tuple. Instead of htmlentitydefs.entitydefs, the test could use htmlentitydefs.name2codepoint. I'd like to see a few tests for error callbacks that return the wrong objects and for callbacks that return an offset that is not exc.end. The ERROR_ISCUSTOM() macro looks wrong to me: smaller than 1 *and* greater that 3? In mbiencoder_encode() r = encoder_encode_stateful(STATEFUL_ECTX(self), data, final); if (r == NULL) return NULL; return r; can be simplified to: return encoder_encode_stateful(STATEFUL_ECTX(self), data, final); Apart from that the patch looks good to me, so go ahead and check it in. ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2006-03-19 05:47 Message: Logged In: YES user_id=89016 Maybe the statement is a bit misleading in its current form. I didn't mean that error handling prevents the flushing of the buffers, just that error handling prevents raising an error. I hope the following is clearer: "If final is true the codec must encode/decode the input completely and must flush all buffers. If this isn't possible (e.g. because of incomplete byte sequences still remaining in the buffer on decoding) it must initiate error handling just like in the stateless case (which might raise an exception)." I'll take a look at the patch in the next few days. ---------------------------------------------------------------------- Comment By: Hye-Shik Chang (perky) Date: 2006-03-19 03:32 Message: Logged In: YES user_id=55188 I updated the patch for the .errors visibility. I like the statement. But the current implementation of the patch is slightly different for a corner case; the current implementation keeps buffers if an error is occurred. That is somewhat natural because error cases doesn't make side-effects usually. But in other side, I agree to your statement in a view of a direct interpretation of final=True. What do you think about this? ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2006-03-19 00:24 Message: Logged In: YES user_id=89016 What other interpretation of the final parameter can we use that doesn't make it completely useless? What about the following: "If final is true the codec must encode/decode the input completely and must flush all buffers. If this isn't possible (e.g. because of incomplete byte sequences on decoding) it must raise an exception (unless prevented by an error handler)"? ---------------------------------------------------------------------- Comment By: Hye-Shik Chang (perky) Date: 2006-03-16 21:32 Message: Logged In: YES user_id=55188 1) Because CJKCodecs had an internal stateful framework, I implemented just an interface using it for IncrementalCodec. It treats final=True as a simple `flush' message(which doesn't reset or terminate the codec). The behavior is quite useful for real-time stream processing such as sockets and tail log watchers. If we disallow that, such usages may require its own sequence detectors. For "to reset or not" issue, I think we can simply follow how iconv does. iconv doesn't reset the internal state for iconv(ic, NULL, NULL, ..). 2) Aah. I didn't notice that .errors is a part of public API. The current CJKCodecs can't support it easily yet. I'll fix it and upload a updated patch soon. Thank you for your review! ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2006-03-15 21:08 Message: Logged In: YES user_id=89016 The patch doesn't apply cleanly (conflicts in Lib/test/test_multibytecodec.py and Tools/unicode/Makefile). Could you update the patch? I haven't looked at the C code to closely yet. Two notes: 1) The tests often call incencoder.encode() or incdecoder.decode() again after the method has been called with final=True before. I'm not sure that this should be allowed. If we allow it, it should be documented in what state the codec is after calling with final=True (probably it should be back to the initial state (i.e. like calling reset())). 2) It seems to me that it isn't possible to change the error handling during the lifetime of a codec. Anyway, thanks for the quick patch. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1443155&group_id=5470 From noreply at sourceforge.net Sun Mar 26 07:41:53 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 25 Mar 2006 21:41:53 -0800 Subject: [Patches] [ python-Patches-1458476 ] Improved PySet C API Message-ID: Patches item #1458476, was opened at 2006-03-25 17:48 Message generated for change (Comment added) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1458476&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Core (C code) Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: Barry A. Warsaw (bwarsaw) Assigned to: Guido van Rossum (gvanrossum) Summary: Improved PySet C API Initial Comment: This patch adds PySet_Next(), PySet_Update(), and PySet_Clear(), three very useful API calls when you're dealing with concrete PySet objects. Patch includes tests and documentation. ---------------------------------------------------------------------- >Comment By: Raymond Hettinger (rhettinger) Date: 2006-03-26 00:41 Message: Logged In: YES user_id=80475 FWIW, I'm open to PyObject_Clear() for an abstract access to the tp_clear slot. Also, for Barry's use only, I'm open to a semi-private _PySet_Next() that isn't part of the official API but gives a Barry-specific hook. It should not be a public function because of all the problems with the approach. Likewise, _PySet_Update() could be done just for Barry's group. I need to keep PySet_Update() open until Py2.6 since the API may evolve to allow a variable length argument list. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2006-03-25 18:56 Message: Logged In: YES user_id=80475 Guido, please reject this patch. I laid-out my reasoning in these two posts: http://mail.python.org/pipermail/python-dev/2006- March/062652.html http://mail.python.org/pipermail/python-dev/2006- March/062737.html In particular, I've found PySet_Next() to be disasterously error-prone (and have had to fix several hard-to-find bugs directly attributable this function). There was some need for it in the PyDict API because it fetched key and value pointers at the same time and allowed direct modification of values. This of course does not apply to sets which do not have a value field. The PySet_Clear() function should be PyObject_Clear() like other functions that have tp_slots. There is no more of a case for this function than there would be for PySet_Repr, PySet_Len, PySet_IsTrue, or PySet_Print. The PySet_Update() function gets in the way of my future development plans for this module. None of these functions are necessary. They simply reflect Barry's programming style and views on having fat, overly-concrete APIs. This patch is against my wishes for the module. As the module author and principal maintainer, if I still have a say in the module's development, I strongly prefer rejection of this patch. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1458476&group_id=5470 From noreply at sourceforge.net Sun Mar 26 19:02:01 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 26 Mar 2006 09:02:01 -0800 Subject: [Patches] [ python-Patches-1457736 ] patch for building trunk with VC6 Message-ID: Patches item #1457736, was opened at 2006-03-24 05:40 Message generated for change (Comment added) made by nnorwitz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1457736&group_id=5470 Please note that this 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: None Priority: 5 Submitted By: ocean-city (ocean-city) >Assigned to: Raymond Hettinger (rhettinger) Summary: patch for building trunk with VC6 Initial Comment: Hello. I tried to build trunk with VC6, but failed. The reasons are - _W64 is not defined on VC6. (PC/pyconfig.h) - intptr_t and uintptr_t are not decleared on VC6. (should use Py_intptr_t and Py_uintptr_t respectively) I'll submit the patch for these two issues as "build_trunk_for_vc6.patch". And more two issues. - zlib was make built into pythoncore, but PC/VC6/pythoncore.dsp is not updated for it yet. I'll submit the file itself. - long long cannot be used on VC6, so 0xFFFFULL is failed to compile with "invalid suffix" error. I workarounded this replaced ULL with UI64 (_int64's suffix) but I don't know how to make the patch. maybe can this tequnique be used? #define Py_ULL(x) x##ULL /* non VC6 */ #define Py_ULL(x) x##UI64 /* VC6 */ Py_ULL(0xFFFFFFFFFFFFFFFF) instead of 0xFFF...FULL ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2006-03-26 09:02 Message: Logged In: YES user_id=33168 Raymond, maybe this will help get VC6 building? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1457736&group_id=5470 From noreply at sourceforge.net Sun Mar 26 23:05:16 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 26 Mar 2006 13:05:16 -0800 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.4 Status: Open Resolution: None Priority: 7 Submitted By: ocean-city (ocean-city) Assigned to: Walter D?rwald (doerwalter) 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-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: ocean-city (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: ocean-city (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: ocean-city (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: ocean-city (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: ocean-city (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: ocean-city (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 Sun Mar 26 23:36:19 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 26 Mar 2006 13:36:19 -0800 Subject: [Patches] [ python-Patches-1454485 ] patch for SIGSEGV in arraymodule.c Message-ID: Patches item #1454485, was opened at 2006-03-20 13:44 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1454485&group_id=5470 Please note that this 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: 7 Submitted By: Baris Metin (tbmetin) Assigned to: Martin v. L??wis (loewis) Summary: patch for SIGSEGV in arraymodule.c Initial Comment: Array module fails handling utf-8 strings giving a SIGSEGV. Attached patch seems to do the trick... gdb> run (no debugging symbols found) (no debugging symbols found) [Thread debugging using libthread_db enabled] [New Thread -1480337216 (LWP 31303)] Python 2.4.2 (#1, Mar 20 2006, 12:08:06) [GCC 3.4.5] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> import array >>> x = array.array("u") >>> x.append(u"bar????") Traceback (most recent call last): File "", line 1, in ? TypeError: array item must be unicode character >>> x.append("bar????") >>> x Program received signal SIGSEGV, Segmentation fault. [Switching to Thread -1480337216 (LWP 31303)] Error while running hook_stop: Invalid type combination in ordering comparison. 0xa7ee0799 in PyUnicodeUCS4_FromUnicode () from /usr/lib/libpython2.4.so.1.0 ---------------------------------------------------------------------- >Comment By: Martin v. L??wis (loewis) Date: 2006-03-26 23:36 Message: Logged In: YES user_id=21627 The second part of the patch (checking that *u is not negative) is definitely right. The first part (requiring an even number of bytes for a u# argument) probably requires discussion on python-dev (or this patch should be assigned to MAL): I don't think it should be allowed to pass a non-Unicode object to u# in the first place. In particular, if you pass a byte string, there would be an implicit assumption that the byte encoding is the same internal representation as a Py_UNICODE. This is bad - Python normally assumes the encoding of a string is the system encoding, which normally is ASCII. Of course, changing the call to a type error for 2.4.3 probably won't work, either, because it might break existing code. Anyway, I believe the latter fix alone should fix the crash: the current getargs implementation will round down to the next multiple of sizeof(Py_UNICODE), thanks the integer division. u_setitem will then refuse the call if the length is not 1. IOW, it is possible to append between 4 and 7 bytes to a Unicode array. I wonder why the patch fixes the problem: *u should be an unsigned, and comparing an unsigned with a signed should convert the signed to unsigned, no? ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2006-03-25 08:29 Message: Logged In: YES user_id=33168 Verified for 2.4 and head. The probably could exist w/ucs2 also if you use 'bar' (I think). I agree with Nick, this patch doesn't really solve the problem. The attached patch fixes the crash more generally, but I'm think there is a better solution. I hope Martin has time to review this and suggest a better fix. Martin, the change in getargs ensures that we don't try to convert an 8-bit string of length 5 to unicode. The change in unicodeobject ensures that we don't reference the array with a negative offset as happens if the buffer conversion succeeds with an invalid unicode character. ---------------------------------------------------------------------- Comment By: Nick Coghlan (ncoghlan) Date: 2006-03-24 15:43 Message: Logged In: YES user_id=1038590 To get the effect of the patch, it should be sufficient to just change the format character to an uppercase U. That doesn't seem like the right fix though - the actual explosion isn't happening until later when the array elements are being converted to Unicode for output. ---------------------------------------------------------------------- Comment By: Baris Metin (tbmetin) Date: 2006-03-24 10:19 Message: Logged In: YES user_id=1045504 I'm able to reproduce the bug with 2.5a0 SVN (r43289). Please try with --enable-unicode=ucs4 The patch is against svn too.. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2006-03-24 07:11 Message: Logged In: YES user_id=33168 With the stock 2.4.2 on my linux box I was able to reproduce this. I couldn't reproduce with 2.4.3c1. Can you verify this is fixed in 2.4.3? Sagol. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1454485&group_id=5470 From noreply at sourceforge.net Mon Mar 27 04:08:48 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 26 Mar 2006 18:08:48 -0800 Subject: [Patches] [ python-Patches-1459011 ] Mutable Iterators PEP Message-ID: Patches item #1459011, was opened at 2006-03-26 21: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=1459011&group_id=5470 Please note that this 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: Adam DePrince (adamdeprince) Assigned to: Nobody/Anonymous (nobody) Summary: Mutable Iterators PEP Initial Comment: This patch is a partial implementation of the mutable iterators PEP currently being discussed on the python-3000 mailing list. It differs from the PEP in a few ways: 1. We havn't quite eliminiated the annoying iter variants of dict.keys/values/items because parts of the python proper expect the non iter variants to return something indexable. 2. We currently don't support the java fast-fail semantics for concurrent mutation. This requires some discussion, because it might involve a small performance burden on all structures that support mutable iterators, evne when there are currrently running. While the eliminiation of iter{keys/items/values} is hoped for 3.0, there is no reason the iters couldn't silently become mutable for 2.5. I'll discuss this in morn depth on the mailing list. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1459011&group_id=5470 From noreply at sourceforge.net Mon Mar 27 04:14:32 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 26 Mar 2006 18:14:32 -0800 Subject: [Patches] [ python-Patches-1459011 ] Mutable Iterators PEP Message-ID: Patches item #1459011, was opened at 2006-03-26 21:08 Message generated for change (Settings changed) made by adamdeprince You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1459011&group_id=5470 Please note that this 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: Pending >Resolution: Later >Priority: 1 Submitted By: Adam DePrince (adamdeprince) Assigned to: Nobody/Anonymous (nobody) Summary: Mutable Iterators PEP Initial Comment: This patch is a partial implementation of the mutable iterators PEP currently being discussed on the python-3000 mailing list. It differs from the PEP in a few ways: 1. We havn't quite eliminiated the annoying iter variants of dict.keys/values/items because parts of the python proper expect the non iter variants to return something indexable. 2. We currently don't support the java fast-fail semantics for concurrent mutation. This requires some discussion, because it might involve a small performance burden on all structures that support mutable iterators, evne when there are currrently running. While the eliminiation of iter{keys/items/values} is hoped for 3.0, there is no reason the iters couldn't silently become mutable for 2.5. I'll discuss this in morn depth on the mailing list. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1459011&group_id=5470 From noreply at sourceforge.net Mon Mar 27 07:44:31 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 26 Mar 2006 21:44:31 -0800 Subject: [Patches] [ python-Patches-1455898 ] patch for mbcs codecs Message-ID: Patches item #1455898, was opened at 2006-03-22 16:31 Message generated for change (Comment added) made by ocean-city 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.4 Status: Open Resolution: None Priority: 7 Submitted By: Hirokazu Yamamoto (ocean-city) Assigned to: Walter D?rwald (doerwalter) 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: Hirokazu Yamamoto (ocean-city) Date: 2006-03-27 14: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-27 06: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 23:02 Message: Logged In: YES user_id=1200846 OK, I'll try. ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2006-03-24 06: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 11: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 23: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 19: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 19: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 18: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 18: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 16: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 Mon Mar 27 09:41:47 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 26 Mar 2006 23:41:47 -0800 Subject: [Patches] [ python-Patches-1455898 ] patch for mbcs codecs Message-ID: Patches item #1455898, was opened at 2006-03-22 16:31 Message generated for change (Comment added) made by ocean-city 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.4 Status: Open Resolution: None Priority: 7 Submitted By: Hirokazu Yamamoto (ocean-city) Assigned to: Walter D?rwald (doerwalter) 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: Hirokazu Yamamoto (ocean-city) Date: 2006-03-27 16: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 14: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-27 06: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 23:02 Message: Logged In: YES user_id=1200846 OK, I'll try. ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2006-03-24 06: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 11: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 23: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 19: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 19: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 18: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 18: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 16: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 Mon Mar 27 18:06:20 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 27 Mar 2006 08:06:20 -0800 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 doerwalter 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.4 Status: Open Resolution: None Priority: 7 Submitted By: Hirokazu Yamamoto (ocean-city) Assigned to: Walter D?rwald (doerwalter) 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: 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 Mon Mar 27 19:25:38 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 27 Mar 2006 09:25:38 -0800 Subject: [Patches] [ python-Patches-1454844 ] Use dlopen() to load extensions on Darwin, where possible Message-ID: Patches item #1454844, was opened at 2006-03-20 20:41 Message generated for change (Comment added) made by ronaldoussoren You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1454844&group_id=5470 Please note that this 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: Zach Pincus (zpincus) Assigned to: Nobody/Anonymous (nobody) Summary: Use dlopen() to load extensions on Darwin, where possible Initial Comment: Here is a patch to make Python on OS X 10.3 and above use dlopen() (via dynload_shlib.c) to load extension modules, and to make the dl module avaliable. The patch was generated against the SVN head as of yesterday, but can be applied (and I have done so with success) to Python 2.4.2. RATIONALE --------- On most unix-like operating systems, Python uses the dlopen() call to load extension modules. In addition, the way that these modules are opened can be modified via 'sys.setdlopenflags(...)'. Modifications of how extensions are loaded are useful for several reasons (enough so that the standard Python docs (e.g. http:// docs.python.org/lib/module-sys.html ). In particular, if multiple modules need to share symbols, a call to sys.setdlopenflags is necessary. Symbol sharing is especially important for interoperability of modules which wrap C++ classes, because GCC creates classes that resolve their run-time type identification by symbol identity. Thus, symbols must be shared globally for many C++ features to work properly for objects passed between modules. On OS X / Darwin, Python uses some NeXT-derived APIs to load modules. Though these APIs provide analogues to the dlopenflags used to control how dlopen() loads modules, this interface is *not* exposed to the Python interpreter. Worse, sys.setdlopenflags remains available on Darwin, though calls to it are never heeded. Fortunately, on OS X 10.3 and above, Apple has included dlopen as a standard function. In 10.3, this call is provided by a compatibility API; in 10.4, the dlopen() call is written to interface directly with the library loading mechanism and is now the recommended method for libraries to be opened for non Carbon/Cocoa tools. IMPLEMENTATION -------------- This (trivial) patch instructs the Python build process to use dynload_shlib.c (which uses dlopen) instead of dynload_next.c (which uses the NeXT-derived APIs). It also allows for the dl module to be built in order to provide access to the proper values for the various dlopen flags. TESTING ------- This patch can be configured and built into executables that build and test correctly on 10.3 and 10.4. Because Python 2.5 and 2.4 do not currently compile properly on OS X 10.2, I have not built or tested this patch on that OS version. However, the configure and compile process does select the appropriate dynload_next.c file to use, and compiles that correctly before breaking elsewhere. Thus, if the other errors are fixed for 10.2, these patches will work fine. (This is because they only change Python's behavior for 10.3 and up.) PATCHES ------- There are three main components to the attached patch. The first is a patch the 'configure.in' file to use dynload_shlib.c when it can, and a patch to the 'configure' file to sync it up with 'configure.in'. The second is a minor change to 'setup.py' and the dl module test to allow the dl module to be built and tested on OS X systems where dlfcn is available. (10.3 and above.) The last part of the patchfile should be considered optional. This patch applies to 'Lib/test/regrtest.py', and it tells the testing suite that the dl test is not expected to be skipped anymore. This is optional because if Python is ever built on 10.2, the test script will expect dl to work, when it only works on 10.3 and above. However, if Python on 10.2 is officially not supported, then this change should be made to properly test the dl functionality on all supported OS X platforms. ---------------------------------------------------------------------- Comment By: Ronald Oussoren (ronaldoussoren) Date: 2006-03-27 19:25 Message: Logged In: YES user_id=580910 I have a number of questions. Firstly, how does symbol sharing between extensions work on windows? And more importantly, have you checked if this will break existing python code? ---------------------------------------------------------------------- Comment By: Zach Pincus (zpincus) Date: 2006-03-22 09:34 Message: Logged In: YES user_id=748718 I just uploaded a new patch which addresses this issue, and fixes this same problem in a few other locations in the configure script. ---------------------------------------------------------------------- Comment By: Andrew Barnert (barnert) Date: 2006-03-22 03:31 Message: Logged In: YES user_id=1473180 One minor issue: Your pattern will match Darwin 10.0, which will come out in a few years as part of OS X 10.7, by which time nobody will remember why this script is written this way. Since it's easy to handle now, we might as well do so. On a side note, there are no 2.x-4.x versions (1.5 was renamed 5.1), so anyone who matches Darwin/2.* will be a false match. Here's what I'd suggest: + Darwin/[0156]\..*) DYNLOADFILE="dynload_next.o";; Meanwhile, your patch seems to work for me on an Intel iMac, but I haven't tried anything too sophisticated. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1454844&group_id=5470 From noreply at sourceforge.net Mon Mar 27 19:40:52 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 27 Mar 2006 09:40:52 -0800 Subject: [Patches] [ python-Patches-1459476 ] Install PKG-INFO with packages Message-ID: Patches item #1459476, was opened at 2006-03-27 17:40 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1459476&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Distutils and setup.py Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: Phillip J. Eby (pje) Assigned to: Guido van Rossum (gvanrossum) Summary: Install PKG-INFO with packages Initial Comment: This patch adds an 'install_egg_info' command to the distutils install process, that writes the standard PKG-INFO metadata to a file in the directory where the associated modules are being installed. The filename is based on setuptools' conventions for reading and writing such files, so that setuptools will be able to recognize distutils-installed packages as being present, and not attempt to reinstall them if they are sufficient to meet a requested dependency. As currently implemented, Python's main setup.py causes a Python-2.5a0-py2.5.egg-info to be installed in lib-dynload. It would probably be best if it also created similar files for ElementTree, ctypes, and any other packages incorporated into 2.4 or 2.5 that were separately distributed for Python 2.3. But that feature doesn't have to be in alpha 1. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1459476&group_id=5470 From noreply at sourceforge.net Mon Mar 27 20:40:59 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 27 Mar 2006 10:40:59 -0800 Subject: [Patches] [ python-Patches-1454844 ] Use dlopen() to load extensions on Darwin, where possible Message-ID: Patches item #1454844, was opened at 2006-03-20 19:41 Message generated for change (Comment added) made by zpincus You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1454844&group_id=5470 Please note that this 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: Zach Pincus (zpincus) Assigned to: Nobody/Anonymous (nobody) Summary: Use dlopen() to load extensions on Darwin, where possible Initial Comment: Here is a patch to make Python on OS X 10.3 and above use dlopen() (via dynload_shlib.c) to load extension modules, and to make the dl module avaliable. The patch was generated against the SVN head as of yesterday, but can be applied (and I have done so with success) to Python 2.4.2. RATIONALE --------- On most unix-like operating systems, Python uses the dlopen() call to load extension modules. In addition, the way that these modules are opened can be modified via 'sys.setdlopenflags(...)'. Modifications of how extensions are loaded are useful for several reasons (enough so that the standard Python docs (e.g. http:// docs.python.org/lib/module-sys.html ). In particular, if multiple modules need to share symbols, a call to sys.setdlopenflags is necessary. Symbol sharing is especially important for interoperability of modules which wrap C++ classes, because GCC creates classes that resolve their run-time type identification by symbol identity. Thus, symbols must be shared globally for many C++ features to work properly for objects passed between modules. On OS X / Darwin, Python uses some NeXT-derived APIs to load modules. Though these APIs provide analogues to the dlopenflags used to control how dlopen() loads modules, this interface is *not* exposed to the Python interpreter. Worse, sys.setdlopenflags remains available on Darwin, though calls to it are never heeded. Fortunately, on OS X 10.3 and above, Apple has included dlopen as a standard function. In 10.3, this call is provided by a compatibility API; in 10.4, the dlopen() call is written to interface directly with the library loading mechanism and is now the recommended method for libraries to be opened for non Carbon/Cocoa tools. IMPLEMENTATION -------------- This (trivial) patch instructs the Python build process to use dynload_shlib.c (which uses dlopen) instead of dynload_next.c (which uses the NeXT-derived APIs). It also allows for the dl module to be built in order to provide access to the proper values for the various dlopen flags. TESTING ------- This patch can be configured and built into executables that build and test correctly on 10.3 and 10.4. Because Python 2.5 and 2.4 do not currently compile properly on OS X 10.2, I have not built or tested this patch on that OS version. However, the configure and compile process does select the appropriate dynload_next.c file to use, and compiles that correctly before breaking elsewhere. Thus, if the other errors are fixed for 10.2, these patches will work fine. (This is because they only change Python's behavior for 10.3 and up.) PATCHES ------- There are three main components to the attached patch. The first is a patch the 'configure.in' file to use dynload_shlib.c when it can, and a patch to the 'configure' file to sync it up with 'configure.in'. The second is a minor change to 'setup.py' and the dl module test to allow the dl module to be built and tested on OS X systems where dlfcn is available. (10.3 and above.) The last part of the patchfile should be considered optional. This patch applies to 'Lib/test/regrtest.py', and it tells the testing suite that the dl test is not expected to be skipped anymore. This is optional because if Python is ever built on 10.2, the test script will expect dl to work, when it only works on 10.3 and above. However, if Python on 10.2 is officially not supported, then this change should be made to properly test the dl functionality on all supported OS X platforms. ---------------------------------------------------------------------- >Comment By: Zach Pincus (zpincus) Date: 2006-03-27 18:40 Message: Logged In: YES user_id=748718 Ronald - I am unfortunately not an expert on windows DLL loading. I do know that in non-GCC C++ implementations, it becomes far less critical to share symbols globally in many circumstances, because non-GCC C++ implementations tend to use string comparisons to resolve C++ object identity, and not use exact address comparisons on the typeinfo objects. Thus, these objects do not need to be shared between windows DLLs. Beyond that, I do not know whether symbols from DLLs are loaded with global visibility in windows or not. Certainly the windows dlopen() equivalent *does not* support mode options. I presume anything tagged with _declspec (dllexport) is loaded globally when the DLL is opened, but I am not sure. However, that issue is largely tangential to the question of whether Python on OS X should work like Python on every other Unix-like system... As to your other question -- have I checked if this will break existing python code -- the answer is of course yes. The python regression suite test passes on both 10.3 and 10.4 with this modification (as I mentioned), so that's a good indication that run-of-the-mill code will not be affected. In fact, on 10.3, the dlopen() call is implemented under the hood with the exact same calls that Python's dynload_next.c file uses. In 10.4 this was changed so that both APIs talk to the same underlying system. Thus, nothing is really changing: both are functionally identical ways of getting the same OS X runtime loader (dyld) to load a bundle from disk. The only difference is that by using dlopen(), there are hooks in Python for manipulating the mode that is used to load that bundle from disk. So, I cannot imagine a situation where this change would break code on the mac. While argument from failure of imagination is typically weak, this combined with the fact that the python tests pass without difficulty (including the dl module test), I am fairy confident in this patch. Moreover, I have been using this patch on my own computer for some time and have not run into any difficulties, even when loading fairly complex custom extensions. Finally, this patch *only* modifies the codepath on Darwin/OS X, so there's zero possibility that it would affect anything on other platforms. ---------------------------------------------------------------------- Comment By: Ronald Oussoren (ronaldoussoren) Date: 2006-03-27 17:25 Message: Logged In: YES user_id=580910 I have a number of questions. Firstly, how does symbol sharing between extensions work on windows? And more importantly, have you checked if this will break existing python code? ---------------------------------------------------------------------- Comment By: Zach Pincus (zpincus) Date: 2006-03-22 08:34 Message: Logged In: YES user_id=748718 I just uploaded a new patch which addresses this issue, and fixes this same problem in a few other locations in the configure script. ---------------------------------------------------------------------- Comment By: Andrew Barnert (barnert) Date: 2006-03-22 02:31 Message: Logged In: YES user_id=1473180 One minor issue: Your pattern will match Darwin 10.0, which will come out in a few years as part of OS X 10.7, by which time nobody will remember why this script is written this way. Since it's easy to handle now, we might as well do so. On a side note, there are no 2.x-4.x versions (1.5 was renamed 5.1), so anyone who matches Darwin/2.* will be a false match. Here's what I'd suggest: + Darwin/[0156]\..*) DYNLOADFILE="dynload_next.o";; Meanwhile, your patch seems to work for me on an Intel iMac, but I haven't tried anything too sophisticated. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1454844&group_id=5470 From noreply at sourceforge.net Mon Mar 27 20:52:14 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 27 Mar 2006 10:52:14 -0800 Subject: [Patches] [ python-Patches-1435422 ] Add copy() method to zlib's compress and decompress objects Message-ID: Patches item #1435422, was opened at 2006-02-20 15:17 Message generated for change (Comment added) made by catlee You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1435422&group_id=5470 Please note that this 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: Chris AtLee (catlee) Assigned to: Nobody/Anonymous (nobody) Summary: Add copy() method to zlib's compress and decompress objects Initial Comment: The attached patch adds a copy() method to zlib's compressobj and decompressobj. Copying a (de)compression object allows a developer to store the state of the (de)compressor at a certain point of the input stream in order to more efficiently compress data sharing some identical header, or to more efficiently seek inside compressed data. Doc/lib/libzlib.tex is updated with descriptions for the new methods. Lib/test/test_zlib.py is updated to test the new functionality. The patch is against revision 42524 in http://svn.python.org/projects/python/trunk ---------------------------------------------------------------------- >Comment By: Chris AtLee (catlee) Date: 2006-03-27 13:52 Message: Logged In: YES user_id=186532 New patch attached with the mentioned changes made. I noticed that PyZlib_unflush() takes an argument, but that its use is not documented. Should the docs be updated to explain what that argument is for? ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2006-03-24 01:02 Message: Logged In: YES user_id=33168 You need to check the return result of newcompobject(). This would crash if it returns NULL. You also need to change METH_VARARGS to METH_NOARGS since these methods don't take any arguments. The doc should contain \versionadded{2.5} before the end markers for new methods. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1435422&group_id=5470 From noreply at sourceforge.net Mon Mar 27 20:56:30 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 27 Mar 2006 10:56:30 -0800 Subject: [Patches] [ python-Patches-1435422 ] Add copy() method to zlib's compress and decompress objects Message-ID: Patches item #1435422, was opened at 2006-02-20 12:17 Message generated for change (Comment added) made by nnorwitz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1435422&group_id=5470 Please note that this 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: Chris AtLee (catlee) Assigned to: Nobody/Anonymous (nobody) Summary: Add copy() method to zlib's compress and decompress objects Initial Comment: The attached patch adds a copy() method to zlib's compressobj and decompressobj. Copying a (de)compression object allows a developer to store the state of the (de)compressor at a certain point of the input stream in order to more efficiently compress data sharing some identical header, or to more efficiently seek inside compressed data. Doc/lib/libzlib.tex is updated with descriptions for the new methods. Lib/test/test_zlib.py is updated to test the new functionality. The patch is against revision 42524 in http://svn.python.org/projects/python/trunk ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2006-03-27 10:56 Message: Logged In: YES user_id=33168 Yes, please fix any docs you find lacking. Also, please create a new patch. Thanks! ---------------------------------------------------------------------- Comment By: Chris AtLee (catlee) Date: 2006-03-27 10:52 Message: Logged In: YES user_id=186532 New patch attached with the mentioned changes made. I noticed that PyZlib_unflush() takes an argument, but that its use is not documented. Should the docs be updated to explain what that argument is for? ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2006-03-23 22:02 Message: Logged In: YES user_id=33168 You need to check the return result of newcompobject(). This would crash if it returns NULL. You also need to change METH_VARARGS to METH_NOARGS since these methods don't take any arguments. The doc should contain \versionadded{2.5} before the end markers for new methods. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1435422&group_id=5470 From noreply at sourceforge.net Mon Mar 27 22:59:03 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 27 Mar 2006 12:59:03 -0800 Subject: [Patches] [ python-Patches-1444398 ] Make itertools.tee participate in GC Message-ID: Patches item #1444398, was opened at 2006-03-06 21:33 Message generated for change (Comment added) made by twouters You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1444398&group_id=5470 Please note that this 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: Thomas Wouters (twouters) >Assigned to: Thomas Wouters (twouters) Summary: Make itertools.tee participate in GC Initial Comment: A small patch to make itertools.tee objects participate in GC; solves the memoryleak in test_generators (and any other use of tee objects in cycles.) ---------------------------------------------------------------------- >Comment By: Thomas Wouters (twouters) Date: 2006-03-27 22:59 Message: Logged In: YES user_id=34209 Hmm. Well, adding PyObject_GC_Track() makes GC work right. I don't know why, since the rest of itertools doesn't use PyObject_GC_Track, but it now fixes refleaks that involve just itertools, like: def leak(): class gen: def __iter__(self): return self def next(self): return self.item g = gen() head, tail = tee(g) g.item = head This example leaked without tee doing GC (and without PyObject_GC_Track), but doesn't leak with proper GC. However! test_generators still leaks, and so does this example (which doesn't use itertools): def leak(): def gen(): while True: yield g g = gen() g.next() I suspect this leak was introduced after I submitted this patch, which explains why this patch suddenly stopped working ;) Since adding GC still fixes reference-cycles, I will check in this patch while I hunt for the other leak. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2006-03-25 18:14 Message: Logged In: YES user_id=80475 In teedataobject_new(), try adding PyObject_GC_Track(tdo) just before the return statement. ---------------------------------------------------------------------- Comment By: Thomas Wouters (twouters) Date: 2006-03-25 17:39 Message: Logged In: YES user_id=34209 I cleaned up my patch (attached), but for some reason, it isn't resolving the refleaks in test_generators. I swear my patch was resolving them before, but I guess I must've done something else (maybe in addition to this) that fixed the leaks. Or maybe I'm just going cross-eyed. I do believe I implemented GC correctly, and I do believe the leaks are uncleanable circular references. I haven't had time to debug it more; if someone else wants to, feel free. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2006-03-25 17:17 Message: Logged In: YES user_id=80475 Georg, do you have time to fix-up this patch and check it in? ---------------------------------------------------------------------- Comment By: Thomas Wouters (twouters) Date: 2006-03-20 22:34 Message: Logged In: YES user_id=34209 Hmm. An alternative fix would be to make itertools.tee only partially participate in GC. That is, not have it traverse over all the stored items, but just the iterator. It would prevent the (potentially rather heavy) cost of going over all cached items, but still leaves a potential for unfindable cycles. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2006-03-19 09:02 Message: Logged In: YES user_id=80475 Okay, go ahead and add GC to itertools.tee(). The test_generators examples make it clear that there are valid use cases for feeding a teeobject back into itself. Tim, the original rationale did not have to do with millions of tee objects; rather, it posited that a tee could contain many objects of some other type and that traversing it during GC was simply a waste of time. Thomas, the patch needs work, but I don't currently have time to go through it. Do your best to model after the other tools which have gc. That includes setting the tp_flags slot, doing an untrack before dealloc starts, replacing PyObject_Del and PyObject_New with their GC counterparts. See section 2.1.3 in Extending and Embedding for the details and examples. Offhand, I think it may also need a tp_clear entry but I'm not sure. If you can work out a good patch, go ahead an apply it for the alpha 1 release. If not, assign back to me and I'll get to it when I can (possibly for the second alpha). ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2006-03-07 01:52 Message: Logged In: YES user_id=31435 If there are likely to be millions of some type of object, then avoiding gc for that type on grounds of reducing memory use may be arguable (or, as in the cases of tuples or lists, may not be arguable regardless). Else "if it points to a PyObject, it might be in a cycle, so gc-enable it" generally rules. I'll note in passing that the m235 and fib generators weren't _intended_ to stress Python in any way, but have been extremely effective at doing so since generators first went in. Think of them as a pair of canaries in the coal mine :-) ---------------------------------------------------------------------- Comment By: Thomas Wouters (twouters) Date: 2006-03-07 01:12 Message: Logged In: YES user_id=34209 Well, I'm fine with removing the scope-enclosed generator versions of _m235() and fib() from test_generators, if that's what you're implying. :> However, I think it's slightly more suitable to just have tee participate in GC. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2006-03-07 01:05 Message: Logged In: YES user_id=80475 I will take a look at the patch soon. IIRC, there was a concious decision to not have tee engage in GC because no normal use cases created cycles (they seem to arise only when intentionally creating a cycle for test code). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1444398&group_id=5470 From noreply at sourceforge.net Mon Mar 27 23:02:48 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 27 Mar 2006 13:02:48 -0800 Subject: [Patches] [ python-Patches-1444398 ] Make itertools.tee participate in GC Message-ID: Patches item #1444398, was opened at 2006-03-06 21:33 Message generated for change (Settings changed) made by twouters You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1444398&group_id=5470 Please note that this 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: Fixed Priority: 5 Submitted By: Thomas Wouters (twouters) Assigned to: Thomas Wouters (twouters) Summary: Make itertools.tee participate in GC Initial Comment: A small patch to make itertools.tee objects participate in GC; solves the memoryleak in test_generators (and any other use of tee objects in cycles.) ---------------------------------------------------------------------- Comment By: Thomas Wouters (twouters) Date: 2006-03-27 22:59 Message: Logged In: YES user_id=34209 Hmm. Well, adding PyObject_GC_Track() makes GC work right. I don't know why, since the rest of itertools doesn't use PyObject_GC_Track, but it now fixes refleaks that involve just itertools, like: def leak(): class gen: def __iter__(self): return self def next(self): return self.item g = gen() head, tail = tee(g) g.item = head This example leaked without tee doing GC (and without PyObject_GC_Track), but doesn't leak with proper GC. However! test_generators still leaks, and so does this example (which doesn't use itertools): def leak(): def gen(): while True: yield g g = gen() g.next() I suspect this leak was introduced after I submitted this patch, which explains why this patch suddenly stopped working ;) Since adding GC still fixes reference-cycles, I will check in this patch while I hunt for the other leak. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2006-03-25 18:14 Message: Logged In: YES user_id=80475 In teedataobject_new(), try adding PyObject_GC_Track(tdo) just before the return statement. ---------------------------------------------------------------------- Comment By: Thomas Wouters (twouters) Date: 2006-03-25 17:39 Message: Logged In: YES user_id=34209 I cleaned up my patch (attached), but for some reason, it isn't resolving the refleaks in test_generators. I swear my patch was resolving them before, but I guess I must've done something else (maybe in addition to this) that fixed the leaks. Or maybe I'm just going cross-eyed. I do believe I implemented GC correctly, and I do believe the leaks are uncleanable circular references. I haven't had time to debug it more; if someone else wants to, feel free. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2006-03-25 17:17 Message: Logged In: YES user_id=80475 Georg, do you have time to fix-up this patch and check it in? ---------------------------------------------------------------------- Comment By: Thomas Wouters (twouters) Date: 2006-03-20 22:34 Message: Logged In: YES user_id=34209 Hmm. An alternative fix would be to make itertools.tee only partially participate in GC. That is, not have it traverse over all the stored items, but just the iterator. It would prevent the (potentially rather heavy) cost of going over all cached items, but still leaves a potential for unfindable cycles. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2006-03-19 09:02 Message: Logged In: YES user_id=80475 Okay, go ahead and add GC to itertools.tee(). The test_generators examples make it clear that there are valid use cases for feeding a teeobject back into itself. Tim, the original rationale did not have to do with millions of tee objects; rather, it posited that a tee could contain many objects of some other type and that traversing it during GC was simply a waste of time. Thomas, the patch needs work, but I don't currently have time to go through it. Do your best to model after the other tools which have gc. That includes setting the tp_flags slot, doing an untrack before dealloc starts, replacing PyObject_Del and PyObject_New with their GC counterparts. See section 2.1.3 in Extending and Embedding for the details and examples. Offhand, I think it may also need a tp_clear entry but I'm not sure. If you can work out a good patch, go ahead an apply it for the alpha 1 release. If not, assign back to me and I'll get to it when I can (possibly for the second alpha). ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2006-03-07 01:52 Message: Logged In: YES user_id=31435 If there are likely to be millions of some type of object, then avoiding gc for that type on grounds of reducing memory use may be arguable (or, as in the cases of tuples or lists, may not be arguable regardless). Else "if it points to a PyObject, it might be in a cycle, so gc-enable it" generally rules. I'll note in passing that the m235 and fib generators weren't _intended_ to stress Python in any way, but have been extremely effective at doing so since generators first went in. Think of them as a pair of canaries in the coal mine :-) ---------------------------------------------------------------------- Comment By: Thomas Wouters (twouters) Date: 2006-03-07 01:12 Message: Logged In: YES user_id=34209 Well, I'm fine with removing the scope-enclosed generator versions of _m235() and fib() from test_generators, if that's what you're implying. :> However, I think it's slightly more suitable to just have tee participate in GC. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2006-03-07 01:05 Message: Logged In: YES user_id=80475 I will take a look at the patch soon. IIRC, there was a concious decision to not have tee engage in GC because no normal use cases created cycles (they seem to arise only when intentionally creating a cycle for test code). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1444398&group_id=5470 From noreply at sourceforge.net Mon Mar 27 23:33:04 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 27 Mar 2006 13:33:04 -0800 Subject: [Patches] [ python-Patches-1459630 ] Add docs for zlib.decompressobj.flush optional param Message-ID: Patches item #1459630, was opened at 2006-03-27 16: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=1459630&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Documentation Group: None Status: Open Resolution: None Priority: 5 Submitted By: Chris AtLee (catlee) Assigned to: Nobody/Anonymous (nobody) Summary: Add docs for zlib.decompressobj.flush optional param Initial Comment: zlib.decompressobj's flush method takes an optional length parameter. This patch adds documentation for that parameter. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1459630&group_id=5470 From noreply at sourceforge.net Mon Mar 27 23:35:02 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 27 Mar 2006 13:35:02 -0800 Subject: [Patches] [ python-Patches-1459631 ] Update docs for zlib.decompressobj.flush() Message-ID: Patches item #1459631, was opened at 2006-03-27 16: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=1459631&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Documentation Group: None Status: Open Resolution: None Priority: 5 Submitted By: Chris AtLee (catlee) Assigned to: Nobody/Anonymous (nobody) Summary: Update docs for zlib.decompressobj.flush() Initial Comment: zlib.decompressobj's flush method takes an optional length parameter. This patch adds documentation for that parameter. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1459631&group_id=5470 From noreply at sourceforge.net Mon Mar 27 23:38:02 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 27 Mar 2006 13:38:02 -0800 Subject: [Patches] [ python-Patches-1459630 ] Add docs for zlib.decompressobj.flush optional param Message-ID: Patches item #1459630, was opened at 2006-03-27 16:33 Message generated for change (Comment added) made by catlee You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1459630&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Documentation Group: None Status: Open Resolution: None Priority: 5 Submitted By: Chris AtLee (catlee) Assigned to: Nobody/Anonymous (nobody) Summary: Add docs for zlib.decompressobj.flush optional param Initial Comment: zlib.decompressobj's flush method takes an optional length parameter. This patch adds documentation for that parameter. ---------------------------------------------------------------------- >Comment By: Chris AtLee (catlee) Date: 2006-03-27 16:38 Message: Logged In: YES user_id=186532 Sorry, please use patch #1459631. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1459630&group_id=5470 From noreply at sourceforge.net Mon Mar 27 23:39:32 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 27 Mar 2006 13:39:32 -0800 Subject: [Patches] [ python-Patches-1459476 ] Install PKG-INFO with packages Message-ID: Patches item #1459476, was opened at 2006-03-27 12:40 Message generated for change (Comment added) made by gvanrossum You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1459476&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Distutils and setup.py Group: Python 2.5 Status: Open >Resolution: Accepted Priority: 5 Submitted By: Phillip J. Eby (pje) >Assigned to: Phillip J. Eby (pje) Summary: Install PKG-INFO with packages Initial Comment: This patch adds an 'install_egg_info' command to the distutils install process, that writes the standard PKG-INFO metadata to a file in the directory where the associated modules are being installed. The filename is based on setuptools' conventions for reading and writing such files, so that setuptools will be able to recognize distutils-installed packages as being present, and not attempt to reinstall them if they are sufficient to meet a requested dependency. As currently implemented, Python's main setup.py causes a Python-2.5a0-py2.5.egg-info to be installed in lib-dynload. It would probably be best if it also created similar files for ElementTree, ctypes, and any other packages incorporated into 2.4 or 2.5 that were separately distributed for Python 2.3. But that feature doesn't have to be in alpha 1. ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2006-03-27 16:39 Message: Logged In: YES user_id=6380 Looks fine to me. Just trim the trailing blank lines and add a module-level docstring (look at the other install_*.py files for examples). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1459476&group_id=5470 From noreply at sourceforge.net Mon Mar 27 23:41:34 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 27 Mar 2006 13:41:34 -0800 Subject: [Patches] [ python-Patches-1458476 ] Improved PySet C API Message-ID: Patches item #1458476, was opened at 2006-03-25 17:48 Message generated for change (Comment added) made by gvanrossum You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1458476&group_id=5470 Please note that this 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: Barry A. Warsaw (bwarsaw) Assigned to: Guido van Rossum (gvanrossum) Summary: Improved PySet C API Initial Comment: This patch adds PySet_Next(), PySet_Update(), and PySet_Clear(), three very useful API calls when you're dealing with concrete PySet objects. Patch includes tests and documentation. ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2006-03-27 16:41 Message: Logged In: YES user_id=6380 I'm rejecting this unread, because I'm not ready to jump into this issue. The discussion should continue without me. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2006-03-26 00:41 Message: Logged In: YES user_id=80475 FWIW, I'm open to PyObject_Clear() for an abstract access to the tp_clear slot. Also, for Barry's use only, I'm open to a semi-private _PySet_Next() that isn't part of the official API but gives a Barry-specific hook. It should not be a public function because of all the problems with the approach. Likewise, _PySet_Update() could be done just for Barry's group. I need to keep PySet_Update() open until Py2.6 since the API may evolve to allow a variable length argument list. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2006-03-25 18:56 Message: Logged In: YES user_id=80475 Guido, please reject this patch. I laid-out my reasoning in these two posts: http://mail.python.org/pipermail/python-dev/2006- March/062652.html http://mail.python.org/pipermail/python-dev/2006- March/062737.html In particular, I've found PySet_Next() to be disasterously error-prone (and have had to fix several hard-to-find bugs directly attributable this function). There was some need for it in the PyDict API because it fetched key and value pointers at the same time and allowed direct modification of values. This of course does not apply to sets which do not have a value field. The PySet_Clear() function should be PyObject_Clear() like other functions that have tp_slots. There is no more of a case for this function than there would be for PySet_Repr, PySet_Len, PySet_IsTrue, or PySet_Print. The PySet_Update() function gets in the way of my future development plans for this module. None of these functions are necessary. They simply reflect Barry's programming style and views on having fat, overly-concrete APIs. This patch is against my wishes for the module. As the module author and principal maintainer, if I still have a say in the module's development, I strongly prefer rejection of this patch. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1458476&group_id=5470 From noreply at sourceforge.net Mon Mar 27 23:46:39 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 27 Mar 2006 13:46:39 -0800 Subject: [Patches] [ python-Patches-1435422 ] Add copy() method to zlib's compress and decompress objects Message-ID: Patches item #1435422, was opened at 2006-02-20 15:17 Message generated for change (Comment added) made by catlee You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1435422&group_id=5470 Please note that this 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: Chris AtLee (catlee) Assigned to: Nobody/Anonymous (nobody) Summary: Add copy() method to zlib's compress and decompress objects Initial Comment: The attached patch adds a copy() method to zlib's compressobj and decompressobj. Copying a (de)compression object allows a developer to store the state of the (de)compressor at a certain point of the input stream in order to more efficiently compress data sharing some identical header, or to more efficiently seek inside compressed data. Doc/lib/libzlib.tex is updated with descriptions for the new methods. Lib/test/test_zlib.py is updated to test the new functionality. The patch is against revision 42524 in http://svn.python.org/projects/python/trunk ---------------------------------------------------------------------- >Comment By: Chris AtLee (catlee) Date: 2006-03-27 16:46 Message: Logged In: YES user_id=186532 Patch for the unflush() docs is uploaded as #1459631 ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2006-03-27 13:56 Message: Logged In: YES user_id=33168 Yes, please fix any docs you find lacking. Also, please create a new patch. Thanks! ---------------------------------------------------------------------- Comment By: Chris AtLee (catlee) Date: 2006-03-27 13:52 Message: Logged In: YES user_id=186532 New patch attached with the mentioned changes made. I noticed that PyZlib_unflush() takes an argument, but that its use is not documented. Should the docs be updated to explain what that argument is for? ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2006-03-24 01:02 Message: Logged In: YES user_id=33168 You need to check the return result of newcompobject(). This would crash if it returns NULL. You also need to change METH_VARARGS to METH_NOARGS since these methods don't take any arguments. The doc should contain \versionadded{2.5} before the end markers for new methods. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1435422&group_id=5470 From noreply at sourceforge.net Tue Mar 28 00:35:03 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 27 Mar 2006 14:35:03 -0800 Subject: [Patches] [ python-Patches-1459630 ] Add docs for zlib.decompressobj.flush optional param Message-ID: Patches item #1459630, was opened at 2006-03-27 21:33 Message generated for change (Settings changed) made by gbrandl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1459630&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Documentation Group: None >Status: Closed >Resolution: Duplicate Priority: 5 Submitted By: Chris AtLee (catlee) Assigned to: Nobody/Anonymous (nobody) Summary: Add docs for zlib.decompressobj.flush optional param Initial Comment: zlib.decompressobj's flush method takes an optional length parameter. This patch adds documentation for that parameter. ---------------------------------------------------------------------- Comment By: Chris AtLee (catlee) Date: 2006-03-27 21:38 Message: Logged In: YES user_id=186532 Sorry, please use patch #1459631. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1459630&group_id=5470 From noreply at sourceforge.net Tue Mar 28 06:29:37 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 27 Mar 2006 20:29:37 -0800 Subject: [Patches] [ python-Patches-1221598 ] ftplib storbinary/storlines callback function Message-ID: Patches item #1221598, was opened at 2005-06-15 16:15 Message generated for change (Settings changed) made by phil_schwartz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1221598&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Modules Group: Python 2.4 Status: Open Resolution: None >Priority: 7 Submitted By: Phil Schwartz (phil_schwartz) Assigned to: Nobody/Anonymous (nobody) Summary: ftplib storbinary/storlines callback function Initial Comment: The ftplib.FTP class currently allows the ability to provide a callback function for the retrbinary & retrlines methods to invoke. However, the corresponding storbinary and storlines methods do not. My ReleaseForge application currently uses the ftplib to send files (rather than retrieve) and it's helpful to know the percentage of the file that has been sent. For my app I subclassed ftplib.FTP and reimplemented storbinary to optionally accept a callback function as a parameter. However, I think this would be a useful method to include in the standard python distribution. I've attached a modified version of ftplib.py which adds this functionality. Unlike the retrX methods, the storX methods only invoke the callback function if it's not None so that it will not interfere with existing code. For completeness, the retrX methods invoke print_line if a callback function is not provided and doing so for the storX functions may be undesired. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1221598&group_id=5470 From noreply at sourceforge.net Tue Mar 28 09:52:40 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 27 Mar 2006 23:52:40 -0800 Subject: [Patches] [ python-Patches-1221598 ] ftplib storbinary/storlines callback function Message-ID: Patches item #1221598, was opened at 2005-06-15 23:15 Message generated for change (Comment added) made by gbrandl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1221598&group_id=5470 Please note that this 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: Phil Schwartz (phil_schwartz) Assigned to: Nobody/Anonymous (nobody) Summary: ftplib storbinary/storlines callback function Initial Comment: The ftplib.FTP class currently allows the ability to provide a callback function for the retrbinary & retrlines methods to invoke. However, the corresponding storbinary and storlines methods do not. My ReleaseForge application currently uses the ftplib to send files (rather than retrieve) and it's helpful to know the percentage of the file that has been sent. For my app I subclassed ftplib.FTP and reimplemented storbinary to optionally accept a callback function as a parameter. However, I think this would be a useful method to include in the standard python distribution. I've attached a modified version of ftplib.py which adds this functionality. Unlike the retrX methods, the storX methods only invoke the callback function if it's not None so that it will not interfere with existing code. For completeness, the retrX methods invoke print_line if a callback function is not provided and doing so for the storX functions may be undesired. ---------------------------------------------------------------------- >Comment By: Georg Brandl (gbrandl) Date: 2006-03-28 07:52 Message: Logged In: YES user_id=849994 Please provide your patch as a diff between the original ftplib.py and your version. It greatly helps reviewers. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1221598&group_id=5470 From noreply at sourceforge.net Tue Mar 28 10:16:14 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 28 Mar 2006 00:16:14 -0800 Subject: [Patches] [ python-Patches-1455898 ] patch for mbcs codecs Message-ID: Patches item #1455898, was opened at 2006-03-22 16:31 Message generated for change (Comment added) made by ocean-city 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.4 Status: Open Resolution: None Priority: 7 Submitted By: Hirokazu Yamamoto (ocean-city) Assigned to: Walter D?rwald (doerwalter) 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: Hirokazu Yamamoto (ocean-city) Date: 2006-03-28 17: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-28 01: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 16: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 14: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-27 06: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 23:02 Message: Logged In: YES user_id=1200846 OK, I'll try. ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2006-03-24 06: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 11: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 23: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 19: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 19: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 18: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 18: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 16: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 Tue Mar 28 11:17:50 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 28 Mar 2006 01:17:50 -0800 Subject: [Patches] [ python-Patches-1459867 ] convenient Message.as_string to use mangle_from_=unixfrom ? Message-ID: Patches item #1459867, was opened at 2006-03-28 11:17 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1459867&group_id=5470 Please note that this 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: kxroberto (kxroberto) Assigned to: Nobody/Anonymous (nobody) Summary: convenient Message.as_string to use mangle_from_=unixfrom ? Initial Comment: --> attachment It produced a message alteration by surprise for me (and maybe does regularly). Not sure but: Aren't UNIX mbox formates produced usually together with unixfrom=True? Also, when one wants to create UNIX mbox formats, one should take extra care using individual Generator's. The average .as_string() user maybe wants his message unaltered. Robert ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1459867&group_id=5470 From noreply at sourceforge.net Tue Mar 28 16:48:01 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 28 Mar 2006 06:48:01 -0800 Subject: [Patches] [ python-Patches-1459867 ] convenient Message.as_string to use mangle_from_=unixfrom ? Message-ID: Patches item #1459867, was opened at 2006-03-28 09:17 Message generated for change (Settings changed) made by gbrandl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1459867&group_id=5470 Please note that this 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: kxroberto (kxroberto) >Assigned to: Barry A. Warsaw (bwarsaw) Summary: convenient Message.as_string to use mangle_from_=unixfrom ? Initial Comment: --> attachment It produced a message alteration by surprise for me (and maybe does regularly). Not sure but: Aren't UNIX mbox formates produced usually together with unixfrom=True? Also, when one wants to create UNIX mbox formats, one should take extra care using individual Generator's. The average .as_string() user maybe wants his message unaltered. Robert ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1459867&group_id=5470 From noreply at sourceforge.net Tue Mar 28 17:08:59 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 28 Mar 2006 07:08:59 -0800 Subject: [Patches] [ python-Patches-1454485 ] patch for SIGSEGV in arraymodule.c Message-ID: Patches item #1454485, was opened at 2006-03-20 13:44 Message generated for change (Settings changed) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1454485&group_id=5470 Please note that this 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: 7 Submitted By: Baris Metin (tbmetin) >Assigned to: Neal Norwitz (nnorwitz) Summary: patch for SIGSEGV in arraymodule.c Initial Comment: Array module fails handling utf-8 strings giving a SIGSEGV. Attached patch seems to do the trick... gdb> run (no debugging symbols found) (no debugging symbols found) [Thread debugging using libthread_db enabled] [New Thread -1480337216 (LWP 31303)] Python 2.4.2 (#1, Mar 20 2006, 12:08:06) [GCC 3.4.5] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> import array >>> x = array.array("u") >>> x.append(u"bar????") Traceback (most recent call last): File "", line 1, in ? TypeError: array item must be unicode character >>> x.append("bar????") >>> x Program received signal SIGSEGV, Segmentation fault. [Switching to Thread -1480337216 (LWP 31303)] Error while running hook_stop: Invalid type combination in ordering comparison. 0xa7ee0799 in PyUnicodeUCS4_FromUnicode () from /usr/lib/libpython2.4.so.1.0 ---------------------------------------------------------------------- Comment By: Martin v. L??wis (loewis) Date: 2006-03-26 23:36 Message: Logged In: YES user_id=21627 The second part of the patch (checking that *u is not negative) is definitely right. The first part (requiring an even number of bytes for a u# argument) probably requires discussion on python-dev (or this patch should be assigned to MAL): I don't think it should be allowed to pass a non-Unicode object to u# in the first place. In particular, if you pass a byte string, there would be an implicit assumption that the byte encoding is the same internal representation as a Py_UNICODE. This is bad - Python normally assumes the encoding of a string is the system encoding, which normally is ASCII. Of course, changing the call to a type error for 2.4.3 probably won't work, either, because it might break existing code. Anyway, I believe the latter fix alone should fix the crash: the current getargs implementation will round down to the next multiple of sizeof(Py_UNICODE), thanks the integer division. u_setitem will then refuse the call if the length is not 1. IOW, it is possible to append between 4 and 7 bytes to a Unicode array. I wonder why the patch fixes the problem: *u should be an unsigned, and comparing an unsigned with a signed should convert the signed to unsigned, no? ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2006-03-25 08:29 Message: Logged In: YES user_id=33168 Verified for 2.4 and head. The probably could exist w/ucs2 also if you use 'bar' (I think). I agree with Nick, this patch doesn't really solve the problem. The attached patch fixes the crash more generally, but I'm think there is a better solution. I hope Martin has time to review this and suggest a better fix. Martin, the change in getargs ensures that we don't try to convert an 8-bit string of length 5 to unicode. The change in unicodeobject ensures that we don't reference the array with a negative offset as happens if the buffer conversion succeeds with an invalid unicode character. ---------------------------------------------------------------------- Comment By: Nick Coghlan (ncoghlan) Date: 2006-03-24 15:43 Message: Logged In: YES user_id=1038590 To get the effect of the patch, it should be sufficient to just change the format character to an uppercase U. That doesn't seem like the right fix though - the actual explosion isn't happening until later when the array elements are being converted to Unicode for output. ---------------------------------------------------------------------- Comment By: Baris Metin (tbmetin) Date: 2006-03-24 10:19 Message: Logged In: YES user_id=1045504 I'm able to reproduce the bug with 2.5a0 SVN (r43289). Please try with --enable-unicode=ucs4 The patch is against svn too.. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2006-03-24 07:11 Message: Logged In: YES user_id=33168 With the stock 2.4.2 on my linux box I was able to reproduce this. I couldn't reproduce with 2.4.3c1. Can you verify this is fixed in 2.4.3? Sagol. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1454485&group_id=5470 From noreply at sourceforge.net Wed Mar 29 09:30:08 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 28 Mar 2006 23:30:08 -0800 Subject: [Patches] [ python-Patches-1460496 ] give round() kwargs (mostly for PFAs) Message-ID: Patches item #1460496, was opened at 2006-03-28 23:30 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1460496&group_id=5470 Please note that this 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: Wesley J. Chun (wesc) Assigned to: Nobody/Anonymous (nobody) Summary: give round() kwargs (mostly for PFAs) Initial Comment: 1. WHAT this is a short non-critical patch to give round() keyword arguments for Partial Function Application (PEP309) purposes. 2. WHY arguments that appear on the RHS of function declarations are hard to call when using functional.partial because the "variable" argument is to the left (since PFAs pretty much favor only variable arguments to the right). if fixed arguments are to the right (are "curried"), then we need to support keyword args for them as much as possible to encourage their use. 3. MOTIVATION similar to the example in the Python Lib Ref doc page for the functional module and its use with int()... http://docs.python.org/dev/lib/module-functional.html >>> basetwo = partial(int, base=2) >>> basetwo.__doc__ = 'Convert base 2 string to an int.' >>> basetwo('10010') 18 ...we should also allow round() to be used in the same way... >>> from functional import partial >>> >>> roundTwo = partial(round, ndigits=2) >>> print '%.2f' % roundTwo(1.5555555) 1.56 >>> print '%.2f' % roundTwo(1.5545555) 1.55 >>> print '%.2f' % roundTwo(1.5445555) 1.54 without this patch, users current get this: >>> from functional import partial >>> roundTwo = partial(round, ndigits=2) >>> '%.2f' % roundTwo(1.5555555) Traceback (most recent call last): File "", line 1, in TypeError: round() takes no keyword arguments 4. THE FIX the number variable in bltinmodule.c is renamed from 'x' to 'number', and the keyword is named 'ndigits' after the doc string: >>> print round.__doc__ round(number[, ndigits]) -> floating point number this patch consists of a single file, Python/bltinmodule.c. the original CVS version from Mar 28, the patched version, output from running test/test_builtin.py, and both the C and U diff files are included in the attached ZIP file. 5. TESTING as mentioned above, we ran the test/test_builtin.py script and there are no changes in the execution of test_round: : test_repr (test.test_builtin.BuiltinTest) ... ok test_round (test.test_builtin.BuiltinTest) ... ok test_setattr (test.test_builtin.BuiltinTest) ... ok : the full output file is in the ZIP file. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1460496&group_id=5470 From noreply at sourceforge.net Wed Mar 29 09:52:47 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 28 Mar 2006 23:52:47 -0800 Subject: [Patches] [ python-Patches-1454485 ] patch for SIGSEGV in arraymodule.c Message-ID: Patches item #1454485, was opened at 2006-03-20 04:44 Message generated for change (Comment added) made by nnorwitz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1454485&group_id=5470 Please note that this 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: 7 Submitted By: Baris Metin (tbmetin) Assigned to: Neal Norwitz (nnorwitz) Summary: patch for SIGSEGV in arraymodule.c Initial Comment: Array module fails handling utf-8 strings giving a SIGSEGV. Attached patch seems to do the trick... gdb> run (no debugging symbols found) (no debugging symbols found) [Thread debugging using libthread_db enabled] [New Thread -1480337216 (LWP 31303)] Python 2.4.2 (#1, Mar 20 2006, 12:08:06) [GCC 3.4.5] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> import array >>> x = array.array("u") >>> x.append(u"bar????") Traceback (most recent call last): File "", line 1, in ? TypeError: array item must be unicode character >>> x.append("bar????") >>> x Program received signal SIGSEGV, Segmentation fault. [Switching to Thread -1480337216 (LWP 31303)] Error while running hook_stop: Invalid type combination in ordering comparison. 0xa7ee0799 in PyUnicodeUCS4_FromUnicode () from /usr/lib/libpython2.4.so.1.0 ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2006-03-28 23:52 Message: Logged In: YES user_id=33168 Attached is an updated patch to only do the (unsigned) cast in unicodeobject.c. The test included in the patch still crashes the interpreter, this time in unicodectype.c. ---------------------------------------------------------------------- Comment By: Martin v. L??wis (loewis) Date: 2006-03-26 13:36 Message: Logged In: YES user_id=21627 The second part of the patch (checking that *u is not negative) is definitely right. The first part (requiring an even number of bytes for a u# argument) probably requires discussion on python-dev (or this patch should be assigned to MAL): I don't think it should be allowed to pass a non-Unicode object to u# in the first place. In particular, if you pass a byte string, there would be an implicit assumption that the byte encoding is the same internal representation as a Py_UNICODE. This is bad - Python normally assumes the encoding of a string is the system encoding, which normally is ASCII. Of course, changing the call to a type error for 2.4.3 probably won't work, either, because it might break existing code. Anyway, I believe the latter fix alone should fix the crash: the current getargs implementation will round down to the next multiple of sizeof(Py_UNICODE), thanks the integer division. u_setitem will then refuse the call if the length is not 1. IOW, it is possible to append between 4 and 7 bytes to a Unicode array. I wonder why the patch fixes the problem: *u should be an unsigned, and comparing an unsigned with a signed should convert the signed to unsigned, no? ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2006-03-24 23:29 Message: Logged In: YES user_id=33168 Verified for 2.4 and head. The probably could exist w/ucs2 also if you use 'bar' (I think). I agree with Nick, this patch doesn't really solve the problem. The attached patch fixes the crash more generally, but I'm think there is a better solution. I hope Martin has time to review this and suggest a better fix. Martin, the change in getargs ensures that we don't try to convert an 8-bit string of length 5 to unicode. The change in unicodeobject ensures that we don't reference the array with a negative offset as happens if the buffer conversion succeeds with an invalid unicode character. ---------------------------------------------------------------------- Comment By: Nick Coghlan (ncoghlan) Date: 2006-03-24 06:43 Message: Logged In: YES user_id=1038590 To get the effect of the patch, it should be sufficient to just change the format character to an uppercase U. That doesn't seem like the right fix though - the actual explosion isn't happening until later when the array elements are being converted to Unicode for output. ---------------------------------------------------------------------- Comment By: Baris Metin (tbmetin) Date: 2006-03-24 01:19 Message: Logged In: YES user_id=1045504 I'm able to reproduce the bug with 2.5a0 SVN (r43289). Please try with --enable-unicode=ucs4 The patch is against svn too.. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2006-03-23 22:11 Message: Logged In: YES user_id=33168 With the stock 2.4.2 on my linux box I was able to reproduce this. I couldn't reproduce with 2.4.3c1. Can you verify this is fixed in 2.4.3? Sagol. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1454485&group_id=5470 From noreply at sourceforge.net Wed Mar 29 20:13:30 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 29 Mar 2006 10:13:30 -0800 Subject: [Patches] [ python-Patches-1454485 ] patch for SIGSEGV in arraymodule.c Message-ID: Patches item #1454485, was opened at 2006-03-20 13:44 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1454485&group_id=5470 Please note that this 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: 7 Submitted By: Baris Metin (tbmetin) Assigned to: Neal Norwitz (nnorwitz) Summary: patch for SIGSEGV in arraymodule.c Initial Comment: Array module fails handling utf-8 strings giving a SIGSEGV. Attached patch seems to do the trick... gdb> run (no debugging symbols found) (no debugging symbols found) [Thread debugging using libthread_db enabled] [New Thread -1480337216 (LWP 31303)] Python 2.4.2 (#1, Mar 20 2006, 12:08:06) [GCC 3.4.5] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> import array >>> x = array.array("u") >>> x.append(u"bar????") Traceback (most recent call last): File "", line 1, in ? TypeError: array item must be unicode character >>> x.append("bar????") >>> x Program received signal SIGSEGV, Segmentation fault. [Switching to Thread -1480337216 (LWP 31303)] Error while running hook_stop: Invalid type combination in ordering comparison. 0xa7ee0799 in PyUnicodeUCS4_FromUnicode () from /usr/lib/libpython2.4.so.1.0 ---------------------------------------------------------------------- >Comment By: Martin v. L??wis (loewis) Date: 2006-03-29 20:13 Message: Logged In: YES user_id=21627 I think there is a design choice here: Should it be an invariant that all characters in a Unicode string are below sys.maxunicode? If so, the procedures to create them should check whether that invariant holds. If not, all code that deals with them most consider cases where they are larger than sys.maxunicode or smaller than 0. Also, should it be a requirement that Py_UNICODE is an unsigned type? Then tests for <0 could be dropped, of course. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2006-03-29 09:52 Message: Logged In: YES user_id=33168 Attached is an updated patch to only do the (unsigned) cast in unicodeobject.c. The test included in the patch still crashes the interpreter, this time in unicodectype.c. ---------------------------------------------------------------------- Comment By: Martin v. L??wis (loewis) Date: 2006-03-26 23:36 Message: Logged In: YES user_id=21627 The second part of the patch (checking that *u is not negative) is definitely right. The first part (requiring an even number of bytes for a u# argument) probably requires discussion on python-dev (or this patch should be assigned to MAL): I don't think it should be allowed to pass a non-Unicode object to u# in the first place. In particular, if you pass a byte string, there would be an implicit assumption that the byte encoding is the same internal representation as a Py_UNICODE. This is bad - Python normally assumes the encoding of a string is the system encoding, which normally is ASCII. Of course, changing the call to a type error for 2.4.3 probably won't work, either, because it might break existing code. Anyway, I believe the latter fix alone should fix the crash: the current getargs implementation will round down to the next multiple of sizeof(Py_UNICODE), thanks the integer division. u_setitem will then refuse the call if the length is not 1. IOW, it is possible to append between 4 and 7 bytes to a Unicode array. I wonder why the patch fixes the problem: *u should be an unsigned, and comparing an unsigned with a signed should convert the signed to unsigned, no? ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2006-03-25 08:29 Message: Logged In: YES user_id=33168 Verified for 2.4 and head. The probably could exist w/ucs2 also if you use 'bar' (I think). I agree with Nick, this patch doesn't really solve the problem. The attached patch fixes the crash more generally, but I'm think there is a better solution. I hope Martin has time to review this and suggest a better fix. Martin, the change in getargs ensures that we don't try to convert an 8-bit string of length 5 to unicode. The change in unicodeobject ensures that we don't reference the array with a negative offset as happens if the buffer conversion succeeds with an invalid unicode character. ---------------------------------------------------------------------- Comment By: Nick Coghlan (ncoghlan) Date: 2006-03-24 15:43 Message: Logged In: YES user_id=1038590 To get the effect of the patch, it should be sufficient to just change the format character to an uppercase U. That doesn't seem like the right fix though - the actual explosion isn't happening until later when the array elements are being converted to Unicode for output. ---------------------------------------------------------------------- Comment By: Baris Metin (tbmetin) Date: 2006-03-24 10:19 Message: Logged In: YES user_id=1045504 I'm able to reproduce the bug with 2.5a0 SVN (r43289). Please try with --enable-unicode=ucs4 The patch is against svn too.. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2006-03-24 07:11 Message: Logged In: YES user_id=33168 With the stock 2.4.2 on my linux box I was able to reproduce this. I couldn't reproduce with 2.4.3c1. Can you verify this is fixed in 2.4.3? Sagol. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1454485&group_id=5470 From noreply at sourceforge.net Wed Mar 29 21:50:16 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 29 Mar 2006 11:50:16 -0800 Subject: [Patches] [ python-Patches-1454452 ] 2 Tools for easy inter-thread communication->Queue, threading Message-ID: Patches item #1454452, was opened at 2006-03-20 03:46 Message generated for change (Comment added) made by josiahcarlson You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1454452&group_id=5470 Please note that this 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: kxroberto (kxroberto) Assigned to: Raymond Hettinger (rhettinger) Summary: 2 Tools for easy inter-thread communication->Queue,threading Initial Comment: Using bare Queue.Queue in an inter-process manner by passing data is often tedious low-level style and overkill and leads to non-cohesive style of coding. Also threading up to now doesn't support a simply framework for non-blocking call execution _with_ result/end - a frequent need in GUI programming and easy load balancing for jerky resources. The attachment contains 2 tools for that: CallQueue and BackgroundCall. I think they fit well into the standard Python (2.5) lib. The attachment is in the form of a standalone Python module and can be tested directly, the 2 things can be easily copied to the target modules Queue / threading. Robert PS: fast atomic list.append / list.pop(0) / obj.var=.. assumed ; commented out use of Queue.Queue ; threading/Queue should maybe last of all do paranoid locking after all other stuff in the lib does so, in case Python would really go towards CPU level memory/time atoms, what in my opinion would destroy a VHL language. In case, I missed something, Queue should be uncommented. of the bare list. (The tests in all my apps raised no problems - I used that like tools since years, just reshaped them a little for this posting) ---------------------------------------------------------------------- Comment By: Josiah Carlson (josiahcarlson) Date: 2006-03-29 11:50 Message: Logged In: YES user_id=341410 Place this in the Python cookbook over at activestate.com and/or release it as a standalone module. If it gets nontrivial community support, it may have a chance at Python standard library inclusion. As it stands, it likely has exactly one user (you), no documentation, no unittest test cases, and no chance of making it into the standard library. Suggested close of this patch. ---------------------------------------------------------------------- Comment By: kxroberto (kxroberto) Date: 2006-03-22 02:43 Message: Logged In: YES user_id=972995 ->attachment (new version and diff): an update which addes options for exception handling (which I needed recently) and resolves one bug. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1454452&group_id=5470 From noreply at sourceforge.net Wed Mar 29 23:16:29 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 29 Mar 2006 13:16:29 -0800 Subject: [Patches] [ python-Patches-1459476 ] Install PKG-INFO with packages Message-ID: Patches item #1459476, was opened at 2006-03-27 17:40 Message generated for change (Comment added) made by pje You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1459476&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Distutils and setup.py Group: Python 2.5 >Status: Closed Resolution: Accepted Priority: 5 Submitted By: Phillip J. Eby (pje) Assigned to: Phillip J. Eby (pje) Summary: Install PKG-INFO with packages Initial Comment: This patch adds an 'install_egg_info' command to the distutils install process, that writes the standard PKG-INFO metadata to a file in the directory where the associated modules are being installed. The filename is based on setuptools' conventions for reading and writing such files, so that setuptools will be able to recognize distutils-installed packages as being present, and not attempt to reinstall them if they are sufficient to meet a requested dependency. As currently implemented, Python's main setup.py causes a Python-2.5a0-py2.5.egg-info to be installed in lib-dynload. It would probably be best if it also created similar files for ElementTree, ctypes, and any other packages incorporated into 2.4 or 2.5 that were separately distributed for Python 2.3. But that feature doesn't have to be in alpha 1. ---------------------------------------------------------------------- >Comment By: Phillip J. Eby (pje) Date: 2006-03-29 21:16 Message: Logged In: YES user_id=56214 Checked in. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2006-03-27 21:39 Message: Logged In: YES user_id=6380 Looks fine to me. Just trim the trailing blank lines and add a module-level docstring (look at the other install_*.py files for examples). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1459476&group_id=5470 From noreply at sourceforge.net Thu Mar 30 04:12:45 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 29 Mar 2006 18:12:45 -0800 Subject: [Patches] [ python-Patches-1457316 ] Support different GPG keys in upload --sign Message-ID: Patches item #1457316, was opened at 2006-03-23 21:40 Message generated for change (Settings changed) made by pje You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1457316&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Distutils and setup.py Group: Python 2.5 >Status: Closed >Resolution: Accepted Priority: 5 Submitted By: Stefan Behnel (scoder) Assigned to: Nobody/Anonymous (nobody) Summary: Support different GPG keys in upload --sign Initial Comment: This patch adds a new option "--identity" to the upload command that selects the GPG identity the package is signed with. Needed if the default key is not the key used for signing software. Usage example: setup.py sdist upload --sign --identity some at user.org ---------------------------------------------------------------------- >Comment By: Phillip J. Eby (pje) Date: 2006-03-30 02:12 Message: Logged In: YES user_id=56214 Feature added for 2.5 alpha 1 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1457316&group_id=5470 From noreply at sourceforge.net Thu Mar 30 20:12:27 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 30 Mar 2006 10:12:27 -0800 Subject: [Patches] [ python-Patches-1402289 ] Allow mappings as globals (was: Fix dictionary subclass ...) Message-ID: Patches item #1402289, was opened at 2006-01-10 16:24 Message generated for change (Comment added) made by crutcher_gmail You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1402289&group_id=5470 Please note that this 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: crutcher (crutcher_gmail) Assigned to: Raymond Hettinger (rhettinger) Summary: Allow mappings as globals (was: Fix dictionary subclass ...) Initial Comment: There is an inconsistancy in the way that dictionary subclasses behave when they are used as as namespaces in execs. Basically, while python 2.4 permits the usage of dictionary subclasses for local environments, it still bypasses the subclass functions and uses the C API for global environments. The attached patch (and unittest!) addresses this issue. I'm pretty sure we keep the fast path in this. ---------------------------------------------------------------------- >Comment By: crutcher (crutcher_gmail) Date: 2006-03-30 10:12 Message: Logged In: YES user_id=1424288 Are you going to get to this? ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2006-02-21 05:28 Message: Logged In: YES user_id=80475 Crutcher, this looked good on my first read-through. Will go through it in detail sometime in March. ---------------------------------------------------------------------- Comment By: crutcher (crutcher_gmail) Date: 2006-01-30 11:10 Message: Logged In: YES user_id=1424288 doh, forgot to check the 'upload' box ---------------------------------------------------------------------- Comment By: crutcher (crutcher_gmail) Date: 2006-01-30 09:08 Message: Logged In: YES user_id=1424288 I have reworked and extended this patch so that arbitrary mappings are permitted for globals, not just dictionary subtypes. This touched a good deal more code. Please use the updated version. ---------------------------------------------------------------------- Comment By: Armin Rigo (arigo) Date: 2006-01-25 10:20 Message: Logged In: YES user_id=4771 I will review and check-in your patch, I think it's a good idea despite the added code complexity. ---------------------------------------------------------------------- Comment By: crutcher (crutcher_gmail) Date: 2006-01-24 19:38 Message: Logged In: YES user_id=1424288 currently chasing through the PyFrame code and the EXEC_STMT code to make globals generic mappings, will update this patch yet again. ---------------------------------------------------------------------- Comment By: crutcher (crutcher_gmail) Date: 2006-01-22 01:19 Message: Logged In: YES user_id=1424288 I've fixed up the exception case, and extended the test case to check for it. Is there anything else I can do to get this in? ---------------------------------------------------------------------- Comment By: crutcher (crutcher_gmail) Date: 2006-01-21 21:11 Message: Logged In: YES user_id=1424288 I'm going to fix the missed exception test this weekend, and try to get an updated patch to you. ---------------------------------------------------------------------- Comment By: Armin Rigo (arigo) Date: 2006-01-14 01:54 Message: Logged In: YES user_id=4771 Provided this can be done with no measurable performance hit, I guess that I'm fine with the idea. The patch needs a bit more work, though: I don't see why it should accept dict subclasses as globals but not arbitrary mappings (as it now does for the locals). This is mainly an issue of removing a few checks in various places, like EXEC_STMT and the eval() and execfile() built-ins. There is a missing exception check/clear in the part about LOAD_NAME, after the PyObject_GetItem(f->f_globals, w). A side note: in the current trunk already, LOAD_GLOBAL contains a couple of checks, namely PyString_CheckExact() and hash != -1. We might be able to prove in advance that these two conditions are always true. We could then remove the checks. Not sure the difference measurable, though. ---------------------------------------------------------------------- Comment By: crutcher (crutcher_gmail) Date: 2006-01-11 23:50 Message: Logged In: YES user_id=1424288 Well, why fix it for eval but not for exec? I don't think the time hit is noticeable, I ran 'time make test' twice each on the trunk with and without the patch. Here are the results: Trunk: real 9m17.117s user 3m30.930s sys 0m35.417s real 9m9.471s user 3m31.484s sys 0m34.978s Patch: real 9m32.469s user 3m40.134s sys 0m36.140s real 9m6.779s user 3m27.529s sys 0m34.716s ---------------------------------------------------------------------- Comment By: Martin v. L??wis (loewis) Date: 2006-01-11 22:11 Message: Logged In: YES user_id=21627 I think the history is this: it originates from python.org/sf/215126, which requested that you can pass dict subtypes to eval. Armin noted that eval will always produce LOAD/STORE_NAME, so just modifying these opcodes is sufficient to fulfil the feature request. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2006-01-11 17:21 Message: Logged In: YES user_id=80475 Okay, I will take it under consideration. Also, I'll try to remember the reason it wasn't done the first time around. No promises though -- by itself consistency is a weak motivation. ---------------------------------------------------------------------- Comment By: crutcher (crutcher_gmail) Date: 2006-01-11 15:11 Message: Logged In: YES user_id=1424288 Here's a more interesting example. This works fine, unless the variables fall through to the global dictionary, or some code marks them global. import code class ManagedVariable: def get(self): return None def set(self, value): pass def delete(self): # Return false to stop the delete. return True class ManagedEnvironment(dict): def __setitem__(self, key, value): if self.has_key(key): if isinstance(dict.__getitem__(self, key), ManagedVariable): dict.__getitem__(self, key).set(value) return dict.__setitem__(self, key, value) def __getitem__(self, key): if self.has_key(key): if isinstance(dict.__getitem__(self, key), ManagedVariable): return dict.__getitem__(self, key).get() return dict.__getitem__(self, key) def __delitem__(self, key): if self.has_key(key): if isinstance(dict.__getitem__(self, key), ManagedVariable): if not dict.__getitem__(self, key).delete(): return dict.__delitem__(self, key) class RangedInt(ManagedVariable): def __init__(self, value, (low, high)): self.value = value self.low = low self.high = high def get(self): return self.value def set(self, value): if value < self.low: value = self.low if value > self.high: value = self.high self.value = value class FunctionValue(ManagedVariable): def __init__(self, get_func = None, set_func = None, del_func = None): self.get_func = get_func self.set_func = set_func self.del_func = del_func def get(self): if self.get_func: return self.get_func() return None def set(self, value): if self.set_func: self.set_func(value) def delete(self): if self.del_func: return self.del_func() return True class Constant(ManagedVariable): def __init__(self, value): self.value = value def get(self): return self.value def delete(self): return False import time d = ManagedEnvironment() d['ranged'] = RangedInt(1, (0, 100)) d['time'] = FunctionValue(lambda: time.time()) d['constant'] = Constant(42) code.interact(local=d) ---------------------------------------------------------------------- Comment By: crutcher (crutcher_gmail) Date: 2006-01-11 10:12 Message: Logged In: YES user_id=1424288 Here's an example of a little typed environment. It's not the most robust, but it gets you thinking. import code class TypedDictionary(dict): def __setitem__(self, key, value): if self.has_key(key): t = type(self[key]) if t != type(value): try: value = t(value) except Exception: raise TypeError, \ "illegal assignment to '%s':" \ " %s cannot be coerced to %s" \ % (key, type(value), t) dict.__setitem__(self, key, value) code.interact(local=TypedDictionary()) ---------------------------------------------------------------------- Comment By: crutcher (crutcher_gmail) Date: 2006-01-10 18:16 Message: Logged In: YES user_id=1424288 With the ability to use dictionary subclasses for local and global environments, it becomes very easy to implement execution environments with extended variable semantics for special purposes. This includes driving interactive processes, config file processors, type checking, lazy object construction, and read-only variables. As it currently stands, the semantics are inconsistent. The local case should not have been changed if the global case was not going to be changed. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2006-01-10 18:03 Message: Logged In: YES user_id=80475 Do you have any use cases? AFAICT, there were no unmet needs with locals option. Also, there was a reason that globals weren't included but I remember what it was. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1402289&group_id=5470 From noreply at sourceforge.net Fri Mar 31 00:19:34 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 30 Mar 2006 14:19:34 -0800 Subject: [Patches] [ python-Patches-1458476 ] Improved PySet C API Message-ID: Patches item #1458476, was opened at 2006-03-25 17:48 Message generated for change (Settings changed) made by bwarsaw You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1458476&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Core (C code) Group: Python 2.5 >Status: Open >Resolution: None Priority: 5 Submitted By: Barry A. Warsaw (bwarsaw) >Assigned to: Barry A. Warsaw (bwarsaw) Summary: Improved PySet C API Initial Comment: This patch adds PySet_Next(), PySet_Update(), and PySet_Clear(), three very useful API calls when you're dealing with concrete PySet objects. Patch includes tests and documentation. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2006-03-27 16:41 Message: Logged In: YES user_id=6380 I'm rejecting this unread, because I'm not ready to jump into this issue. The discussion should continue without me. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2006-03-26 00:41 Message: Logged In: YES user_id=80475 FWIW, I'm open to PyObject_Clear() for an abstract access to the tp_clear slot. Also, for Barry's use only, I'm open to a semi-private _PySet_Next() that isn't part of the official API but gives a Barry-specific hook. It should not be a public function because of all the problems with the approach. Likewise, _PySet_Update() could be done just for Barry's group. I need to keep PySet_Update() open until Py2.6 since the API may evolve to allow a variable length argument list. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2006-03-25 18:56 Message: Logged In: YES user_id=80475 Guido, please reject this patch. I laid-out my reasoning in these two posts: http://mail.python.org/pipermail/python-dev/2006- March/062652.html http://mail.python.org/pipermail/python-dev/2006- March/062737.html In particular, I've found PySet_Next() to be disasterously error-prone (and have had to fix several hard-to-find bugs directly attributable this function). There was some need for it in the PyDict API because it fetched key and value pointers at the same time and allowed direct modification of values. This of course does not apply to sets which do not have a value field. The PySet_Clear() function should be PyObject_Clear() like other functions that have tp_slots. There is no more of a case for this function than there would be for PySet_Repr, PySet_Len, PySet_IsTrue, or PySet_Print. The PySet_Update() function gets in the way of my future development plans for this module. None of these functions are necessary. They simply reflect Barry's programming style and views on having fat, overly-concrete APIs. This patch is against my wishes for the module. As the module author and principal maintainer, if I still have a say in the module's development, I strongly prefer rejection of this patch. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1458476&group_id=5470 From noreply at sourceforge.net Fri Mar 31 00:46:54 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 30 Mar 2006 14:46:54 -0800 Subject: [Patches] [ python-Patches-1458476 ] Improved PySet C API Message-ID: Patches item #1458476, was opened at 2006-03-25 17:48 Message generated for change (Comment added) made by bwarsaw You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1458476&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Core (C code) Group: Python 2.5 >Status: Closed >Resolution: Accepted Priority: 5 Submitted By: Barry A. Warsaw (bwarsaw) Assigned to: Barry A. Warsaw (bwarsaw) Summary: Improved PySet C API Initial Comment: This patch adds PySet_Next(), PySet_Update(), and PySet_Clear(), three very useful API calls when you're dealing with concrete PySet objects. Patch includes tests and documentation. ---------------------------------------------------------------------- >Comment By: Barry A. Warsaw (bwarsaw) Date: 2006-03-30 17:46 Message: Logged In: YES user_id=12800 r43465 ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2006-03-27 16:41 Message: Logged In: YES user_id=6380 I'm rejecting this unread, because I'm not ready to jump into this issue. The discussion should continue without me. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2006-03-26 00:41 Message: Logged In: YES user_id=80475 FWIW, I'm open to PyObject_Clear() for an abstract access to the tp_clear slot. Also, for Barry's use only, I'm open to a semi-private _PySet_Next() that isn't part of the official API but gives a Barry-specific hook. It should not be a public function because of all the problems with the approach. Likewise, _PySet_Update() could be done just for Barry's group. I need to keep PySet_Update() open until Py2.6 since the API may evolve to allow a variable length argument list. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2006-03-25 18:56 Message: Logged In: YES user_id=80475 Guido, please reject this patch. I laid-out my reasoning in these two posts: http://mail.python.org/pipermail/python-dev/2006- March/062652.html http://mail.python.org/pipermail/python-dev/2006- March/062737.html In particular, I've found PySet_Next() to be disasterously error-prone (and have had to fix several hard-to-find bugs directly attributable this function). There was some need for it in the PyDict API because it fetched key and value pointers at the same time and allowed direct modification of values. This of course does not apply to sets which do not have a value field. The PySet_Clear() function should be PyObject_Clear() like other functions that have tp_slots. There is no more of a case for this function than there would be for PySet_Repr, PySet_Len, PySet_IsTrue, or PySet_Print. The PySet_Update() function gets in the way of my future development plans for this module. None of these functions are necessary. They simply reflect Barry's programming style and views on having fat, overly-concrete APIs. This patch is against my wishes for the module. As the module author and principal maintainer, if I still have a say in the module's development, I strongly prefer rejection of this patch. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1458476&group_id=5470 From noreply at sourceforge.net Fri Mar 31 05:15:08 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 30 Mar 2006 19:15:08 -0800 Subject: [Patches] [ python-Patches-1461822 ] "const int" was truncated to "char" Message-ID: Patches item #1461822, was opened at 2006-03-31 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=1461822&group_id=5470 Please note that this 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: Hirokazu Yamamoto (ocean-city) Assigned to: Nobody/Anonymous (nobody) Summary: "const int" was truncated to "char" Initial Comment: Hello. I got this warning message in building trunk with VC6. This happens because "char" == "signed char" in my environment, and 255 is out of range of signed char. Probably attached patch will solve problem. Thank you. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1461822&group_id=5470 From noreply at sourceforge.net Fri Mar 31 15:05:51 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 31 Mar 2006 05:05:51 -0800 Subject: [Patches] [ python-Patches-1462080 ] ssl build fails due to undefined NETLINK_ stuff Message-ID: Patches item #1462080, was opened at 2006-03-31 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=1462080&group_id=5470 Please note that this 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: Arkadiusz Miskiewicz (arekm) Assigned to: Nobody/Anonymous (nobody) Summary: ssl build fails due to undefined NETLINK_ stuff Initial Comment: gcc -pthread -fPIC -fno-strict-aliasing -DNDEBUG -g -O 3 -Wall -Wstrict-prototypes -I. -I/home/users/arekm/ test/python/./Include -I/home/users/arekm/test/python- test/include -I/usr/include/ncurses -I./Include -I. -I/ usr/local/include -I/home/users/arekm/test/python/ Include -I/home/users/arekm/test/python -c /home/users/ arekm/test/python/Modules/socketmodule.c -o build/temp. linux-i686-2.5/socketmodule.o /home/users/arekm/test/python/Modules/socketmodule.c: In function ???init_socket???: /home/users/arekm/test/python/Modules/socketmodule.c: 4050: error: ???NETLINK_ARPD??? undeclared (first use in this function) /home/users/arekm/test/python/Modules/socketmodule.c: 4050: error: (Each undeclared identifier is reported only once /home/users/arekm/test/python/Modules/socketmodule.c: 4050: error: for each function it appears in.) /home/users/arekm/test/python/Modules/socketmodule.c: 4051: error: ???NETLINK_ROUTE6??? undeclared (first use in this function) /home/users/arekm/test/python/Modules/socketmodule.c: 4054: error: ???NETLINK_TAPBASE??? undeclared (first use in this function) I'm using sanitized version of linux headers - linux- libc-headers. Attached patch fixes these by ifdefing them + adds NETLINK_W1 which replaced NETLINK_SKIP in latest linux kernels. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1462080&group_id=5470 From noreply at sourceforge.net Fri Mar 31 15:53:45 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 31 Mar 2006 05:53:45 -0800 Subject: [Patches] [ python-Patches-1462106 ] Patch for 1115886 - splitext incorrectly handles filenames l Message-ID: Patches item #1462106, was opened at 2006-03-31 13:53 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1462106&group_id=5470 Please note that this 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: Mike Foord (mjfoord) Assigned to: Nobody/Anonymous (nobody) Summary: Patch for 1115886 - splitext incorrectly handles filenames l Initial Comment: Patch attached which modifies behaviour in macpath, posixpath, and ntpath - and modifies tests as well. Change is desirable, the intention is to split the extension from the filename. A fiel called '.foo' does not have an extension. There is the possibility that this change will break code where workarounds have been made. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1462106&group_id=5470 From noreply at sourceforge.net Fri Mar 31 16:26:37 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 31 Mar 2006 06:26:37 -0800 Subject: [Patches] [ python-Patches-1161914 ] python-config Message-ID: Patches item #1161914, was opened at 2005-03-12 10:44 Message generated for change (Comment added) made by gbrandl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1161914&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Distutils and setup.py Group: None Status: Open Resolution: None Priority: 5 Submitted By: Andre Jonsson (tatsujin) Assigned to: Nobody/Anonymous (nobody) Summary: python-config Initial Comment: I'm not sure this is the correct place to do this, but I found the need for a python-config (similar to sdl-config, etc.) when building an C++ application that embeds python. It accepts two arguments --cflags and --static-libs: # ./python-config --cflags --static-libs -I/usr/include/python2.4 /usr/lib/python2.4/config/libpython2.4.a I guess it could be expanded to do more, but it was all I needed. ---------------------------------------------------------------------- >Comment By: Georg Brandl (gbrandl) Date: 2006-03-31 14:26 Message: Logged In: YES user_id=849994 Uploading a python-only version. This should conform more with pkg-config, though every *-config program on my box has other options. ---------------------------------------------------------------------- Comment By: Andre Jonsson (tatsujin) Date: 2005-06-11 13:15 Message: Logged In: YES user_id=195710 1. php? Anyway, I see that the 'lib' attribute actually isn't an official one. Bad call from my part. 2. Yes, I'm ashamed to have commited such atrocities. :-) 3. Ah, I see. Didn't know about that one. That said, as loewis stated previously this script should probably follow the pkg-config standard anyhow. I haven't gotten around to do anything further in this matter, unfortunately. ---------------------------------------------------------------------- Comment By: Michiel de Hoon (mdehoon) Date: 2005-06-10 15:03 Message: Logged In: YES user_id=488897 Three comments: 1) When running this script, I got the following error on Unix and Cygwin: $ python-config.php --cflags --static-libs -I/usr/local/include/python2.4 Traceback (most recent call last): File "", line 1, in ? AttributeError: 'module' object has no attribute 'lib' 2) Since we are Pythoneers, why write this script as a shell-script instead of a Python script? (sh may not even be available on Windows). 3) Isn't it easier / more reliable to get this information via distutils? See section 5.6 of "Extending and Embedding the Python Interpreter". ---------------------------------------------------------------------- Comment By: Martin v. L??wis (loewis) Date: 2005-03-14 19:14 Message: Logged In: YES user_id=21627 It appears that the *-config programs (e.g. gtk-config, ...) share command line options; this seems to be part of the "pkg-config" system. I think we need to understand what precisely the standard for these utilities is, and conform to it. ---------------------------------------------------------------------- Comment By: Andre Jonsson (tatsujin) Date: 2005-03-14 08:43 Message: Logged In: YES user_id=195710 Ok. I'll make an attempt. What do you mean by "what specific options are expected from a *-config program" ? ---------------------------------------------------------------------- Comment By: Martin v. L??wis (loewis) Date: 2005-03-13 22:47 Message: Logged In: YES user_id=21627 This is the right place if you want this to be included in the standard Python distribution. If you just want to share it with others, the Python cookbook is a better place: http://aspn.activestate.com/ASPN/Python/Cookbook/ In the current form, this is not acceptable, as it is incomplete (e.g. there is no integration into the Python build process, and we need to know what specific options are expected from a *-config program, and implement them). Are you willing to complete this? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1161914&group_id=5470 From noreply at sourceforge.net Fri Mar 31 16:49:34 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 31 Mar 2006 06:49:34 -0800 Subject: [Patches] [ python-Patches-1161914 ] python-config Message-ID: Patches item #1161914, was opened at 2005-03-12 11:44 Message generated for change (Comment added) made by tatsujin You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1161914&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Distutils and setup.py Group: None Status: Open Resolution: None Priority: 5 Submitted By: Andre Jonsson (tatsujin) Assigned to: Nobody/Anonymous (nobody) Summary: python-config Initial Comment: I'm not sure this is the correct place to do this, but I found the need for a python-config (similar to sdl-config, etc.) when building an C++ application that embeds python. It accepts two arguments --cflags and --static-libs: # ./python-config --cflags --static-libs -I/usr/include/python2.4 /usr/lib/python2.4/config/libpython2.4.a I guess it could be expanded to do more, but it was all I needed. ---------------------------------------------------------------------- >Comment By: Andre Jonsson (tatsujin) Date: 2006-03-31 16:49 Message: Logged In: YES user_id=195710 Excellent work! Looks nice. ---------------------------------------------------------------------- Comment By: Georg Brandl (gbrandl) Date: 2006-03-31 16:26 Message: Logged In: YES user_id=849994 Uploading a python-only version. This should conform more with pkg-config, though every *-config program on my box has other options. ---------------------------------------------------------------------- Comment By: Andre Jonsson (tatsujin) Date: 2005-06-11 15:15 Message: Logged In: YES user_id=195710 1. php? Anyway, I see that the 'lib' attribute actually isn't an official one. Bad call from my part. 2. Yes, I'm ashamed to have commited such atrocities. :-) 3. Ah, I see. Didn't know about that one. That said, as loewis stated previously this script should probably follow the pkg-config standard anyhow. I haven't gotten around to do anything further in this matter, unfortunately. ---------------------------------------------------------------------- Comment By: Michiel de Hoon (mdehoon) Date: 2005-06-10 17:03 Message: Logged In: YES user_id=488897 Three comments: 1) When running this script, I got the following error on Unix and Cygwin: $ python-config.php --cflags --static-libs -I/usr/local/include/python2.4 Traceback (most recent call last): File "", line 1, in ? AttributeError: 'module' object has no attribute 'lib' 2) Since we are Pythoneers, why write this script as a shell-script instead of a Python script? (sh may not even be available on Windows). 3) Isn't it easier / more reliable to get this information via distutils? See section 5.6 of "Extending and Embedding the Python Interpreter". ---------------------------------------------------------------------- Comment By: Martin v. L??wis (loewis) Date: 2005-03-14 20:14 Message: Logged In: YES user_id=21627 It appears that the *-config programs (e.g. gtk-config, ...) share command line options; this seems to be part of the "pkg-config" system. I think we need to understand what precisely the standard for these utilities is, and conform to it. ---------------------------------------------------------------------- Comment By: Andre Jonsson (tatsujin) Date: 2005-03-14 09:43 Message: Logged In: YES user_id=195710 Ok. I'll make an attempt. What do you mean by "what specific options are expected from a *-config program" ? ---------------------------------------------------------------------- Comment By: Martin v. L??wis (loewis) Date: 2005-03-13 23:47 Message: Logged In: YES user_id=21627 This is the right place if you want this to be included in the standard Python distribution. If you just want to share it with others, the Python cookbook is a better place: http://aspn.activestate.com/ASPN/Python/Cookbook/ In the current form, this is not acceptable, as it is incomplete (e.g. there is no integration into the Python build process, and we need to know what specific options are expected from a *-config program, and implement them). Are you willing to complete this? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1161914&group_id=5470 From noreply at sourceforge.net Fri Mar 31 18:28:05 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 31 Mar 2006 08:28:05 -0800 Subject: [Patches] [ python-Patches-1462222 ] Functioning Tix.Grid Message-ID: Patches item #1462222, was opened at 2006-03-31 19:28 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1462222&group_id=5470 Please note that this 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: Christos Georgiou (tzot) Assigned to: Martin v. L??wis (loewis) Summary: Functioning Tix.Grid Initial Comment: This patch to Tix.py provides the basic functionality needed for the tixGrid widget to work in Tix applications. As I unravel the Tix C / Tcl/Tk code and find out what more functionality is available, I will update the patch. There will be an associated patch providing a module to be used with tixwidgets.py as a demo. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1462222&group_id=5470 From noreply at sourceforge.net Fri Mar 31 18:30:56 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 31 Mar 2006 08:30:56 -0800 Subject: [Patches] [ python-Patches-1462227 ] fdopen(..., "a") Message-ID: Patches item #1462227, was opened at 2006-03-31 18:30 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1462227&group_id=5470 Please note that this 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: Ralf Schmitt (titty) Assigned to: Nobody/Anonymous (nobody) Summary: fdopen(..., "a") Initial Comment: patch for issue number I forgot, over dumb sourceforge bugtracker ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1462227&group_id=5470 From noreply at sourceforge.net Fri Mar 31 18:31:20 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 31 Mar 2006 08:31:20 -0800 Subject: [Patches] [ python-Patches-1462222 ] Functioning Tix.Grid Message-ID: Patches item #1462222, was opened at 2006-03-31 19:28 Message generated for change (Comment added) made by tzot You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1462222&group_id=5470 Please note that this 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: Christos Georgiou (tzot) Assigned to: Martin v. L??wis (loewis) Summary: Functioning Tix.Grid Initial Comment: This patch to Tix.py provides the basic functionality needed for the tixGrid widget to work in Tix applications. As I unravel the Tix C / Tcl/Tk code and find out what more functionality is available, I will update the patch. There will be an associated patch providing a module to be used with tixwidgets.py as a demo. ---------------------------------------------------------------------- >Comment By: Christos Georgiou (tzot) Date: 2006-03-31 19:31 Message: Logged In: YES user_id=539787 Here follows code (testgrid.py) I use to test the patched Tix.py, used as 'python -i testgrid.py' ### import Tix as tk from pprint import pprint r= tk.Tk() r.title("test") l=tk.Label(r, name="a_label") l.pack() class MyGrid(tk.Grid): def __init__(self, *args, **kwargs): kwargs['editnotify']= self.editnotify tk.Grid.__init__(self, *args, **kwargs) def editnotify(self, x, y): return True g = MyGrid(r, name="a_grid", selectunit="cell") g.pack(fill=tk.BOTH) for x in xrange(5): for y in xrange(5): g.set(x,y,text=str((x,y))) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1462222&group_id=5470 From noreply at sourceforge.net Fri Mar 31 18:31:41 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 31 Mar 2006 08:31:41 -0800 Subject: [Patches] [ python-Patches-1462228 ] custom comparison function for bisect module Message-ID: Patches item #1462228, was opened at 2006-03-31 16: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=1462228&group_id=5470 Please note that this 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: splitscreen (splitscreen) Assigned to: Nobody/Anonymous (nobody) Summary: custom comparison function for bisect module Initial Comment: This is a patch for the feature requets #1451588 The patch is from the current trunk, r43488. The patch provides the bisect module (both the python and C implementation) with an option for a custom comparison function. If not custom comparison function is provided the standard cmp() built-in function it used. Please review, any comments welcome. matt ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1462228&group_id=5470 From noreply at sourceforge.net Fri Mar 31 18:36:06 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 31 Mar 2006 08:36:06 -0800 Subject: [Patches] [ python-Patches-1462230 ] Fix for #1250170 Message-ID: Patches item #1462230, was opened at 2006-03-31 16: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=1462230&group_id=5470 Please note that this 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: Kuba Ko??czyk (jakamkon) Assigned to: Nobody/Anonymous (nobody) Summary: Fix for #1250170 Initial Comment: Patch handle gaierror exception in mimetools and test_urllib2. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1462230&group_id=5470 From noreply at sourceforge.net Fri Mar 31 18:38:53 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 31 Mar 2006 08:38:53 -0800 Subject: [Patches] [ python-Patches-1462235 ] Fix of "disgusting hack" in Misc.after Message-ID: Patches item #1462235, was opened at 2006-03-31 19: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=1462235&group_id=5470 Please note that this 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: Christos Georgiou (tzot) Assigned to: Martin v. L??wis (loewis) Summary: Fix of "disgusting hack" in Misc.after Initial Comment: Misc.after had a "disgusting hack" probably dating before closures in order to clean up functions after having been called by 'after'. This patch changes the functionality from using a list as a default argument to using a plain closure. I came upon it while fixing the Tix.Grid class, trying to understand the Tkinter code. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1462235&group_id=5470 From noreply at sourceforge.net Fri Mar 31 18:47:59 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 31 Mar 2006 08:47:59 -0800 Subject: [Patches] [ python-Patches-1462245 ] fdopen(..., "a") Message-ID: Patches item #1462245, was opened at 2006-03-31 18: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=1462245&group_id=5470 Please note that this 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: Ralf Schmitt (titty) Assigned to: Nobody/Anonymous (nobody) Summary: fdopen(..., "a") Initial Comment: patch for issue number I forgot, over dumb sourceforge bugtracker ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1462245&group_id=5470 From noreply at sourceforge.net Fri Mar 31 18:59:46 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 31 Mar 2006 08:59:46 -0800 Subject: [Patches] [ python-Patches-1462245 ] fdopen(..., "a") Message-ID: Patches item #1462245, was opened at 2006-03-31 18:47 Message generated for change (Settings changed) made by titty You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1462245&group_id=5470 Please note that this 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: Deleted Resolution: None Priority: 5 Submitted By: Ralf Schmitt (titty) Assigned to: Nobody/Anonymous (nobody) Summary: fdopen(..., "a") Initial Comment: patch for issue number I forgot, over dumb sourceforge bugtracker ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1462245&group_id=5470 From noreply at sourceforge.net Fri Mar 31 19:40:38 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 31 Mar 2006 09:40:38 -0800 Subject: [Patches] [ python-Patches-1462230 ] Fix for #1250170 Message-ID: Patches item #1462230, was opened at 2006-03-31 16:36 Message generated for change (Settings changed) made by gbrandl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1462230&group_id=5470 Please note that this 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: Kuba Ko??czyk (jakamkon) Assigned to: Nobody/Anonymous (nobody) Summary: Fix for #1250170 Initial Comment: Patch handle gaierror exception in mimetools and test_urllib2. ---------------------------------------------------------------------- >Comment By: Georg Brandl (gbrandl) Date: 2006-03-31 17:40 Message: Logged In: YES user_id=849994 Committed in rev. 43490. Thanks! ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1462230&group_id=5470 From noreply at sourceforge.net Fri Mar 31 19:42:49 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 31 Mar 2006 09:42:49 -0800 Subject: [Patches] [ python-Patches-1462298 ] Fix for bug #1445068 getpass.getpass query on stderr Message-ID: Patches item #1462298, was opened at 2006-03-31 17:42 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1462298&group_id=5470 Please note that this 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: splitscreen (splitscreen) Assigned to: Nobody/Anonymous (nobody) Summary: Fix for bug #1445068 getpass.getpass query on stderr Initial Comment: This is a patch for #1445068. the signature of unix_getpass(prompt='Password: ', stream=sys.stderr) So that the user can configure the stream they wish to write output to. Matt ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1462298&group_id=5470 From noreply at sourceforge.net Fri Mar 31 19:59:02 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 31 Mar 2006 09:59:02 -0800 Subject: [Patches] [ python-Patches-1462313 ] Pickle protocol 2 fails on private slots Message-ID: Patches item #1462313, was opened at 2006-03-31 19: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=1462313&group_id=5470 Please note that this 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: ?iga Seilnacht (zseil) Assigned to: Nobody/Anonymous (nobody) Summary: Pickle protocol 2 fails on private slots Initial Comment: This is a patch for bug #1443328. It fixes both failing cases from that bug (the second one is in the comments) and has tests for all the cases. On Windows with this patch applied, all test pass. If somebody is interested in rewriting this in C, he could use tp_slots field of the PyHeapTypeObject structure. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1462313&group_id=5470 From noreply at sourceforge.net Fri Mar 31 20:01:58 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 31 Mar 2006 10:01:58 -0800 Subject: [Patches] [ python-Patches-1380952 ] Fix bug read() would hang on ssl socket if settimeout() used Message-ID: Patches item #1380952, was opened at 2005-12-14 23:14 Message generated for change (Settings changed) made by gbrandl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1380952&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Modules Group: Python 2.4 >Status: Closed >Resolution: Accepted Priority: 5 Submitted By: Arkadiusz Miskiewicz (arekm) Assigned to: Nobody/Anonymous (nobody) Summary: Fix bug read() would hang on ssl socket if settimeout() used Initial Comment: The problem has occured many times before like bugs https://sourceforge.net/tracker/?group_id=5470&atid= 105470&func=detail&aid=1353269 https://sourceforge.net/tracker/?group_id=5470&atid= 105470&func=detail&aid=977680 https://sourceforge.net/tracker/index.php?func=detail& aid=1098618&group_id=5470&atid=105470 This also fixes this bug: https://sourceforge.net/tracker/index.php?func=detail& aid=1166206&group_id=5470&atid=105470 Example test: import socket s = socket.socket(socket.AF_INET, socket.SOCK_STREAM) s.settimeout(30.0) # connect to service which issues an welcome banner (without need to write anything) s.connect(("gmail.org", 995)) ss = socket.ssl(s) # read part of return welcome banner twice,# read part of return welcome banner twice ss.read(1) ss.read(1) s.close() it will cause socket.sslerror: The read operation timed out on the second read() This is because _ssl.so modules doesn't handle SSL reads properly. The problem is in Modules/_ssl.c: PySSL_SSLread() we have: sockstate = check_socket_and_wait_for_timeout (self->Socket, self->ssl, 0); // XXXX HERE XXX if (sockstate == SOCKET_HAS_TIMED_OUT) { PyErr_SetString(PySSLErrorObject, "The read operation timed out"); Py_DECREF(buf); return NULL; } do {.... What will happen if SSL layer already read data and have that data in it's own buffers? The function check_ socket_and_wait_for_timeout() doing select(readfds) will wait forever until timeout occurs. The solution is to use http://www.openssl.org/docs/ssl/SSL_pending. html function. The attached patch fixes the problem and also adds test for python test suite. ---------------------------------------------------------------------- >Comment By: Georg Brandl (gbrandl) Date: 2006-03-31 18:01 Message: Logged In: YES user_id=849994 Committed as rev. 43491, 43492. Thanks! ---------------------------------------------------------------------- Comment By: Arkadiusz Miskiewicz (arekm) Date: 2005-12-15 17:28 Message: Logged In: YES user_id=139606 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1380952&group_id=5470 From noreply at sourceforge.net Fri Mar 31 20:26:31 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 31 Mar 2006 10:26:31 -0800 Subject: [Patches] [ python-Patches-1462313 ] Pickle protocol 2 fails on private slots Message-ID: Patches item #1462313, was opened at 2006-03-31 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=1462313&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Library (Lib) Group: None >Status: Closed >Resolution: Accepted Priority: 5 Submitted By: ?iga Seilnacht (zseil) Assigned to: Nobody/Anonymous (nobody) Summary: Pickle protocol 2 fails on private slots Initial Comment: This is a patch for bug #1443328. It fixes both failing cases from that bug (the second one is in the comments) and has tests for all the cases. On Windows with this patch applied, all test pass. If somebody is interested in rewriting this in C, he could use tp_slots field of the PyHeapTypeObject structure. ---------------------------------------------------------------------- >Comment By: Georg Brandl (gbrandl) Date: 2006-03-31 18:26 Message: Logged In: YES user_id=849994 Thanks for the patch, committed as rev. 43493, 43494. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1462313&group_id=5470 From noreply at sourceforge.net Fri Mar 31 20:31:40 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 31 Mar 2006 10:31:40 -0800 Subject: [Patches] [ python-Patches-1462227 ] fdopen(..., "a") Message-ID: Patches item #1462227, was opened at 2006-03-31 18:30 Message generated for change (Comment added) made by titty You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1462227&group_id=5470 Please note that this 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: Ralf Schmitt (titty) Assigned to: Nobody/Anonymous (nobody) Summary: fdopen(..., "a") Initial Comment: patch for issue number I forgot, over dumb sourceforge bugtracker ---------------------------------------------------------------------- >Comment By: Ralf Schmitt (titty) Date: 2006-03-31 20:31 Message: Logged In: YES user_id=17929 issue here: http://sourceforge.net/tracker/index.php?func=detail&aid=1461855&group_id=5470&atid=105470 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1462227&group_id=5470 From noreply at sourceforge.net Fri Mar 31 20:32:44 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 31 Mar 2006 10:32:44 -0800 Subject: [Patches] [ python-Patches-1460496 ] give round() kwargs (mostly for PFAs) Message-ID: Patches item #1460496, was opened at 2006-03-29 02:30 Message generated for change (Comment added) made by tim_one You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1460496&group_id=5470 Please note that this 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: Wesley J. Chun (wesc) Assigned to: Nobody/Anonymous (nobody) Summary: give round() kwargs (mostly for PFAs) Initial Comment: 1. WHAT this is a short non-critical patch to give round() keyword arguments for Partial Function Application (PEP309) purposes. 2. WHY arguments that appear on the RHS of function declarations are hard to call when using functional.partial because the "variable" argument is to the left (since PFAs pretty much favor only variable arguments to the right). if fixed arguments are to the right (are "curried"), then we need to support keyword args for them as much as possible to encourage their use. 3. MOTIVATION similar to the example in the Python Lib Ref doc page for the functional module and its use with int()... http://docs.python.org/dev/lib/module-functional.html >>> basetwo = partial(int, base=2) >>> basetwo.__doc__ = 'Convert base 2 string to an int.' >>> basetwo('10010') 18 ...we should also allow round() to be used in the same way... >>> from functional import partial >>> >>> roundTwo = partial(round, ndigits=2) >>> print '%.2f' % roundTwo(1.5555555) 1.56 >>> print '%.2f' % roundTwo(1.5545555) 1.55 >>> print '%.2f' % roundTwo(1.5445555) 1.54 without this patch, users current get this: >>> from functional import partial >>> roundTwo = partial(round, ndigits=2) >>> '%.2f' % roundTwo(1.5555555) Traceback (most recent call last): File "", line 1, in TypeError: round() takes no keyword arguments 4. THE FIX the number variable in bltinmodule.c is renamed from 'x' to 'number', and the keyword is named 'ndigits' after the doc string: >>> print round.__doc__ round(number[, ndigits]) -> floating point number this patch consists of a single file, Python/bltinmodule.c. the original CVS version from Mar 28, the patched version, output from running test/test_builtin.py, and both the C and U diff files are included in the attached ZIP file. 5. TESTING as mentioned above, we ran the test/test_builtin.py script and there are no changes in the execution of test_round: : test_repr (test.test_builtin.BuiltinTest) ... ok test_round (test.test_builtin.BuiltinTest) ... ok test_setattr (test.test_builtin.BuiltinTest) ... ok : the full output file is in the ZIP file. ---------------------------------------------------------------------- >Comment By: Tim Peters (tim_one) Date: 2006-03-31 13:32 Message: Logged In: YES user_id=31435 Marked as Accepted. Thanks! Note that, in the future, a unified diff is sufficient. The other stuff doesn't really help, and "hiding" the patch in an archive file actually makes it harder for people to review. Ah! That all obscured something important: the patch doesn't add test cases. When you add new features, you must also add new tests. Set the Resolution back to None. When new tests are added, the patch can be applied. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1460496&group_id=5470 From noreply at sourceforge.net Fri Mar 31 20:40:08 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 31 Mar 2006 10:40:08 -0800 Subject: [Patches] [ python-Patches-1257988 ] fix smtplib when local host isn't resolvable in dns Message-ID: Patches item #1257988, was opened at 2005-08-12 22:18 Message generated for change (Comment added) made by arekm You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1257988&group_id=5470 Please note that this 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: Arkadiusz Miskiewicz (arekm) Assigned to: Nobody/Anonymous (nobody) Summary: fix smtplib when local host isn't resolvable in dns Initial Comment: Suppose that hostname gives hostX. hostX doesn't exists in dns nor in / etc/hosts (it's unresolvable). Now when trying to connect to smtp service: >>> import smtplib >>> smtplib.SMTP('akcyza.pld-linux.org') Traceback (most recent call last): File "", line 1, in ? File "/usr/share/python2.4/smtplib.py", line 255, in __init__ socket.gaierror: (-2, 'Name or service not known') The problem is gethostbyname() here: # We can't find an fqdn hostname, so use a domain literal addr = socket.gethostbyname(socket.gethostname()) self.local_hostname = '[%s]' % addr It's much easier and better to just use getsockname() for local socket. Attached patch fixes this problem and doesn't require for the local system to be resolvable in dns/hosts. ---------------------------------------------------------------------- >Comment By: Arkadiusz Miskiewicz (arekm) Date: 2006-03-31 20:40 Message: Logged In: YES user_id=139606 Patch is wrong btw. Doesn't allow to create pure object without connecting. ---------------------------------------------------------------------- Comment By: Arkadiusz Miskiewicz (arekm) Date: 2005-08-24 19:00 Message: Logged In: YES user_id=139606 On unconnected socket it returns 0.0.0.0 afaik which doesn't happen here. Please drop that part. ---------------------------------------------------------------------- Comment By: Martin v. L??wis (loewis) Date: 2005-08-24 17:01 Message: Logged In: YES user_id=21627 Why would getsockname return '0.0.0.0'? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1257988&group_id=5470 From noreply at sourceforge.net Fri Mar 31 20:43:09 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 31 Mar 2006 10:43:09 -0800 Subject: [Patches] [ python-Patches-1462298 ] Fix for bug #1445068 getpass.getpass query on stderr Message-ID: Patches item #1462298, was opened at 2006-03-31 17:42 Message generated for change (Comment added) made by gbrandl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1462298&group_id=5470 Please note that this 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: Fixed Priority: 5 Submitted By: splitscreen (splitscreen) Assigned to: Nobody/Anonymous (nobody) Summary: Fix for bug #1445068 getpass.getpass query on stderr Initial Comment: This is a patch for #1445068. the signature of unix_getpass(prompt='Password: ', stream=sys.stderr) So that the user can configure the stream they wish to write output to. Matt ---------------------------------------------------------------------- >Comment By: Georg Brandl (gbrandl) Date: 2006-03-31 18:43 Message: Logged In: YES user_id=849994 Fixed in rev. 43495. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1462298&group_id=5470 From noreply at sourceforge.net Fri Mar 31 20:44:16 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 31 Mar 2006 10:44:16 -0800 Subject: [Patches] [ python-Patches-1462080 ] ssl build fails due to undefined NETLINK_ stuff Message-ID: Patches item #1462080, was opened at 2006-03-31 08:05 Message generated for change (Comment added) made by tim_one You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1462080&group_id=5470 Please note that this 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: Arkadiusz Miskiewicz (arekm) >Assigned to: Martin v. L??wis (loewis) Summary: ssl build fails due to undefined NETLINK_ stuff Initial Comment: gcc -pthread -fPIC -fno-strict-aliasing -DNDEBUG -g -O 3 -Wall -Wstrict-prototypes -I. -I/home/users/arekm/ test/python/./Include -I/home/users/arekm/test/python- test/include -I/usr/include/ncurses -I./Include -I. -I/ usr/local/include -I/home/users/arekm/test/python/ Include -I/home/users/arekm/test/python -c /home/users/ arekm/test/python/Modules/socketmodule.c -o build/temp. linux-i686-2.5/socketmodule.o /home/users/arekm/test/python/Modules/socketmodule.c: In function ???init_socket???: /home/users/arekm/test/python/Modules/socketmodule.c: 4050: error: ???NETLINK_ARPD??? undeclared (first use in this function) /home/users/arekm/test/python/Modules/socketmodule.c: 4050: error: (Each undeclared identifier is reported only once /home/users/arekm/test/python/Modules/socketmodule.c: 4050: error: for each function it appears in.) /home/users/arekm/test/python/Modules/socketmodule.c: 4051: error: ???NETLINK_ROUTE6??? undeclared (first use in this function) /home/users/arekm/test/python/Modules/socketmodule.c: 4054: error: ???NETLINK_TAPBASE??? undeclared (first use in this function) I'm using sanitized version of linux headers - linux- libc-headers. Attached patch fixes these by ifdefing them + adds NETLINK_W1 which replaced NETLINK_SKIP in latest linux kernels. ---------------------------------------------------------------------- >Comment By: Tim Peters (tim_one) Date: 2006-03-31 13:44 Message: Logged In: YES user_id=31435 Assigned to Martin. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1462080&group_id=5470 From noreply at sourceforge.net Fri Mar 31 20:45:12 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 31 Mar 2006 10:45:12 -0800 Subject: [Patches] [ python-Patches-1462298 ] Fix for bug #1445068 getpass.getpass query on stderr Message-ID: Patches item #1462298, was opened at 2006-03-31 17:42 Message generated for change (Settings changed) made by splitscreen You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1462298&group_id=5470 Please note that this 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: splitscreen (splitscreen) Assigned to: Nobody/Anonymous (nobody) Summary: Fix for bug #1445068 getpass.getpass query on stderr Initial Comment: This is a patch for #1445068. the signature of unix_getpass(prompt='Password: ', stream=sys.stderr) So that the user can configure the stream they wish to write output to. Matt ---------------------------------------------------------------------- Comment By: Georg Brandl (gbrandl) Date: 2006-03-31 18:43 Message: Logged In: YES user_id=849994 Fixed in rev. 43495. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1462298&group_id=5470 From noreply at sourceforge.net Fri Mar 31 20:47:26 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 31 Mar 2006 10:47:26 -0800 Subject: [Patches] [ python-Patches-1462338 ] upgrade pyexpat to expat 2.0.0 Message-ID: Patches item #1462338, was opened at 2006-03-31 18: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=1462338&group_id=5470 Please note that this 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: Trent Mick (tmick) Assigned to: Nobody/Anonymous (nobody) Summary: upgrade pyexpat to expat 2.0.0 Initial Comment: Update Modules/expat to expat 2.0.0. The only effective change in the introduction of the XML_Size typedef for the XML_GetCurrent{Column|Line}Number() functions which effectively changed the type from 'int' to 'long'. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1462338&group_id=5470 From noreply at sourceforge.net Fri Mar 31 20:47:48 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 31 Mar 2006 10:47:48 -0800 Subject: [Patches] [ python-Patches-1462298 ] Fix for bug #1445068 getpass.getpass query on stderr Message-ID: Patches item #1462298, was opened at 2006-03-31 17:42 Message generated for change (Settings changed) made by splitscreen You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1462298&group_id=5470 Please note that this 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: None Priority: 5 Submitted By: splitscreen (splitscreen) Assigned to: Nobody/Anonymous (nobody) Summary: Fix for bug #1445068 getpass.getpass query on stderr Initial Comment: This is a patch for #1445068. the signature of unix_getpass(prompt='Password: ', stream=sys.stderr) So that the user can configure the stream they wish to write output to. Matt ---------------------------------------------------------------------- Comment By: Georg Brandl (gbrandl) Date: 2006-03-31 18:43 Message: Logged In: YES user_id=849994 Fixed in rev. 43495. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1462298&group_id=5470 From noreply at sourceforge.net Fri Mar 31 20:55:16 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 31 Mar 2006 10:55:16 -0800 Subject: [Patches] [ python-Patches-1460496 ] give round() kwargs (mostly for PFAs) Message-ID: Patches item #1460496, was opened at 2006-03-29 07:30 Message generated for change (Comment added) made by gbrandl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1460496&group_id=5470 Please note that this 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: Wesley J. Chun (wesc) Assigned to: Nobody/Anonymous (nobody) Summary: give round() kwargs (mostly for PFAs) Initial Comment: 1. WHAT this is a short non-critical patch to give round() keyword arguments for Partial Function Application (PEP309) purposes. 2. WHY arguments that appear on the RHS of function declarations are hard to call when using functional.partial because the "variable" argument is to the left (since PFAs pretty much favor only variable arguments to the right). if fixed arguments are to the right (are "curried"), then we need to support keyword args for them as much as possible to encourage their use. 3. MOTIVATION similar to the example in the Python Lib Ref doc page for the functional module and its use with int()... http://docs.python.org/dev/lib/module-functional.html >>> basetwo = partial(int, base=2) >>> basetwo.__doc__ = 'Convert base 2 string to an int.' >>> basetwo('10010') 18 ...we should also allow round() to be used in the same way... >>> from functional import partial >>> >>> roundTwo = partial(round, ndigits=2) >>> print '%.2f' % roundTwo(1.5555555) 1.56 >>> print '%.2f' % roundTwo(1.5545555) 1.55 >>> print '%.2f' % roundTwo(1.5445555) 1.54 without this patch, users current get this: >>> from functional import partial >>> roundTwo = partial(round, ndigits=2) >>> '%.2f' % roundTwo(1.5555555) Traceback (most recent call last): File "", line 1, in TypeError: round() takes no keyword arguments 4. THE FIX the number variable in bltinmodule.c is renamed from 'x' to 'number', and the keyword is named 'ndigits' after the doc string: >>> print round.__doc__ round(number[, ndigits]) -> floating point number this patch consists of a single file, Python/bltinmodule.c. the original CVS version from Mar 28, the patched version, output from running test/test_builtin.py, and both the C and U diff files are included in the attached ZIP file. 5. TESTING as mentioned above, we ran the test/test_builtin.py script and there are no changes in the execution of test_round: : test_repr (test.test_builtin.BuiltinTest) ... ok test_round (test.test_builtin.BuiltinTest) ... ok test_setattr (test.test_builtin.BuiltinTest) ... ok : the full output file is in the ZIP file. ---------------------------------------------------------------------- >Comment By: Georg Brandl (gbrandl) Date: 2006-03-31 18:55 Message: Logged In: YES user_id=849994 Added tests and checked in in rev. 43496. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2006-03-31 18:32 Message: Logged In: YES user_id=31435 Marked as Accepted. Thanks! Note that, in the future, a unified diff is sufficient. The other stuff doesn't really help, and "hiding" the patch in an archive file actually makes it harder for people to review. Ah! That all obscured something important: the patch doesn't add test cases. When you add new features, you must also add new tests. Set the Resolution back to None. When new tests are added, the patch can be applied. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1460496&group_id=5470 From noreply at sourceforge.net Fri Mar 31 20:57:53 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 31 Mar 2006 10:57:53 -0800 Subject: [Patches] [ python-Patches-1257988 ] fix smtplib when local host isn't resolvable in dns Message-ID: Patches item #1257988, was opened at 2005-08-12 22:18 Message generated for change (Comment added) made by arekm You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1257988&group_id=5470 Please note that this 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: Arkadiusz Miskiewicz (arekm) Assigned to: Nobody/Anonymous (nobody) Summary: fix smtplib when local host isn't resolvable in dns Initial Comment: Suppose that hostname gives hostX. hostX doesn't exists in dns nor in / etc/hosts (it's unresolvable). Now when trying to connect to smtp service: >>> import smtplib >>> smtplib.SMTP('akcyza.pld-linux.org') Traceback (most recent call last): File "", line 1, in ? File "/usr/share/python2.4/smtplib.py", line 255, in __init__ socket.gaierror: (-2, 'Name or service not known') The problem is gethostbyname() here: # We can't find an fqdn hostname, so use a domain literal addr = socket.gethostbyname(socket.gethostname()) self.local_hostname = '[%s]' % addr It's much easier and better to just use getsockname() for local socket. Attached patch fixes this problem and doesn't require for the local system to be resolvable in dns/hosts. ---------------------------------------------------------------------- >Comment By: Arkadiusz Miskiewicz (arekm) Date: 2006-03-31 20:57 Message: Logged In: YES user_id=139606 Maybe just always fallback to safe value? --- Lib/smtplib.py.org 2006-03-31 20:57:05.000000000 +0200 +++ Lib/smtplib.py 2006-03-31 20:57:28.000000000 +0200 @@ -255,7 +255,11 @@ self.local_hostname = fqdn else: # We can't find an fqdn hostname, so use a domain literal - addr = socket.gethostbyname(socket. gethostname()) + addr = '127.0.0.1' + try: + addr = socket.gethostbyname(socket. gethostname()) + except socket.gaierror: + pass self.local_hostname = '[%s]' % addr def set_debuglevel(self, debuglevel): ---------------------------------------------------------------------- Comment By: Arkadiusz Miskiewicz (arekm) Date: 2006-03-31 20:40 Message: Logged In: YES user_id=139606 Patch is wrong btw. Doesn't allow to create pure object without connecting. ---------------------------------------------------------------------- Comment By: Arkadiusz Miskiewicz (arekm) Date: 2005-08-24 19:00 Message: Logged In: YES user_id=139606 On unconnected socket it returns 0.0.0.0 afaik which doesn't happen here. Please drop that part. ---------------------------------------------------------------------- Comment By: Martin v. L??wis (loewis) Date: 2005-08-24 17:01 Message: Logged In: YES user_id=21627 Why would getsockname return '0.0.0.0'? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1257988&group_id=5470 From noreply at sourceforge.net Fri Mar 31 21:23:16 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 31 Mar 2006 11:23:16 -0800 Subject: [Patches] [ python-Patches-1462361 ] Possible fix to #1334662 (int() wrong answers) Message-ID: Patches item #1462361, was opened at 2006-03-31 21: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=1462361&group_id=5470 Please note that this 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: Ivan Vilata i Balaguer (ivilata) Assigned to: Nobody/Anonymous (nobody) Summary: Possible fix to #1334662 (int() wrong answers) Initial Comment: This is the patch I talked about in #1334662. I think it fixes int() returning zero for non-zero literals under some bases. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1462361&group_id=5470 From noreply at sourceforge.net Fri Mar 31 21:25:56 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 31 Mar 2006 11:25:56 -0800 Subject: [Patches] [ python-Patches-1462228 ] custom comparison function for bisect module Message-ID: Patches item #1462228, was opened at 2006-03-31 16:31 Message generated for change (Settings changed) made by gbrandl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1462228&group_id=5470 Please note that this 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: splitscreen (splitscreen) >Assigned to: Raymond Hettinger (rhettinger) Summary: custom comparison function for bisect module Initial Comment: This is a patch for the feature requets #1451588 The patch is from the current trunk, r43488. The patch provides the bisect module (both the python and C implementation) with an option for a custom comparison function. If not custom comparison function is provided the standard cmp() built-in function it used. Please review, any comments welcome. matt ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1462228&group_id=5470 From noreply at sourceforge.net Fri Mar 31 21:29:43 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 31 Mar 2006 11:29:43 -0800 Subject: [Patches] [ python-Patches-1462361 ] Possible fix to #1334662 (int() wrong answers) Message-ID: Patches item #1462361, was opened at 2006-03-31 21:23 Message generated for change (Comment added) made by ivilata You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1462361&group_id=5470 Please note that this 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: Ivan Vilata i Balaguer (ivilata) Assigned to: Nobody/Anonymous (nobody) Summary: Possible fix to #1334662 (int() wrong answers) Initial Comment: This is the patch I talked about in #1334662. I think it fixes int() returning zero for non-zero literals under some bases. ---------------------------------------------------------------------- >Comment By: Ivan Vilata i Balaguer (ivilata) Date: 2006-03-31 21:29 Message: Logged In: YES user_id=1064183 I *love* this web interface... Here you have the patch. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1462361&group_id=5470 From noreply at sourceforge.net Fri Mar 31 21:34:27 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 31 Mar 2006 11:34:27 -0800 Subject: [Patches] [ python-Patches-1257988 ] fix smtplib when local host isn't resolvable in dns Message-ID: Patches item #1257988, was opened at 2005-08-12 20:18 Message generated for change (Comment added) made by gbrandl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1257988&group_id=5470 Please note that this 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: Fixed Priority: 5 Submitted By: Arkadiusz Miskiewicz (arekm) Assigned to: Nobody/Anonymous (nobody) Summary: fix smtplib when local host isn't resolvable in dns Initial Comment: Suppose that hostname gives hostX. hostX doesn't exists in dns nor in / etc/hosts (it's unresolvable). Now when trying to connect to smtp service: >>> import smtplib >>> smtplib.SMTP('akcyza.pld-linux.org') Traceback (most recent call last): File "", line 1, in ? File "/usr/share/python2.4/smtplib.py", line 255, in __init__ socket.gaierror: (-2, 'Name or service not known') The problem is gethostbyname() here: # We can't find an fqdn hostname, so use a domain literal addr = socket.gethostbyname(socket.gethostname()) self.local_hostname = '[%s]' % addr It's much easier and better to just use getsockname() for local socket. Attached patch fixes this problem and doesn't require for the local system to be resolvable in dns/hosts. ---------------------------------------------------------------------- >Comment By: Georg Brandl (gbrandl) Date: 2006-03-31 19:34 Message: Logged In: YES user_id=849994 Committed safe patch in rev. 43499, 43500. ---------------------------------------------------------------------- Comment By: Arkadiusz Miskiewicz (arekm) Date: 2006-03-31 18:57 Message: Logged In: YES user_id=139606 Maybe just always fallback to safe value? --- Lib/smtplib.py.org 2006-03-31 20:57:05.000000000 +0200 +++ Lib/smtplib.py 2006-03-31 20:57:28.000000000 +0200 @@ -255,7 +255,11 @@ self.local_hostname = fqdn else: # We can't find an fqdn hostname, so use a domain literal - addr = socket.gethostbyname(socket. gethostname()) + addr = '127.0.0.1' + try: + addr = socket.gethostbyname(socket. gethostname()) + except socket.gaierror: + pass self.local_hostname = '[%s]' % addr def set_debuglevel(self, debuglevel): ---------------------------------------------------------------------- Comment By: Arkadiusz Miskiewicz (arekm) Date: 2006-03-31 18:40 Message: Logged In: YES user_id=139606 Patch is wrong btw. Doesn't allow to create pure object without connecting. ---------------------------------------------------------------------- Comment By: Arkadiusz Miskiewicz (arekm) Date: 2005-08-24 17:00 Message: Logged In: YES user_id=139606 On unconnected socket it returns 0.0.0.0 afaik which doesn't happen here. Please drop that part. ---------------------------------------------------------------------- Comment By: Martin v. L??wis (loewis) Date: 2005-08-24 15:01 Message: Logged In: YES user_id=21627 Why would getsockname return '0.0.0.0'? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1257988&group_id=5470 From noreply at sourceforge.net Fri Mar 31 21:49:03 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 31 Mar 2006 11:49:03 -0800 Subject: [Patches] [ python-Patches-1462228 ] custom comparison function for bisect module Message-ID: Patches item #1462228, was opened at 2006-03-31 16:31 Message generated for change (Settings changed) made by splitscreen You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1462228&group_id=5470 Please note that this 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: splitscreen (splitscreen) >Assigned to: Nobody/Anonymous (nobody) Summary: custom comparison function for bisect module Initial Comment: This is a patch for the feature requets #1451588 The patch is from the current trunk, r43488. The patch provides the bisect module (both the python and C implementation) with an option for a custom comparison function. If not custom comparison function is provided the standard cmp() built-in function it used. Please review, any comments welcome. matt ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1462228&group_id=5470 From noreply at sourceforge.net Fri Mar 31 22:01:16 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 31 Mar 2006 12:01:16 -0800 Subject: [Patches] [ python-Patches-1462227 ] fdopen(..., "a") Message-ID: Patches item #1462227, was opened at 2006-03-31 16:30 Message generated for change (Comment added) made by gbrandl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1462227&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Ralf Schmitt (titty) Assigned to: Nobody/Anonymous (nobody) Summary: fdopen(..., "a") Initial Comment: patch for issue number I forgot, over dumb sourceforge bugtracker ---------------------------------------------------------------------- >Comment By: Georg Brandl (gbrandl) Date: 2006-03-31 20:01 Message: Logged In: YES user_id=849994 Patch applied in rev. 43501, 43502. ---------------------------------------------------------------------- Comment By: Ralf Schmitt (titty) Date: 2006-03-31 18:31 Message: Logged In: YES user_id=17929 issue here: http://sourceforge.net/tracker/index.php?func=detail&aid=1461855&group_id=5470&atid=105470 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1462227&group_id=5470 From noreply at sourceforge.net Fri Mar 31 22:12:57 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 31 Mar 2006 12:12:57 -0800 Subject: [Patches] [ python-Patches-1462361 ] Possible fix to #1334662 (int() wrong answers) Message-ID: Patches item #1462361, was opened at 2006-03-31 21:23 Message generated for change (Comment added) made by ivilata You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1462361&group_id=5470 Please note that this 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: Ivan Vilata i Balaguer (ivilata) Assigned to: Nobody/Anonymous (nobody) Summary: Possible fix to #1334662 (int() wrong answers) Initial Comment: This is the patch I talked about in #1334662. I think it fixes int() returning zero for non-zero literals under some bases. ---------------------------------------------------------------------- >Comment By: Ivan Vilata i Balaguer (ivilata) Date: 2006-03-31 22:12 Message: Logged In: YES user_id=1064183 This is a little modification to ``test_builtin.py`` to check for the bug. It would be nice for someone to run it under a 64-bit platform! ---------------------------------------------------------------------- Comment By: Ivan Vilata i Balaguer (ivilata) Date: 2006-03-31 21:29 Message: Logged In: YES user_id=1064183 I *love* this web interface... Here you have the patch. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1462361&group_id=5470 From noreply at sourceforge.net Fri Mar 31 22:51:13 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 31 Mar 2006 12:51:13 -0800 Subject: [Patches] [ python-Patches-1462361 ] Possible fix to #1334662 (int() wrong answers) Message-ID: Patches item #1462361, was opened at 2006-03-31 21:23 Message generated for change (Comment added) made by titty You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1462361&group_id=5470 Please note that this 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: Ivan Vilata i Balaguer (ivilata) Assigned to: Nobody/Anonymous (nobody) Summary: Possible fix to #1334662 (int() wrong answers) Initial Comment: This is the patch I talked about in #1334662. I think it fixes int() returning zero for non-zero literals under some bases. ---------------------------------------------------------------------- Comment By: Ralf Schmitt (titty) Date: 2006-03-31 22:51 Message: Logged In: YES user_id=17929 with patch to tests applied I get: =============================================== ======================= FAIL: test_int (__main__.BuiltinTest) ----------------------------------------------------------------- ----- Traceback (most recent call last): File "Lib/test/test_builtin.py", line 685, in test_int self.assertEqual(int('c9c336o0mlb7eg', 25), max_uint64) AssertionError: 0 != 18446744073709551616L ----------------------------------------------------------------- ----- Ran 60 tests in 0.118s FAILED (failures=1) Traceback (most recent call last): File "Lib/test/test_builtin.py", line 103, in class BuiltinTest(unittest.TestCase): File "Lib/test/test_builtin.py", line 1587, in test_main run_unittest(*test_classes) File "/home/ralf/python-trunk/Lib/test/test_support.py", line 300, in run_unittest run_suite(suite, testclass) File "/home/ralf/python-trunk/Lib/test/test_support.py", line 285, in run_suite raise TestFailed(err) test.test_support.TestFailed: Traceback (most recent call last): File "Lib/test/test_builtin.py", line 685, in test_int self.assertEqual(int('c9c336o0mlb7eg', 25), max_uint64) AssertionError: 0 != 18446744073709551616L ---------------------------------------------------------------------- Comment By: Ivan Vilata i Balaguer (ivilata) Date: 2006-03-31 22:12 Message: Logged In: YES user_id=1064183 This is a little modification to ``test_builtin.py`` to check for the bug. It would be nice for someone to run it under a 64-bit platform! ---------------------------------------------------------------------- Comment By: Ivan Vilata i Balaguer (ivilata) Date: 2006-03-31 21:29 Message: Logged In: YES user_id=1064183 I *love* this web interface... Here you have the patch. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1462361&group_id=5470 From noreply at sourceforge.net Fri Mar 31 22:55:16 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 31 Mar 2006 12:55:16 -0800 Subject: [Patches] [ python-Patches-1462361 ] Possible fix to #1334662 (int() wrong answers) Message-ID: Patches item #1462361, was opened at 2006-03-31 21:23 Message generated for change (Comment added) made by titty You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1462361&group_id=5470 Please note that this 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: Ivan Vilata i Balaguer (ivilata) Assigned to: Nobody/Anonymous (nobody) Summary: Possible fix to #1334662 (int() wrong answers) Initial Comment: This is the patch I talked about in #1334662. I think it fixes int() returning zero for non-zero literals under some bases. ---------------------------------------------------------------------- Comment By: Ralf Schmitt (titty) Date: 2006-03-31 22:55 Message: Logged In: YES user_id=17929 After applying the patch to mystrtoul all tests work. tests were run on ubuntu dapper amd64 ---------------------------------------------------------------------- Comment By: Ralf Schmitt (titty) Date: 2006-03-31 22:51 Message: Logged In: YES user_id=17929 with patch to tests applied I get: =============================================== ======================= FAIL: test_int (__main__.BuiltinTest) ----------------------------------------------------------------- ----- Traceback (most recent call last): File "Lib/test/test_builtin.py", line 685, in test_int self.assertEqual(int('c9c336o0mlb7eg', 25), max_uint64) AssertionError: 0 != 18446744073709551616L ----------------------------------------------------------------- ----- Ran 60 tests in 0.118s FAILED (failures=1) Traceback (most recent call last): File "Lib/test/test_builtin.py", line 103, in class BuiltinTest(unittest.TestCase): File "Lib/test/test_builtin.py", line 1587, in test_main run_unittest(*test_classes) File "/home/ralf/python-trunk/Lib/test/test_support.py", line 300, in run_unittest run_suite(suite, testclass) File "/home/ralf/python-trunk/Lib/test/test_support.py", line 285, in run_suite raise TestFailed(err) test.test_support.TestFailed: Traceback (most recent call last): File "Lib/test/test_builtin.py", line 685, in test_int self.assertEqual(int('c9c336o0mlb7eg', 25), max_uint64) AssertionError: 0 != 18446744073709551616L ---------------------------------------------------------------------- Comment By: Ivan Vilata i Balaguer (ivilata) Date: 2006-03-31 22:12 Message: Logged In: YES user_id=1064183 This is a little modification to ``test_builtin.py`` to check for the bug. It would be nice for someone to run it under a 64-bit platform! ---------------------------------------------------------------------- Comment By: Ivan Vilata i Balaguer (ivilata) Date: 2006-03-31 21:29 Message: Logged In: YES user_id=1064183 I *love* this web interface... Here you have the patch. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1462361&group_id=5470 From noreply at sourceforge.net Fri Mar 31 23:16:50 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 31 Mar 2006 13:16:50 -0800 Subject: [Patches] [ python-Patches-972322 ] urllib2 handler naming convention collision Message-ID: Patches item #972322, was opened at 2004-06-14 00:16 Message generated for change (Comment added) made by jjlee You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=972322&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Library (Lib) Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: John J Lee (jjlee) Assigned to: Jeremy Hylton (jhylton) Summary: urllib2 handler naming convention collision Initial Comment: The method naming conventions of *_open and *_request in urllib2 are accidentally met by the following methods: AbstractHTTPHandler.do_open() ProxyHandler.proxy_open() AbstractHTTPHandler.redirect_request() So URLs like do://example.com/ are regarded as having a handler, and urllib2.urlopen("do://python.org/") causes a TypeError. I think *something* should be done about this, but I'm willing to provide a different patch if this one is frowned upon. The alternative would be to rename do_open and proxy_open, and leave the redirect_request case unchanged (see below for why). The first two methods are undocumented, so could in theory be renamed. However, people will likely be overriding them anyway, so perhaps it's better to apply this ugly patch than rename them. redirect_request is documented, so can't be renamed, but it will never be accidentally called unless somebody actually adds a handler with a method named "redirect_open". ---------------------------------------------------------------------- >Comment By: John J Lee (jjlee) Date: 2006-03-31 22:16 Message: Logged In: YES user_id=261020 Here's an updated patch (collision.patch) that applies against SVN HEAD. I also made the test a little clearer. collision.patch supercedes both urllib2.py.patch and test_urllib2.py.patch ---------------------------------------------------------------------- Comment By: John J Lee (jjlee) Date: 2005-05-19 21:53 Message: Logged In: YES user_id=261020 Since nobody seems to mind the slightly uglified code required to fix these bugs in a backwards-compatible way, could somebody please apply this patch? ---------------------------------------------------------------------- Comment By: Michael Chermside (mcherm) Date: 2004-10-22 17:36 Message: Logged In: YES user_id=99874 I have reviewed this patch and I recomend applying it. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=972322&group_id=5470 From noreply at sourceforge.net Fri Mar 31 23:21:10 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 31 Mar 2006 13:21:10 -0800 Subject: [Patches] [ python-Patches-1462414 ] Patch for bug #1458017 Log._log needs to be more forgiving Message-ID: Patches item #1462414, was opened at 2006-03-31 21:21 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1462414&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Distutils and setup.py Group: None Status: Open Resolution: None Priority: 5 Submitted By: splitscreen (splitscreen) Assigned to: Nobody/Anonymous (nobody) Summary: Patch for bug #1458017 Log._log needs to be more forgiving Initial Comment: This is a patch to stop Log._log() from crashing when the message string contains a % escape but args is an empty tuple (i.e we're not expecting to format anything). It's only a modest patch against trunk r43509. Matt ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1462414&group_id=5470