From noreply at sourceforge.net Tue Nov 1 01:55:20 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 31 Oct 2005 16:55:20 -0800 Subject: [Patches] [ python-Patches-1335972 ] Fix for int(string, base) wrong answers (take 2) Message-ID: Patches item #1335972, was opened at 2005-10-24 01: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=1335972&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Core (C code) Group: None Status: Open Resolution: None Priority: 5 Submitted By: Alan McIntyre (ESRG) (alanmcintyre) Assigned to: Nobody/Anonymous (nobody) Summary: Fix for int(string, base) wrong answers (take 2) Initial Comment: This incorporates patch #1334979, adds test cases for all the cases listed in bug #1334662, and adds test cases for evaluation of 2**32+1. There seem to be some minor speed improvements (simplistic stats shown below). Some simple performance test scripts have been included in the attached file as well. A lookup table was added for the maximum number of digits that can never overflow on a 32-bit ulong for each base. Overflow is only checked when this limit is exceeded by 1, and once the input string is determined to be too long (2 over the limit), the evaluation is halted and an overflow indication is returned. This appears to help reduce the evaluation time for very long strings (no time is wasted trying to evaluate all of it into a 32-bit ulong). Evaluation of each character has also been replaced by a lookup table. I'm not certain of the amount of speed benefit obtained from this; I added it early on and haven't had time to go back and test. It may be that it's not worth the extra static table. Baseline Python from CVS: alan at tarantula:~/python/dist/src# ./python -m timeit 'int("9")' 100000 loops, best of 3: 4 usec per loop alan at tarantula:~/python/dist/src# ./python -m timeit 'int("999999999")' 100000 loops, best of 3: 5.49 usec per loop alan at tarantula:~/python/dist/src# ./python -m timeit 'int("999999999999")' 100000 loops, best of 3: 11.8 usec per loop alan at tarantula:~/python/dist/src# ./python -m timeit 'int("999999999999999")' 100000 loops, best of 3: 13.4 usec per loop alan at tarantula:~/python/dist/src# ./python -m timeit 'int("1"*600)' 1000 loops, best of 3: 997 usec per loop Modified: alan at tarantula:~/python_testint/dist/src# ./python -m timeit 'int("9")' 100000 loops, best of 3: 3.63 usec per loop alan at tarantula:~/python_testint/dist/src# ./python -m timeit 'int("999999999")' 100000 loops, best of 3: 3.93 usec per loop alan at tarantula:~/python_testint/dist/src# ./python -m timeit 'int("999999999999")' 100000 loops, best of 3: 9.79 usec per loop alan at tarantula:~/python_testint/dist/src# ./python -m timeit 'int("999999999999999")' 100000 loops, best of 3: 11 usec per loop alan at tarantula:~/python_testint/dist/src# ./python -m timeit 'int("1"*600)' 1000 loops, best of 3: 905 usec per loop 10.2% faster for 1-digit int 39.7% faster for 9-digit int 20.5% faster for 12-digit int 21.8% faster for 15-digit int 10.2% faster for 600-digit int Test program that takes 750k ints from [0, 2**32) through stdin: Baseline: 8.114 sec (best of 5 consecutive runs) Modified: 6.774 sec (best of 5 consecutive runs) 19.8% faster NOTE: This patch causes new errors in test_array and test_compile, but it seems that these *should* be failing given the input string for long(), unless I'm missing something: ====================================================================== ERROR: test_repr (__main__.FloatTest) ---------------------------------------------------------------------- Traceback (most recent call last): File "Lib/test/test_array.py", line 187, in test_repr self.assertEqual(a, eval(repr(a), {"array": array.array})) ValueError: invalid literal for long(): 10000000000.0 ====================================================================== ERROR: test_repr (__main__.DoubleTest) ---------------------------------------------------------------------- Traceback (most recent call last): File "Lib/test/test_array.py", line 187, in test_repr self.assertEqual(a, eval(repr(a), {"array": array.array})) ValueError: invalid literal for long(): 10000000000.0 ---------------------------------------------------------------------- test test_compile crashed -- exceptions.ValueError: invalid literal for long(): 90000000000000. ---------------------------------------------------------------------- >Comment By: Tim Peters (tim_one) Date: 2005-10-31 19:55 Message: Logged In: YES user_id=31435 This looks pretty good to me -- talk about every trick in the book . Note that the digitlimit vector is too cautious for bases that are powers of 2. For example, it's obvious that any string of 32 bits can't overflow an unsigned long, but the table cuts base 2 off at 31 instead. The formula should use log(2**32, base) instead: "N digits can't overflow" iff base**N-1 < 2**32 iff base**N < 2**32+1 base**N <= 2**32 iff N <= log(2**32, base) Assuming exact calculation of log(2**32, base) then (dubious, really), the floor of that is exactly the maximum safe N. The power-of-2 bases, and base 10, should be added to the tests. We really want to check that _all_ supported bases work, right? ---------------------------------------------------------------------- Comment By: Alan McIntyre (ESRG) (alanmcintyre) Date: 2005-10-24 11:26 Message: Logged In: YES user_id=1115903 Thanks, funny_falcon - that corrected the problem with the literals. I also included the change to the digit lookup table. The new patch is attached as python-mystrtoul4.tgz; it passes all tests now on my machine. ---------------------------------------------------------------------- Comment By: funny_falcon (funny_falcon) Date: 2005-10-24 03:07 Message: Logged In: YES user_id=1290388 Instead of: overflowed: /* spool through remaining characters */ while ((c = Py_CHARMASK(*str)) != '\0') str ++; Shoold be while ((c = Py_CHARMASK(*str)) != '\0') { c = digitlookup[c]; if (c < 0 || c >= base) /* non-"digit" character */ break; str++; } And why not static int digitlookup[] = { 37, 37, 37 ...... }; and if (c >= base) break; ---------------------------------------------------------------------- Comment By: Alan McIntyre (ESRG) (alanmcintyre) Date: 2005-10-24 01:41 Message: Logged In: YES user_id=1115903 I forgot to add that these results were obtained on a PIIIm 833MHz running Linux 2.4.2, GCC 3.2.2, with the Python 2.5a0 CVS source from about 8pm EST Oct 23, 2005. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1335972&group_id=5470 From noreply at sourceforge.net Wed Nov 2 08:11:48 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 01 Nov 2005 23:11:48 -0800 Subject: [Patches] [ python-Patches-1335054 ] Python 2.4.2 doesn't build with "--without-threads" Message-ID: Patches item #1335054, was opened at 2005-10-22 12:51 Message generated for change (Comment added) made by nnorwitz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1335054&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Build Group: Python 2.4 >Status: Closed >Resolution: Out of Date Priority: 5 Submitted By: Gunter Ohrner (interneci) >Assigned to: Neal Norwitz (nnorwitz) Summary: Python 2.4.2 doesn't build with "--without-threads" Initial Comment: Build fix is attached. (Not yet runtime tested.) ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2005-11-01 23:11 Message: Logged In: YES user_id=33168 This was fixed a while ago. Thanks. ---------------------------------------------------------------------- Comment By: Francois Perrad (fperrad) Date: 2005-10-28 00:22 Message: Logged In: YES user_id=1293818 Just an alternate patch : --- pystate.c.orig 2005-10-27 17:35:32.000000000 +0200 +++ pystate.c 2005-10-27 17:47:16.000000000 +0200 @@ -42,10 +42,14 @@ */ static PyInterpreterState *autoInterpreterState = NULL; static int autoTLSkey = 0; + +static void _PyGILState_NoteThreadState(PyThreadState* tstate); #else #define HEAD_INIT() /* Nothing */ #define HEAD_LOCK() /* Nothing */ #define HEAD_UNLOCK() /* Nothing */ + +#define _PyGILState_NoteThreadState(tstate) #endif static PyInterpreterState *interp_head = NULL; @@ -53,8 +57,6 @@ PyThreadState *_PyThreadState_Current = NULL; PyThreadFrameGetter _PyThreadState_GetFrame = NULL; -static void _PyGILState_NoteThreadState(PyThreadState* tstate); - PyInterpreterState * PyInterpreterState_New(void) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1335054&group_id=5470 From noreply at sourceforge.net Wed Nov 2 08:45:31 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 01 Nov 2005 23:45:31 -0800 Subject: [Patches] [ python-Patches-1313939 ] Speedup PyUnicode_DecodeCharmap Message-ID: Patches item #1313939, was opened at 2005-10-05 17:01 Message generated for change (Settings changed) made by lemburg You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1313939&group_id=5470 Please note that this 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: Walter D?rwald (doerwalter) Assigned to: M.-A. Lemburg (lemburg) Summary: Speedup PyUnicode_DecodeCharmap Initial Comment: This patch speeds up PyUnicode_DecodeCharmap() as discussed in the thread: http://mail.python.org/pipermail/python-dev/2005-October/056958.html It makes it possible to pass a unicode string to cPyUnicode_DecodeCharmap() in addition to the dictionary which is still supported. The unicode character at position i in the string is used as the decoded value for byte i. Byte values greater that the length of the string and u"\ufffd" characters in the string are treated as "maps to undefined". ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2005-11-02 08:12 Message: Logged In: YES user_id=33168 MAL, didn't you update the codecs? Is there anything left to do or can this be closed? ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2005-10-09 21:23 Message: Logged In: YES user_id=89016 Assigning to MAL for the codec update ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2005-10-06 22:32 Message: Logged In: YES user_id=89016 Checked in as: Objects/unicodeobject.c 2.232 Lib/test/test_codecs.py 1.27 Doc/api/concrete.tex 1.68 Misc/NEWS 1.1387 ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2005-10-06 20:37 Message: Logged In: YES user_id=38388 Yes, please. ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2005-10-06 18:59 Message: Logged In: YES user_id=89016 > I can regenerate the codecs using gencodec.py, no problem. I > can also change it to create the string mapping. That would be great. So should I check in everything else (i.e. unicodeobject.c and the doc and test changes)? ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2005-10-06 18:02 Message: Logged In: YES user_id=38388 Thanks for the change. I can regenerate the codecs using gencodec.py, no problem. I can also change it to create the string mapping. For reference: the mapping files can be downloaded from ftp.unicode.org. The gencodec.py script then takes the mapping filename as argument and creates a codec .py file from it. Special care has to be taken in that some codecs contains hand-edited details. Note that it's likely that some codecs will have additions or removals - the files on the ftp.unicode.org are updated every now and then and usually contain more up-to-date mappings. For some codecs, you won't find mapping files on the Unicode site - these were then contributed by 3rd parties. ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2005-10-06 17:50 Message: Logged In: YES user_id=89016 > Thanks, Walter. However, you won't get my approval with the > choice of FFFD as meaning "undefined mapping" - that code > point is defined. Please choose a different code that is > documented to never be defined by the Unicode standard. OK, I've updated the patch to use 0xfffe instead. Note that this only work as long as u"\fffe" is a legal Unicode literal. > Also, please explain the new alias 'unicode_1_1_utf_7' : > 'utf_7'. Oops, that was for bug #1245379. Removed > About the make_maps() function: the decoding maps should be > generated by the gencodec.py script instead of doing this a > import time. The dictionaries can then be removed from the > codecs. That's true. I'm still working on that. Do you have any tips on how to do that (what files do I have to download and where do I have to put it and how (and from where) do I have to call gencodec.py). Is this documented somewhere? ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2005-10-06 17:24 Message: Logged In: YES user_id=38388 Thanks, Walter. However, you won't get my approval with the choice of FFFD as meaning "undefined mapping" - that code point is defined. Please choose a different code that is documented to never be defined by the Unicode standard. Also, please explain the new alias 'unicode_1_1_utf_7' : 'utf_7'. About the make_maps() function: the decoding maps should be generated by the gencodec.py script instead of doing this a import time. The dictionaries can then be removed from the codecs. ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2005-10-06 16:45 Message: Logged In: YES user_id=89016 OK, I've updated the patch to include an update of the documentation and a few test and I've simplified codecs.make_maps a bit, since we'll always have a decoding string. 0xFFFD is still used as the undefined marker value. ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2005-10-05 22:39 Message: Logged In: YES user_id=38388 The whole point is finding a replacement code point for the None value in dictionaries. Since None is not a character, a code point should be chosen that is guaranteed to never be assigned. FFFE is such a code point, hence the choice. FFFD is an assigned code point. Note that a mapping to FFFE will always raise an exception and the codec user can then decide to use the replace error handler to have the codec use FFFD instead. It is also very reasonable for a codec to map some characters to FFFD to avoid invoking the exception handling in those cases. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2005-10-05 20:36 Message: Logged In: YES user_id=21627 For decoding, Walter's code is nearly identical to the fastmap decoder: both use a Py_UNICODE array to represent the map, and both use REPLACEMENT CHARACTER to denote a missing target code. I find the use of U+FFFD highly appropriate, and not at all debatable. None of the existing codecs maps any of its characters to U+FFFD, and I would consider it a bug if one did. REPLACEMENT CHARACTER should only be used if there is no approprate character, so no charmap should claim that the appropriate mapping for some by is that character. That you often use U+FFFD in output to denote unmappable characters is a different issue, indeed, Python's "replace" mode does so. It would continue to do so under this patch. ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2005-10-05 19:50 Message: Logged In: YES user_id=38388 The patch looks good, but I'd still like to see whether Hye-Shik's fastmap codec wouldn't be a better and more general solution since it seems to also provide good performance for encoding Unicode strings. That said, you should use a non-code point such as 0xFFFE for meaning "undefined mapping". The Unicode replacement character is not a good choice as this is a very valid character which often actually gets used to replace characters for which no Unicode code point is known. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1313939&group_id=5470 From noreply at sourceforge.net Wed Nov 2 08:12:36 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 01 Nov 2005 23:12:36 -0800 Subject: [Patches] [ python-Patches-1313939 ] Speedup PyUnicode_DecodeCharmap Message-ID: Patches item #1313939, was opened at 2005-10-05 08:01 Message generated for change (Comment added) made by nnorwitz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1313939&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Library (Lib) Group: None Status: Open Resolution: Accepted Priority: 5 Submitted By: Walter D?rwald (doerwalter) Assigned to: M.-A. Lemburg (lemburg) Summary: Speedup PyUnicode_DecodeCharmap Initial Comment: This patch speeds up PyUnicode_DecodeCharmap() as discussed in the thread: http://mail.python.org/pipermail/python-dev/2005-October/056958.html It makes it possible to pass a unicode string to cPyUnicode_DecodeCharmap() in addition to the dictionary which is still supported. The unicode character at position i in the string is used as the decoded value for byte i. Byte values greater that the length of the string and u"\ufffd" characters in the string are treated as "maps to undefined". ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2005-11-01 23:12 Message: Logged In: YES user_id=33168 MAL, didn't you update the codecs? Is there anything left to do or can this be closed? ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2005-10-09 12:23 Message: Logged In: YES user_id=89016 Assigning to MAL for the codec update ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2005-10-06 13:32 Message: Logged In: YES user_id=89016 Checked in as: Objects/unicodeobject.c 2.232 Lib/test/test_codecs.py 1.27 Doc/api/concrete.tex 1.68 Misc/NEWS 1.1387 ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2005-10-06 11:37 Message: Logged In: YES user_id=38388 Yes, please. ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2005-10-06 09:59 Message: Logged In: YES user_id=89016 > I can regenerate the codecs using gencodec.py, no problem. I > can also change it to create the string mapping. That would be great. So should I check in everything else (i.e. unicodeobject.c and the doc and test changes)? ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2005-10-06 09:02 Message: Logged In: YES user_id=38388 Thanks for the change. I can regenerate the codecs using gencodec.py, no problem. I can also change it to create the string mapping. For reference: the mapping files can be downloaded from ftp.unicode.org. The gencodec.py script then takes the mapping filename as argument and creates a codec .py file from it. Special care has to be taken in that some codecs contains hand-edited details. Note that it's likely that some codecs will have additions or removals - the files on the ftp.unicode.org are updated every now and then and usually contain more up-to-date mappings. For some codecs, you won't find mapping files on the Unicode site - these were then contributed by 3rd parties. ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2005-10-06 08:50 Message: Logged In: YES user_id=89016 > Thanks, Walter. However, you won't get my approval with the > choice of FFFD as meaning "undefined mapping" - that code > point is defined. Please choose a different code that is > documented to never be defined by the Unicode standard. OK, I've updated the patch to use 0xfffe instead. Note that this only work as long as u"\fffe" is a legal Unicode literal. > Also, please explain the new alias 'unicode_1_1_utf_7' : > 'utf_7'. Oops, that was for bug #1245379. Removed > About the make_maps() function: the decoding maps should be > generated by the gencodec.py script instead of doing this a > import time. The dictionaries can then be removed from the > codecs. That's true. I'm still working on that. Do you have any tips on how to do that (what files do I have to download and where do I have to put it and how (and from where) do I have to call gencodec.py). Is this documented somewhere? ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2005-10-06 08:24 Message: Logged In: YES user_id=38388 Thanks, Walter. However, you won't get my approval with the choice of FFFD as meaning "undefined mapping" - that code point is defined. Please choose a different code that is documented to never be defined by the Unicode standard. Also, please explain the new alias 'unicode_1_1_utf_7' : 'utf_7'. About the make_maps() function: the decoding maps should be generated by the gencodec.py script instead of doing this a import time. The dictionaries can then be removed from the codecs. ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2005-10-06 07:45 Message: Logged In: YES user_id=89016 OK, I've updated the patch to include an update of the documentation and a few test and I've simplified codecs.make_maps a bit, since we'll always have a decoding string. 0xFFFD is still used as the undefined marker value. ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2005-10-05 13:39 Message: Logged In: YES user_id=38388 The whole point is finding a replacement code point for the None value in dictionaries. Since None is not a character, a code point should be chosen that is guaranteed to never be assigned. FFFE is such a code point, hence the choice. FFFD is an assigned code point. Note that a mapping to FFFE will always raise an exception and the codec user can then decide to use the replace error handler to have the codec use FFFD instead. It is also very reasonable for a codec to map some characters to FFFD to avoid invoking the exception handling in those cases. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2005-10-05 11:36 Message: Logged In: YES user_id=21627 For decoding, Walter's code is nearly identical to the fastmap decoder: both use a Py_UNICODE array to represent the map, and both use REPLACEMENT CHARACTER to denote a missing target code. I find the use of U+FFFD highly appropriate, and not at all debatable. None of the existing codecs maps any of its characters to U+FFFD, and I would consider it a bug if one did. REPLACEMENT CHARACTER should only be used if there is no approprate character, so no charmap should claim that the appropriate mapping for some by is that character. That you often use U+FFFD in output to denote unmappable characters is a different issue, indeed, Python's "replace" mode does so. It would continue to do so under this patch. ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2005-10-05 10:50 Message: Logged In: YES user_id=38388 The patch looks good, but I'd still like to see whether Hye-Shik's fastmap codec wouldn't be a better and more general solution since it seems to also provide good performance for encoding Unicode strings. That said, you should use a non-code point such as 0xFFFE for meaning "undefined mapping". The Unicode replacement character is not a good choice as this is a very valid character which often actually gets used to replace characters for which no Unicode code point is known. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1313939&group_id=5470 From noreply at sourceforge.net Wed Nov 2 05:40:16 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 01 Nov 2005 20:40:16 -0800 Subject: [Patches] [ python-Patches-1337648 ] Elemental Security contribution - parsexml.py Message-ID: Patches item #1337648, was opened at 2005-10-25 18:49 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1337648&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: XML Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: Guido van Rossum (gvanrossum) Assigned to: Guido van Rossum (gvanrossum) Summary: Elemental Security contribution - parsexml.py Initial Comment: This is a module I developed at Elemental for parsing and unparsing certain simple XML structures. It is licensed to the PSF using the contributor agreement. I expect that it will have to be transmogrified somewhat before it enters the standard library, and we'll need to find a good place for it in the xml package. It also needs docs. I will take care of all that in my spare time. ---------------------------------------------------------------------- >Comment By: Martin v. L?wis (loewis) Date: 2005-11-02 05:40 Message: Logged In: YES user_id=21627 There are a number of "simple" APIs out there, such as Fredrik Lundh's ElementTree and Greg Stein's qp_xml, although this is the only one with the notion of a document type. I would encourage to contribute it to PyXML first; it is not clear (to me) that this is somehow a "right" way to do XML processing. For example, it seems limited in the structure of XML content models supported (e.g. no mixed content, no support for preserving the order of child elements). It might be confusing to users if their seemingly simple documents are not properly supported. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1337648&group_id=5470 From noreply at sourceforge.net Wed Nov 2 08:14:46 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 01 Nov 2005 23:14:46 -0800 Subject: [Patches] [ python-Patches-1337051 ] remove 4 ints from PyFrameObject Message-ID: Patches item #1337051, was opened at 2005-10-24 23:18 Message generated for change (Comment added) made by nnorwitz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1337051&group_id=5470 Please note that this 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: Neal Norwitz (nnorwitz) Assigned to: Nobody/Anonymous (nobody) Summary: remove 4 ints from PyFrameObject Initial Comment: Decreases the size of each frame object by 32 bytes. The 4 ints are already in the PyCodeObject. Well, 2 are in there directly (co_nlocals and co_stacksize). The other 2 are the tuple lengths of co_cellvars and co_freevars. I ran pybench before and after the patch. With the patch, the interpreter was .002 seconds slower, ie, noise. I get more variability than that with each recompile. Mostly the change is from using f->f_... to co->co_... ie, no difference in pointer derefs, just deref a different pointer. I don't see a good reason to duplicate the data. ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2005-11-01 23:14 Message: Logged In: YES user_id=33168 Heh, my math sucks. It should be 16 bytes, not 32. Though I got rid of 1 more (f_restricted), so it's really 20 bytes now. I need to clean up the patch and attach here. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1337051&group_id=5470 From noreply at sourceforge.net Wed Nov 2 05:43:34 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 01 Nov 2005 20:43:34 -0800 Subject: [Patches] [ python-Patches-1333679 ] Allow use of non-latin1 chars in interactive shell Message-ID: Patches item #1333679, was opened at 2005-10-21 02:49 Message generated for change (Settings changed) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1333679&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: IDLE Group: None >Status: Closed >Resolution: Rejected Priority: 5 Submitted By: Noam Raphael (noamr) Assigned to: Nobody/Anonymous (nobody) Summary: Allow use of non-latin1 chars in interactive shell Initial Comment: If I type a unicode string, such as u"שלום" in the interactive interpreter in the terminal, it does what I expect - return the unicode string (in this case, u'\u05e9\u05dc\u05d5\u05dd') However, if I type it in IDLE's interactive interpreter, I get something funny - I get a unicode string (u'\xd7\xa9\xd7\x9c\xd7\x95\xd7\x9d'), which is actually u"שלום".decode('utf8').encode('latin1'). This is caused by the PyShell.runsource method, which checks if the source string it gets is unicode, and if so, encodes it using the 'ascii' codec. If this check is removed, so that the unicode object itself gets compiled, everything works out fine. The bottom line: remove the if block starting with "if isinstance(source, types.UnicodeType)", at PyShell.py:589, and everything is fine. Have a good day, Noam ---------------------------------------------------------------------- >Comment By: Martin v. L?wis (loewis) Date: 2005-11-02 05:43 Message: Logged In: YES user_id=21627 This isn't right, though: it will assume that the source is UTF-8 encoded, even though the user would expect a different encoding. The "right" way would be if IDLE compiled the source with IOBindings.encoding. Rejecting this patch. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1333679&group_id=5470 From noreply at sourceforge.net Wed Nov 2 12:27:02 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 02 Nov 2005 03:27:02 -0800 Subject: [Patches] [ python-Patches-1333679 ] Allow use of non-latin1 chars in interactive shell Message-ID: Patches item #1333679, was opened at 2005-10-21 02:49 Message generated for change (Comment added) made by noamr You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1333679&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: IDLE Group: None Status: Closed Resolution: Rejected Priority: 5 Submitted By: Noam Raphael (noamr) Assigned to: Nobody/Anonymous (nobody) Summary: Allow use of non-latin1 chars in interactive shell Initial Comment: If I type a unicode string, such as u"שלום" in the interactive interpreter in the terminal, it does what I expect - return the unicode string (in this case, u'\u05e9\u05dc\u05d5\u05dd') However, if I type it in IDLE's interactive interpreter, I get something funny - I get a unicode string (u'\xd7\xa9\xd7\x9c\xd7\x95\xd7\x9d'), which is actually u"שלום".decode('utf8').encode('latin1'). This is caused by the PyShell.runsource method, which checks if the source string it gets is unicode, and if so, encodes it using the 'ascii' codec. If this check is removed, so that the unicode object itself gets compiled, everything works out fine. The bottom line: remove the if block starting with "if isinstance(source, types.UnicodeType)", at PyShell.py:589, and everything is fine. Have a good day, Noam ---------------------------------------------------------------------- >Comment By: Noam Raphael (noamr) Date: 2005-11-02 13:27 Message: Logged In: YES user_id=679426 But IOBindings.encoding is a hard coded 'latin1', which is certainly not better than 'utf8'. Is there a way to detect the encoding from the current locale? Noam ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2005-11-02 06:43 Message: Logged In: YES user_id=21627 This isn't right, though: it will assume that the source is UTF-8 encoded, even though the user would expect a different encoding. The "right" way would be if IDLE compiled the source with IOBindings.encoding. Rejecting this patch. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1333679&group_id=5470 From noreply at sourceforge.net Wed Nov 2 19:13:05 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 02 Nov 2005 10:13:05 -0800 Subject: [Patches] [ python-Patches-1333679 ] Allow use of non-latin1 chars in interactive shell Message-ID: Patches item #1333679, was opened at 2005-10-21 02:49 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1333679&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: IDLE Group: None Status: Closed Resolution: Rejected Priority: 5 Submitted By: Noam Raphael (noamr) Assigned to: Nobody/Anonymous (nobody) Summary: Allow use of non-latin1 chars in interactive shell Initial Comment: If I type a unicode string, such as u"שלום" in the interactive interpreter in the terminal, it does what I expect - return the unicode string (in this case, u'\u05e9\u05dc\u05d5\u05dd') However, if I type it in IDLE's interactive interpreter, I get something funny - I get a unicode string (u'\xd7\xa9\xd7\x9c\xd7\x95\xd7\x9d'), which is actually u"שלום".decode('utf8').encode('latin1'). This is caused by the PyShell.runsource method, which checks if the source string it gets is unicode, and if so, encodes it using the 'ascii' codec. If this check is removed, so that the unicode object itself gets compiled, everything works out fine. The bottom line: remove the if block starting with "if isinstance(source, types.UnicodeType)", at PyShell.py:589, and everything is fine. Have a good day, Noam ---------------------------------------------------------------------- >Comment By: Martin v. L?wis (loewis) Date: 2005-11-02 19:13 Message: Logged In: YES user_id=21627 No, IOBindings.encoding is not hard coded 'latin1'. It is locale.getdefaultlocale()[1] on Windows, and locale.nl_langinfo(locale.CODESET) on Unix. If these fail, it is 'ascii'. ---------------------------------------------------------------------- Comment By: Noam Raphael (noamr) Date: 2005-11-02 12:27 Message: Logged In: YES user_id=679426 But IOBindings.encoding is a hard coded 'latin1', which is certainly not better than 'utf8'. Is there a way to detect the encoding from the current locale? Noam ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2005-11-02 05:43 Message: Logged In: YES user_id=21627 This isn't right, though: it will assume that the source is UTF-8 encoded, even though the user would expect a different encoding. The "right" way would be if IDLE compiled the source with IOBindings.encoding. Rejecting this patch. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1333679&group_id=5470 From noreply at sourceforge.net Wed Nov 2 19:20:15 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 02 Nov 2005 10:20:15 -0800 Subject: [Patches] [ python-Patches-1346211 ] commands.getstatusoutput() Message-ID: Patches item #1346211, was opened at 2005-11-02 18:20 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1346211&group_id=5470 Please note that this 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: Dawa Lama (dawalama) Assigned to: Nobody/Anonymous (nobody) Summary: commands.getstatusoutput() Initial Comment: when you run a script using > commands.getstatusoutput() I was getting sh in the process list. Looks like the problem was because of >pipe.read() Following if the modification to the module commands.py which runs without the defunct'ing the shell. ============================================= def getstatusoutput( cmd ): """Return (status, output) of executing cmd in a shell.""" import os pipe = os.popen('{ ' + cmd + '; } 2>&1', 'r', 0) try: lines = pipe.readline() finally: sts = pipe.close() if sts is None: sts = 0 if lines[-1:] == '\n'; lines = lines[:-1] return sts, lines ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1346211&group_id=5470 From noreply at sourceforge.net Wed Nov 2 19:21:32 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 02 Nov 2005 10:21:32 -0800 Subject: [Patches] [ python-Patches-1346214 ] Better dead code elimination for the AST compiler Message-ID: Patches item #1346214, was opened at 2005-11-02 19: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=1346214&group_id=5470 Please note that this 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: Rune Holm (titanstar) Assigned to: Nobody/Anonymous (nobody) Summary: Better dead code elimination for the AST compiler Initial Comment: Here's a patch that adds dead code elimination for if 0: style statements, and improves the current dead code elimination for while statements by not performing elimination if the function is a generator. If the last yield statement from a generator is removed, the generator is turned into a regular function, which changes the semantics of the function. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1346214&group_id=5470 From noreply at sourceforge.net Wed Nov 2 19:49:16 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 02 Nov 2005 10:49:16 -0800 Subject: [Patches] [ python-Patches-1346238 ] A constant folding optimization pass for the AST Message-ID: Patches item #1346238, was opened at 2005-11-02 19:49 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1346238&group_id=5470 Please note that this 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: Rune Holm (titanstar) Assigned to: Nobody/Anonymous (nobody) Summary: A constant folding optimization pass for the AST Initial Comment: This patch adds the following: A visitor interface generalized from the existing ast pass code in order to make it easy to write ast passes that only care about specific node types. A constant folding pass that looks for operations involving number or string literals, and calculates these at compile time. Example code snippets that this pass will optimize: 3 + 4 + x => 7 + x 2 ** 2 ** 2 => 16 4 and 5 and x and 6 => x and 6 4 or 5 or x => 4 4 and 5 and ~6 => -7 When combined with patch 1346214, the compiler will also optimize statements like if 2**2**2 - 16: expensive_computation() => nothing The patch adds two new files: Include/optimize.h and Python.optimize.c. This was done because I anticipate adding more AST optimizations later using the same visitor interface, and Python/compile.c is already very crowded with byte code generation and bytecode optimization. If new files aren't desired, I could easily change the pass to add the extra code to compile.c This patch combined with patch 1346214 passes the unit tests on all the platforms I've tested it on, namely: macos 10.3/ppc linux/x86 linux/amd64 linux/ppc linux/ia64 valgrind on linux/x86 does not reveal any additional leaks or uninitialized accesses that aren't already in the svn head. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1346238&group_id=5470 From noreply at sourceforge.net Wed Nov 2 19:57:28 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 02 Nov 2005 10:57:28 -0800 Subject: [Patches] [ python-Patches-1346211 ] commands.getstatusoutput() Message-ID: Patches item #1346211, was opened at 2005-11-02 18:20 Message generated for change (Comment added) made by dawalama You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1346211&group_id=5470 Please note that this 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: Dawa Lama (dawalama) Assigned to: Nobody/Anonymous (nobody) Summary: commands.getstatusoutput() Initial Comment: when you run a script using > commands.getstatusoutput() I was getting sh in the process list. Looks like the problem was because of >pipe.read() Following if the modification to the module commands.py which runs without the defunct'ing the shell. ============================================= def getstatusoutput( cmd ): """Return (status, output) of executing cmd in a shell.""" import os pipe = os.popen('{ ' + cmd + '; } 2>&1', 'r', 0) try: lines = pipe.readline() finally: sts = pipe.close() if sts is None: sts = 0 if lines[-1:] == '\n'; lines = lines[:-1] return sts, lines ---------------------------------------------------------------------- >Comment By: Dawa Lama (dawalama) Date: 2005-11-02 18:57 Message: Logged In: YES user_id=517642 def getstatusoutput( cmd ): """Return (status, output) of executing cmd in a shell.""" import os pipe = os.popen('{ ' + cmd + '; } 2>&1', 'r', 0) lines = None try: lines = pipe.readline() finally: sts = pipe.close() if sts is None: sts = 0 if lines[-1:] == '\n'; lines = lines[:-1] ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1346211&group_id=5470 From noreply at sourceforge.net Thu Nov 3 04:43:17 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 02 Nov 2005 19:43:17 -0800 Subject: [Patches] [ python-Patches-1346572 ] Remove inconsistent behavior between import and zipimport Message-ID: Patches item #1346572, was opened at 2005-11-03 01:43 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1346572&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Core (C code) Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: Osvaldo Santana Neto (acidbase) Assigned to: Nobody/Anonymous (nobody) Summary: Remove inconsistent behavior between import and zipimport Initial Comment: Look the inconsistent behavior: $ ls modulo_c.pyc modulo_o.pyo $ zip modulos.zip modulo_o.pyo modulo_c.pyc adding: modulo_o.pyo (deflated 38%) adding: modulo_c.pyc (deflated 38%) $ ls modulo_c.pyc modulo_o.pyo modulos.zip $ python2.4 >>> import modulo_c modulo_c >>> import modulo_o ImportError: No module named modulo_o $ python2.4 -O >>> import modulo_c ImportError: No module named modulo_c >>> import modulo_o modulo_o $ rm *.pyc *.pyo $ ls modulos.zip $ PYTHONPATH=modulos.zip python2.4 >>> import modulo_c modulo_c >>> import modulo_o modulo_o $ PYTHONPATH=modulos.zip python2.4 -O >>> import modulo_c modulo_c >>> import modulo_o modulo_o ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1346572&group_id=5470 From noreply at sourceforge.net Fri Nov 4 14:59:26 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 04 Nov 2005 05:59:26 -0800 Subject: [Patches] [ python-Patches-1339673 ] cross compile and mingw support Message-ID: Patches item #1339673, was opened at 2005-10-27 18:18 Message generated for change (Comment added) made by janneke-sf You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1339673&group_id=5470 Please note that this 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: Jan Nieuwenhuizen (janneke-sf) Assigned to: Nobody/Anonymous (nobody) Summary: cross compile and mingw support Initial Comment: The cross compile patch is similar to what I did for Guile and has still some bits from Daniel Goertzen's https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1006238&group_id=5470 The mingw patch is based on Matthias Kramm's https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1053879&group_id=5470 but adds autoconf tests and does have his C modifications. -- Jan Nieuwenhuizen | GNU LilyPond - The music typesetter http://www.xs4all.nl/~jantien | http://www.lilypond.org ---------------------------------------------------------------------- >Comment By: Jan Nieuwenhuizen (janneke-sf) Date: 2005-11-04 14:59 Message: Logged In: YES user_id=1368960 The second mingw patch actually produces a working python, fixing * loadable dll modules * argv0 relocation * posixflavour nt -- Jan. ---------------------------------------------------------------------- Comment By: Jan Nieuwenhuizen (janneke-sf) Date: 2005-10-27 18:20 Message: Logged In: YES user_id=1368960 .... and does NOT have his C modifications ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1339673&group_id=5470 From noreply at sourceforge.net Sat Nov 5 18:06:17 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 05 Nov 2005 09:06:17 -0800 Subject: [Patches] [ python-Patches-1349117 ] Patch f. bug 495682 cannot handle http_proxy with user:pass@ Message-ID: Patches item #1349117, was opened at 2005-11-05 18: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=1349117&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Library (Lib) Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: Johannes Nicolai (jonico) Assigned to: Nobody/Anonymous (nobody) Summary: Patch f. bug 495682 cannot handle http_proxy with user:pass@ Initial Comment: solves problems for http and https proxies described in this bug solves tracebacks if proxy is specified for a protocol where no proxy is currently supported added dynamic proxy authentification for http and https solved bug that if a host accessed by the https protocol requires authentification, the https proxy won't be used after questioning the password ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1349117&group_id=5470 From noreply at sourceforge.net Sat Nov 5 18:06:17 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 05 Nov 2005 09:06:17 -0800 Subject: [Patches] [ python-Patches-1349118 ] Patch f. bug 495682 cannot handle http_proxy with user:pass@ Message-ID: Patches item #1349118, was opened at 2005-11-05 18:05 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1349118&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Library (Lib) Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: Johannes Nicolai (jonico) Assigned to: Nobody/Anonymous (nobody) Summary: Patch f. bug 495682 cannot handle http_proxy with user:pass@ Initial Comment: solves problems for http and https proxies described in this bug solves tracebacks if proxy is specified for a protocol where no proxy is currently supported added dynamic proxy authentification for http and https solved bug that if a host accessed by the https protocol requires authentification, the https proxy won't be used after questioning the password ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1349118&group_id=5470 From noreply at sourceforge.net Sat Nov 5 23:30:37 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 05 Nov 2005 14:30:37 -0800 Subject: [Patches] [ python-Patches-1349117 ] Patch f. bug 495682 cannot handle http_proxy with user:pass@ Message-ID: Patches item #1349117, was opened at 2005-11-05 18:05 Message generated for change (Comment added) made by birkenfeld You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1349117&group_id=5470 Please note that this 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: Duplicate Priority: 5 Submitted By: Johannes Nicolai (jonico) Assigned to: Nobody/Anonymous (nobody) Summary: Patch f. bug 495682 cannot handle http_proxy with user:pass@ Initial Comment: solves problems for http and https proxies described in this bug solves tracebacks if proxy is specified for a protocol where no proxy is currently supported added dynamic proxy authentification for http and https solved bug that if a host accessed by the https protocol requires authentification, the https proxy won't be used after questioning the password ---------------------------------------------------------------------- >Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-11-05 23:30 Message: Logged In: YES user_id=1188172 Duplicate of #1349118. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1349117&group_id=5470 From noreply at sourceforge.net Sun Nov 6 01:18:03 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 05 Nov 2005 16:18:03 -0800 Subject: [Patches] [ python-Patches-1349274 ] [PATCH] 100x optimization for ngettext Message-ID: Patches item #1349274, was opened at 2005-11-06 00: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=1349274&group_id=5470 Please note that this 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: Joe Wreschnig (piman) Assigned to: Nobody/Anonymous (nobody) Summary: [PATCH] 100x optimization for ngettext Initial Comment: Currently gettext.ngettext scans the filesystem whenever you call it. This makes it ridiculously slow. But if one uses gettext.install to initialize gettext, gettext.ngettext is the cleanest way to do plural translation. This patch makes gettext.install install both "_" and "ngettext" into the builtin namespace, which means using "ngettext" won't have to do the filesystem lookup. My benchmarks show this is about 100 times faster. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1349274&group_id=5470 From noreply at sourceforge.net Sun Nov 6 20:08:37 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 06 Nov 2005 11:08:37 -0800 Subject: [Patches] [ python-Patches-1346214 ] Better dead code elimination for the AST compiler Message-ID: Patches item #1346214, was opened at 2005-11-02 20:21 Message generated for change (Comment added) made by sdahlbac You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1346214&group_id=5470 Please note that this 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: Rune Holm (titanstar) Assigned to: Nobody/Anonymous (nobody) Summary: Better dead code elimination for the AST compiler Initial Comment: Here's a patch that adds dead code elimination for if 0: style statements, and improves the current dead code elimination for while statements by not performing elimination if the function is a generator. If the last yield statement from a generator is removed, the generator is turned into a regular function, which changes the semantics of the function. ---------------------------------------------------------------------- Comment By: Simon Dahlbacka (sdahlbac) Date: 2005-11-06 21:08 Message: Logged In: YES user_id=750513 the actual patch is missing.. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1346214&group_id=5470 From noreply at sourceforge.net Sun Nov 6 20:10:23 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 06 Nov 2005 11:10:23 -0800 Subject: [Patches] [ python-Patches-1346238 ] A constant folding optimization pass for the AST Message-ID: Patches item #1346238, was opened at 2005-11-02 20:49 Message generated for change (Comment added) made by sdahlbac You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1346238&group_id=5470 Please note that this 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: Rune Holm (titanstar) Assigned to: Nobody/Anonymous (nobody) Summary: A constant folding optimization pass for the AST Initial Comment: This patch adds the following: A visitor interface generalized from the existing ast pass code in order to make it easy to write ast passes that only care about specific node types. A constant folding pass that looks for operations involving number or string literals, and calculates these at compile time. Example code snippets that this pass will optimize: 3 + 4 + x => 7 + x 2 ** 2 ** 2 => 16 4 and 5 and x and 6 => x and 6 4 or 5 or x => 4 4 and 5 and ~6 => -7 When combined with patch 1346214, the compiler will also optimize statements like if 2**2**2 - 16: expensive_computation() => nothing The patch adds two new files: Include/optimize.h and Python.optimize.c. This was done because I anticipate adding more AST optimizations later using the same visitor interface, and Python/compile.c is already very crowded with byte code generation and bytecode optimization. If new files aren't desired, I could easily change the pass to add the extra code to compile.c This patch combined with patch 1346214 passes the unit tests on all the platforms I've tested it on, namely: macos 10.3/ppc linux/x86 linux/amd64 linux/ppc linux/ia64 valgrind on linux/x86 does not reveal any additional leaks or uninitialized accesses that aren't already in the svn head. ---------------------------------------------------------------------- Comment By: Simon Dahlbacka (sdahlbac) Date: 2005-11-06 21:10 Message: Logged In: YES user_id=750513 the actual patch is missing... ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1346238&group_id=5470 From noreply at sourceforge.net Sun Nov 6 20:21:24 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 06 Nov 2005 11:21:24 -0800 Subject: [Patches] [ python-Patches-1349274 ] [PATCH] 100x optimization for ngettext Message-ID: Patches item #1349274, was opened at 2005-11-06 01:18 Message generated for change (Comment added) made by birkenfeld You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1349274&group_id=5470 Please note that this 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: Joe Wreschnig (piman) Assigned to: Nobody/Anonymous (nobody) Summary: [PATCH] 100x optimization for ngettext Initial Comment: Currently gettext.ngettext scans the filesystem whenever you call it. This makes it ridiculously slow. But if one uses gettext.install to initialize gettext, gettext.ngettext is the cleanest way to do plural translation. This patch makes gettext.install install both "_" and "ngettext" into the builtin namespace, which means using "ngettext" won't have to do the filesystem lookup. My benchmarks show this is about 100 times faster. ---------------------------------------------------------------------- >Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-11-06 20:21 Message: Logged In: YES user_id=1188172 The problem you diagnosed is valid, but I don't think the patch is a proper way to salvage it (by cluttering the builtin namespace). I'd rather have the installed name "_" point to a wrapper object that gives one access to the other translation functions. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1349274&group_id=5470 From noreply at sourceforge.net Sun Nov 6 21:41:36 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 06 Nov 2005 12:41:36 -0800 Subject: [Patches] [ python-Patches-1346214 ] Better dead code elimination for the AST compiler Message-ID: Patches item #1346214, was opened at 2005-11-02 19:21 Message generated for change (Comment added) made by titanstar You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1346214&group_id=5470 Please note that this 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: Rune Holm (titanstar) Assigned to: Nobody/Anonymous (nobody) Summary: Better dead code elimination for the AST compiler Initial Comment: Here's a patch that adds dead code elimination for if 0: style statements, and improves the current dead code elimination for while statements by not performing elimination if the function is a generator. If the last yield statement from a generator is removed, the generator is turned into a regular function, which changes the semantics of the function. ---------------------------------------------------------------------- >Comment By: Rune Holm (titanstar) Date: 2005-11-06 21:41 Message: Logged In: YES user_id=858364 Sorry, I'm new to the sourceforge patch tracker. The patch should be attached now. ---------------------------------------------------------------------- Comment By: Simon Dahlbacka (sdahlbac) Date: 2005-11-06 20:08 Message: Logged In: YES user_id=750513 the actual patch is missing.. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1346214&group_id=5470 From noreply at sourceforge.net Sun Nov 6 21:42:46 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 06 Nov 2005 12:42:46 -0800 Subject: [Patches] [ python-Patches-1346238 ] A constant folding optimization pass for the AST Message-ID: Patches item #1346238, was opened at 2005-11-02 19:49 Message generated for change (Comment added) made by titanstar You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1346238&group_id=5470 Please note that this 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: Rune Holm (titanstar) Assigned to: Nobody/Anonymous (nobody) Summary: A constant folding optimization pass for the AST Initial Comment: This patch adds the following: A visitor interface generalized from the existing ast pass code in order to make it easy to write ast passes that only care about specific node types. A constant folding pass that looks for operations involving number or string literals, and calculates these at compile time. Example code snippets that this pass will optimize: 3 + 4 + x => 7 + x 2 ** 2 ** 2 => 16 4 and 5 and x and 6 => x and 6 4 or 5 or x => 4 4 and 5 and ~6 => -7 When combined with patch 1346214, the compiler will also optimize statements like if 2**2**2 - 16: expensive_computation() => nothing The patch adds two new files: Include/optimize.h and Python.optimize.c. This was done because I anticipate adding more AST optimizations later using the same visitor interface, and Python/compile.c is already very crowded with byte code generation and bytecode optimization. If new files aren't desired, I could easily change the pass to add the extra code to compile.c This patch combined with patch 1346214 passes the unit tests on all the platforms I've tested it on, namely: macos 10.3/ppc linux/x86 linux/amd64 linux/ppc linux/ia64 valgrind on linux/x86 does not reveal any additional leaks or uninitialized accesses that aren't already in the svn head. ---------------------------------------------------------------------- >Comment By: Rune Holm (titanstar) Date: 2005-11-06 21:42 Message: Logged In: YES user_id=858364 Sorry, I'm new to the sourceforge patch tracker. The patch should be attached now. ---------------------------------------------------------------------- Comment By: Simon Dahlbacka (sdahlbac) Date: 2005-11-06 20:10 Message: Logged In: YES user_id=750513 the actual patch is missing... ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1346238&group_id=5470 From noreply at sourceforge.net Sun Nov 6 21:59:26 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 06 Nov 2005 12:59:26 -0800 Subject: [Patches] [ python-Patches-1349274 ] [PATCH] 100x optimization for ngettext Message-ID: Patches item #1349274, was opened at 2005-11-06 00:18 Message generated for change (Comment added) made by piman You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1349274&group_id=5470 Please note that this 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: Joe Wreschnig (piman) Assigned to: Nobody/Anonymous (nobody) Summary: [PATCH] 100x optimization for ngettext Initial Comment: Currently gettext.ngettext scans the filesystem whenever you call it. This makes it ridiculously slow. But if one uses gettext.install to initialize gettext, gettext.ngettext is the cleanest way to do plural translation. This patch makes gettext.install install both "_" and "ngettext" into the builtin namespace, which means using "ngettext" won't have to do the filesystem lookup. My benchmarks show this is about 100 times faster. ---------------------------------------------------------------------- >Comment By: Joe Wreschnig (piman) Date: 2005-11-06 20:59 Message: Logged In: YES user_id=796 It seems to me that the time to complain about namespace clutter was when gettext.install was written. Besides, it's only "clutter" if you're not using it, and if you're not using it, just don't call install. Making _ dispatch on the number of arguments would break all the existing string extraction tools. It's also unintuitive for anyone coming from gettext in other languages. It's also messy semantic overloading. ---------------------------------------------------------------------- Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-11-06 19:21 Message: Logged In: YES user_id=1188172 The problem you diagnosed is valid, but I don't think the patch is a proper way to salvage it (by cluttering the builtin namespace). I'd rather have the installed name "_" point to a wrapper object that gives one access to the other translation functions. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1349274&group_id=5470 From noreply at sourceforge.net Mon Nov 7 11:27:23 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 07 Nov 2005 02:27:23 -0800 Subject: [Patches] [ python-Patches-1349118 ] Patch f. bug 495682 cannot handle http_proxy with user:pass@ Message-ID: Patches item #1349118, was opened at 2005-11-05 18:05 Message generated for change (Comment added) made by jonico You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1349118&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Library (Lib) Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: Johannes Nicolai (jonico) Assigned to: Nobody/Anonymous (nobody) Summary: Patch f. bug 495682 cannot handle http_proxy with user:pass@ Initial Comment: solves problems for http and https proxies described in this bug solves tracebacks if proxy is specified for a protocol where no proxy is currently supported added dynamic proxy authentification for http and https solved bug that if a host accessed by the https protocol requires authentification, the https proxy won't be used after questioning the password ---------------------------------------------------------------------- >Comment By: Johannes Nicolai (jonico) Date: 2005-11-07 11:27 Message: Logged In: YES user_id=863272 Perhaps some words about the accuracy of the patch: I have successfully tested it with squid 2.5 and squid 3.0 as http and https proxy with and without password. I used the integrated test routines in urllib.py ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1349118&group_id=5470 From noreply at sourceforge.net Mon Nov 7 16:33:19 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 07 Nov 2005 07:33:19 -0800 Subject: [Patches] [ python-Patches-1350409 ] Fix for signal related abort in Visual Studio 2005 Message-ID: Patches item #1350409, was opened at 2005-11-07 17: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=1350409&group_id=5470 Please note that this 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: Adal Chiriliuc (adalx) Assigned to: Nobody/Anonymous (nobody) Summary: Fix for signal related abort in Visual Studio 2005 Initial Comment: See #1167262 and #1311784. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1350409&group_id=5470 From noreply at sourceforge.net Mon Nov 7 21:14:49 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 07 Nov 2005 12:14:49 -0800 Subject: [Patches] [ python-Patches-1350658 ] Redundant connect() call in logging.handlers.SysLogHandler Message-ID: Patches item #1350658, was opened at 2005-11-07 15:14 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1350658&group_id=5470 Please note that this 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: Ken Lalonde (kenlalonde) Assigned to: Nobody/Anonymous (nobody) Summary: Redundant connect() call in logging.handlers.SysLogHandler Initial Comment: Visual inspection of _connect_unixsocket() in Lib/logging/handlers.py shows that, in the absence of an exception, a DGRAM socket will always be connected twice. This is likely harmless, but also pointless. The attached patch against today's CVS simply omits the second connect() call. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1350658&group_id=5470 From noreply at sourceforge.net Mon Nov 7 21:30:10 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 07 Nov 2005 12:30:10 -0800 Subject: [Patches] [ python-Patches-1349274 ] [PATCH] 100x optimization for ngettext Message-ID: Patches item #1349274, was opened at 2005-11-06 01:18 Message generated for change (Comment added) made by birkenfeld You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1349274&group_id=5470 Please note that this 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: Joe Wreschnig (piman) Assigned to: Nobody/Anonymous (nobody) Summary: [PATCH] 100x optimization for ngettext Initial Comment: Currently gettext.ngettext scans the filesystem whenever you call it. This makes it ridiculously slow. But if one uses gettext.install to initialize gettext, gettext.ngettext is the cleanest way to do plural translation. This patch makes gettext.install install both "_" and "ngettext" into the builtin namespace, which means using "ngettext" won't have to do the filesystem lookup. My benchmarks show this is about 100 times faster. ---------------------------------------------------------------------- >Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-11-07 21:30 Message: Logged In: YES user_id=1188172 I didn't mean to overload the calling of "_", but I can think of "_.gettext()", "_.ngettext()" etc. Of course with "_()" staying the same. Other than that, if you need ngettext in builtins, why don't you write your own install function? ---------------------------------------------------------------------- Comment By: Joe Wreschnig (piman) Date: 2005-11-06 21:59 Message: Logged In: YES user_id=796 It seems to me that the time to complain about namespace clutter was when gettext.install was written. Besides, it's only "clutter" if you're not using it, and if you're not using it, just don't call install. Making _ dispatch on the number of arguments would break all the existing string extraction tools. It's also unintuitive for anyone coming from gettext in other languages. It's also messy semantic overloading. ---------------------------------------------------------------------- Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-11-06 20:21 Message: Logged In: YES user_id=1188172 The problem you diagnosed is valid, but I don't think the patch is a proper way to salvage it (by cluttering the builtin namespace). I'd rather have the installed name "_" point to a wrapper object that gives one access to the other translation functions. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1349274&group_id=5470 From noreply at sourceforge.net Mon Nov 7 22:41:07 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 07 Nov 2005 13:41:07 -0800 Subject: [Patches] [ python-Patches-1349274 ] [PATCH] 100x optimization for ngettext Message-ID: Patches item #1349274, was opened at 2005-11-06 00:18 Message generated for change (Comment added) made by piman You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1349274&group_id=5470 Please note that this 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: Joe Wreschnig (piman) Assigned to: Nobody/Anonymous (nobody) Summary: [PATCH] 100x optimization for ngettext Initial Comment: Currently gettext.ngettext scans the filesystem whenever you call it. This makes it ridiculously slow. But if one uses gettext.install to initialize gettext, gettext.ngettext is the cleanest way to do plural translation. This patch makes gettext.install install both "_" and "ngettext" into the builtin namespace, which means using "ngettext" won't have to do the filesystem lookup. My benchmarks show this is about 100 times faster. ---------------------------------------------------------------------- >Comment By: Joe Wreschnig (piman) Date: 2005-11-07 21:41 Message: Logged In: YES user_id=796 Well, I did write my own install function; that's the patch you see below. I figured I'd submit it in the interest of other users (that's the point of a standard library, right?) but if the Pythonic thing to do is choose between ugly or slow, I guess I'll just keep using my own. ---------------------------------------------------------------------- Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-11-07 20:30 Message: Logged In: YES user_id=1188172 I didn't mean to overload the calling of "_", but I can think of "_.gettext()", "_.ngettext()" etc. Of course with "_()" staying the same. Other than that, if you need ngettext in builtins, why don't you write your own install function? ---------------------------------------------------------------------- Comment By: Joe Wreschnig (piman) Date: 2005-11-06 20:59 Message: Logged In: YES user_id=796 It seems to me that the time to complain about namespace clutter was when gettext.install was written. Besides, it's only "clutter" if you're not using it, and if you're not using it, just don't call install. Making _ dispatch on the number of arguments would break all the existing string extraction tools. It's also unintuitive for anyone coming from gettext in other languages. It's also messy semantic overloading. ---------------------------------------------------------------------- Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-11-06 19:21 Message: Logged In: YES user_id=1188172 The problem you diagnosed is valid, but I don't think the patch is a proper way to salvage it (by cluttering the builtin namespace). I'd rather have the installed name "_" point to a wrapper object that gives one access to the other translation functions. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1349274&group_id=5470 From noreply at sourceforge.net Tue Nov 8 00:21:52 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 07 Nov 2005 15:21:52 -0800 Subject: [Patches] [ python-Patches-1350409 ] Fix for signal related abort in Visual Studio 2005 Message-ID: Patches item #1350409, was opened at 2005-11-07 16:31 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1350409&group_id=5470 Please note that this 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: Adal Chiriliuc (adalx) Assigned to: Nobody/Anonymous (nobody) Summary: Fix for signal related abort in Visual Studio 2005 Initial Comment: See #1167262 and #1311784. ---------------------------------------------------------------------- >Comment By: Martin v. L?wis (loewis) Date: 2005-11-08 00:21 Message: Logged In: YES user_id=21627 What precise version of visual studio did you use to develop this patch? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1350409&group_id=5470 From noreply at sourceforge.net Tue Nov 8 00:48:23 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 07 Nov 2005 15:48:23 -0800 Subject: [Patches] [ python-Patches-1350409 ] Fix for signal related abort in Visual Studio 2005 Message-ID: Patches item #1350409, was opened at 2005-11-07 17:31 Message generated for change (Comment added) made by adalx You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1350409&group_id=5470 Please note that this 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: Adal Chiriliuc (adalx) Assigned to: Nobody/Anonymous (nobody) Summary: Fix for signal related abort in Visual Studio 2005 Initial Comment: See #1167262 and #1311784. ---------------------------------------------------------------------- >Comment By: Adal Chiriliuc (adalx) Date: 2005-11-08 01:48 Message: Logged In: YES user_id=1067739 Microsoft Visual Studio 2005 Professional Edition Version 8.0.50727.42 (RTM 050727-4200) It's the final version (RTM=Release To Manufacture), released a week ago on MSDN. I understand that it should be available in stores starting from today. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2005-11-08 01:21 Message: Logged In: YES user_id=21627 What precise version of visual studio did you use to develop this patch? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1350409&group_id=5470 From noreply at sourceforge.net Tue Nov 8 03:12:22 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 07 Nov 2005 18:12:22 -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 jdalambert 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: 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 Tue Nov 8 03:33:48 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 07 Nov 2005 18:33:48 -0800 Subject: [Patches] [ python-Patches-1350573 ] zlib.crc32 doesn't handle 0xffffffff seed Message-ID: Patches item #1350573, was opened at 2005-11-07 10:25 Message generated for change (Settings changed) made by nnorwitz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1350573&group_id=5470 Please note that this 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: Danny Yoo (dyoo) Assigned to: Nobody/Anonymous (nobody) Summary: zlib.crc32 doesn't handle 0xffffffff seed Initial Comment: Reported by John Schmidt: zlibc.crc32 doesn't appear to properly parse its seed argument. For example: ###### >>> zlib.crc32('foobar',0xFFFFFFFF)) OverflowError: long int too large to convert to int ###### This appears to be fixed if we make the included patch to zlibmodule. I haven't tested this on a 64-bit platform, though; can someone look into this? Hope this helps! ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1350573&group_id=5470 From noreply at sourceforge.net Tue Nov 8 09:08:26 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 08 Nov 2005 00:08:26 -0800 Subject: [Patches] [ python-Patches-1351020 ] PythonD DJGPP-specific patch set for porting to DOS. Message-ID: Patches item #1351020, was opened at 2005-11-08 09:08 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1351020&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Ben Decker (bdeck) Assigned to: Nobody/Anonymous (nobody) Summary: PythonD DJGPP-specific patch set for porting to DOS. Initial Comment: This is our initial recommendation for PythonD specific patch set running in DOS. Build requires at least DJGPP 2.04 32-bit DOS compiler (see http://www.delorie.com/djgpp/) and Watt-32 tcp/ip stack for DJGPP (see http://www.bgnett.no/~giva/). Operates under MSDOS, FreeDOS, Win32 and NT. Requires DOS mode long filename driver/TSR. See http://www.caddit.net/pythond.htm for details concerning the PythonD project. Diffed against 2.4.2 Final distribution. Diff script used: #! /usr/bin/bash for file in `find . -name *.orig -print` do export filename=`echo -n $file | sed -e 's/\.orig$//'` diff -c $file $filename >> pythond.diff done ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1351020&group_id=5470 From noreply at sourceforge.net Tue Nov 8 09:32:17 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 08 Nov 2005 00:32:17 -0800 Subject: [Patches] [ python-Patches-1351036 ] PythonD new file: python2.4/plat-ms-dos5/djstat.py Message-ID: Patches item #1351036, was opened at 2005-11-08 09:32 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1351036&group_id=5470 Please note that this 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: Ben Decker (bdeck) Assigned to: Nobody/Anonymous (nobody) Summary: PythonD new file: python2.4/plat-ms-dos5/djstat.py Initial Comment: This file is referenced in the previous PythonD patch set, but itself was not present. DJGPP provides different stat values than most other OSes, appearantly. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1351036&group_id=5470 From noreply at sourceforge.net Tue Nov 8 14:41:32 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 08 Nov 2005 05:41:32 -0800 Subject: [Patches] [ python-Patches-1350658 ] Redundant connect() call in logging.handlers.SysLogHandler Message-ID: Patches item #1350658, was opened at 2005-11-07 20:14 Message generated for change (Comment added) made by vsajip You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1350658&group_id=5470 Please note that this 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: Ken Lalonde (kenlalonde) >Assigned to: Vinay Sajip (vsajip) Summary: Redundant connect() call in logging.handlers.SysLogHandler Initial Comment: Visual inspection of _connect_unixsocket() in Lib/logging/handlers.py shows that, in the absence of an exception, a DGRAM socket will always be connected twice. This is likely harmless, but also pointless. The attached patch against today's CVS simply omits the second connect() call. ---------------------------------------------------------------------- >Comment By: Vinay Sajip (vsajip) Date: 2005-11-08 13:41 Message: Logged In: YES user_id=308438 The bug is valid but the patch is not :-( The exception clause tries to open a TCP socket and this needs to be connected. So the correct fix (I think) is to indent the second connect() call. I will check the change into SVN later. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1350658&group_id=5470 From noreply at sourceforge.net Tue Nov 8 14:47:54 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 08 Nov 2005 05:47:54 -0800 Subject: [Patches] [ python-Patches-1069624 ] incomplete support for AF_PACKET in socketmodule.c Message-ID: Patches item #1069624, was opened at 2004-11-19 19:00 Message generated for change (Settings changed) made by gustavo You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1069624&group_id=5470 Please note that this 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: Gustavo J. A. M. Carneiro (gustavo) Assigned to: Nobody/Anonymous (nobody) Summary: incomplete support for AF_PACKET in socketmodule.c Initial Comment: A comment in the source documents the AF_PACKET address format: - an AF_PACKET socket address is a tuple containing a string specifying the ethernet interface and an integer specifying the Ethernet protocol number to be received. For example: ("eth0",0x1234). Optional 3rd,4th,5th elements in the tuple specify packet-type and ha-type/addr -- these are ignored by networking code, but accepted since they are returned by the getsockname() method. The part that says "these are ignored by networking code," is clearly innacurate when comparing with the packet(7) man page: "(...)Packets sent through a SOCK_DGRAM packet socket get a suitable physical layer header based on the information in the sockaddr_ll destination address before they are queued.(...)" Attached patch copies the passed in addr into the sockaddr structure. It is against Python 2.3.4. ---------------------------------------------------------------------- Comment By: Gustavo J. A. M. Carneiro (gustavo) Date: 2005-03-26 12:54 Message: Logged In: YES user_id=908 Oh, I just noticed this patch (fixed) was committed to CVS before 2.4/2.5 branching! Thanks! Guess this can be closed now... ---------------------------------------------------------------------- Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-03-03 15:23 Message: Logged In: YES user_id=1188172 >From the patch: + addr->sll_halen = hatype; + addr->sll_halen = halen; This doesn't seem to make sense, so the upper line can be removed. Also, you are mixing tabs and spaces. ---------------------------------------------------------------------- Comment By: Gustavo J. A. M. Carneiro (gustavo) Date: 2004-11-19 19:19 Message: Logged In: YES user_id=908 And just now I actually tested this patch. It works! While before the ethernet frame was sent with broadcast destination address, now it goes with a correct destination address. This should go into python 2.3.x as well. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1069624&group_id=5470 From noreply at sourceforge.net Tue Nov 8 15:05:48 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 08 Nov 2005 06:05:48 -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: 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 Tue Nov 8 15:26:04 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 08 Nov 2005 06:26:04 -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 jdalambert 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: 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 Tue Nov 8 16:09:18 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 08 Nov 2005 07:09:18 -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: 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 Tue Nov 8 17:06:57 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 08 Nov 2005 08:06:57 -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 jdalambert 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: 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 Tue Nov 8 18:34:35 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 08 Nov 2005 09:34:35 -0800 Subject: [Patches] [ python-Patches-1350658 ] Redundant connect() call in logging.handlers.SysLogHandler Message-ID: Patches item #1350658, was opened at 2005-11-07 15:14 Message generated for change (Comment added) made by kenlalonde You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1350658&group_id=5470 Please note that this 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: Ken Lalonde (kenlalonde) Assigned to: Vinay Sajip (vsajip) Summary: Redundant connect() call in logging.handlers.SysLogHandler Initial Comment: Visual inspection of _connect_unixsocket() in Lib/logging/handlers.py shows that, in the absence of an exception, a DGRAM socket will always be connected twice. This is likely harmless, but also pointless. The attached patch against today's CVS simply omits the second connect() call. ---------------------------------------------------------------------- >Comment By: Ken Lalonde (kenlalonde) Date: 2005-11-08 12:34 Message: Logged In: YES user_id=203927 Thanks for the quick response. Perhaps my original post was unclear, but the patch I included does precisely as you suggest: it indents the second call. ---------------------------------------------------------------------- Comment By: Vinay Sajip (vsajip) Date: 2005-11-08 08:41 Message: Logged In: YES user_id=308438 The bug is valid but the patch is not :-( The exception clause tries to open a TCP socket and this needs to be connected. So the correct fix (I think) is to indent the second connect() call. I will check the change into SVN later. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1350658&group_id=5470 From noreply at sourceforge.net Tue Nov 8 23:45:10 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 08 Nov 2005 14:45:10 -0800 Subject: [Patches] [ python-Patches-1351744 ] askyesnocancel helper for tkMessageBox Message-ID: Patches item #1351744, was opened at 2005-11-08 23:45 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1351744&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Tkinter Group: None Status: Open Resolution: None Priority: 5 Submitted By: Fredrik Lundh (effbot) Assigned to: Martin v. L?wis (loewis) Summary: askyesnocancel helper for tkMessageBox Initial Comment: This patch adds a an askyesnocancel helper to the tkMessageBox support module. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1351744&group_id=5470 From noreply at sourceforge.net Tue Nov 8 23:51:51 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 08 Nov 2005 14:51:51 -0800 Subject: [Patches] [ python-Patches-1324762 ] Compiling and linking main() with C++ compiler Message-ID: Patches item #1324762, was opened at 2005-10-12 13:45 Message generated for change (Comment added) made by jackjansen You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1324762&group_id=5470 Please note that this 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: Christoph Ludwig (cludwig) Assigned to: Nobody/Anonymous (nobody) Summary: Compiling and linking main() with C++ compiler Initial Comment: The attached patch proposes a resolution to the discussion started in regarding the compiler (C vs. C++) used to compile python's main() and to link the executable. The patch contains the following changes: 1) The configure option --with-cxx is renamed --with-cxx-main. This was done to avoid surprising the user by the changed meaning. Furthermore, it is now possible that CXX has a different value than provided by --with-cxx-main, so the old name would have been confusing. 2) The compiler used to translate python's main() function is stored in the configure / Makefile variable MAINCC. By default, MAINCC=$(CC). If --with-cxx-main is given (without an appended compiler name), then MAINCC=$(CXX). If --with-cxx-main= is on the configure command line, then MAINCC=. Additionally, configure sets CXX= unless CXX was already set on the configure command line. 3) The command used to link the python executable is (as before) stored in LINKCC. By default, LINKCC='$(PURIFY) $(MAINCC)', i.e. the linker front-end is the compiler used to translate main(). If necessary, LINKCC can be set on the configure command line in which case it won't be altered. 4) If CXX is not set by the user (on the command line or via --with-cxx-main), then configure tries several likely C++ compiler names. CXX is assigned the first name that refers to a callable program in the system. (CXX is set even if python is built with a C compiler only, so distutils can build C++ extensions.) 5) Modules/ccpython.cc is no longer used and can be removed. ---------------------------------------------------------------------- >Comment By: Jack Jansen (jackjansen) Date: 2005-11-08 23:51 Message: Logged In: YES user_id=45365 One question: is step 4 a wise idea? Picking a random C++ compiler if multiple are available may result in picking a vendor C++ when the user has specified CC=gcc, for example. OTOH, actually doing the configure magic to determine that the selected C++ works together with the c-compiler selected for Python may be overkill too. Maybe try only standard combinations cc/c++ gcc/g++ and otherwise require --with{out}-cxx? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1324762&group_id=5470 From noreply at sourceforge.net Wed Nov 9 10:05:52 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 09 Nov 2005 01:05:52 -0800 Subject: [Patches] [ python-Patches-1351997 ] fix for resource leak in _subprocess Message-ID: Patches item #1351997, was opened at 2005-11-09 10: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=1351997&group_id=5470 Please note that this 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: Fredrik Lundh (effbot) Assigned to: Nobody/Anonymous (nobody) Summary: fix for resource leak in _subprocess Initial Comment: The _subprocess CreateProcess driver may leak if you pass in an explicit environment dictionary. This trivial patch fixes this. Can be backported to 2.3 and 2.4. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1351997&group_id=5470 From noreply at sourceforge.net Wed Nov 9 14:59:32 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 09 Nov 2005 05:59:32 -0800 Subject: [Patches] [ python-Patches-1350658 ] Redundant connect() call in logging.handlers.SysLogHandler Message-ID: Patches item #1350658, was opened at 2005-11-07 20:14 Message generated for change (Comment added) made by vsajip You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1350658&group_id=5470 Please note that this 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: Ken Lalonde (kenlalonde) Assigned to: Vinay Sajip (vsajip) Summary: Redundant connect() call in logging.handlers.SysLogHandler Initial Comment: Visual inspection of _connect_unixsocket() in Lib/logging/handlers.py shows that, in the absence of an exception, a DGRAM socket will always be connected twice. This is likely harmless, but also pointless. The attached patch against today's CVS simply omits the second connect() call. ---------------------------------------------------------------------- >Comment By: Vinay Sajip (vsajip) Date: 2005-11-09 13:59 Message: Logged In: YES user_id=308438 Sorry, I didn't look at the patch - I just looked at your comment. The fix is now checked into the Subversion repository. Thanks for the patch. ---------------------------------------------------------------------- Comment By: Ken Lalonde (kenlalonde) Date: 2005-11-08 17:34 Message: Logged In: YES user_id=203927 Thanks for the quick response. Perhaps my original post was unclear, but the patch I included does precisely as you suggest: it indents the second call. ---------------------------------------------------------------------- Comment By: Vinay Sajip (vsajip) Date: 2005-11-08 13:41 Message: Logged In: YES user_id=308438 The bug is valid but the patch is not :-( The exception clause tries to open a TCP socket and this needs to be connected. So the correct fix (I think) is to indent the second connect() call. I will check the change into SVN later. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1350658&group_id=5470 From G.S.-Design at t-online.de Wed Nov 9 19:50:41 2005 From: G.S.-Design at t-online.de (G.S.-Design@t-online.de) Date: Wed, 9 Nov 2005 19:50:41 +0100 Subject: [Patches] I would not like to trouble you Message-ID: <1EZv1t-0hXmTk0@fwd29.sul.t-online.de> therefore my question, Is it permits for you that I make an offer to you. If yes, please send remail to me. If no, please you excuse this mail. Yours sincerely W. Riemer -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.python.org/pipermail/patches/attachments/20051109/829bbdf8/attachment.html From noreply at sourceforge.net Thu Nov 10 01:43:52 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 09 Nov 2005 16:43:52 -0800 Subject: [Patches] [ python-Patches-1352711 ] [PATCH] Bug #1351707 Message-ID: Patches item #1352711, was opened at 2005-11-10 10:43 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1352711&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Thomas Lee (krumms) Assigned to: Nobody/Anonymous (nobody) Summary: [PATCH] Bug #1351707 Initial Comment: Fix for bug #1351707 - zipimport.zipimporter raises incomplete IOError instances. Patch based on a suggestion by Fred L. Drake, Jr., who submitted the bug report. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1352711&group_id=5470 From noreply at sourceforge.net Thu Nov 10 02:19:42 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 09 Nov 2005 17:19:42 -0800 Subject: [Patches] [ python-Patches-1352731 ] Small upgrades to platform.platform() Message-ID: Patches item #1352731, was opened at 2005-11-10 01:19 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1352731&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Library (Lib) Group: None Status: Open Resolution: None Priority: 5 Submitted By: daishi harada (daishiharada) Assigned to: Nobody/Anonymous (nobody) Summary: Small upgrades to platform.platform() Initial Comment: This patch updates platform.platform() to recognize some more Linux distributions. In addition, for RedHat-like distributions, will use the contents of the /etc/ to determine distname. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1352731&group_id=5470 From noreply at sourceforge.net Thu Nov 10 02:23:05 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 09 Nov 2005 17:23:05 -0800 Subject: [Patches] [ python-Patches-1352731 ] Small upgrades to platform.platform() Message-ID: Patches item #1352731, was opened at 2005-11-10 01:19 Message generated for change (Comment added) made by daishiharada You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1352731&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Library (Lib) Group: None Status: Open Resolution: None Priority: 5 Submitted By: daishi harada (daishiharada) >Assigned to: M.-A. Lemburg (lemburg) Summary: Small upgrades to platform.platform() Initial Comment: This patch updates platform.platform() to recognize some more Linux distributions. In addition, for RedHat-like distributions, will use the contents of the /etc/ to determine distname. ---------------------------------------------------------------------- >Comment By: daishi harada (daishiharada) Date: 2005-11-10 01:23 Message: Logged In: YES user_id=493197 assigning to lemberg as suggested in the file. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1352731&group_id=5470 From noreply at sourceforge.net Thu Nov 10 06:53:55 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 09 Nov 2005 21:53:55 -0800 Subject: [Patches] [ python-Patches-1351997 ] fix for resource leak in _subprocess Message-ID: Patches item #1351997, was opened at 2005-11-09 01:05 Message generated for change (Comment added) made by nnorwitz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1351997&group_id=5470 Please note that this 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: Fredrik Lundh (effbot) Assigned to: Nobody/Anonymous (nobody) Summary: fix for resource leak in _subprocess Initial Comment: The _subprocess CreateProcess driver may leak if you pass in an explicit environment dictionary. This trivial patch fixes this. Can be backported to 2.3 and 2.4. ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2005-11-09 21:53 Message: Logged In: YES user_id=33168 /f did you want to check this in yourself? I'm not sure if you have an svn account or if you want one. I can check it in if you'd like. See also bug #1346547. There is another problem in this area (lines 379/380) should check if an error occurred. I can't test this stuff, but if you test, I can check in. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1351997&group_id=5470 From noreply at sourceforge.net Thu Nov 10 19:42:23 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 10 Nov 2005 10:42:23 -0800 Subject: [Patches] [ python-Patches-1324762 ] Compiling and linking main() with C++ compiler Message-ID: Patches item #1324762, was opened at 2005-10-12 13:45 Message generated for change (Comment added) made by cludwig You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1324762&group_id=5470 Please note that this 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: Christoph Ludwig (cludwig) Assigned to: Nobody/Anonymous (nobody) Summary: Compiling and linking main() with C++ compiler Initial Comment: The attached patch proposes a resolution to the discussion started in regarding the compiler (C vs. C++) used to compile python's main() and to link the executable. The patch contains the following changes: 1) The configure option --with-cxx is renamed --with-cxx-main. This was done to avoid surprising the user by the changed meaning. Furthermore, it is now possible that CXX has a different value than provided by --with-cxx-main, so the old name would have been confusing. 2) The compiler used to translate python's main() function is stored in the configure / Makefile variable MAINCC. By default, MAINCC=$(CC). If --with-cxx-main is given (without an appended compiler name), then MAINCC=$(CXX). If --with-cxx-main= is on the configure command line, then MAINCC=. Additionally, configure sets CXX= unless CXX was already set on the configure command line. 3) The command used to link the python executable is (as before) stored in LINKCC. By default, LINKCC='$(PURIFY) $(MAINCC)', i.e. the linker front-end is the compiler used to translate main(). If necessary, LINKCC can be set on the configure command line in which case it won't be altered. 4) If CXX is not set by the user (on the command line or via --with-cxx-main), then configure tries several likely C++ compiler names. CXX is assigned the first name that refers to a callable program in the system. (CXX is set even if python is built with a C compiler only, so distutils can build C++ extensions.) 5) Modules/ccpython.cc is no longer used and can be removed. ---------------------------------------------------------------------- >Comment By: Christoph Ludwig (cludwig) Date: 2005-11-10 19:42 Message: Logged In: YES user_id=1266029 I am going to upload a revision of my patch that addresses jackjansen's comment: It sets CXX to g++ or c++ if CC is gcc or cc, respectively. Additionally, it writes a warning if configure had to "guess" the C++ compiler and tells the user how to override this guess. The change is in lin with jackjansen's second suggestion. It is pretty straight forward and avoids fragile configure magic. ---------------------------------------------------------------------- Comment By: Jack Jansen (jackjansen) Date: 2005-11-08 23:51 Message: Logged In: YES user_id=45365 One question: is step 4 a wise idea? Picking a random C++ compiler if multiple are available may result in picking a vendor C++ when the user has specified CC=gcc, for example. OTOH, actually doing the configure magic to determine that the selected C++ works together with the c-compiler selected for Python may be overkill too. Maybe try only standard combinations cc/c++ gcc/g++ and otherwise require --with{out}-cxx? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1324762&group_id=5470 From noreply at sourceforge.net Thu Nov 10 23:48:07 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 10 Nov 2005 14:48:07 -0800 Subject: [Patches] [ python-Patches-1351997 ] fix for resource leak in _subprocess Message-ID: Patches item #1351997, was opened at 2005-11-09 10:05 Message generated for change (Comment added) made by effbot You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1351997&group_id=5470 Please note that this 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: Fredrik Lundh (effbot) >Assigned to: Neal Norwitz (nnorwitz) Summary: fix for resource leak in _subprocess Initial Comment: The _subprocess CreateProcess driver may leak if you pass in an explicit environment dictionary. This trivial patch fixes this. Can be backported to 2.3 and 2.4. ---------------------------------------------------------------------- >Comment By: Fredrik Lundh (effbot) Date: 2005-11-10 23:48 Message: Logged In: YES user_id=38376 I've updated the patch to address #1346547 as well. If you have the time, feel free to check this in. I don't have a proper account set up yet (but I promise to fix that soon). thanks /F ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2005-11-10 06:53 Message: Logged In: YES user_id=33168 /f did you want to check this in yourself? I'm not sure if you have an svn account or if you want one. I can check it in if you'd like. See also bug #1346547. There is another problem in this area (lines 379/380) should check if an error occurred. I can't test this stuff, but if you test, I can check in. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1351997&group_id=5470 From noreply at sourceforge.net Fri Nov 11 04:35:16 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 10 Nov 2005 19:35:16 -0800 Subject: [Patches] [ python-Patches-1337648 ] Elemental Security contribution - parsexml.py Message-ID: Patches item #1337648, was opened at 2005-10-25 12:49 Message generated for change (Comment added) made by gvanrossum You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1337648&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: XML Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: Guido van Rossum (gvanrossum) Assigned to: Guido van Rossum (gvanrossum) Summary: Elemental Security contribution - parsexml.py Initial Comment: This is a module I developed at Elemental for parsing and unparsing certain simple XML structures. It is licensed to the PSF using the contributor agreement. I expect that it will have to be transmogrified somewhat before it enters the standard library, and we'll need to find a good place for it in the xml package. It also needs docs. I will take care of all that in my spare time. ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2005-11-10 22:35 Message: Logged In: YES user_id=6380 Understood. It is very different from ElementTree; I'll have to look at qp_xml. The emphasis of parsexml.py is on converting Python data structures to/from XML, rather than supporting all of XML. What exactly do you mean by contributing to PyXML? Do you mean bring it up on the xml-sig list? ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2005-11-01 23:40 Message: Logged In: YES user_id=21627 There are a number of "simple" APIs out there, such as Fredrik Lundh's ElementTree and Greg Stein's qp_xml, although this is the only one with the notion of a document type. I would encourage to contribute it to PyXML first; it is not clear (to me) that this is somehow a "right" way to do XML processing. For example, it seems limited in the structure of XML content models supported (e.g. no mixed content, no support for preserving the order of child elements). It might be confusing to users if their seemingly simple documents are not properly supported. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1337648&group_id=5470 From noreply at sourceforge.net Fri Nov 11 12:51:35 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 11 Nov 2005 03:51:35 -0800 Subject: [Patches] [ python-Patches-1353872 ] a faster Modulefinder Message-ID: Patches item #1353872, was opened at 2005-11-11 12:51 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1353872&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Thomas Heller (theller) Assigned to: Nobody/Anonymous (nobody) Summary: a faster Modulefinder Initial Comment: py2exe uses Python's modulefinder to find the modules and packages that belong to one or more scripts. For not too small projects, the runtime of modulefinder is quite long. On my system, the time to find all 533 modules my project needs is around 48 seconds. So, I profiled the Python 2.4 modulefinder, and patched it for a speedup of a factor of ~2.5 - the time required to find the modules drops to around 19 seconds. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1353872&group_id=5470 From noreply at sourceforge.net Fri Nov 11 13:02:45 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 11 Nov 2005 04:02:45 -0800 Subject: [Patches] [ python-Patches-1353872 ] a faster Modulefinder Message-ID: Patches item #1353872, was opened at 2005-11-11 12:51 Message generated for change (Comment added) made by theller You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1353872&group_id=5470 Please note that this 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: Thomas Heller (theller) Assigned to: Nobody/Anonymous (nobody) Summary: a faster Modulefinder Initial Comment: py2exe uses Python's modulefinder to find the modules and packages that belong to one or more scripts. For not too small projects, the runtime of modulefinder is quite long. On my system, the time to find all 533 modules my project needs is around 48 seconds. So, I profiled the Python 2.4 modulefinder, and patched it for a speedup of a factor of ~2.5 - the time required to find the modules drops to around 19 seconds. ---------------------------------------------------------------------- >Comment By: Thomas Heller (theller) Date: 2005-11-11 13:02 Message: Logged In: YES user_id=11105 Here is a description of the changes in the patch: Modulefinder's scan_code method did call ord() on each character of the co.co_code string, that took the most time, and it built the argument (again with ord() calls) of each bytecode that had one, even if it was never used. The patch changes the code to - work on the characters of the co.co_code string, avoiding the calls to ord() altogether - create the bytecodes argument only when needed, - create the bytecode with struct.pack which is faster. I did not stop there, so other changes were that the objects that scan_code needs most are passed as default arguments to the functions instead of looking them up in the global namespace. This patch will probably be in the next py2exe release, so it will undergo some testing. I would appreciate comments on the patch. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1353872&group_id=5470 From noreply at sourceforge.net Fri Nov 11 18:47:20 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 11 Nov 2005 09:47:20 -0800 Subject: [Patches] [ python-Patches-1301512 ] desktop module (providing startfile as open, all platforms) Message-ID: Patches item #1301512, was opened at 2005-09-23 18:30 Message generated for change (Comment added) made by pboddie You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1301512&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Library (Lib) Group: None Status: Open Resolution: None Priority: 5 Submitted By: Paul Boddie (pboddie) Assigned to: Nobody/Anonymous (nobody) Summary: desktop module (providing startfile as open, all platforms) Initial Comment: Currently, in Python's standard library, there is apparently no coherent, cross-platform way of getting the user's environment to "open" files or resources (ie. show such files in browsers, editors) when requested by a Python program. There is an os.startfile function which works for Windows, but no equivalent function for other desktop environments - the webbrowser module seems to employ alternative mechanisms in choosing and running external programs and presumably does not seek to provide general support for non-URL resources anyway. Since desktop environments like KDE and GNOME provide mechanisms for running browsers and editors according to the identified type of a file or resource, just as Windows "runs" files or resources, it is appropriate to have a module which accesses these mechanisms. Attached is a simple module which seeks to support KDE, GNOME and Windows - the latter using the existing os.startfile support - and which could be extended to support other desktop environments such as Mac OS X, XFCE, CDE (along with others deemed important and feasible enough to support). Note that this approach is arguably better than that employed by the webbrowser module since most desktop environments already provide mechanisms for configuring and choosing the user's preferred programs for various activities, whereas the webbrowser module makes relatively uninformed guesses (eg. opening Firefox on a KDE desktop configured to use Konqueror as the default browser). Note also that the startfile function is arguably misplaced in the os module; thus, this functionality is supplied as a new module rather than as a patch to the os module, and the name of the function is "open" (like in the webbrowser module) rather than "startfile" which is a fairly Windows specific term. One could also envisage the desktop module residing within the os package to avoid top-level namespace pollution. Recent discussion in the comp.lang.python thread "Open PDF" covering this issue can be found here: http://groups.google.no/group/comp.lang.python/browse_frm/thread/8e00f7c1ccfae166/6168b6728cf64cb7 ---------------------------------------------------------------------- >Comment By: Paul Boddie (pboddie) Date: 2005-11-11 18:47 Message: Logged In: YES user_id=226443 Another reference to DESKTOP_LAUNCH: http://www.openoffice.org/issues/show_bug.cgi?id=37708 ---------------------------------------------------------------------- Comment By: Paul Boddie (pboddie) Date: 2005-10-01 01:54 Message: Logged In: YES user_id=226443 I've removed the attachments from this item and uploaded a proper package to PyPI: http://www.python.org/pypi/desktop I still think it's worth keeping this item open, even though it was never really a patch as such, because I still believe the need is there for the standard library. Moreover, I've licensed the code according to the PSF criteria in order to satisfy that eventual objective. ---------------------------------------------------------------------- Comment By: John J Lee (jjlee) Date: 2005-09-27 12:50 Message: Logged In: YES user_id=261020 Mike: I'm unpersuaded, but I've nothing to add to what I've already said, so I'll shut up now :-) ---------------------------------------------------------------------- Comment By: Paul Boddie (pboddie) Date: 2005-09-27 12:07 Message: Logged In: YES user_id=226443 Well, the latest attachment (the first in the list) goes some way towards providing user override support. I've since posted to the xdg mailing list asking for clarification about environment variables. As for the code, I've now changed the way the environment variable is used - it must be a shell-quoted command plus optional arguments. ---------------------------------------------------------------------- Comment By: Mike Meyer (mwm) Date: 2005-09-27 03:14 Message: Logged In: YES user_id=93910 I purposely avoided dealing with the "better off using os.system" before, because I didn't think it was relevant. Since you seem to think it's right, let's deal with it. First of all, the code isn't that simple. You want a convention for your environment variable that's flexible enough to deal with the three cases (kde, gnome and OS X) we already have. Just tossing a string to Popen won't cut it. The split() done by the current implementation is problematical - OS X at the very least comes with standard directories with spaces in their names. I'm not proposing a solution to that here - just pointing out the problem. You're advocating that, instead of putting this functionality in desktop, we leave it up to every application writer to write it. That means - at the very least - that every application writer now has to write if os.environ.has_key("DESKTOP_LAUNCH"): else: desktop.open(filename) rather than simply doing: desktop.open(filename) It also means that every application writer has to decide how they're going to deal with possible spaces in the file name in the environment variable, or if they are at all. And they also get to decide which of the various proposed environment variable names they want to use. If the user is lucky, they won't have two applications that use the same name with different conventions. If not, well, that would just suck. Second, if another a standard does emerge, you can fix all the applications by fixing *one* file in stdlib. Better yet, ithe fix can be transitioned in smoothly for all applications by working with that one file. Basically, *not* providing this hook is simply poor software engineering - it makes things harder on the developers, harder on the users, and harder on the maintainers in the future. While not wanting to push forward standards may be a good thing, it's certainly not a reason for doing a wrong thing. ---------------------------------------------------------------------- Comment By: John J Lee (jjlee) Date: 2005-09-27 02:20 Message: Logged In: YES user_id=261020 Quite correct about desktop meaning (roughly) what it says, rather than "opener": my mistake. And I see we are all in agreement about what environment variables are for. But, as Paul says, """the decisions then made by the function aren't themselves configurable, but then a developer would arguably be better off using os.system at that point.""" The correct way of dealing with things like these proposed opener environment vars in the Python stdlib at this point in time (in the absence of anything very close to an accepted wider standard) is for applications to do this: if os.environ.has_key("USER_KNOWS_BETTER"): obey_user(fn) else: desktop.open(fn) where one would expect obey_user() to be a one-liner: def obey_user(fn): subprocess.Popen(os.environ["DESKTOP_OPENER"]) So what is to be gained by baking some random new "standard" into the Python stdlib? Clearly, any individual application obeying some such environment var gains little without others following suit with the *same* env var, but that is no reason to include code knowing about eg. OPENER in the stdlib; in fact, that's precisely the reason such code shouldn't be included right now: we don't know what env var (or other mechanism) other apps will end up using. I don't think de facto semi-standardisation across "applications using Python 2.5 and the desktop module" is likely to gain much momentum or prove very useful to the vast majority of end users, but it does make life that extra little bit more complicated for future users and maintainers of Python, and for users and maintainers of applications wishing to "start" files. I suppose you could try and argue that OPENER is simply an implementation detail of open() that should be changed when and if some standard env var name or other mechanism becomes popular, but that doesn't make sense to me: first, we would be exposing this detail to "end-users" (or else what use is it), and second, the presence of code such as the if os.environ.has_key("OPENER") in the last version of desktop.py I looked at makes life slightly *harder* for applications who know about newer, more widespread conventions than some old version of desktop.py knows about. Finally, I don't know what to make of your (Mike) comment that "neither of those carries as much weight with me as running code". Writing code is simply not the problem here: the (obey_user()) code is almost as simple as it gets. The problem here is almost entirely about getting agreement with other people, which, yes, means sometimes-tiresome discussions. Sometimes it means trying to generate de-facto standards and leave those tiresome discussions in the dust, agreed: I guess I'm stating my opinion here that the Python stdlib is not the place to do that, for the reasons I enumerated above and in my ealier post (2005-09-26 00:34). Foolishly trusting in the sanity of humankind, I think that KDE and GNOME will *eventually* get their act together. Am I just totally wrongheaded about this? OK, I must stop this nonsense, perhaps this is just one of those bikesheds... ---------------------------------------------------------------------- Comment By: Paul Boddie (pboddie) Date: 2005-09-26 15:08 Message: Logged In: YES user_id=226443 I've now attached another version of the module which observes DESKTOP_LAUNCH, does a bit more verification, and exposes the desktop detection. I'll probably do a bit more reading of the fd.o mailing lists and possibly try and get some answers from the interested parties. ---------------------------------------------------------------------- Comment By: Mike Meyer (mwm) Date: 2005-09-26 04:25 Message: Logged In: YES user_id=93910 Actually, the guess that the module makes is which desktop the user is on - and that's overridable by the "desktop" argument. The pre-OPENER version of desktop.py had no way to override it's choice of opener - the best you can do is tell it to use the default opener for some desktop it knows about. Further, the "desktop" argument is really only applicable to the application developer. The end-user - the person who actually chooses the launcher to use - can't use it without editing the source to the application. While you may consider this an acceptable configuration mechanism, I don't. The standard Unix mechanism for setting things like this - dating back to the 70s - is an environment variable that names the command to use. If you want to suggest a better mechanism, feel free to do so. Until then the question is what the name should be. Based on what the freedesktop talk, maybe it shold be DESKTOP_OPEN or DESKTOP_LAUNCH. On the other hand, the freedesktop folks seem much better at generating discussion than specifications - and neither of those carries as much weight with me as running code. Part of this does depend on the point of the desktop module. I thought it was to make os.startfile functionality available in a platform-independent manner. If so, it needs to deal with things other than the tools provided by a couple of common desktops. If instead it's supposed to provide access to the knowledge built into the most popular desktops, then ignoring user preferences is reasonable. But that makes it much less usefull. ---------------------------------------------------------------------- Comment By: Paul Boddie (pboddie) Date: 2005-09-26 02:55 Message: Logged In: YES user_id=226443 Oh, and after the DESKTOP specification, there was the DESKTOP_LAUNCH specification: http://lists.freedesktop.org/archives/xdg/2004-August/004489.html Things happen slowly in desktop standardisation land. Searching for usage of DESKTOP_LAUNCH revealed this interesting script: http://www.mail-archive.com/dashboard-hackers%40gnome.org/msg00762/desktop-launch ---------------------------------------------------------------------- Comment By: Paul Boddie (pboddie) Date: 2005-09-26 02:45 Message: Logged In: YES user_id=226443 On environment variables, here's a thread discussing them: http://lists.freedesktop.org/archives/xdg/2004-December/005553.html The discussion ranges from environment variables referring to the desktop (DESKTOP) and a launcher (DESKTOP_LAUNCH) or some kind of information program (DESKTOP_CTL), all the way to such variables referencing .so files which are then dlopened. The abstraction elevator/escalator is thankfully stopped before things get any more complicated. A previous thread (mentioned in the above thread) proposes the DESKTOP variable and the alternative DESKTOP_OPEN variable: http://lists.freedesktop.org/archives/xdg/2004-May/003942.html The above thread continues here, proposing DESKTOP again along with a desktop-open script, later shifting to some people favouring DESKTOP_LAUNCH and some favouring a desktop-launch script: http://lists.freedesktop.org/archives/xdg/2004-May/003995.html A standards document mentioned in the last thread: http://primates.ximian.com/~michael/desktop.txt ---------------------------------------------------------------------- Comment By: Paul Boddie (pboddie) Date: 2005-09-26 02:14 Message: Logged In: YES user_id=226443 Actually, "desktop" just provides a way of saying "I'm on KDE not GNOME!" or something similar; the decisions then made by the function aren't themselves configurable, but then a developer would arguably be better off using os.system at that point. The module is really supposed to encapsulate knowledge about how to start programs in various desktop environments, along with a means to detect those environments in the first place. If you as a programmer disagree with the detection, override it; if you as a programmer know better, don't use the function... but do send a patch! As for user overrides, something like OPENER might be needed to get around the decisions taken in the module, although something "lighter" like DESKTOP might also be useful to override just the detection. It astounds me that such simple things haven't been agreed on by the freedesktop people, or at least not in any obvious way. ---------------------------------------------------------------------- Comment By: John J Lee (jjlee) Date: 2005-09-26 01:34 Message: Logged In: YES user_id=261020 Why does the desktop module need something more than Paul's "desktop" argument? (Though perhaps "desktop" is not a sufficiently general name, as I think you said.) I don't think it's desirable for Python to start introducing half-baked and nonstandard environment variable conventions, especially in this area. 1. Why should other people start following *Python*'s convention here? 2. Any such convention may be overtaken by efforts with more backing (such as freedesktop), leaving us with cruft in the stdlib, perhaps even cruft that's in conflict with the new standards (what if somebody with actual clout mandates START instead? something will break). 3. Any program that wants to can follow this supposed OPENER convention, without needing to bake it into the stdlib. Having said all that, if you can get agreement from people at freedesktop to agree on OPENER (which might well be possible), and I guess set a useful default at desktop startup, I will worship at your feet ;-) I'm not sure what you mean by "the guesses that the module makes". It makes exactly one guess: which opener to use, and that guess is overridable with the "desktop" argument to open(). ---------------------------------------------------------------------- Comment By: Mike Meyer (mwm) Date: 2005-09-26 00:01 Message: Logged In: YES user_id=93910 I suggested OPENER because I saw it in use somewhere while looking for things for open. I couldn't find it when I went looking for it to reply to this. Clearly, the desktop module needs some way for the user to say "I don't care what you think the system looks like - use *this*." If there's a standard for that, we should use it. If there isn't a standard, we get to establish one. Putting it in the beta version so people can play with it is a good idea. Until the module is accepted, nothing is wired down, and testers should know that. Open has been announced in a number of places. It doesn't have it's own web page yet. You can find a link to the tarball at http://www.mired.org/downloads/. It's also listed in PyPI. Other than it's existence showing that desktop needs a way for user to override the guesses the module makes (which the OSS launch tool does for OS X as well), this isn't really the place to discuss open. I've addressed the issues raised here about open in the README file that was posted in the 0.3 version. Further discussion should go to me directly, or to the Python list/newsgroup. If you think it belongs in another forum, please let me know. ---------------------------------------------------------------------- Comment By: John J Lee (jjlee) Date: 2005-09-25 17:57 Message: Logged In: YES user_id=261020 If OPENER is not standard in any way (ad hoc or otherwise), why add it? Moght not doing that without talking to other people about it (presumably on freedesktop, including GNOME, KDE. etc. people) be positively harmful? Mike: is this Python version of Apple's "open" actually published on the web somewhere? I can't find it. I also notice that "open" is already in use as a shell wrapper around open (2) the system call. "start" seems unused, FWTW here. ---------------------------------------------------------------------- Comment By: Paul Boddie (pboddie) Date: 2005-09-25 16:26 Message: Logged In: YES user_id=226443 I've uploaded a version which supports OPENER, although I can't find any references to that variable anywhere. By the way, I wonder if the open program's preferences couldn't somehow work with the various freedesktop.org standards if they don't already. ---------------------------------------------------------------------- Comment By: Mike Meyer (mwm) Date: 2005-09-25 03:01 Message: Logged In: YES user_id=93910 open is a desktop-independent variation on gnome-open and kfmclient. So it's something that desktop could be set up to run, using cmd = ["open", url]. On the other hand, it also exposes an API to Python progams, so you could (in theory) replace Unix-specific parts of desktop with (using the development version): from open import run run(filename, have = ['open']) except that it'd use the users "open" preferences instead of their desktop preferences. This is why I proposed the OPENER environment variable. I don't run a desktop, so the proposed version would default to trying os.startfile. I'd rather it use open. KDE Components->File Associations to do that. All of those editors are installed on my machine. Then I attempted to open this text file: $ file /home/john/test.txt /home/john/test.txt: ASCII text $ cat /home/john/test.txt hello, world $ When I open it by clicking on it from a Konqueror directory listing, GNU emacs running in an X11 window starts up, with the specified file opened. When I use your module: $ python2.4 Python 2.4 (#1, Feb 19 2005, 23:54:54) [GCC 3.3.2 20031218 (Gentoo Linux 3.3.2-r5, propolice-3.3-7)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> import desktop >>> desktop.open("/home/john/blocking.txt") >>> ...it opens in Konqueror with some embedded editor (KEdit or KWrite, I assume), not directly in any of the editors I specified, and certainly not in emacs. Same applies if I use a URL: >>> desktop.open("file:///home/john/test.txt") This doesn't seem to be the intended behaviour of your module. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1301512&group_id=5470 From noreply at sourceforge.net Fri Nov 11 22:40:48 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 11 Nov 2005 13:40:48 -0800 Subject: [Patches] [ python-Patches-1097671 ] Info Associated with Merge to AST Message-ID: Patches item #1097671, was opened at 2005-01-07 01:28 Message generated for change (Settings changed) made by kbk You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1097671&group_id=5470 Please note that this 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: AST >Status: Closed Resolution: Accepted Priority: 5 Submitted By: Kurt B. Kaiser (kbk) Assigned to: Kurt B. Kaiser (kbk) Summary: Info Associated with Merge to AST Initial Comment: Attached file is the output of the merge from MAIN to ast-branch. -j mrg_to_ast-branch_24APR03 (24 April 2003 17:30 UTC) (estimated time of first merge) -j mrg_to_ast-branch_05JAN05 (05 January 2005 08:23 UTC) C Include/compile.h C Include/symtable.h C Lib/distutils/sysconfig.py C Lib/test/test_compile.py NOT MERGED C Lib/test/output/test_profile C Modules/main.c C Objects/listobject.c C Objects/tupleobject.c C Python/bltinmodule.c C Python/compile.c NOT MERGED C Python/future.c C Python/pythonrun.c C Python/symtable.c Other conflicts resolved. ---------------------------------------------------------------------- >Comment By: Kurt B. Kaiser (kbk) Date: 2005-11-11 16:40 Message: Logged In: YES user_id=149084 Missing directories are a non-issue because of the method Jeremy used to land the branch. ---------------------------------------------------------------------- Comment By: Kurt B. Kaiser (kbk) Date: 2005-04-30 15:12 Message: Logged In: YES user_id=149084 logging package missing: That's a good question. It was added after the AST branch was created and didn't get tagged with the mrg_to_ast-branch_24APR03 tag for some reason.... Researching. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2005-04-26 02:22 Message: Logged In: YES user_id=357491 Kurt, what happened to the logging package? ---------------------------------------------------------------------- Comment By: Kurt B. Kaiser (kbk) Date: 2005-04-24 22:05 Message: Logged In: YES user_id=149084 The change to test_compile.py looks ok, probably the best solution since there have been many changes on MAIN. There have been 11 updates to Python.c since the merge from 5 Jan tag. The AST crew probably should look at them so we don't get too far behind. We will need to do another merge from MAIN at some point. Let me know. Closing this Tracker item. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2005-04-24 18:06 Message: Logged In: YES user_id=357491 rev. 1.10.10.4 has the checked-in copy. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2005-04-24 14:23 Message: Logged In: YES user_id=357491 That was my plan. And no need for the patch, logistix. Easier for me to just copy from release24-maint into ast-branch and check it in. Thanks for the offer, though. ---------------------------------------------------------------------- Comment By: logistix (logistix) Date: 2005-04-23 16:38 Message: Logged In: YES user_id=699438 I took a look at test_compile to see how bad the conflicts were and it doesn't look good. On the ast-branch, it was rewritten to use doctests. On the main branch, it was rewritten to use unittest. So everything is out of whack due to two completely differnent rewrites. Other than that, I don't see any critical changes to either branch. I recommend that you just copy the test from the main branch as-is (from the last mergepoint, not HEAD) instead of trying to do a proper backport and merge. I can generate a patch if you need it. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2005-04-19 01:08 Message: Logged In: YES user_id=357491 test_compile should have been merged; tests that the compiler is doing its job at the bytecode level, not Python/compile.c directly. Need to remember to backport changes at some point. ---------------------------------------------------------------------- Comment By: logistix (logistix) Date: 2005-04-03 18:03 Message: Logged In: YES user_id=699438 This can probably be closed. People have been developing off of the branch post-merge. ---------------------------------------------------------------------- Comment By: Kurt B. Kaiser (kbk) Date: 2005-01-07 01:32 Message: Logged In: YES user_id=149084 Hm, file was a little too big. bzip2 it, 10x compression ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1097671&group_id=5470 From noreply at sourceforge.net Sat Nov 12 11:26:49 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 12 Nov 2005 02:26:49 -0800 Subject: [Patches] [ python-Patches-1351997 ] fix for resource leak in _subprocess Message-ID: Patches item #1351997, was opened at 2005-11-09 10:05 Message generated for change (Comment added) made by effbot You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1351997&group_id=5470 Please note that this 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: Fredrik Lundh (effbot) >Assigned to: Fredrik Lundh (effbot) Summary: fix for resource leak in _subprocess Initial Comment: The _subprocess CreateProcess driver may leak if you pass in an explicit environment dictionary. This trivial patch fixes this. Can be backported to 2.3 and 2.4. ---------------------------------------------------------------------- >Comment By: Fredrik Lundh (effbot) Date: 2005-11-12 11:26 Message: Logged In: YES user_id=38376 MvL fixed my account, so I went ahead and checked this in. This patch can be backported to all subprocess releases, but I think the problem is relatively minor, so I won't do that now. ---------------------------------------------------------------------- Comment By: Fredrik Lundh (effbot) Date: 2005-11-10 23:48 Message: Logged In: YES user_id=38376 I've updated the patch to address #1346547 as well. If you have the time, feel free to check this in. I don't have a proper account set up yet (but I promise to fix that soon). thanks /F ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2005-11-10 06:53 Message: Logged In: YES user_id=33168 /f did you want to check this in yourself? I'm not sure if you have an svn account or if you want one. I can check it in if you'd like. See also bug #1346547. There is another problem in this area (lines 379/380) should check if an error occurred. I can't test this stuff, but if you test, I can check in. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1351997&group_id=5470 From noreply at sourceforge.net Sat Nov 12 11:55:54 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 12 Nov 2005 02:55:54 -0800 Subject: [Patches] [ python-Patches-1355023 ] support whence argument for GzipFile.seek (bug #1316069) Message-ID: Patches item #1355023, was opened at 2005-11-12 11:55 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1355023&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Modules Group: None Status: Open Resolution: None Priority: 5 Submitted By: Fredrik Lundh (effbot) Assigned to: Nobody/Anonymous (nobody) Summary: support whence argument for GzipFile.seek (bug #1316069) Initial Comment: This adds support for whence=0 and whence=1 to the GzipFile seek method. See www.python.org/sf/1316069 for background. Open questions: Q: can/should whence=2 be supported? Q: if not, should whence=2 give an IOError or a ValueError Q: can patches be attached to bug reports? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1355023&group_id=5470 From noreply at sourceforge.net Sun Nov 13 11:43:14 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 13 Nov 2005 02:43:14 -0800 Subject: [Patches] [ python-Patches-1337648 ] Elemental Security contribution - parsexml.py Message-ID: Patches item #1337648, was opened at 2005-10-25 18:49 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1337648&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: XML Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: Guido van Rossum (gvanrossum) Assigned to: Guido van Rossum (gvanrossum) Summary: Elemental Security contribution - parsexml.py Initial Comment: This is a module I developed at Elemental for parsing and unparsing certain simple XML structures. It is licensed to the PSF using the contributor agreement. I expect that it will have to be transmogrified somewhat before it enters the standard library, and we'll need to find a good place for it in the xml package. It also needs docs. I will take care of all that in my spare time. ---------------------------------------------------------------------- >Comment By: Martin v. L?wis (loewis) Date: 2005-11-13 11:43 Message: Logged In: YES user_id=21627 If your goal is to save arbitrary Python objects, instead of loading arbitrary XML files, then qp_xml is also different, and it is more like David Mertz's gnosis xml pickle, J?rg R?dler's XMarshal, or any other XML pickling library. Contributing to PyXML literally means to submit a patch at http://sourceforge.net/projects/pyxml I should then roll another PyXML release. However, getting feedback from the xml-sig list certainly also is a good idea. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2005-11-11 04:35 Message: Logged In: YES user_id=6380 Understood. It is very different from ElementTree; I'll have to look at qp_xml. The emphasis of parsexml.py is on converting Python data structures to/from XML, rather than supporting all of XML. What exactly do you mean by contributing to PyXML? Do you mean bring it up on the xml-sig list? ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2005-11-02 05:40 Message: Logged In: YES user_id=21627 There are a number of "simple" APIs out there, such as Fredrik Lundh's ElementTree and Greg Stein's qp_xml, although this is the only one with the notion of a document type. I would encourage to contribute it to PyXML first; it is not clear (to me) that this is somehow a "right" way to do XML processing. For example, it seems limited in the structure of XML content models supported (e.g. no mixed content, no support for preserving the order of child elements). It might be confusing to users if their seemingly simple documents are not properly supported. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1337648&group_id=5470 From noreply at sourceforge.net Sun Nov 13 11:57:05 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 13 Nov 2005 02:57:05 -0800 Subject: [Patches] [ python-Patches-1355023 ] support whence argument for GzipFile.seek (bug #1316069) Message-ID: Patches item #1355023, was opened at 2005-11-12 11:55 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1355023&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Modules Group: None Status: Open Resolution: None Priority: 5 Submitted By: Fredrik Lundh (effbot) Assigned to: Nobody/Anonymous (nobody) Summary: support whence argument for GzipFile.seek (bug #1316069) Initial Comment: This adds support for whence=0 and whence=1 to the GzipFile seek method. See www.python.org/sf/1316069 for background. Open questions: Q: can/should whence=2 be supported? Q: if not, should whence=2 give an IOError or a ValueError Q: can patches be attached to bug reports? ---------------------------------------------------------------------- >Comment By: Martin v. L?wis (loewis) Date: 2005-11-13 11:57 Message: Logged In: YES user_id=21627 I think whence=2 can be supported, but shouldn't be. For reading, only negative offsets would be meaningful, and they can be supported the same way as they currently are (i.e. read all over). For writing, whence=2 would have no effect. seek apparently always gives a value error (e.g. also file.seek, for whence=10), so it should do so also here. Patches can be attached to bug reports if you are a patch admin. The patch lacks documentation and test case changes. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1355023&group_id=5470 From noreply at sourceforge.net Sun Nov 13 12:36:15 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 13 Nov 2005 03:36:15 -0800 Subject: [Patches] [ python-Patches-1355023 ] support whence argument for GzipFile.seek (bug #1316069) Message-ID: Patches item #1355023, was opened at 2005-11-12 11:55 Message generated for change (Comment added) made by effbot You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1355023&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Modules Group: None Status: Open Resolution: None Priority: 5 Submitted By: Fredrik Lundh (effbot) Assigned to: Nobody/Anonymous (nobody) Summary: support whence argument for GzipFile.seek (bug #1316069) Initial Comment: This adds support for whence=0 and whence=1 to the GzipFile seek method. See www.python.org/sf/1316069 for background. Open questions: Q: can/should whence=2 be supported? Q: if not, should whence=2 give an IOError or a ValueError Q: can patches be attached to bug reports? ---------------------------------------------------------------------- >Comment By: Fredrik Lundh (effbot) Date: 2005-11-13 12:36 Message: Logged In: YES user_id=38376 I'll add a test case and check it in. >From what I can tell, no documentation is affected by this change (maybe the gzip documentation should include a full description of what exactly "simulates most of the methods of a file object" really means, but that's a separate issue). ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2005-11-13 11:57 Message: Logged In: YES user_id=21627 I think whence=2 can be supported, but shouldn't be. For reading, only negative offsets would be meaningful, and they can be supported the same way as they currently are (i.e. read all over). For writing, whence=2 would have no effect. seek apparently always gives a value error (e.g. also file.seek, for whence=10), so it should do so also here. Patches can be attached to bug reports if you are a patch admin. The patch lacks documentation and test case changes. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1355023&group_id=5470 From noreply at sourceforge.net Sun Nov 13 12:36:41 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 13 Nov 2005 03:36:41 -0800 Subject: [Patches] [ python-Patches-1355023 ] support whence argument for GzipFile.seek (bug #1316069) Message-ID: Patches item #1355023, was opened at 2005-11-12 11:55 Message generated for change (Settings changed) made by effbot You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1355023&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Modules Group: None Status: Open Resolution: None Priority: 5 Submitted By: Fredrik Lundh (effbot) >Assigned to: Fredrik Lundh (effbot) Summary: support whence argument for GzipFile.seek (bug #1316069) Initial Comment: This adds support for whence=0 and whence=1 to the GzipFile seek method. See www.python.org/sf/1316069 for background. Open questions: Q: can/should whence=2 be supported? Q: if not, should whence=2 give an IOError or a ValueError Q: can patches be attached to bug reports? ---------------------------------------------------------------------- Comment By: Fredrik Lundh (effbot) Date: 2005-11-13 12:36 Message: Logged In: YES user_id=38376 I'll add a test case and check it in. >From what I can tell, no documentation is affected by this change (maybe the gzip documentation should include a full description of what exactly "simulates most of the methods of a file object" really means, but that's a separate issue). ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2005-11-13 11:57 Message: Logged In: YES user_id=21627 I think whence=2 can be supported, but shouldn't be. For reading, only negative offsets would be meaningful, and they can be supported the same way as they currently are (i.e. read all over). For writing, whence=2 would have no effect. seek apparently always gives a value error (e.g. also file.seek, for whence=10), so it should do so also here. Patches can be attached to bug reports if you are a patch admin. The patch lacks documentation and test case changes. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1355023&group_id=5470 From noreply at sourceforge.net Sun Nov 13 15:59:08 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 13 Nov 2005 06:59:08 -0800 Subject: [Patches] [ python-Patches-1355913 ] PEP 341 - Unification of try/except and try/finally Message-ID: Patches item #1355913, was opened at 2005-11-14 00: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=1355913&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Core (C code) Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: Thomas Lee (krumms) Assigned to: Nobody/Anonymous (nobody) Summary: PEP 341 - Unification of try/except and try/finally Initial Comment: Attached is a patch implementing PEP 341 against HEAD in subversion. It includes the following changes: 1. Grammar/Grammar updated as per the PEP 2. Python/ast.c wraps try/except blocks inside try/finally blocks if it detects the extended syntax. This patch is based heavily upon suggestions by Nick Coghlan on python-dev. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1355913&group_id=5470 From noreply at sourceforge.net Sun Nov 13 16:02:07 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 13 Nov 2005 07:02:07 -0800 Subject: [Patches] [ python-Patches-1355913 ] PEP 341 - Unification of try/except and try/finally Message-ID: Patches item #1355913, was opened at 2005-11-14 00:59 Message generated for change (Comment added) made by krumms You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1355913&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Core (C code) Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: Thomas Lee (krumms) >Assigned to: Reinhold Birkenfeld (birkenfeld) Summary: PEP 341 - Unification of try/except and try/finally Initial Comment: Attached is a patch implementing PEP 341 against HEAD in subversion. It includes the following changes: 1. Grammar/Grammar updated as per the PEP 2. Python/ast.c wraps try/except blocks inside try/finally blocks if it detects the extended syntax. This patch is based heavily upon suggestions by Nick Coghlan on python-dev. ---------------------------------------------------------------------- >Comment By: Thomas Lee (krumms) Date: 2005-11-14 01:02 Message: Logged In: YES user_id=315535 Attaching a unit test checking the various different types of exception handling syntax. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1355913&group_id=5470 From noreply at sourceforge.net Sun Nov 13 16:24:24 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 13 Nov 2005 07:24:24 -0800 Subject: [Patches] [ python-Patches-1337648 ] Elemental Security contribution - parsexml.py Message-ID: Patches item #1337648, was opened at 2005-10-25 12:49 Message generated for change (Comment added) made by gvanrossum You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1337648&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: XML Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: Guido van Rossum (gvanrossum) Assigned to: Guido van Rossum (gvanrossum) Summary: Elemental Security contribution - parsexml.py Initial Comment: This is a module I developed at Elemental for parsing and unparsing certain simple XML structures. It is licensed to the PSF using the contributor agreement. I expect that it will have to be transmogrified somewhat before it enters the standard library, and we'll need to find a good place for it in the xml package. It also needs docs. I will take care of all that in my spare time. ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2005-11-13 10:24 Message: Logged In: YES user_id=6380 Actually the goal isn't so much to save *arbitrary* Python objects but to be able to create objects that on the one hand correspond to XML (which can be read or written by other languages -- this was done for a Java/Python environment) and on the other hand have a "Pythonic" interface. Thus, both the Python side and the XML side are constrained. The constraints on the Python side include the need to explicitly inherit from ElementClass and declare the XML mapping; there is no support for dicts or tuples and only limited support for lists. But the result is something that has a better API quality than the typical DOM or ElementTree: you can write x.foo instead of x.someGetMethod("foo"). I will work on contributing to PyXML next, now that I understand the concept. :-) ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2005-11-13 05:43 Message: Logged In: YES user_id=21627 If your goal is to save arbitrary Python objects, instead of loading arbitrary XML files, then qp_xml is also different, and it is more like David Mertz's gnosis xml pickle, J?rg R?dler's XMarshal, or any other XML pickling library. Contributing to PyXML literally means to submit a patch at http://sourceforge.net/projects/pyxml I should then roll another PyXML release. However, getting feedback from the xml-sig list certainly also is a good idea. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2005-11-10 22:35 Message: Logged In: YES user_id=6380 Understood. It is very different from ElementTree; I'll have to look at qp_xml. The emphasis of parsexml.py is on converting Python data structures to/from XML, rather than supporting all of XML. What exactly do you mean by contributing to PyXML? Do you mean bring it up on the xml-sig list? ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2005-11-01 23:40 Message: Logged In: YES user_id=21627 There are a number of "simple" APIs out there, such as Fredrik Lundh's ElementTree and Greg Stein's qp_xml, although this is the only one with the notion of a document type. I would encourage to contribute it to PyXML first; it is not clear (to me) that this is somehow a "right" way to do XML processing. For example, it seems limited in the structure of XML content models supported (e.g. no mixed content, no support for preserving the order of child elements). It might be confusing to users if their seemingly simple documents are not properly supported. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1337648&group_id=5470 From noreply at sourceforge.net Sun Nov 13 16:40:58 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 13 Nov 2005 07:40:58 -0800 Subject: [Patches] [ python-Patches-1355940 ] Delete Python-ast.[ch] during "make depclean" (#1355883) Message-ID: Patches item #1355940, was opened at 2005-11-14 01: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=1355940&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Thomas Lee (krumms) Assigned to: Nobody/Anonymous (nobody) Summary: Delete Python-ast.[ch] during "make depclean" (#1355883) Initial Comment: Partial fix for bug #1355883 (the second problem outlined by Skip - the "make -j2" problem still remains) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1355940&group_id=5470 From noreply at sourceforge.net Sun Nov 13 16:42:31 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 13 Nov 2005 07:42:31 -0800 Subject: [Patches] [ python-Patches-1355940 ] Delete Python-ast.[ch] during "make depclean" (#1355883) Message-ID: Patches item #1355940, was opened at 2005-11-14 01:40 Message generated for change (Settings changed) made by krumms You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1355940&group_id=5470 Please note that this 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: Thomas Lee (krumms) >Assigned to: Skip Montanaro (montanaro) Summary: Delete Python-ast.[ch] during "make depclean" (#1355883) Initial Comment: Partial fix for bug #1355883 (the second problem outlined by Skip - the "make -j2" problem still remains) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1355940&group_id=5470 From noreply at sourceforge.net Sun Nov 13 16:51:19 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 13 Nov 2005 07:51:19 -0800 Subject: [Patches] [ python-Patches-1355940 ] Delete Python-ast.[ch] during "make depclean" (#1355883) Message-ID: Patches item #1355940, was opened at 2005-11-13 09:40 Message generated for change (Comment added) made by montanaro You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1355940&group_id=5470 Please note that this 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: Thomas Lee (krumms) Assigned to: Skip Montanaro (montanaro) Summary: Delete Python-ast.[ch] during "make depclean" (#1355883) Initial Comment: Partial fix for bug #1355883 (the second problem outlined by Skip - the "make -j2" problem still remains) ---------------------------------------------------------------------- >Comment By: Skip Montanaro (montanaro) Date: 2005-11-13 09:51 Message: Logged In: YES user_id=44345 Thanks. That's the trivial part (and should reference $(AST_H) and $(AST_C)). Can you see what the problem with the dependencies are that cause the double run of the converter when running a parallel build on a fresh tree? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1355940&group_id=5470 From noreply at sourceforge.net Sun Nov 13 16:55:14 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 13 Nov 2005 07:55:14 -0800 Subject: [Patches] [ python-Patches-1355940 ] Delete Python-ast.[ch] during "make depclean" (#1355883) Message-ID: Patches item #1355940, was opened at 2005-11-13 09:40 Message generated for change (Comment added) made by montanaro You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1355940&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Build Group: Python 2.5 >Status: Closed >Resolution: Accepted Priority: 5 Submitted By: Thomas Lee (krumms) Assigned to: Skip Montanaro (montanaro) Summary: Delete Python-ast.[ch] during "make depclean" (#1355883) Initial Comment: Partial fix for bug #1355883 (the second problem outlined by Skip - the "make -j2" problem still remains) ---------------------------------------------------------------------- >Comment By: Skip Montanaro (montanaro) Date: 2005-11-13 09:55 Message: Logged In: YES user_id=44345 Applied slightly different version as rev 41433. ---------------------------------------------------------------------- Comment By: Skip Montanaro (montanaro) Date: 2005-11-13 09:51 Message: Logged In: YES user_id=44345 Thanks. That's the trivial part (and should reference $(AST_H) and $(AST_C)). Can you see what the problem with the dependencies are that cause the double run of the converter when running a parallel build on a fresh tree? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1355940&group_id=5470 From noreply at sourceforge.net Sun Nov 13 17:54:52 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 13 Nov 2005 08:54:52 -0800 Subject: [Patches] [ python-Patches-1355971 ] Python-ast.h & Python-ast.c generated twice (#1355883) Message-ID: Patches item #1355971, was opened at 2005-11-14 02: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=1355971&group_id=5470 Please note that this 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: Thomas Lee (krumms) Assigned to: Nobody/Anonymous (nobody) Summary: Python-ast.h & Python-ast.c generated twice (#1355883) Initial Comment: Added a fix for the first part of bug #1355883: make -j2 may cause corruption of Python-ast.h/Python-ast.c. Summary: * Updated asdl_c.py to only generate the interface or the implementation depending on which is given on the command line (e.g. asdl_c.py -h Include Python.asdl will generate Include/Python-ast.h but will not generate Python-ast.c) * Updated Makefile.pre.in to call asdl_c.py with the appropriate arguments. Fix for the second part of this bug here: http://sourceforge.net/tracker/index.php?func=detail&aid=1355940&group_id=5470&atid=305470 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1355971&group_id=5470 From noreply at sourceforge.net Sun Nov 13 17:55:47 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 13 Nov 2005 08:55:47 -0800 Subject: [Patches] [ python-Patches-1355971 ] Python-ast.h & Python-ast.c generated twice (#1355883) Message-ID: Patches item #1355971, was opened at 2005-11-14 02:54 Message generated for change (Settings changed) made by krumms You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1355971&group_id=5470 Please note that this 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: Thomas Lee (krumms) >Assigned to: Skip Montanaro (montanaro) Summary: Python-ast.h & Python-ast.c generated twice (#1355883) Initial Comment: Added a fix for the first part of bug #1355883: make -j2 may cause corruption of Python-ast.h/Python-ast.c. Summary: * Updated asdl_c.py to only generate the interface or the implementation depending on which is given on the command line (e.g. asdl_c.py -h Include Python.asdl will generate Include/Python-ast.h but will not generate Python-ast.c) * Updated Makefile.pre.in to call asdl_c.py with the appropriate arguments. Fix for the second part of this bug here: http://sourceforge.net/tracker/index.php?func=detail&aid=1355940&group_id=5470&atid=305470 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1355971&group_id=5470 From noreply at sourceforge.net Sun Nov 13 17:59:20 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 13 Nov 2005 08:59:20 -0800 Subject: [Patches] [ python-Patches-1355940 ] Delete Python-ast.[ch] during "make distclean" (#1355883) Message-ID: Patches item #1355940, was opened at 2005-11-14 01:40 Message generated for change (Settings changed) made by krumms You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1355940&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Build Group: Python 2.5 Status: Closed Resolution: Accepted Priority: 5 Submitted By: Thomas Lee (krumms) Assigned to: Skip Montanaro (montanaro) >Summary: Delete Python-ast.[ch] during "make distclean" (#1355883) Initial Comment: Partial fix for bug #1355883 (the second problem outlined by Skip - the "make -j2" problem still remains) ---------------------------------------------------------------------- Comment By: Skip Montanaro (montanaro) Date: 2005-11-14 01:55 Message: Logged In: YES user_id=44345 Applied slightly different version as rev 41433. ---------------------------------------------------------------------- Comment By: Skip Montanaro (montanaro) Date: 2005-11-14 01:51 Message: Logged In: YES user_id=44345 Thanks. That's the trivial part (and should reference $(AST_H) and $(AST_C)). Can you see what the problem with the dependencies are that cause the double run of the converter when running a parallel build on a fresh tree? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1355940&group_id=5470 From noreply at sourceforge.net Sun Nov 13 22:27:24 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 13 Nov 2005 13:27:24 -0800 Subject: [Patches] [ python-Patches-1355913 ] PEP 341 - Unification of try/except and try/finally Message-ID: Patches item #1355913, was opened at 2005-11-13 06:59 Message generated for change (Comment added) made by nnorwitz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1355913&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Core (C code) Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: Thomas Lee (krumms) Assigned to: Reinhold Birkenfeld (birkenfeld) Summary: PEP 341 - Unification of try/except and try/finally Initial Comment: Attached is a patch implementing PEP 341 against HEAD in subversion. It includes the following changes: 1. Grammar/Grammar updated as per the PEP 2. Python/ast.c wraps try/except blocks inside try/finally blocks if it detects the extended syntax. This patch is based heavily upon suggestions by Nick Coghlan on python-dev. ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2005-11-13 13:27 Message: Logged In: YES user_id=33168 Updated patch to correct memory leaks. Put everything in one file. Works for me. There needs to be doc changes done too. ---------------------------------------------------------------------- Comment By: Thomas Lee (krumms) Date: 2005-11-13 07:02 Message: Logged In: YES user_id=315535 Attaching a unit test checking the various different types of exception handling syntax. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1355913&group_id=5470 From noreply at sourceforge.net Mon Nov 14 00:10:05 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 13 Nov 2005 15:10:05 -0800 Subject: [Patches] [ python-Patches-1355913 ] PEP 341 - Unification of try/except and try/finally Message-ID: Patches item #1355913, was opened at 2005-11-13 06:59 Message generated for change (Comment added) made by nnorwitz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1355913&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Core (C code) Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: Thomas Lee (krumms) Assigned to: Reinhold Birkenfeld (birkenfeld) Summary: PEP 341 - Unification of try/except and try/finally Initial Comment: Attached is a patch implementing PEP 341 against HEAD in subversion. It includes the following changes: 1. Grammar/Grammar updated as per the PEP 2. Python/ast.c wraps try/except blocks inside try/finally blocks if it detects the extended syntax. This patch is based heavily upon suggestions by Nick Coghlan on python-dev. ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2005-11-13 15:10 Message: Logged In: YES user_id=33168 I'm pretty sure this patch causes this problem: python: Objects/frameobject.c:187: frame_setlineno: Assertion `blockstack_top > 0' failed. I'm not sure if it's just my hacked up version or the original. Thomas, can you test your version? ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2005-11-13 13:27 Message: Logged In: YES user_id=33168 Updated patch to correct memory leaks. Put everything in one file. Works for me. There needs to be doc changes done too. ---------------------------------------------------------------------- Comment By: Thomas Lee (krumms) Date: 2005-11-13 07:02 Message: Logged In: YES user_id=315535 Attaching a unit test checking the various different types of exception handling syntax. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1355913&group_id=5470 From noreply at sourceforge.net Mon Nov 14 00:12:21 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 13 Nov 2005 15:12:21 -0800 Subject: [Patches] [ python-Patches-1355913 ] PEP 341 - Unification of try/except and try/finally Message-ID: Patches item #1355913, was opened at 2005-11-14 00:59 Message generated for change (Comment added) made by krumms You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1355913&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Core (C code) Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: Thomas Lee (krumms) Assigned to: Reinhold Birkenfeld (birkenfeld) Summary: PEP 341 - Unification of try/except and try/finally Initial Comment: Attached is a patch implementing PEP 341 against HEAD in subversion. It includes the following changes: 1. Grammar/Grammar updated as per the PEP 2. Python/ast.c wraps try/except blocks inside try/finally blocks if it detects the extended syntax. This patch is based heavily upon suggestions by Nick Coghlan on python-dev. ---------------------------------------------------------------------- >Comment By: Thomas Lee (krumms) Date: 2005-11-14 09:12 Message: Logged In: YES user_id=315535 Further correction of memory leaks. 'finally' and 'orelse' need to be deallocated if an error occurs in the "if (n_except > 0)" branch. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2005-11-14 09:10 Message: Logged In: YES user_id=33168 I'm pretty sure this patch causes this problem: python: Objects/frameobject.c:187: frame_setlineno: Assertion `blockstack_top > 0' failed. I'm not sure if it's just my hacked up version or the original. Thomas, can you test your version? ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2005-11-14 07:27 Message: Logged In: YES user_id=33168 Updated patch to correct memory leaks. Put everything in one file. Works for me. There needs to be doc changes done too. ---------------------------------------------------------------------- Comment By: Thomas Lee (krumms) Date: 2005-11-14 01:02 Message: Logged In: YES user_id=315535 Attaching a unit test checking the various different types of exception handling syntax. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1355913&group_id=5470 From noreply at sourceforge.net Mon Nov 14 00:12:26 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 13 Nov 2005 15:12:26 -0800 Subject: [Patches] [ python-Patches-1355913 ] PEP 341 - Unification of try/except and try/finally Message-ID: Patches item #1355913, was opened at 2005-11-14 00:59 Message generated for change (Comment added) made by krumms You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1355913&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Core (C code) Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: Thomas Lee (krumms) Assigned to: Reinhold Birkenfeld (birkenfeld) Summary: PEP 341 - Unification of try/except and try/finally Initial Comment: Attached is a patch implementing PEP 341 against HEAD in subversion. It includes the following changes: 1. Grammar/Grammar updated as per the PEP 2. Python/ast.c wraps try/except blocks inside try/finally blocks if it detects the extended syntax. This patch is based heavily upon suggestions by Nick Coghlan on python-dev. ---------------------------------------------------------------------- >Comment By: Thomas Lee (krumms) Date: 2005-11-14 09:12 Message: Logged In: YES user_id=315535 Further correction of memory leaks. 'finally' and 'orelse' need to be deallocated if an error occurs in the "if (n_except > 0)" branch. ---------------------------------------------------------------------- Comment By: Thomas Lee (krumms) Date: 2005-11-14 09:12 Message: Logged In: YES user_id=315535 Further correction of memory leaks. 'finally' and 'orelse' need to be deallocated if an error occurs in the "if (n_except > 0)" branch. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2005-11-14 09:10 Message: Logged In: YES user_id=33168 I'm pretty sure this patch causes this problem: python: Objects/frameobject.c:187: frame_setlineno: Assertion `blockstack_top > 0' failed. I'm not sure if it's just my hacked up version or the original. Thomas, can you test your version? ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2005-11-14 07:27 Message: Logged In: YES user_id=33168 Updated patch to correct memory leaks. Put everything in one file. Works for me. There needs to be doc changes done too. ---------------------------------------------------------------------- Comment By: Thomas Lee (krumms) Date: 2005-11-14 01:02 Message: Logged In: YES user_id=315535 Attaching a unit test checking the various different types of exception handling syntax. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1355913&group_id=5470 From noreply at sourceforge.net Mon Nov 14 01:02:34 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 13 Nov 2005 16:02:34 -0800 Subject: [Patches] [ python-Patches-1355913 ] PEP 341 - Unification of try/except and try/finally Message-ID: Patches item #1355913, was opened at 2005-11-14 00:59 Message generated for change (Comment added) made by krumms You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1355913&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Core (C code) Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: Thomas Lee (krumms) Assigned to: Reinhold Birkenfeld (birkenfeld) Summary: PEP 341 - Unification of try/except and try/finally Initial Comment: Attached is a patch implementing PEP 341 against HEAD in subversion. It includes the following changes: 1. Grammar/Grammar updated as per the PEP 2. Python/ast.c wraps try/except blocks inside try/finally blocks if it detects the extended syntax. This patch is based heavily upon suggestions by Nick Coghlan on python-dev. ---------------------------------------------------------------------- >Comment By: Thomas Lee (krumms) Date: 2005-11-14 10:02 Message: Logged In: YES user_id=315535 Fixed a bad assumption when parsing a try-finally. Should be fixed now. I'm not sure if this fixes the problem you're experiencing, Neal. I'll have a look into it. ---------------------------------------------------------------------- Comment By: Thomas Lee (krumms) Date: 2005-11-14 09:12 Message: Logged In: YES user_id=315535 Further correction of memory leaks. 'finally' and 'orelse' need to be deallocated if an error occurs in the "if (n_except > 0)" branch. ---------------------------------------------------------------------- Comment By: Thomas Lee (krumms) Date: 2005-11-14 09:12 Message: Logged In: YES user_id=315535 Further correction of memory leaks. 'finally' and 'orelse' need to be deallocated if an error occurs in the "if (n_except > 0)" branch. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2005-11-14 09:10 Message: Logged In: YES user_id=33168 I'm pretty sure this patch causes this problem: python: Objects/frameobject.c:187: frame_setlineno: Assertion `blockstack_top > 0' failed. I'm not sure if it's just my hacked up version or the original. Thomas, can you test your version? ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2005-11-14 07:27 Message: Logged In: YES user_id=33168 Updated patch to correct memory leaks. Put everything in one file. Works for me. There needs to be doc changes done too. ---------------------------------------------------------------------- Comment By: Thomas Lee (krumms) Date: 2005-11-14 01:02 Message: Logged In: YES user_id=315535 Attaching a unit test checking the various different types of exception handling syntax. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1355913&group_id=5470 From noreply at sourceforge.net Mon Nov 14 06:17:05 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 13 Nov 2005 21:17:05 -0800 Subject: [Patches] [ python-Patches-1355913 ] PEP 341 - Unification of try/except and try/finally Message-ID: Patches item #1355913, was opened at 2005-11-14 00:59 Message generated for change (Comment added) made by krumms You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1355913&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Core (C code) Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: Thomas Lee (krumms) Assigned to: Reinhold Birkenfeld (birkenfeld) Summary: PEP 341 - Unification of try/except and try/finally Initial Comment: Attached is a patch implementing PEP 341 against HEAD in subversion. It includes the following changes: 1. Grammar/Grammar updated as per the PEP 2. Python/ast.c wraps try/except blocks inside try/finally blocks if it detects the extended syntax. This patch is based heavily upon suggestions by Nick Coghlan on python-dev. ---------------------------------------------------------------------- >Comment By: Thomas Lee (krumms) Date: 2005-11-14 15:17 Message: Logged In: YES user_id=315535 Fix for the problem you encountered in the v5 patch, Nick. All tests in the suite now pass for me, no assertion failures when using --with-pydebug. I was stupidly generating a TryFinally in every scenario. This breaks down in the 'trace' unit test when no 'finally' clause is present with the extended syntax. Oops. Also added a little more error checking code and updated the unit test to test nested exception handling. I'm using a few goto statements in the "if (n_except > 0)" branch to reduce duplication deallocating memory. If there's any great objections to this feel free to yell & I'll resubmit a patch without the use of goto. Can you please verify this works for you, Nick? ---------------------------------------------------------------------- Comment By: Thomas Lee (krumms) Date: 2005-11-14 10:02 Message: Logged In: YES user_id=315535 Fixed a bad assumption when parsing a try-finally. Should be fixed now. I'm not sure if this fixes the problem you're experiencing, Neal. I'll have a look into it. ---------------------------------------------------------------------- Comment By: Thomas Lee (krumms) Date: 2005-11-14 09:12 Message: Logged In: YES user_id=315535 Further correction of memory leaks. 'finally' and 'orelse' need to be deallocated if an error occurs in the "if (n_except > 0)" branch. ---------------------------------------------------------------------- Comment By: Thomas Lee (krumms) Date: 2005-11-14 09:12 Message: Logged In: YES user_id=315535 Further correction of memory leaks. 'finally' and 'orelse' need to be deallocated if an error occurs in the "if (n_except > 0)" branch. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2005-11-14 09:10 Message: Logged In: YES user_id=33168 I'm pretty sure this patch causes this problem: python: Objects/frameobject.c:187: frame_setlineno: Assertion `blockstack_top > 0' failed. I'm not sure if it's just my hacked up version or the original. Thomas, can you test your version? ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2005-11-14 07:27 Message: Logged In: YES user_id=33168 Updated patch to correct memory leaks. Put everything in one file. Works for me. There needs to be doc changes done too. ---------------------------------------------------------------------- Comment By: Thomas Lee (krumms) Date: 2005-11-14 01:02 Message: Logged In: YES user_id=315535 Attaching a unit test checking the various different types of exception handling syntax. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1355913&group_id=5470 From noreply at sourceforge.net Mon Nov 14 06:18:22 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 13 Nov 2005 21:18:22 -0800 Subject: [Patches] [ python-Patches-1355913 ] PEP 341 - Unification of try/except and try/finally Message-ID: Patches item #1355913, was opened at 2005-11-14 00:59 Message generated for change (Comment added) made by krumms You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1355913&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Core (C code) Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: Thomas Lee (krumms) Assigned to: Reinhold Birkenfeld (birkenfeld) Summary: PEP 341 - Unification of try/except and try/finally Initial Comment: Attached is a patch implementing PEP 341 against HEAD in subversion. It includes the following changes: 1. Grammar/Grammar updated as per the PEP 2. Python/ast.c wraps try/except blocks inside try/finally blocks if it detects the extended syntax. This patch is based heavily upon suggestions by Nick Coghlan on python-dev. ---------------------------------------------------------------------- >Comment By: Thomas Lee (krumms) Date: 2005-11-14 15:18 Message: Logged In: YES user_id=315535 Oops - I mean Neal :) ---------------------------------------------------------------------- Comment By: Thomas Lee (krumms) Date: 2005-11-14 15:17 Message: Logged In: YES user_id=315535 Fix for the problem you encountered in the v5 patch, Nick. All tests in the suite now pass for me, no assertion failures when using --with-pydebug. I was stupidly generating a TryFinally in every scenario. This breaks down in the 'trace' unit test when no 'finally' clause is present with the extended syntax. Oops. Also added a little more error checking code and updated the unit test to test nested exception handling. I'm using a few goto statements in the "if (n_except > 0)" branch to reduce duplication deallocating memory. If there's any great objections to this feel free to yell & I'll resubmit a patch without the use of goto. Can you please verify this works for you, Nick? ---------------------------------------------------------------------- Comment By: Thomas Lee (krumms) Date: 2005-11-14 10:02 Message: Logged In: YES user_id=315535 Fixed a bad assumption when parsing a try-finally. Should be fixed now. I'm not sure if this fixes the problem you're experiencing, Neal. I'll have a look into it. ---------------------------------------------------------------------- Comment By: Thomas Lee (krumms) Date: 2005-11-14 09:12 Message: Logged In: YES user_id=315535 Further correction of memory leaks. 'finally' and 'orelse' need to be deallocated if an error occurs in the "if (n_except > 0)" branch. ---------------------------------------------------------------------- Comment By: Thomas Lee (krumms) Date: 2005-11-14 09:12 Message: Logged In: YES user_id=315535 Further correction of memory leaks. 'finally' and 'orelse' need to be deallocated if an error occurs in the "if (n_except > 0)" branch. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2005-11-14 09:10 Message: Logged In: YES user_id=33168 I'm pretty sure this patch causes this problem: python: Objects/frameobject.c:187: frame_setlineno: Assertion `blockstack_top > 0' failed. I'm not sure if it's just my hacked up version or the original. Thomas, can you test your version? ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2005-11-14 07:27 Message: Logged In: YES user_id=33168 Updated patch to correct memory leaks. Put everything in one file. Works for me. There needs to be doc changes done too. ---------------------------------------------------------------------- Comment By: Thomas Lee (krumms) Date: 2005-11-14 01:02 Message: Logged In: YES user_id=315535 Attaching a unit test checking the various different types of exception handling syntax. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1355913&group_id=5470 From noreply at sourceforge.net Mon Nov 14 09:54:42 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 14 Nov 2005 00:54:42 -0800 Subject: [Patches] [ python-Patches-1355913 ] PEP 341 - Unification of try/except and try/finally Message-ID: Patches item #1355913, was opened at 2005-11-14 00:59 Message generated for change (Comment added) made by ncoghlan You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1355913&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Core (C code) Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: Thomas Lee (krumms) Assigned to: Reinhold Birkenfeld (birkenfeld) Summary: PEP 341 - Unification of try/except and try/finally Initial Comment: Attached is a patch implementing PEP 341 against HEAD in subversion. It includes the following changes: 1. Grammar/Grammar updated as per the PEP 2. Python/ast.c wraps try/except blocks inside try/finally blocks if it detects the extended syntax. This patch is based heavily upon suggestions by Nick Coghlan on python-dev. ---------------------------------------------------------------------- >Comment By: Nick Coghlan (ncoghlan) Date: 2005-11-14 18:54 Message: Logged In: YES user_id=1038590 >From a code inspection of v5 of the patch (I haven't actually run the patch anywhere), I'm a little uncomfortable with the mixture of the two error handling styles (that is, test-cleanup-return for most of the function, but test-goto-cleanup for the one specific case). I don't mind either style (and both are used in the Python source), but mixing them in one function bothers me :) Further, there appears to be a bug in the deallocation code, in that all sequences should be freed with adsl_seq_stmt_free. The current direct use of adsl_seq_free means any contained statements are not released. I suggest putting a single 'error' label at the end of the function that uses adsl_seq_stmt_free to clean up all the statement sequences , as well as free_stmt to clean up the nested except statements. As both of these functions handle nulls gracefully, the bodies of the current error cleanup and return branches can all then be replaced with "goto error". ---------------------------------------------------------------------- Comment By: Thomas Lee (krumms) Date: 2005-11-14 15:18 Message: Logged In: YES user_id=315535 Oops - I mean Neal :) ---------------------------------------------------------------------- Comment By: Thomas Lee (krumms) Date: 2005-11-14 15:17 Message: Logged In: YES user_id=315535 Fix for the problem you encountered in the v5 patch, Nick. All tests in the suite now pass for me, no assertion failures when using --with-pydebug. I was stupidly generating a TryFinally in every scenario. This breaks down in the 'trace' unit test when no 'finally' clause is present with the extended syntax. Oops. Also added a little more error checking code and updated the unit test to test nested exception handling. I'm using a few goto statements in the "if (n_except > 0)" branch to reduce duplication deallocating memory. If there's any great objections to this feel free to yell & I'll resubmit a patch without the use of goto. Can you please verify this works for you, Nick? ---------------------------------------------------------------------- Comment By: Thomas Lee (krumms) Date: 2005-11-14 10:02 Message: Logged In: YES user_id=315535 Fixed a bad assumption when parsing a try-finally. Should be fixed now. I'm not sure if this fixes the problem you're experiencing, Neal. I'll have a look into it. ---------------------------------------------------------------------- Comment By: Thomas Lee (krumms) Date: 2005-11-14 09:12 Message: Logged In: YES user_id=315535 Further correction of memory leaks. 'finally' and 'orelse' need to be deallocated if an error occurs in the "if (n_except > 0)" branch. ---------------------------------------------------------------------- Comment By: Thomas Lee (krumms) Date: 2005-11-14 09:12 Message: Logged In: YES user_id=315535 Further correction of memory leaks. 'finally' and 'orelse' need to be deallocated if an error occurs in the "if (n_except > 0)" branch. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2005-11-14 09:10 Message: Logged In: YES user_id=33168 I'm pretty sure this patch causes this problem: python: Objects/frameobject.c:187: frame_setlineno: Assertion `blockstack_top > 0' failed. I'm not sure if it's just my hacked up version or the original. Thomas, can you test your version? ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2005-11-14 07:27 Message: Logged In: YES user_id=33168 Updated patch to correct memory leaks. Put everything in one file. Works for me. There needs to be doc changes done too. ---------------------------------------------------------------------- Comment By: Thomas Lee (krumms) Date: 2005-11-14 01:02 Message: Logged In: YES user_id=315535 Attaching a unit test checking the various different types of exception handling syntax. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1355913&group_id=5470 From noreply at sourceforge.net Mon Nov 14 13:14:58 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 14 Nov 2005 04:14:58 -0800 Subject: [Patches] [ python-Patches-1355913 ] PEP 341 - Unification of try/except and try/finally Message-ID: Patches item #1355913, was opened at 2005-11-14 00:59 Message generated for change (Comment added) made by krumms You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1355913&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Core (C code) Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: Thomas Lee (krumms) Assigned to: Reinhold Birkenfeld (birkenfeld) Summary: PEP 341 - Unification of try/except and try/finally Initial Comment: Attached is a patch implementing PEP 341 against HEAD in subversion. It includes the following changes: 1. Grammar/Grammar updated as per the PEP 2. Python/ast.c wraps try/except blocks inside try/finally blocks if it detects the extended syntax. This patch is based heavily upon suggestions by Nick Coghlan on python-dev. ---------------------------------------------------------------------- >Comment By: Thomas Lee (krumms) Date: 2005-11-14 22:14 Message: Logged In: YES user_id=315535 Thanks for your input Nick - I'll sort out a patch taking your suggestions into consideration tomorrow & resubmit it. ---------------------------------------------------------------------- Comment By: Nick Coghlan (ncoghlan) Date: 2005-11-14 18:54 Message: Logged In: YES user_id=1038590 >From a code inspection of v5 of the patch (I haven't actually run the patch anywhere), I'm a little uncomfortable with the mixture of the two error handling styles (that is, test-cleanup-return for most of the function, but test-goto-cleanup for the one specific case). I don't mind either style (and both are used in the Python source), but mixing them in one function bothers me :) Further, there appears to be a bug in the deallocation code, in that all sequences should be freed with adsl_seq_stmt_free. The current direct use of adsl_seq_free means any contained statements are not released. I suggest putting a single 'error' label at the end of the function that uses adsl_seq_stmt_free to clean up all the statement sequences , as well as free_stmt to clean up the nested except statements. As both of these functions handle nulls gracefully, the bodies of the current error cleanup and return branches can all then be replaced with "goto error". ---------------------------------------------------------------------- Comment By: Thomas Lee (krumms) Date: 2005-11-14 15:18 Message: Logged In: YES user_id=315535 Oops - I mean Neal :) ---------------------------------------------------------------------- Comment By: Thomas Lee (krumms) Date: 2005-11-14 15:17 Message: Logged In: YES user_id=315535 Fix for the problem you encountered in the v5 patch, Nick. All tests in the suite now pass for me, no assertion failures when using --with-pydebug. I was stupidly generating a TryFinally in every scenario. This breaks down in the 'trace' unit test when no 'finally' clause is present with the extended syntax. Oops. Also added a little more error checking code and updated the unit test to test nested exception handling. I'm using a few goto statements in the "if (n_except > 0)" branch to reduce duplication deallocating memory. If there's any great objections to this feel free to yell & I'll resubmit a patch without the use of goto. Can you please verify this works for you, Nick? ---------------------------------------------------------------------- Comment By: Thomas Lee (krumms) Date: 2005-11-14 10:02 Message: Logged In: YES user_id=315535 Fixed a bad assumption when parsing a try-finally. Should be fixed now. I'm not sure if this fixes the problem you're experiencing, Neal. I'll have a look into it. ---------------------------------------------------------------------- Comment By: Thomas Lee (krumms) Date: 2005-11-14 09:12 Message: Logged In: YES user_id=315535 Further correction of memory leaks. 'finally' and 'orelse' need to be deallocated if an error occurs in the "if (n_except > 0)" branch. ---------------------------------------------------------------------- Comment By: Thomas Lee (krumms) Date: 2005-11-14 09:12 Message: Logged In: YES user_id=315535 Further correction of memory leaks. 'finally' and 'orelse' need to be deallocated if an error occurs in the "if (n_except > 0)" branch. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2005-11-14 09:10 Message: Logged In: YES user_id=33168 I'm pretty sure this patch causes this problem: python: Objects/frameobject.c:187: frame_setlineno: Assertion `blockstack_top > 0' failed. I'm not sure if it's just my hacked up version or the original. Thomas, can you test your version? ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2005-11-14 07:27 Message: Logged In: YES user_id=33168 Updated patch to correct memory leaks. Put everything in one file. Works for me. There needs to be doc changes done too. ---------------------------------------------------------------------- Comment By: Thomas Lee (krumms) Date: 2005-11-14 01:02 Message: Logged In: YES user_id=315535 Attaching a unit test checking the various different types of exception handling syntax. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1355913&group_id=5470 From noreply at sourceforge.net Mon Nov 14 14:58:38 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 14 Nov 2005 05:58:38 -0800 Subject: [Patches] [ python-Patches-1356571 ] Sort nodes when writing to file Message-ID: Patches item #1356571, was opened at 2005-11-14 14: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=1356571&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: XML Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Johan Str?m (jstrom) Assigned to: Nobody/Anonymous (nobody) Summary: Sort nodes when writing to file Initial Comment: Regarding xml/dom/minidom.py Noticed that the minidom's writer functions sorted the attributes, but not the nodes, when writing (to file or other). This resulted in XML files having nodes in different order each time it was written (or at least not sorted, in OSX the nodes came in different order each time). This could maybe be a problem with ie. files that seemd to change when there realy isn't any content changes. If not, its just better looking to have them sorted. Wrote a patch for it if anyone wants to use it or add it to the repository. Can't say that I've done any extensive testing tho, if anyone sees any problems with it, please tell! ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1356571&group_id=5470 From noreply at sourceforge.net Mon Nov 14 17:56:18 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 14 Nov 2005 08:56:18 -0800 Subject: [Patches] [ python-Patches-1356571 ] Sort nodes when writing to file Message-ID: Patches item #1356571, was opened at 2005-11-14 14:58 Message generated for change (Settings changed) made by effbot You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1356571&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: XML Group: Python 2.4 >Status: Closed >Resolution: Rejected Priority: 5 Submitted By: Johan Str?m (jstrom) Assigned to: Nobody/Anonymous (nobody) Summary: Sort nodes when writing to file Initial Comment: Regarding xml/dom/minidom.py Noticed that the minidom's writer functions sorted the attributes, but not the nodes, when writing (to file or other). This resulted in XML files having nodes in different order each time it was written (or at least not sorted, in OSX the nodes came in different order each time). This could maybe be a problem with ie. files that seemd to change when there realy isn't any content changes. If not, its just better looking to have them sorted. Wrote a patch for it if anyone wants to use it or add it to the repository. Can't say that I've done any extensive testing tho, if anyone sees any problems with it, please tell! ---------------------------------------------------------------------- >Comment By: Fredrik Lundh (effbot) Date: 2005-11-14 17:56 Message: Logged In: YES user_id=38376 The element order tends to be pretty important in most XML formats. If applied to e.g. a simple XHTML file, your patch would place all text nodes first in the body, followed by all headers, and finally all paragraphs. I'm not sure a human reader would agree that the resulting document looks better... ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1356571&group_id=5470 From noreply at sourceforge.net Mon Nov 14 18:31:59 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 14 Nov 2005 09:31:59 -0800 Subject: [Patches] [ python-Patches-1356571 ] Sort nodes when writing to file Message-ID: Patches item #1356571, was opened at 2005-11-14 14:58 Message generated for change (Comment added) made by jstrom You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1356571&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: XML Group: Python 2.4 Status: Closed Resolution: Rejected Priority: 5 Submitted By: Johan Str?m (jstrom) Assigned to: Nobody/Anonymous (nobody) Summary: Sort nodes when writing to file Initial Comment: Regarding xml/dom/minidom.py Noticed that the minidom's writer functions sorted the attributes, but not the nodes, when writing (to file or other). This resulted in XML files having nodes in different order each time it was written (or at least not sorted, in OSX the nodes came in different order each time). This could maybe be a problem with ie. files that seemd to change when there realy isn't any content changes. If not, its just better looking to have them sorted. Wrote a patch for it if anyone wants to use it or add it to the repository. Can't say that I've done any extensive testing tho, if anyone sees any problems with it, please tell! ---------------------------------------------------------------------- >Comment By: Johan Str?m (jstrom) Date: 2005-11-14 18:31 Message: Logged In: YES user_id=1378372 Doh... I was to focused on my specific usage. ---------------------------------------------------------------------- Comment By: Fredrik Lundh (effbot) Date: 2005-11-14 17:56 Message: Logged In: YES user_id=38376 The element order tends to be pretty important in most XML formats. If applied to e.g. a simple XHTML file, your patch would place all text nodes first in the body, followed by all headers, and finally all paragraphs. I'm not sure a human reader would agree that the resulting document looks better... ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1356571&group_id=5470 From noreply at sourceforge.net Tue Nov 15 05:10:56 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 14 Nov 2005 20:10:56 -0800 Subject: [Patches] [ python-Patches-1355913 ] PEP 341 - Unification of try/except and try/finally Message-ID: Patches item #1355913, was opened at 2005-11-14 00:59 Message generated for change (Comment added) made by krumms You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1355913&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Core (C code) Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: Thomas Lee (krumms) Assigned to: Reinhold Birkenfeld (birkenfeld) Summary: PEP 341 - Unification of try/except and try/finally Initial Comment: Attached is a patch implementing PEP 341 against HEAD in subversion. It includes the following changes: 1. Grammar/Grammar updated as per the PEP 2. Python/ast.c wraps try/except blocks inside try/finally blocks if it detects the extended syntax. This patch is based heavily upon suggestions by Nick Coghlan on python-dev. ---------------------------------------------------------------------- >Comment By: Thomas Lee (krumms) Date: 2005-11-15 14:10 Message: Logged In: YES user_id=315535 Okay, v6 is up. Now using test-goto-cleanup. Also using asdl_stmt_seq_free. Any more suggestions/feedback? Anybody having trouble using this patch? ---------------------------------------------------------------------- Comment By: Thomas Lee (krumms) Date: 2005-11-14 22:14 Message: Logged In: YES user_id=315535 Thanks for your input Nick - I'll sort out a patch taking your suggestions into consideration tomorrow & resubmit it. ---------------------------------------------------------------------- Comment By: Nick Coghlan (ncoghlan) Date: 2005-11-14 18:54 Message: Logged In: YES user_id=1038590 >From a code inspection of v5 of the patch (I haven't actually run the patch anywhere), I'm a little uncomfortable with the mixture of the two error handling styles (that is, test-cleanup-return for most of the function, but test-goto-cleanup for the one specific case). I don't mind either style (and both are used in the Python source), but mixing them in one function bothers me :) Further, there appears to be a bug in the deallocation code, in that all sequences should be freed with adsl_seq_stmt_free. The current direct use of adsl_seq_free means any contained statements are not released. I suggest putting a single 'error' label at the end of the function that uses adsl_seq_stmt_free to clean up all the statement sequences , as well as free_stmt to clean up the nested except statements. As both of these functions handle nulls gracefully, the bodies of the current error cleanup and return branches can all then be replaced with "goto error". ---------------------------------------------------------------------- Comment By: Thomas Lee (krumms) Date: 2005-11-14 15:18 Message: Logged In: YES user_id=315535 Oops - I mean Neal :) ---------------------------------------------------------------------- Comment By: Thomas Lee (krumms) Date: 2005-11-14 15:17 Message: Logged In: YES user_id=315535 Fix for the problem you encountered in the v5 patch, Nick. All tests in the suite now pass for me, no assertion failures when using --with-pydebug. I was stupidly generating a TryFinally in every scenario. This breaks down in the 'trace' unit test when no 'finally' clause is present with the extended syntax. Oops. Also added a little more error checking code and updated the unit test to test nested exception handling. I'm using a few goto statements in the "if (n_except > 0)" branch to reduce duplication deallocating memory. If there's any great objections to this feel free to yell & I'll resubmit a patch without the use of goto. Can you please verify this works for you, Nick? ---------------------------------------------------------------------- Comment By: Thomas Lee (krumms) Date: 2005-11-14 10:02 Message: Logged In: YES user_id=315535 Fixed a bad assumption when parsing a try-finally. Should be fixed now. I'm not sure if this fixes the problem you're experiencing, Neal. I'll have a look into it. ---------------------------------------------------------------------- Comment By: Thomas Lee (krumms) Date: 2005-11-14 09:12 Message: Logged In: YES user_id=315535 Further correction of memory leaks. 'finally' and 'orelse' need to be deallocated if an error occurs in the "if (n_except > 0)" branch. ---------------------------------------------------------------------- Comment By: Thomas Lee (krumms) Date: 2005-11-14 09:12 Message: Logged In: YES user_id=315535 Further correction of memory leaks. 'finally' and 'orelse' need to be deallocated if an error occurs in the "if (n_except > 0)" branch. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2005-11-14 09:10 Message: Logged In: YES user_id=33168 I'm pretty sure this patch causes this problem: python: Objects/frameobject.c:187: frame_setlineno: Assertion `blockstack_top > 0' failed. I'm not sure if it's just my hacked up version or the original. Thomas, can you test your version? ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2005-11-14 07:27 Message: Logged In: YES user_id=33168 Updated patch to correct memory leaks. Put everything in one file. Works for me. There needs to be doc changes done too. ---------------------------------------------------------------------- Comment By: Thomas Lee (krumms) Date: 2005-11-14 01:02 Message: Logged In: YES user_id=315535 Attaching a unit test checking the various different types of exception handling syntax. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1355913&group_id=5470 From noreply at sourceforge.net Tue Nov 15 05:43:21 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 14 Nov 2005 20:43:21 -0800 Subject: [Patches] [ python-Patches-1355913 ] PEP 341 - Unification of try/except and try/finally Message-ID: Patches item #1355913, was opened at 2005-11-13 06:59 Message generated for change (Comment added) made by nnorwitz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1355913&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Core (C code) Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: Thomas Lee (krumms) Assigned to: Reinhold Birkenfeld (birkenfeld) Summary: PEP 341 - Unification of try/except and try/finally Initial Comment: Attached is a patch implementing PEP 341 against HEAD in subversion. It includes the following changes: 1. Grammar/Grammar updated as per the PEP 2. Python/ast.c wraps try/except blocks inside try/finally blocks if it detects the extended syntax. This patch is based heavily upon suggestions by Nick Coghlan on python-dev. ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2005-11-14 20:43 Message: Logged In: YES user_id=33168 Oh, so close, I'm sorry, I see one more problem. :-) Thomas, I hope you will write up this experience in coding this patch. IMO it clearly demonstrates a problem with the new AST code that needs to be addressed. ie, Memory management is not possible to get right. I've got a 700+ line patch to ast.c to correct many more memory issues (hopefully that won't cause conflicts with this patch). I would like to hear ideas of how the AST code can be improved to make it much easier to not leak memory and be safe at the same time. The problem is that handlers is not an asdl_seq of stmt's, but rather an asdl_seq of exceptionhandlers. There is no utility function to clean out this seq, so you need to do it manually. for (i = 0; i < asdl_seq_LEN(handlers); i++) free_exceptionhandler(asdl_seq_GET(handlers, i)); asdl_seq_free(handlers); I don't see any other problems, but perhaps I will when it gets checked in or I run valgrind on it. The Other Nick :-) ---------------------------------------------------------------------- Comment By: Thomas Lee (krumms) Date: 2005-11-14 20:10 Message: Logged In: YES user_id=315535 Okay, v6 is up. Now using test-goto-cleanup. Also using asdl_stmt_seq_free. Any more suggestions/feedback? Anybody having trouble using this patch? ---------------------------------------------------------------------- Comment By: Thomas Lee (krumms) Date: 2005-11-14 04:14 Message: Logged In: YES user_id=315535 Thanks for your input Nick - I'll sort out a patch taking your suggestions into consideration tomorrow & resubmit it. ---------------------------------------------------------------------- Comment By: Nick Coghlan (ncoghlan) Date: 2005-11-14 00:54 Message: Logged In: YES user_id=1038590 >From a code inspection of v5 of the patch (I haven't actually run the patch anywhere), I'm a little uncomfortable with the mixture of the two error handling styles (that is, test-cleanup-return for most of the function, but test-goto-cleanup for the one specific case). I don't mind either style (and both are used in the Python source), but mixing them in one function bothers me :) Further, there appears to be a bug in the deallocation code, in that all sequences should be freed with adsl_seq_stmt_free. The current direct use of adsl_seq_free means any contained statements are not released. I suggest putting a single 'error' label at the end of the function that uses adsl_seq_stmt_free to clean up all the statement sequences , as well as free_stmt to clean up the nested except statements. As both of these functions handle nulls gracefully, the bodies of the current error cleanup and return branches can all then be replaced with "goto error". ---------------------------------------------------------------------- Comment By: Thomas Lee (krumms) Date: 2005-11-13 21:18 Message: Logged In: YES user_id=315535 Oops - I mean Neal :) ---------------------------------------------------------------------- Comment By: Thomas Lee (krumms) Date: 2005-11-13 21:17 Message: Logged In: YES user_id=315535 Fix for the problem you encountered in the v5 patch, Nick. All tests in the suite now pass for me, no assertion failures when using --with-pydebug. I was stupidly generating a TryFinally in every scenario. This breaks down in the 'trace' unit test when no 'finally' clause is present with the extended syntax. Oops. Also added a little more error checking code and updated the unit test to test nested exception handling. I'm using a few goto statements in the "if (n_except > 0)" branch to reduce duplication deallocating memory. If there's any great objections to this feel free to yell & I'll resubmit a patch without the use of goto. Can you please verify this works for you, Nick? ---------------------------------------------------------------------- Comment By: Thomas Lee (krumms) Date: 2005-11-13 16:02 Message: Logged In: YES user_id=315535 Fixed a bad assumption when parsing a try-finally. Should be fixed now. I'm not sure if this fixes the problem you're experiencing, Neal. I'll have a look into it. ---------------------------------------------------------------------- Comment By: Thomas Lee (krumms) Date: 2005-11-13 15:12 Message: Logged In: YES user_id=315535 Further correction of memory leaks. 'finally' and 'orelse' need to be deallocated if an error occurs in the "if (n_except > 0)" branch. ---------------------------------------------------------------------- Comment By: Thomas Lee (krumms) Date: 2005-11-13 15:12 Message: Logged In: YES user_id=315535 Further correction of memory leaks. 'finally' and 'orelse' need to be deallocated if an error occurs in the "if (n_except > 0)" branch. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2005-11-13 15:10 Message: Logged In: YES user_id=33168 I'm pretty sure this patch causes this problem: python: Objects/frameobject.c:187: frame_setlineno: Assertion `blockstack_top > 0' failed. I'm not sure if it's just my hacked up version or the original. Thomas, can you test your version? ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2005-11-13 13:27 Message: Logged In: YES user_id=33168 Updated patch to correct memory leaks. Put everything in one file. Works for me. There needs to be doc changes done too. ---------------------------------------------------------------------- Comment By: Thomas Lee (krumms) Date: 2005-11-13 07:02 Message: Logged In: YES user_id=315535 Attaching a unit test checking the various different types of exception handling syntax. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1355913&group_id=5470 From noreply at sourceforge.net Tue Nov 15 05:50:18 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 14 Nov 2005 20:50:18 -0800 Subject: [Patches] [ python-Patches-1355913 ] PEP 341 - Unification of try/except and try/finally Message-ID: Patches item #1355913, was opened at 2005-11-14 00:59 Message generated for change (Comment added) made by krumms You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1355913&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Core (C code) Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: Thomas Lee (krumms) Assigned to: Reinhold Birkenfeld (birkenfeld) Summary: PEP 341 - Unification of try/except and try/finally Initial Comment: Attached is a patch implementing PEP 341 against HEAD in subversion. It includes the following changes: 1. Grammar/Grammar updated as per the PEP 2. Python/ast.c wraps try/except blocks inside try/finally blocks if it detects the extended syntax. This patch is based heavily upon suggestions by Nick Coghlan on python-dev. ---------------------------------------------------------------------- >Comment By: Thomas Lee (krumms) Date: 2005-11-15 14:50 Message: Logged In: YES user_id=315535 lol thanks Neal/Nick, that's fine. :) Nick Coghlan and yourself have been extremely helpful throughout this whole process, and it's been a great learning experience. I'll implement your suggested fix for 'handlers' right away. If you like, let me know when you've committed the 700+ line patch and I'll generate the PEP 341 patch from that. - Tom ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2005-11-15 14:43 Message: Logged In: YES user_id=33168 Oh, so close, I'm sorry, I see one more problem. :-) Thomas, I hope you will write up this experience in coding this patch. IMO it clearly demonstrates a problem with the new AST code that needs to be addressed. ie, Memory management is not possible to get right. I've got a 700+ line patch to ast.c to correct many more memory issues (hopefully that won't cause conflicts with this patch). I would like to hear ideas of how the AST code can be improved to make it much easier to not leak memory and be safe at the same time. The problem is that handlers is not an asdl_seq of stmt's, but rather an asdl_seq of exceptionhandlers. There is no utility function to clean out this seq, so you need to do it manually. for (i = 0; i < asdl_seq_LEN(handlers); i++) free_exceptionhandler(asdl_seq_GET(handlers, i)); asdl_seq_free(handlers); I don't see any other problems, but perhaps I will when it gets checked in or I run valgrind on it. The Other Nick :-) ---------------------------------------------------------------------- Comment By: Thomas Lee (krumms) Date: 2005-11-15 14:10 Message: Logged In: YES user_id=315535 Okay, v6 is up. Now using test-goto-cleanup. Also using asdl_stmt_seq_free. Any more suggestions/feedback? Anybody having trouble using this patch? ---------------------------------------------------------------------- Comment By: Thomas Lee (krumms) Date: 2005-11-14 22:14 Message: Logged In: YES user_id=315535 Thanks for your input Nick - I'll sort out a patch taking your suggestions into consideration tomorrow & resubmit it. ---------------------------------------------------------------------- Comment By: Nick Coghlan (ncoghlan) Date: 2005-11-14 18:54 Message: Logged In: YES user_id=1038590 >From a code inspection of v5 of the patch (I haven't actually run the patch anywhere), I'm a little uncomfortable with the mixture of the two error handling styles (that is, test-cleanup-return for most of the function, but test-goto-cleanup for the one specific case). I don't mind either style (and both are used in the Python source), but mixing them in one function bothers me :) Further, there appears to be a bug in the deallocation code, in that all sequences should be freed with adsl_seq_stmt_free. The current direct use of adsl_seq_free means any contained statements are not released. I suggest putting a single 'error' label at the end of the function that uses adsl_seq_stmt_free to clean up all the statement sequences , as well as free_stmt to clean up the nested except statements. As both of these functions handle nulls gracefully, the bodies of the current error cleanup and return branches can all then be replaced with "goto error". ---------------------------------------------------------------------- Comment By: Thomas Lee (krumms) Date: 2005-11-14 15:18 Message: Logged In: YES user_id=315535 Oops - I mean Neal :) ---------------------------------------------------------------------- Comment By: Thomas Lee (krumms) Date: 2005-11-14 15:17 Message: Logged In: YES user_id=315535 Fix for the problem you encountered in the v5 patch, Nick. All tests in the suite now pass for me, no assertion failures when using --with-pydebug. I was stupidly generating a TryFinally in every scenario. This breaks down in the 'trace' unit test when no 'finally' clause is present with the extended syntax. Oops. Also added a little more error checking code and updated the unit test to test nested exception handling. I'm using a few goto statements in the "if (n_except > 0)" branch to reduce duplication deallocating memory. If there's any great objections to this feel free to yell & I'll resubmit a patch without the use of goto. Can you please verify this works for you, Nick? ---------------------------------------------------------------------- Comment By: Thomas Lee (krumms) Date: 2005-11-14 10:02 Message: Logged In: YES user_id=315535 Fixed a bad assumption when parsing a try-finally. Should be fixed now. I'm not sure if this fixes the problem you're experiencing, Neal. I'll have a look into it. ---------------------------------------------------------------------- Comment By: Thomas Lee (krumms) Date: 2005-11-14 09:12 Message: Logged In: YES user_id=315535 Further correction of memory leaks. 'finally' and 'orelse' need to be deallocated if an error occurs in the "if (n_except > 0)" branch. ---------------------------------------------------------------------- Comment By: Thomas Lee (krumms) Date: 2005-11-14 09:12 Message: Logged In: YES user_id=315535 Further correction of memory leaks. 'finally' and 'orelse' need to be deallocated if an error occurs in the "if (n_except > 0)" branch. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2005-11-14 09:10 Message: Logged In: YES user_id=33168 I'm pretty sure this patch causes this problem: python: Objects/frameobject.c:187: frame_setlineno: Assertion `blockstack_top > 0' failed. I'm not sure if it's just my hacked up version or the original. Thomas, can you test your version? ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2005-11-14 07:27 Message: Logged In: YES user_id=33168 Updated patch to correct memory leaks. Put everything in one file. Works for me. There needs to be doc changes done too. ---------------------------------------------------------------------- Comment By: Thomas Lee (krumms) Date: 2005-11-14 01:02 Message: Logged In: YES user_id=315535 Attaching a unit test checking the various different types of exception handling syntax. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1355913&group_id=5470 From noreply at sourceforge.net Tue Nov 15 14:15:57 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 15 Nov 2005 05:15:57 -0800 Subject: [Patches] [ python-Patches-1355913 ] PEP 341 - Unification of try/except and try/finally Message-ID: Patches item #1355913, was opened at 2005-11-14 00:59 Message generated for change (Comment added) made by krumms You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1355913&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Core (C code) Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: Thomas Lee (krumms) Assigned to: Reinhold Birkenfeld (birkenfeld) Summary: PEP 341 - Unification of try/except and try/finally Initial Comment: Attached is a patch implementing PEP 341 against HEAD in subversion. It includes the following changes: 1. Grammar/Grammar updated as per the PEP 2. Python/ast.c wraps try/except blocks inside try/finally blocks if it detects the extended syntax. This patch is based heavily upon suggestions by Nick Coghlan on python-dev. ---------------------------------------------------------------------- >Comment By: Thomas Lee (krumms) Date: 2005-11-15 23:15 Message: Logged In: YES user_id=315535 Here's the v7 patch against revision 41451, with Neal's last fix :) Using Marek's suggestion for try/except emulation in C from python-dev to avoid the "goto" crap. Any more problems here? *looks hopeful* :) - Tom ---------------------------------------------------------------------- Comment By: Thomas Lee (krumms) Date: 2005-11-15 14:50 Message: Logged In: YES user_id=315535 lol thanks Neal/Nick, that's fine. :) Nick Coghlan and yourself have been extremely helpful throughout this whole process, and it's been a great learning experience. I'll implement your suggested fix for 'handlers' right away. If you like, let me know when you've committed the 700+ line patch and I'll generate the PEP 341 patch from that. - Tom ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2005-11-15 14:43 Message: Logged In: YES user_id=33168 Oh, so close, I'm sorry, I see one more problem. :-) Thomas, I hope you will write up this experience in coding this patch. IMO it clearly demonstrates a problem with the new AST code that needs to be addressed. ie, Memory management is not possible to get right. I've got a 700+ line patch to ast.c to correct many more memory issues (hopefully that won't cause conflicts with this patch). I would like to hear ideas of how the AST code can be improved to make it much easier to not leak memory and be safe at the same time. The problem is that handlers is not an asdl_seq of stmt's, but rather an asdl_seq of exceptionhandlers. There is no utility function to clean out this seq, so you need to do it manually. for (i = 0; i < asdl_seq_LEN(handlers); i++) free_exceptionhandler(asdl_seq_GET(handlers, i)); asdl_seq_free(handlers); I don't see any other problems, but perhaps I will when it gets checked in or I run valgrind on it. The Other Nick :-) ---------------------------------------------------------------------- Comment By: Thomas Lee (krumms) Date: 2005-11-15 14:10 Message: Logged In: YES user_id=315535 Okay, v6 is up. Now using test-goto-cleanup. Also using asdl_stmt_seq_free. Any more suggestions/feedback? Anybody having trouble using this patch? ---------------------------------------------------------------------- Comment By: Thomas Lee (krumms) Date: 2005-11-14 22:14 Message: Logged In: YES user_id=315535 Thanks for your input Nick - I'll sort out a patch taking your suggestions into consideration tomorrow & resubmit it. ---------------------------------------------------------------------- Comment By: Nick Coghlan (ncoghlan) Date: 2005-11-14 18:54 Message: Logged In: YES user_id=1038590 >From a code inspection of v5 of the patch (I haven't actually run the patch anywhere), I'm a little uncomfortable with the mixture of the two error handling styles (that is, test-cleanup-return for most of the function, but test-goto-cleanup for the one specific case). I don't mind either style (and both are used in the Python source), but mixing them in one function bothers me :) Further, there appears to be a bug in the deallocation code, in that all sequences should be freed with adsl_seq_stmt_free. The current direct use of adsl_seq_free means any contained statements are not released. I suggest putting a single 'error' label at the end of the function that uses adsl_seq_stmt_free to clean up all the statement sequences , as well as free_stmt to clean up the nested except statements. As both of these functions handle nulls gracefully, the bodies of the current error cleanup and return branches can all then be replaced with "goto error". ---------------------------------------------------------------------- Comment By: Thomas Lee (krumms) Date: 2005-11-14 15:18 Message: Logged In: YES user_id=315535 Oops - I mean Neal :) ---------------------------------------------------------------------- Comment By: Thomas Lee (krumms) Date: 2005-11-14 15:17 Message: Logged In: YES user_id=315535 Fix for the problem you encountered in the v5 patch, Nick. All tests in the suite now pass for me, no assertion failures when using --with-pydebug. I was stupidly generating a TryFinally in every scenario. This breaks down in the 'trace' unit test when no 'finally' clause is present with the extended syntax. Oops. Also added a little more error checking code and updated the unit test to test nested exception handling. I'm using a few goto statements in the "if (n_except > 0)" branch to reduce duplication deallocating memory. If there's any great objections to this feel free to yell & I'll resubmit a patch without the use of goto. Can you please verify this works for you, Nick? ---------------------------------------------------------------------- Comment By: Thomas Lee (krumms) Date: 2005-11-14 10:02 Message: Logged In: YES user_id=315535 Fixed a bad assumption when parsing a try-finally. Should be fixed now. I'm not sure if this fixes the problem you're experiencing, Neal. I'll have a look into it. ---------------------------------------------------------------------- Comment By: Thomas Lee (krumms) Date: 2005-11-14 09:12 Message: Logged In: YES user_id=315535 Further correction of memory leaks. 'finally' and 'orelse' need to be deallocated if an error occurs in the "if (n_except > 0)" branch. ---------------------------------------------------------------------- Comment By: Thomas Lee (krumms) Date: 2005-11-14 09:12 Message: Logged In: YES user_id=315535 Further correction of memory leaks. 'finally' and 'orelse' need to be deallocated if an error occurs in the "if (n_except > 0)" branch. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2005-11-14 09:10 Message: Logged In: YES user_id=33168 I'm pretty sure this patch causes this problem: python: Objects/frameobject.c:187: frame_setlineno: Assertion `blockstack_top > 0' failed. I'm not sure if it's just my hacked up version or the original. Thomas, can you test your version? ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2005-11-14 07:27 Message: Logged In: YES user_id=33168 Updated patch to correct memory leaks. Put everything in one file. Works for me. There needs to be doc changes done too. ---------------------------------------------------------------------- Comment By: Thomas Lee (krumms) Date: 2005-11-14 01:02 Message: Logged In: YES user_id=315535 Attaching a unit test checking the various different types of exception handling syntax. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1355913&group_id=5470 From noreply at sourceforge.net Wed Nov 16 06:26:25 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 15 Nov 2005 21:26:25 -0800 Subject: [Patches] [ python-Patches-1357836 ] potential crash and free memory read Message-ID: Patches item #1357836, was opened at 2005-11-15 21:26 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1357836&group_id=5470 Please note that this 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: Neal Norwitz (nnorwitz) Assigned to: Martin v. L?wis (loewis) Summary: potential crash and free memory read Initial Comment: Martin, I think this problem came about from the work on PEP 263 (coding spec). Attached is a patch that corrects a free memory write. The problem shows up with valgrind and test_coding IIRC. There is a XXX comment in the code which points to another problem. It's possible that you could break and not do a strcpy(). Or perhaps decoding_fgets() shouldn't call error_ret(). I'm not sure if error_ret() should free the buffer ever. I think that would be my preference. That way we can deallocate it where we allocate it. I think I plugged all the other leaks. Let me know what you think. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1357836&group_id=5470 From noreply at sourceforge.net Wed Nov 16 06:38:46 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 15 Nov 2005 21:38:46 -0800 Subject: [Patches] [ python-Patches-1355913 ] PEP 341 - Unification of try/except and try/finally Message-ID: Patches item #1355913, was opened at 2005-11-13 06:59 Message generated for change (Comment added) made by nnorwitz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1355913&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Core (C code) Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: Thomas Lee (krumms) Assigned to: Reinhold Birkenfeld (birkenfeld) Summary: PEP 341 - Unification of try/except and try/finally Initial Comment: Attached is a patch implementing PEP 341 against HEAD in subversion. It includes the following changes: 1. Grammar/Grammar updated as per the PEP 2. Python/ast.c wraps try/except blocks inside try/finally blocks if it detects the extended syntax. This patch is based heavily upon suggestions by Nick Coghlan on python-dev. ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2005-11-15 21:38 Message: Logged In: YES user_id=33168 ISTM there are a couple of problems. Some of these were likely in there before and I may have told you to do some. :-( I probably made the same error too. :-( :-( One is a new one though. That starts in the for loop. You break in there, but that only breaks out of the for loop, doesn't it? So you really need a goto to break out I think. After setting except_st, it holds references to body, handlers, and orelse, so if you free except_st, it should free all the others. Therefore if except_st was created (after the if (except_st) break;), you should set body = handlers = orelse = NULL; Do you agree? I think if you don't you will get a double free. The same would go for after you asdl_seq_SET(inner, 0, except_st); you should set except_st = NULL; OTOH, you fixed a memory leak. Whenever one does return TryExcept(); (or any other similar AST call), if TryExcept fails, we will return NULL and all the local variables will be leaked. *sigh* Sorry you have to deal with this crap. You've been a very good guinea pig being the first. I really hope we do the arenas as discussed on python-dev. If you aren't too burnt out, it would be a really good way to learn the rest of the AST. :-) ---------------------------------------------------------------------- Comment By: Thomas Lee (krumms) Date: 2005-11-15 05:15 Message: Logged In: YES user_id=315535 Here's the v7 patch against revision 41451, with Neal's last fix :) Using Marek's suggestion for try/except emulation in C from python-dev to avoid the "goto" crap. Any more problems here? *looks hopeful* :) - Tom ---------------------------------------------------------------------- Comment By: Thomas Lee (krumms) Date: 2005-11-14 20:50 Message: Logged In: YES user_id=315535 lol thanks Neal/Nick, that's fine. :) Nick Coghlan and yourself have been extremely helpful throughout this whole process, and it's been a great learning experience. I'll implement your suggested fix for 'handlers' right away. If you like, let me know when you've committed the 700+ line patch and I'll generate the PEP 341 patch from that. - Tom ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2005-11-14 20:43 Message: Logged In: YES user_id=33168 Oh, so close, I'm sorry, I see one more problem. :-) Thomas, I hope you will write up this experience in coding this patch. IMO it clearly demonstrates a problem with the new AST code that needs to be addressed. ie, Memory management is not possible to get right. I've got a 700+ line patch to ast.c to correct many more memory issues (hopefully that won't cause conflicts with this patch). I would like to hear ideas of how the AST code can be improved to make it much easier to not leak memory and be safe at the same time. The problem is that handlers is not an asdl_seq of stmt's, but rather an asdl_seq of exceptionhandlers. There is no utility function to clean out this seq, so you need to do it manually. for (i = 0; i < asdl_seq_LEN(handlers); i++) free_exceptionhandler(asdl_seq_GET(handlers, i)); asdl_seq_free(handlers); I don't see any other problems, but perhaps I will when it gets checked in or I run valgrind on it. The Other Nick :-) ---------------------------------------------------------------------- Comment By: Thomas Lee (krumms) Date: 2005-11-14 20:10 Message: Logged In: YES user_id=315535 Okay, v6 is up. Now using test-goto-cleanup. Also using asdl_stmt_seq_free. Any more suggestions/feedback? Anybody having trouble using this patch? ---------------------------------------------------------------------- Comment By: Thomas Lee (krumms) Date: 2005-11-14 04:14 Message: Logged In: YES user_id=315535 Thanks for your input Nick - I'll sort out a patch taking your suggestions into consideration tomorrow & resubmit it. ---------------------------------------------------------------------- Comment By: Nick Coghlan (ncoghlan) Date: 2005-11-14 00:54 Message: Logged In: YES user_id=1038590 >From a code inspection of v5 of the patch (I haven't actually run the patch anywhere), I'm a little uncomfortable with the mixture of the two error handling styles (that is, test-cleanup-return for most of the function, but test-goto-cleanup for the one specific case). I don't mind either style (and both are used in the Python source), but mixing them in one function bothers me :) Further, there appears to be a bug in the deallocation code, in that all sequences should be freed with adsl_seq_stmt_free. The current direct use of adsl_seq_free means any contained statements are not released. I suggest putting a single 'error' label at the end of the function that uses adsl_seq_stmt_free to clean up all the statement sequences , as well as free_stmt to clean up the nested except statements. As both of these functions handle nulls gracefully, the bodies of the current error cleanup and return branches can all then be replaced with "goto error". ---------------------------------------------------------------------- Comment By: Thomas Lee (krumms) Date: 2005-11-13 21:18 Message: Logged In: YES user_id=315535 Oops - I mean Neal :) ---------------------------------------------------------------------- Comment By: Thomas Lee (krumms) Date: 2005-11-13 21:17 Message: Logged In: YES user_id=315535 Fix for the problem you encountered in the v5 patch, Nick. All tests in the suite now pass for me, no assertion failures when using --with-pydebug. I was stupidly generating a TryFinally in every scenario. This breaks down in the 'trace' unit test when no 'finally' clause is present with the extended syntax. Oops. Also added a little more error checking code and updated the unit test to test nested exception handling. I'm using a few goto statements in the "if (n_except > 0)" branch to reduce duplication deallocating memory. If there's any great objections to this feel free to yell & I'll resubmit a patch without the use of goto. Can you please verify this works for you, Nick? ---------------------------------------------------------------------- Comment By: Thomas Lee (krumms) Date: 2005-11-13 16:02 Message: Logged In: YES user_id=315535 Fixed a bad assumption when parsing a try-finally. Should be fixed now. I'm not sure if this fixes the problem you're experiencing, Neal. I'll have a look into it. ---------------------------------------------------------------------- Comment By: Thomas Lee (krumms) Date: 2005-11-13 15:12 Message: Logged In: YES user_id=315535 Further correction of memory leaks. 'finally' and 'orelse' need to be deallocated if an error occurs in the "if (n_except > 0)" branch. ---------------------------------------------------------------------- Comment By: Thomas Lee (krumms) Date: 2005-11-13 15:12 Message: Logged In: YES user_id=315535 Further correction of memory leaks. 'finally' and 'orelse' need to be deallocated if an error occurs in the "if (n_except > 0)" branch. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2005-11-13 15:10 Message: Logged In: YES user_id=33168 I'm pretty sure this patch causes this problem: python: Objects/frameobject.c:187: frame_setlineno: Assertion `blockstack_top > 0' failed. I'm not sure if it's just my hacked up version or the original. Thomas, can you test your version? ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2005-11-13 13:27 Message: Logged In: YES user_id=33168 Updated patch to correct memory leaks. Put everything in one file. Works for me. There needs to be doc changes done too. ---------------------------------------------------------------------- Comment By: Thomas Lee (krumms) Date: 2005-11-13 07:02 Message: Logged In: YES user_id=315535 Attaching a unit test checking the various different types of exception handling syntax. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1355913&group_id=5470 From noreply at sourceforge.net Wed Nov 16 09:35:23 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 16 Nov 2005 00:35:23 -0800 Subject: [Patches] [ python-Patches-1355913 ] PEP 341 - Unification of try/except and try/finally Message-ID: Patches item #1355913, was opened at 2005-11-14 00:59 Message generated for change (Comment added) made by krumms You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1355913&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Core (C code) Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: Thomas Lee (krumms) Assigned to: Reinhold Birkenfeld (birkenfeld) Summary: PEP 341 - Unification of try/except and try/finally Initial Comment: Attached is a patch implementing PEP 341 against HEAD in subversion. It includes the following changes: 1. Grammar/Grammar updated as per the PEP 2. Python/ast.c wraps try/except blocks inside try/finally blocks if it detects the extended syntax. This patch is based heavily upon suggestions by Nick Coghlan on python-dev. ---------------------------------------------------------------------- >Comment By: Thomas Lee (krumms) Date: 2005-11-16 18:35 Message: Logged In: YES user_id=315535 Arrgh! :) Well ... I'll fix up this patch & submit it again. I might fall back to the 'goto' style of doing things just so we don't have the mix of "do ... break ... while" and goto (which I imagine could be almost as confusing as the mix of check-cleanup and goto-cleanup as described by Nick earlier). Again, if you could check the v8 patch for me it would be much appreciated. After that, I might hit python-dev and read up on what everybody's been saying about pools/arenas & maybe get started on something we can use for the AST ... anyway, I'll discuss that on python-dev. This isn't really the place for it :) ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2005-11-16 15:38 Message: Logged In: YES user_id=33168 ISTM there are a couple of problems. Some of these were likely in there before and I may have told you to do some. :-( I probably made the same error too. :-( :-( One is a new one though. That starts in the for loop. You break in there, but that only breaks out of the for loop, doesn't it? So you really need a goto to break out I think. After setting except_st, it holds references to body, handlers, and orelse, so if you free except_st, it should free all the others. Therefore if except_st was created (after the if (except_st) break;), you should set body = handlers = orelse = NULL; Do you agree? I think if you don't you will get a double free. The same would go for after you asdl_seq_SET(inner, 0, except_st); you should set except_st = NULL; OTOH, you fixed a memory leak. Whenever one does return TryExcept(); (or any other similar AST call), if TryExcept fails, we will return NULL and all the local variables will be leaked. *sigh* Sorry you have to deal with this crap. You've been a very good guinea pig being the first. I really hope we do the arenas as discussed on python-dev. If you aren't too burnt out, it would be a really good way to learn the rest of the AST. :-) ---------------------------------------------------------------------- Comment By: Thomas Lee (krumms) Date: 2005-11-15 23:15 Message: Logged In: YES user_id=315535 Here's the v7 patch against revision 41451, with Neal's last fix :) Using Marek's suggestion for try/except emulation in C from python-dev to avoid the "goto" crap. Any more problems here? *looks hopeful* :) - Tom ---------------------------------------------------------------------- Comment By: Thomas Lee (krumms) Date: 2005-11-15 14:50 Message: Logged In: YES user_id=315535 lol thanks Neal/Nick, that's fine. :) Nick Coghlan and yourself have been extremely helpful throughout this whole process, and it's been a great learning experience. I'll implement your suggested fix for 'handlers' right away. If you like, let me know when you've committed the 700+ line patch and I'll generate the PEP 341 patch from that. - Tom ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2005-11-15 14:43 Message: Logged In: YES user_id=33168 Oh, so close, I'm sorry, I see one more problem. :-) Thomas, I hope you will write up this experience in coding this patch. IMO it clearly demonstrates a problem with the new AST code that needs to be addressed. ie, Memory management is not possible to get right. I've got a 700+ line patch to ast.c to correct many more memory issues (hopefully that won't cause conflicts with this patch). I would like to hear ideas of how the AST code can be improved to make it much easier to not leak memory and be safe at the same time. The problem is that handlers is not an asdl_seq of stmt's, but rather an asdl_seq of exceptionhandlers. There is no utility function to clean out this seq, so you need to do it manually. for (i = 0; i < asdl_seq_LEN(handlers); i++) free_exceptionhandler(asdl_seq_GET(handlers, i)); asdl_seq_free(handlers); I don't see any other problems, but perhaps I will when it gets checked in or I run valgrind on it. The Other Nick :-) ---------------------------------------------------------------------- Comment By: Thomas Lee (krumms) Date: 2005-11-15 14:10 Message: Logged In: YES user_id=315535 Okay, v6 is up. Now using test-goto-cleanup. Also using asdl_stmt_seq_free. Any more suggestions/feedback? Anybody having trouble using this patch? ---------------------------------------------------------------------- Comment By: Thomas Lee (krumms) Date: 2005-11-14 22:14 Message: Logged In: YES user_id=315535 Thanks for your input Nick - I'll sort out a patch taking your suggestions into consideration tomorrow & resubmit it. ---------------------------------------------------------------------- Comment By: Nick Coghlan (ncoghlan) Date: 2005-11-14 18:54 Message: Logged In: YES user_id=1038590 >From a code inspection of v5 of the patch (I haven't actually run the patch anywhere), I'm a little uncomfortable with the mixture of the two error handling styles (that is, test-cleanup-return for most of the function, but test-goto-cleanup for the one specific case). I don't mind either style (and both are used in the Python source), but mixing them in one function bothers me :) Further, there appears to be a bug in the deallocation code, in that all sequences should be freed with adsl_seq_stmt_free. The current direct use of adsl_seq_free means any contained statements are not released. I suggest putting a single 'error' label at the end of the function that uses adsl_seq_stmt_free to clean up all the statement sequences , as well as free_stmt to clean up the nested except statements. As both of these functions handle nulls gracefully, the bodies of the current error cleanup and return branches can all then be replaced with "goto error". ---------------------------------------------------------------------- Comment By: Thomas Lee (krumms) Date: 2005-11-14 15:18 Message: Logged In: YES user_id=315535 Oops - I mean Neal :) ---------------------------------------------------------------------- Comment By: Thomas Lee (krumms) Date: 2005-11-14 15:17 Message: Logged In: YES user_id=315535 Fix for the problem you encountered in the v5 patch, Nick. All tests in the suite now pass for me, no assertion failures when using --with-pydebug. I was stupidly generating a TryFinally in every scenario. This breaks down in the 'trace' unit test when no 'finally' clause is present with the extended syntax. Oops. Also added a little more error checking code and updated the unit test to test nested exception handling. I'm using a few goto statements in the "if (n_except > 0)" branch to reduce duplication deallocating memory. If there's any great objections to this feel free to yell & I'll resubmit a patch without the use of goto. Can you please verify this works for you, Nick? ---------------------------------------------------------------------- Comment By: Thomas Lee (krumms) Date: 2005-11-14 10:02 Message: Logged In: YES user_id=315535 Fixed a bad assumption when parsing a try-finally. Should be fixed now. I'm not sure if this fixes the problem you're experiencing, Neal. I'll have a look into it. ---------------------------------------------------------------------- Comment By: Thomas Lee (krumms) Date: 2005-11-14 09:12 Message: Logged In: YES user_id=315535 Further correction of memory leaks. 'finally' and 'orelse' need to be deallocated if an error occurs in the "if (n_except > 0)" branch. ---------------------------------------------------------------------- Comment By: Thomas Lee (krumms) Date: 2005-11-14 09:12 Message: Logged In: YES user_id=315535 Further correction of memory leaks. 'finally' and 'orelse' need to be deallocated if an error occurs in the "if (n_except > 0)" branch. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2005-11-14 09:10 Message: Logged In: YES user_id=33168 I'm pretty sure this patch causes this problem: python: Objects/frameobject.c:187: frame_setlineno: Assertion `blockstack_top > 0' failed. I'm not sure if it's just my hacked up version or the original. Thomas, can you test your version? ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2005-11-14 07:27 Message: Logged In: YES user_id=33168 Updated patch to correct memory leaks. Put everything in one file. Works for me. There needs to be doc changes done too. ---------------------------------------------------------------------- Comment By: Thomas Lee (krumms) Date: 2005-11-14 01:02 Message: Logged In: YES user_id=315535 Attaching a unit test checking the various different types of exception handling syntax. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1355913&group_id=5470 From noreply at sourceforge.net Wed Nov 16 10:23:28 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 16 Nov 2005 01:23:28 -0800 Subject: [Patches] [ python-Patches-1355913 ] PEP 341 - Unification of try/except and try/finally Message-ID: Patches item #1355913, was opened at 2005-11-14 00:59 Message generated for change (Comment added) made by krumms You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1355913&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Core (C code) Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: Thomas Lee (krumms) Assigned to: Reinhold Birkenfeld (birkenfeld) Summary: PEP 341 - Unification of try/except and try/finally Initial Comment: Attached is a patch implementing PEP 341 against HEAD in subversion. It includes the following changes: 1. Grammar/Grammar updated as per the PEP 2. Python/ast.c wraps try/except blocks inside try/finally blocks if it detects the extended syntax. This patch is based heavily upon suggestions by Nick Coghlan on python-dev. ---------------------------------------------------------------------- >Comment By: Thomas Lee (krumms) Date: 2005-11-16 19:23 Message: Logged In: YES user_id=315535 Okay, here we go: v8! *sighs* this is devestating for my ego :) ---------------------------------------------------------------------- Comment By: Thomas Lee (krumms) Date: 2005-11-16 18:35 Message: Logged In: YES user_id=315535 Arrgh! :) Well ... I'll fix up this patch & submit it again. I might fall back to the 'goto' style of doing things just so we don't have the mix of "do ... break ... while" and goto (which I imagine could be almost as confusing as the mix of check-cleanup and goto-cleanup as described by Nick earlier). Again, if you could check the v8 patch for me it would be much appreciated. After that, I might hit python-dev and read up on what everybody's been saying about pools/arenas & maybe get started on something we can use for the AST ... anyway, I'll discuss that on python-dev. This isn't really the place for it :) ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2005-11-16 15:38 Message: Logged In: YES user_id=33168 ISTM there are a couple of problems. Some of these were likely in there before and I may have told you to do some. :-( I probably made the same error too. :-( :-( One is a new one though. That starts in the for loop. You break in there, but that only breaks out of the for loop, doesn't it? So you really need a goto to break out I think. After setting except_st, it holds references to body, handlers, and orelse, so if you free except_st, it should free all the others. Therefore if except_st was created (after the if (except_st) break;), you should set body = handlers = orelse = NULL; Do you agree? I think if you don't you will get a double free. The same would go for after you asdl_seq_SET(inner, 0, except_st); you should set except_st = NULL; OTOH, you fixed a memory leak. Whenever one does return TryExcept(); (or any other similar AST call), if TryExcept fails, we will return NULL and all the local variables will be leaked. *sigh* Sorry you have to deal with this crap. You've been a very good guinea pig being the first. I really hope we do the arenas as discussed on python-dev. If you aren't too burnt out, it would be a really good way to learn the rest of the AST. :-) ---------------------------------------------------------------------- Comment By: Thomas Lee (krumms) Date: 2005-11-15 23:15 Message: Logged In: YES user_id=315535 Here's the v7 patch against revision 41451, with Neal's last fix :) Using Marek's suggestion for try/except emulation in C from python-dev to avoid the "goto" crap. Any more problems here? *looks hopeful* :) - Tom ---------------------------------------------------------------------- Comment By: Thomas Lee (krumms) Date: 2005-11-15 14:50 Message: Logged In: YES user_id=315535 lol thanks Neal/Nick, that's fine. :) Nick Coghlan and yourself have been extremely helpful throughout this whole process, and it's been a great learning experience. I'll implement your suggested fix for 'handlers' right away. If you like, let me know when you've committed the 700+ line patch and I'll generate the PEP 341 patch from that. - Tom ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2005-11-15 14:43 Message: Logged In: YES user_id=33168 Oh, so close, I'm sorry, I see one more problem. :-) Thomas, I hope you will write up this experience in coding this patch. IMO it clearly demonstrates a problem with the new AST code that needs to be addressed. ie, Memory management is not possible to get right. I've got a 700+ line patch to ast.c to correct many more memory issues (hopefully that won't cause conflicts with this patch). I would like to hear ideas of how the AST code can be improved to make it much easier to not leak memory and be safe at the same time. The problem is that handlers is not an asdl_seq of stmt's, but rather an asdl_seq of exceptionhandlers. There is no utility function to clean out this seq, so you need to do it manually. for (i = 0; i < asdl_seq_LEN(handlers); i++) free_exceptionhandler(asdl_seq_GET(handlers, i)); asdl_seq_free(handlers); I don't see any other problems, but perhaps I will when it gets checked in or I run valgrind on it. The Other Nick :-) ---------------------------------------------------------------------- Comment By: Thomas Lee (krumms) Date: 2005-11-15 14:10 Message: Logged In: YES user_id=315535 Okay, v6 is up. Now using test-goto-cleanup. Also using asdl_stmt_seq_free. Any more suggestions/feedback? Anybody having trouble using this patch? ---------------------------------------------------------------------- Comment By: Thomas Lee (krumms) Date: 2005-11-14 22:14 Message: Logged In: YES user_id=315535 Thanks for your input Nick - I'll sort out a patch taking your suggestions into consideration tomorrow & resubmit it. ---------------------------------------------------------------------- Comment By: Nick Coghlan (ncoghlan) Date: 2005-11-14 18:54 Message: Logged In: YES user_id=1038590 >From a code inspection of v5 of the patch (I haven't actually run the patch anywhere), I'm a little uncomfortable with the mixture of the two error handling styles (that is, test-cleanup-return for most of the function, but test-goto-cleanup for the one specific case). I don't mind either style (and both are used in the Python source), but mixing them in one function bothers me :) Further, there appears to be a bug in the deallocation code, in that all sequences should be freed with adsl_seq_stmt_free. The current direct use of adsl_seq_free means any contained statements are not released. I suggest putting a single 'error' label at the end of the function that uses adsl_seq_stmt_free to clean up all the statement sequences , as well as free_stmt to clean up the nested except statements. As both of these functions handle nulls gracefully, the bodies of the current error cleanup and return branches can all then be replaced with "goto error". ---------------------------------------------------------------------- Comment By: Thomas Lee (krumms) Date: 2005-11-14 15:18 Message: Logged In: YES user_id=315535 Oops - I mean Neal :) ---------------------------------------------------------------------- Comment By: Thomas Lee (krumms) Date: 2005-11-14 15:17 Message: Logged In: YES user_id=315535 Fix for the problem you encountered in the v5 patch, Nick. All tests in the suite now pass for me, no assertion failures when using --with-pydebug. I was stupidly generating a TryFinally in every scenario. This breaks down in the 'trace' unit test when no 'finally' clause is present with the extended syntax. Oops. Also added a little more error checking code and updated the unit test to test nested exception handling. I'm using a few goto statements in the "if (n_except > 0)" branch to reduce duplication deallocating memory. If there's any great objections to this feel free to yell & I'll resubmit a patch without the use of goto. Can you please verify this works for you, Nick? ---------------------------------------------------------------------- Comment By: Thomas Lee (krumms) Date: 2005-11-14 10:02 Message: Logged In: YES user_id=315535 Fixed a bad assumption when parsing a try-finally. Should be fixed now. I'm not sure if this fixes the problem you're experiencing, Neal. I'll have a look into it. ---------------------------------------------------------------------- Comment By: Thomas Lee (krumms) Date: 2005-11-14 09:12 Message: Logged In: YES user_id=315535 Further correction of memory leaks. 'finally' and 'orelse' need to be deallocated if an error occurs in the "if (n_except > 0)" branch. ---------------------------------------------------------------------- Comment By: Thomas Lee (krumms) Date: 2005-11-14 09:12 Message: Logged In: YES user_id=315535 Further correction of memory leaks. 'finally' and 'orelse' need to be deallocated if an error occurs in the "if (n_except > 0)" branch. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2005-11-14 09:10 Message: Logged In: YES user_id=33168 I'm pretty sure this patch causes this problem: python: Objects/frameobject.c:187: frame_setlineno: Assertion `blockstack_top > 0' failed. I'm not sure if it's just my hacked up version or the original. Thomas, can you test your version? ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2005-11-14 07:27 Message: Logged In: YES user_id=33168 Updated patch to correct memory leaks. Put everything in one file. Works for me. There needs to be doc changes done too. ---------------------------------------------------------------------- Comment By: Thomas Lee (krumms) Date: 2005-11-14 01:02 Message: Logged In: YES user_id=315535 Attaching a unit test checking the various different types of exception handling syntax. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1355913&group_id=5470 From noreply at sourceforge.net Wed Nov 16 14:25:43 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 16 Nov 2005 05:25:43 -0800 Subject: [Patches] [ python-Patches-1355913 ] PEP 341 - Unification of try/except and try/finally Message-ID: Patches item #1355913, was opened at 2005-11-14 00:59 Message generated for change (Comment added) made by ncoghlan You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1355913&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Core (C code) Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: Thomas Lee (krumms) Assigned to: Reinhold Birkenfeld (birkenfeld) Summary: PEP 341 - Unification of try/except and try/finally Initial Comment: Attached is a patch implementing PEP 341 against HEAD in subversion. It includes the following changes: 1. Grammar/Grammar updated as per the PEP 2. Python/ast.c wraps try/except blocks inside try/finally blocks if it detects the extended syntax. This patch is based heavily upon suggestions by Nick Coghlan on python-dev. ---------------------------------------------------------------------- >Comment By: Nick Coghlan (ncoghlan) Date: 2005-11-16 23:25 Message: Logged In: YES user_id=1038590 Closest yet, but I don't think we're quite there yet. The 'except_st = NULL' part should be on the line immediately after except_st is inserted into the inner sequence. As soon as that insertion happens, we want to ensure that the statement is only freed once. What's currently there will technically work, but doesn't really have the right semantics. More importantly, the "body = handlers = orelse = NULL" part should only be executed if the call to TryExcept *succeeds*, not if it fails. Neil's right - we seriously need to find a better way to handle this memory management or it will be a source of significant pain (well, more pain than you've already experienced ;) ---------------------------------------------------------------------- Comment By: Thomas Lee (krumms) Date: 2005-11-16 19:23 Message: Logged In: YES user_id=315535 Okay, here we go: v8! *sighs* this is devestating for my ego :) ---------------------------------------------------------------------- Comment By: Thomas Lee (krumms) Date: 2005-11-16 18:35 Message: Logged In: YES user_id=315535 Arrgh! :) Well ... I'll fix up this patch & submit it again. I might fall back to the 'goto' style of doing things just so we don't have the mix of "do ... break ... while" and goto (which I imagine could be almost as confusing as the mix of check-cleanup and goto-cleanup as described by Nick earlier). Again, if you could check the v8 patch for me it would be much appreciated. After that, I might hit python-dev and read up on what everybody's been saying about pools/arenas & maybe get started on something we can use for the AST ... anyway, I'll discuss that on python-dev. This isn't really the place for it :) ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2005-11-16 15:38 Message: Logged In: YES user_id=33168 ISTM there are a couple of problems. Some of these were likely in there before and I may have told you to do some. :-( I probably made the same error too. :-( :-( One is a new one though. That starts in the for loop. You break in there, but that only breaks out of the for loop, doesn't it? So you really need a goto to break out I think. After setting except_st, it holds references to body, handlers, and orelse, so if you free except_st, it should free all the others. Therefore if except_st was created (after the if (except_st) break;), you should set body = handlers = orelse = NULL; Do you agree? I think if you don't you will get a double free. The same would go for after you asdl_seq_SET(inner, 0, except_st); you should set except_st = NULL; OTOH, you fixed a memory leak. Whenever one does return TryExcept(); (or any other similar AST call), if TryExcept fails, we will return NULL and all the local variables will be leaked. *sigh* Sorry you have to deal with this crap. You've been a very good guinea pig being the first. I really hope we do the arenas as discussed on python-dev. If you aren't too burnt out, it would be a really good way to learn the rest of the AST. :-) ---------------------------------------------------------------------- Comment By: Thomas Lee (krumms) Date: 2005-11-15 23:15 Message: Logged In: YES user_id=315535 Here's the v7 patch against revision 41451, with Neal's last fix :) Using Marek's suggestion for try/except emulation in C from python-dev to avoid the "goto" crap. Any more problems here? *looks hopeful* :) - Tom ---------------------------------------------------------------------- Comment By: Thomas Lee (krumms) Date: 2005-11-15 14:50 Message: Logged In: YES user_id=315535 lol thanks Neal/Nick, that's fine. :) Nick Coghlan and yourself have been extremely helpful throughout this whole process, and it's been a great learning experience. I'll implement your suggested fix for 'handlers' right away. If you like, let me know when you've committed the 700+ line patch and I'll generate the PEP 341 patch from that. - Tom ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2005-11-15 14:43 Message: Logged In: YES user_id=33168 Oh, so close, I'm sorry, I see one more problem. :-) Thomas, I hope you will write up this experience in coding this patch. IMO it clearly demonstrates a problem with the new AST code that needs to be addressed. ie, Memory management is not possible to get right. I've got a 700+ line patch to ast.c to correct many more memory issues (hopefully that won't cause conflicts with this patch). I would like to hear ideas of how the AST code can be improved to make it much easier to not leak memory and be safe at the same time. The problem is that handlers is not an asdl_seq of stmt's, but rather an asdl_seq of exceptionhandlers. There is no utility function to clean out this seq, so you need to do it manually. for (i = 0; i < asdl_seq_LEN(handlers); i++) free_exceptionhandler(asdl_seq_GET(handlers, i)); asdl_seq_free(handlers); I don't see any other problems, but perhaps I will when it gets checked in or I run valgrind on it. The Other Nick :-) ---------------------------------------------------------------------- Comment By: Thomas Lee (krumms) Date: 2005-11-15 14:10 Message: Logged In: YES user_id=315535 Okay, v6 is up. Now using test-goto-cleanup. Also using asdl_stmt_seq_free. Any more suggestions/feedback? Anybody having trouble using this patch? ---------------------------------------------------------------------- Comment By: Thomas Lee (krumms) Date: 2005-11-14 22:14 Message: Logged In: YES user_id=315535 Thanks for your input Nick - I'll sort out a patch taking your suggestions into consideration tomorrow & resubmit it. ---------------------------------------------------------------------- Comment By: Nick Coghlan (ncoghlan) Date: 2005-11-14 18:54 Message: Logged In: YES user_id=1038590 >From a code inspection of v5 of the patch (I haven't actually run the patch anywhere), I'm a little uncomfortable with the mixture of the two error handling styles (that is, test-cleanup-return for most of the function, but test-goto-cleanup for the one specific case). I don't mind either style (and both are used in the Python source), but mixing them in one function bothers me :) Further, there appears to be a bug in the deallocation code, in that all sequences should be freed with adsl_seq_stmt_free. The current direct use of adsl_seq_free means any contained statements are not released. I suggest putting a single 'error' label at the end of the function that uses adsl_seq_stmt_free to clean up all the statement sequences , as well as free_stmt to clean up the nested except statements. As both of these functions handle nulls gracefully, the bodies of the current error cleanup and return branches can all then be replaced with "goto error". ---------------------------------------------------------------------- Comment By: Thomas Lee (krumms) Date: 2005-11-14 15:18 Message: Logged In: YES user_id=315535 Oops - I mean Neal :) ---------------------------------------------------------------------- Comment By: Thomas Lee (krumms) Date: 2005-11-14 15:17 Message: Logged In: YES user_id=315535 Fix for the problem you encountered in the v5 patch, Nick. All tests in the suite now pass for me, no assertion failures when using --with-pydebug. I was stupidly generating a TryFinally in every scenario. This breaks down in the 'trace' unit test when no 'finally' clause is present with the extended syntax. Oops. Also added a little more error checking code and updated the unit test to test nested exception handling. I'm using a few goto statements in the "if (n_except > 0)" branch to reduce duplication deallocating memory. If there's any great objections to this feel free to yell & I'll resubmit a patch without the use of goto. Can you please verify this works for you, Nick? ---------------------------------------------------------------------- Comment By: Thomas Lee (krumms) Date: 2005-11-14 10:02 Message: Logged In: YES user_id=315535 Fixed a bad assumption when parsing a try-finally. Should be fixed now. I'm not sure if this fixes the problem you're experiencing, Neal. I'll have a look into it. ---------------------------------------------------------------------- Comment By: Thomas Lee (krumms) Date: 2005-11-14 09:12 Message: Logged In: YES user_id=315535 Further correction of memory leaks. 'finally' and 'orelse' need to be deallocated if an error occurs in the "if (n_except > 0)" branch. ---------------------------------------------------------------------- Comment By: Thomas Lee (krumms) Date: 2005-11-14 09:12 Message: Logged In: YES user_id=315535 Further correction of memory leaks. 'finally' and 'orelse' need to be deallocated if an error occurs in the "if (n_except > 0)" branch. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2005-11-14 09:10 Message: Logged In: YES user_id=33168 I'm pretty sure this patch causes this problem: python: Objects/frameobject.c:187: frame_setlineno: Assertion `blockstack_top > 0' failed. I'm not sure if it's just my hacked up version or the original. Thomas, can you test your version? ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2005-11-14 07:27 Message: Logged In: YES user_id=33168 Updated patch to correct memory leaks. Put everything in one file. Works for me. There needs to be doc changes done too. ---------------------------------------------------------------------- Comment By: Thomas Lee (krumms) Date: 2005-11-14 01:02 Message: Logged In: YES user_id=315535 Attaching a unit test checking the various different types of exception handling syntax. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1355913&group_id=5470 From jean-claude.brauer at wanadoo.fr Wed Nov 16 14:10:14 2005 From: jean-claude.brauer at wanadoo.fr (jean-claude) Date: Wed, 16 Nov 2005 14:10:14 +0100 (Paris, Madrid) Subject: [Patches] Tr : Message-ID: <437B2FB6.00000A.02664@PROPRI-S90BNCQJ> -------Message original------- De : vipmax Date : 11/16/05 13:53:03 A : jean-claude.brauer at wanadoo.fr From: "aurelie slama" To: lindseyattia at hotmail.com, chlomithhaik at msn.com, lesplusbelles at hotmail com, sam0309 at hotmail.com, axellesmia at hotmail.com Subject: FW: urgent a lire, CE N'EST PAS UNE CHAINE Date: Mon, 14 Nov 2005 12:09:27 +0000 > >URGENT FAITES SUIVRE LARGEMENT SVP > >Ceci est un appel au secours venant du CHU de ROUEN. >Merci de le lire et de faire suivre au plus grand nombre de gens >que vous connaissez. >Dr Mathieu DUPONT Assistant Chef de Clinique Service des Maladies >Infectieuses et R?animation M?dicale au CHU de RENNES >Tel : 02 99 28 42 87 Fax: 02 99 28 26 52 >Bonjour, >Auriez-vous la gentillesse de faire suivre ce mail a toutes vos >listes d'envois ? >Merci de votre implication. >Si vous connaissez une personne de groupe sanguin A rh?sus >n?gatif (tr?s rare), si cette personne est de pr?f?rence de sexe >masculin et ?g?e de moins de 40 ans, alors elle pourra peut-?tre >aider NOELIE qui a 1 an et est atteinte d'une leuc?mie rare a >b?n?ficier d'une greffe. >LE DELAI EST COURT : 2 MOIS >Contacter l'?tablissement Fran?ais du Sang de Bois Guillaume au : >02 35 60 50 50 >NOELIE est pour le moment hospitalis?e a Rennes (35) >Pour contact: >Fabienne HALOPEAU Normandie Est Service Tel : 02.31.65.60.51 / >fax 02.31.64.21.76 >FAITES SUIVRE CE MAIL, C'EST SERIEUX. COPIER COLLER LE >< >/STRONG> >MESSAGE >nbsp; >SINON CA DEVIENT ILLISIBLE!!!! > >_________________________________________________________________ -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.python.org/pipermail/patches/attachments/20051116/62a5b3b2/attachment.htm From noreply at sourceforge.net Wed Nov 16 14:52:13 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 16 Nov 2005 05:52:13 -0800 Subject: [Patches] [ python-Patches-1355913 ] PEP 341 - Unification of try/except and try/finally Message-ID: Patches item #1355913, was opened at 2005-11-14 00:59 Message generated for change (Comment added) made by krumms You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1355913&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Core (C code) Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: Thomas Lee (krumms) Assigned to: Reinhold Birkenfeld (birkenfeld) Summary: PEP 341 - Unification of try/except and try/finally Initial Comment: Attached is a patch implementing PEP 341 against HEAD in subversion. It includes the following changes: 1. Grammar/Grammar updated as per the PEP 2. Python/ast.c wraps try/except blocks inside try/finally blocks if it detects the extended syntax. This patch is based heavily upon suggestions by Nick Coghlan on python-dev. ---------------------------------------------------------------------- >Comment By: Thomas Lee (krumms) Date: 2005-11-16 23:52 Message: Logged In: YES user_id=315535 You're absolutely right with those bugs Nick. Fixed now. See how you go with v9 :) ---------------------------------------------------------------------- Comment By: Nick Coghlan (ncoghlan) Date: 2005-11-16 23:25 Message: Logged In: YES user_id=1038590 Closest yet, but I don't think we're quite there yet. The 'except_st = NULL' part should be on the line immediately after except_st is inserted into the inner sequence. As soon as that insertion happens, we want to ensure that the statement is only freed once. What's currently there will technically work, but doesn't really have the right semantics. More importantly, the "body = handlers = orelse = NULL" part should only be executed if the call to TryExcept *succeeds*, not if it fails. Neil's right - we seriously need to find a better way to handle this memory management or it will be a source of significant pain (well, more pain than you've already experienced ;) ---------------------------------------------------------------------- Comment By: Thomas Lee (krumms) Date: 2005-11-16 19:23 Message: Logged In: YES user_id=315535 Okay, here we go: v8! *sighs* this is devestating for my ego :) ---------------------------------------------------------------------- Comment By: Thomas Lee (krumms) Date: 2005-11-16 18:35 Message: Logged In: YES user_id=315535 Arrgh! :) Well ... I'll fix up this patch & submit it again. I might fall back to the 'goto' style of doing things just so we don't have the mix of "do ... break ... while" and goto (which I imagine could be almost as confusing as the mix of check-cleanup and goto-cleanup as described by Nick earlier). Again, if you could check the v8 patch for me it would be much appreciated. After that, I might hit python-dev and read up on what everybody's been saying about pools/arenas & maybe get started on something we can use for the AST ... anyway, I'll discuss that on python-dev. This isn't really the place for it :) ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2005-11-16 15:38 Message: Logged In: YES user_id=33168 ISTM there are a couple of problems. Some of these were likely in there before and I may have told you to do some. :-( I probably made the same error too. :-( :-( One is a new one though. That starts in the for loop. You break in there, but that only breaks out of the for loop, doesn't it? So you really need a goto to break out I think. After setting except_st, it holds references to body, handlers, and orelse, so if you free except_st, it should free all the others. Therefore if except_st was created (after the if (except_st) break;), you should set body = handlers = orelse = NULL; Do you agree? I think if you don't you will get a double free. The same would go for after you asdl_seq_SET(inner, 0, except_st); you should set except_st = NULL; OTOH, you fixed a memory leak. Whenever one does return TryExcept(); (or any other similar AST call), if TryExcept fails, we will return NULL and all the local variables will be leaked. *sigh* Sorry you have to deal with this crap. You've been a very good guinea pig being the first. I really hope we do the arenas as discussed on python-dev. If you aren't too burnt out, it would be a really good way to learn the rest of the AST. :-) ---------------------------------------------------------------------- Comment By: Thomas Lee (krumms) Date: 2005-11-15 23:15 Message: Logged In: YES user_id=315535 Here's the v7 patch against revision 41451, with Neal's last fix :) Using Marek's suggestion for try/except emulation in C from python-dev to avoid the "goto" crap. Any more problems here? *looks hopeful* :) - Tom ---------------------------------------------------------------------- Comment By: Thomas Lee (krumms) Date: 2005-11-15 14:50 Message: Logged In: YES user_id=315535 lol thanks Neal/Nick, that's fine. :) Nick Coghlan and yourself have been extremely helpful throughout this whole process, and it's been a great learning experience. I'll implement your suggested fix for 'handlers' right away. If you like, let me know when you've committed the 700+ line patch and I'll generate the PEP 341 patch from that. - Tom ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2005-11-15 14:43 Message: Logged In: YES user_id=33168 Oh, so close, I'm sorry, I see one more problem. :-) Thomas, I hope you will write up this experience in coding this patch. IMO it clearly demonstrates a problem with the new AST code that needs to be addressed. ie, Memory management is not possible to get right. I've got a 700+ line patch to ast.c to correct many more memory issues (hopefully that won't cause conflicts with this patch). I would like to hear ideas of how the AST code can be improved to make it much easier to not leak memory and be safe at the same time. The problem is that handlers is not an asdl_seq of stmt's, but rather an asdl_seq of exceptionhandlers. There is no utility function to clean out this seq, so you need to do it manually. for (i = 0; i < asdl_seq_LEN(handlers); i++) free_exceptionhandler(asdl_seq_GET(handlers, i)); asdl_seq_free(handlers); I don't see any other problems, but perhaps I will when it gets checked in or I run valgrind on it. The Other Nick :-) ---------------------------------------------------------------------- Comment By: Thomas Lee (krumms) Date: 2005-11-15 14:10 Message: Logged In: YES user_id=315535 Okay, v6 is up. Now using test-goto-cleanup. Also using asdl_stmt_seq_free. Any more suggestions/feedback? Anybody having trouble using this patch? ---------------------------------------------------------------------- Comment By: Thomas Lee (krumms) Date: 2005-11-14 22:14 Message: Logged In: YES user_id=315535 Thanks for your input Nick - I'll sort out a patch taking your suggestions into consideration tomorrow & resubmit it. ---------------------------------------------------------------------- Comment By: Nick Coghlan (ncoghlan) Date: 2005-11-14 18:54 Message: Logged In: YES user_id=1038590 >From a code inspection of v5 of the patch (I haven't actually run the patch anywhere), I'm a little uncomfortable with the mixture of the two error handling styles (that is, test-cleanup-return for most of the function, but test-goto-cleanup for the one specific case). I don't mind either style (and both are used in the Python source), but mixing them in one function bothers me :) Further, there appears to be a bug in the deallocation code, in that all sequences should be freed with adsl_seq_stmt_free. The current direct use of adsl_seq_free means any contained statements are not released. I suggest putting a single 'error' label at the end of the function that uses adsl_seq_stmt_free to clean up all the statement sequences , as well as free_stmt to clean up the nested except statements. As both of these functions handle nulls gracefully, the bodies of the current error cleanup and return branches can all then be replaced with "goto error". ---------------------------------------------------------------------- Comment By: Thomas Lee (krumms) Date: 2005-11-14 15:18 Message: Logged In: YES user_id=315535 Oops - I mean Neal :) ---------------------------------------------------------------------- Comment By: Thomas Lee (krumms) Date: 2005-11-14 15:17 Message: Logged In: YES user_id=315535 Fix for the problem you encountered in the v5 patch, Nick. All tests in the suite now pass for me, no assertion failures when using --with-pydebug. I was stupidly generating a TryFinally in every scenario. This breaks down in the 'trace' unit test when no 'finally' clause is present with the extended syntax. Oops. Also added a little more error checking code and updated the unit test to test nested exception handling. I'm using a few goto statements in the "if (n_except > 0)" branch to reduce duplication deallocating memory. If there's any great objections to this feel free to yell & I'll resubmit a patch without the use of goto. Can you please verify this works for you, Nick? ---------------------------------------------------------------------- Comment By: Thomas Lee (krumms) Date: 2005-11-14 10:02 Message: Logged In: YES user_id=315535 Fixed a bad assumption when parsing a try-finally. Should be fixed now. I'm not sure if this fixes the problem you're experiencing, Neal. I'll have a look into it. ---------------------------------------------------------------------- Comment By: Thomas Lee (krumms) Date: 2005-11-14 09:12 Message: Logged In: YES user_id=315535 Further correction of memory leaks. 'finally' and 'orelse' need to be deallocated if an error occurs in the "if (n_except > 0)" branch. ---------------------------------------------------------------------- Comment By: Thomas Lee (krumms) Date: 2005-11-14 09:12 Message: Logged In: YES user_id=315535 Further correction of memory leaks. 'finally' and 'orelse' need to be deallocated if an error occurs in the "if (n_except > 0)" branch. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2005-11-14 09:10 Message: Logged In: YES user_id=33168 I'm pretty sure this patch causes this problem: python: Objects/frameobject.c:187: frame_setlineno: Assertion `blockstack_top > 0' failed. I'm not sure if it's just my hacked up version or the original. Thomas, can you test your version? ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2005-11-14 07:27 Message: Logged In: YES user_id=33168 Updated patch to correct memory leaks. Put everything in one file. Works for me. There needs to be doc changes done too. ---------------------------------------------------------------------- Comment By: Thomas Lee (krumms) Date: 2005-11-14 01:02 Message: Logged In: YES user_id=315535 Attaching a unit test checking the various different types of exception handling syntax. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1355913&group_id=5470 From noreply at sourceforge.net Thu Nov 17 06:48:19 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 16 Nov 2005 21:48:19 -0800 Subject: [Patches] [ python-Patches-1355913 ] PEP 341 - Unification of try/except and try/finally Message-ID: Patches item #1355913, was opened at 2005-11-13 06:59 Message generated for change (Comment added) made by nnorwitz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1355913&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Core (C code) Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: Thomas Lee (krumms) Assigned to: Reinhold Birkenfeld (birkenfeld) Summary: PEP 341 - Unification of try/except and try/finally Initial Comment: Attached is a patch implementing PEP 341 against HEAD in subversion. It includes the following changes: 1. Grammar/Grammar updated as per the PEP 2. Python/ast.c wraps try/except blocks inside try/finally blocks if it detects the extended syntax. This patch is based heavily upon suggestions by Nick Coghlan on python-dev. ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2005-11-16 21:48 Message: Logged In: YES user_id=33168 Maybe I'm just tired, but I can't find any problems. Assuming this patch gets in, it ought to be the least buggy code in compile.c. :-) ---------------------------------------------------------------------- Comment By: Thomas Lee (krumms) Date: 2005-11-16 05:52 Message: Logged In: YES user_id=315535 You're absolutely right with those bugs Nick. Fixed now. See how you go with v9 :) ---------------------------------------------------------------------- Comment By: Nick Coghlan (ncoghlan) Date: 2005-11-16 05:25 Message: Logged In: YES user_id=1038590 Closest yet, but I don't think we're quite there yet. The 'except_st = NULL' part should be on the line immediately after except_st is inserted into the inner sequence. As soon as that insertion happens, we want to ensure that the statement is only freed once. What's currently there will technically work, but doesn't really have the right semantics. More importantly, the "body = handlers = orelse = NULL" part should only be executed if the call to TryExcept *succeeds*, not if it fails. Neil's right - we seriously need to find a better way to handle this memory management or it will be a source of significant pain (well, more pain than you've already experienced ;) ---------------------------------------------------------------------- Comment By: Thomas Lee (krumms) Date: 2005-11-16 01:23 Message: Logged In: YES user_id=315535 Okay, here we go: v8! *sighs* this is devestating for my ego :) ---------------------------------------------------------------------- Comment By: Thomas Lee (krumms) Date: 2005-11-16 00:35 Message: Logged In: YES user_id=315535 Arrgh! :) Well ... I'll fix up this patch & submit it again. I might fall back to the 'goto' style of doing things just so we don't have the mix of "do ... break ... while" and goto (which I imagine could be almost as confusing as the mix of check-cleanup and goto-cleanup as described by Nick earlier). Again, if you could check the v8 patch for me it would be much appreciated. After that, I might hit python-dev and read up on what everybody's been saying about pools/arenas & maybe get started on something we can use for the AST ... anyway, I'll discuss that on python-dev. This isn't really the place for it :) ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2005-11-15 21:38 Message: Logged In: YES user_id=33168 ISTM there are a couple of problems. Some of these were likely in there before and I may have told you to do some. :-( I probably made the same error too. :-( :-( One is a new one though. That starts in the for loop. You break in there, but that only breaks out of the for loop, doesn't it? So you really need a goto to break out I think. After setting except_st, it holds references to body, handlers, and orelse, so if you free except_st, it should free all the others. Therefore if except_st was created (after the if (except_st) break;), you should set body = handlers = orelse = NULL; Do you agree? I think if you don't you will get a double free. The same would go for after you asdl_seq_SET(inner, 0, except_st); you should set except_st = NULL; OTOH, you fixed a memory leak. Whenever one does return TryExcept(); (or any other similar AST call), if TryExcept fails, we will return NULL and all the local variables will be leaked. *sigh* Sorry you have to deal with this crap. You've been a very good guinea pig being the first. I really hope we do the arenas as discussed on python-dev. If you aren't too burnt out, it would be a really good way to learn the rest of the AST. :-) ---------------------------------------------------------------------- Comment By: Thomas Lee (krumms) Date: 2005-11-15 05:15 Message: Logged In: YES user_id=315535 Here's the v7 patch against revision 41451, with Neal's last fix :) Using Marek's suggestion for try/except emulation in C from python-dev to avoid the "goto" crap. Any more problems here? *looks hopeful* :) - Tom ---------------------------------------------------------------------- Comment By: Thomas Lee (krumms) Date: 2005-11-14 20:50 Message: Logged In: YES user_id=315535 lol thanks Neal/Nick, that's fine. :) Nick Coghlan and yourself have been extremely helpful throughout this whole process, and it's been a great learning experience. I'll implement your suggested fix for 'handlers' right away. If you like, let me know when you've committed the 700+ line patch and I'll generate the PEP 341 patch from that. - Tom ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2005-11-14 20:43 Message: Logged In: YES user_id=33168 Oh, so close, I'm sorry, I see one more problem. :-) Thomas, I hope you will write up this experience in coding this patch. IMO it clearly demonstrates a problem with the new AST code that needs to be addressed. ie, Memory management is not possible to get right. I've got a 700+ line patch to ast.c to correct many more memory issues (hopefully that won't cause conflicts with this patch). I would like to hear ideas of how the AST code can be improved to make it much easier to not leak memory and be safe at the same time. The problem is that handlers is not an asdl_seq of stmt's, but rather an asdl_seq of exceptionhandlers. There is no utility function to clean out this seq, so you need to do it manually. for (i = 0; i < asdl_seq_LEN(handlers); i++) free_exceptionhandler(asdl_seq_GET(handlers, i)); asdl_seq_free(handlers); I don't see any other problems, but perhaps I will when it gets checked in or I run valgrind on it. The Other Nick :-) ---------------------------------------------------------------------- Comment By: Thomas Lee (krumms) Date: 2005-11-14 20:10 Message: Logged In: YES user_id=315535 Okay, v6 is up. Now using test-goto-cleanup. Also using asdl_stmt_seq_free. Any more suggestions/feedback? Anybody having trouble using this patch? ---------------------------------------------------------------------- Comment By: Thomas Lee (krumms) Date: 2005-11-14 04:14 Message: Logged In: YES user_id=315535 Thanks for your input Nick - I'll sort out a patch taking your suggestions into consideration tomorrow & resubmit it. ---------------------------------------------------------------------- Comment By: Nick Coghlan (ncoghlan) Date: 2005-11-14 00:54 Message: Logged In: YES user_id=1038590 >From a code inspection of v5 of the patch (I haven't actually run the patch anywhere), I'm a little uncomfortable with the mixture of the two error handling styles (that is, test-cleanup-return for most of the function, but test-goto-cleanup for the one specific case). I don't mind either style (and both are used in the Python source), but mixing them in one function bothers me :) Further, there appears to be a bug in the deallocation code, in that all sequences should be freed with adsl_seq_stmt_free. The current direct use of adsl_seq_free means any contained statements are not released. I suggest putting a single 'error' label at the end of the function that uses adsl_seq_stmt_free to clean up all the statement sequences , as well as free_stmt to clean up the nested except statements. As both of these functions handle nulls gracefully, the bodies of the current error cleanup and return branches can all then be replaced with "goto error". ---------------------------------------------------------------------- Comment By: Thomas Lee (krumms) Date: 2005-11-13 21:18 Message: Logged In: YES user_id=315535 Oops - I mean Neal :) ---------------------------------------------------------------------- Comment By: Thomas Lee (krumms) Date: 2005-11-13 21:17 Message: Logged In: YES user_id=315535 Fix for the problem you encountered in the v5 patch, Nick. All tests in the suite now pass for me, no assertion failures when using --with-pydebug. I was stupidly generating a TryFinally in every scenario. This breaks down in the 'trace' unit test when no 'finally' clause is present with the extended syntax. Oops. Also added a little more error checking code and updated the unit test to test nested exception handling. I'm using a few goto statements in the "if (n_except > 0)" branch to reduce duplication deallocating memory. If there's any great objections to this feel free to yell & I'll resubmit a patch without the use of goto. Can you please verify this works for you, Nick? ---------------------------------------------------------------------- Comment By: Thomas Lee (krumms) Date: 2005-11-13 16:02 Message: Logged In: YES user_id=315535 Fixed a bad assumption when parsing a try-finally. Should be fixed now. I'm not sure if this fixes the problem you're experiencing, Neal. I'll have a look into it. ---------------------------------------------------------------------- Comment By: Thomas Lee (krumms) Date: 2005-11-13 15:12 Message: Logged In: YES user_id=315535 Further correction of memory leaks. 'finally' and 'orelse' need to be deallocated if an error occurs in the "if (n_except > 0)" branch. ---------------------------------------------------------------------- Comment By: Thomas Lee (krumms) Date: 2005-11-13 15:12 Message: Logged In: YES user_id=315535 Further correction of memory leaks. 'finally' and 'orelse' need to be deallocated if an error occurs in the "if (n_except > 0)" branch. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2005-11-13 15:10 Message: Logged In: YES user_id=33168 I'm pretty sure this patch causes this problem: python: Objects/frameobject.c:187: frame_setlineno: Assertion `blockstack_top > 0' failed. I'm not sure if it's just my hacked up version or the original. Thomas, can you test your version? ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2005-11-13 13:27 Message: Logged In: YES user_id=33168 Updated patch to correct memory leaks. Put everything in one file. Works for me. There needs to be doc changes done too. ---------------------------------------------------------------------- Comment By: Thomas Lee (krumms) Date: 2005-11-13 07:02 Message: Logged In: YES user_id=315535 Attaching a unit test checking the various different types of exception handling syntax. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1355913&group_id=5470 From noreply at sourceforge.net Thu Nov 17 07:03:54 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 16 Nov 2005 22:03:54 -0800 Subject: [Patches] [ python-Patches-1355913 ] PEP 341 - Unification of try/except and try/finally Message-ID: Patches item #1355913, was opened at 2005-11-14 00:59 Message generated for change (Comment added) made by krumms You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1355913&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. >Category: Parser/Compiler Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: Thomas Lee (krumms) Assigned to: Reinhold Birkenfeld (birkenfeld) Summary: PEP 341 - Unification of try/except and try/finally Initial Comment: Attached is a patch implementing PEP 341 against HEAD in subversion. It includes the following changes: 1. Grammar/Grammar updated as per the PEP 2. Python/ast.c wraps try/except blocks inside try/finally blocks if it detects the extended syntax. This patch is based heavily upon suggestions by Nick Coghlan on python-dev. ---------------------------------------------------------------------- >Comment By: Thomas Lee (krumms) Date: 2005-11-17 16:03 Message: Logged In: YES user_id=315535 lol ... even if it doesn't get accepted, it was a great learning experience. The PEP itself hasn't even been approved as yet, I've just wanted this syntax in Python for a while :) Anyway ... might try my hand at a few ideas I have for that arena/pool stuff as discussed on python-dev when I get home tonight. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2005-11-17 15:48 Message: Logged In: YES user_id=33168 Maybe I'm just tired, but I can't find any problems. Assuming this patch gets in, it ought to be the least buggy code in compile.c. :-) ---------------------------------------------------------------------- Comment By: Thomas Lee (krumms) Date: 2005-11-16 23:52 Message: Logged In: YES user_id=315535 You're absolutely right with those bugs Nick. Fixed now. See how you go with v9 :) ---------------------------------------------------------------------- Comment By: Nick Coghlan (ncoghlan) Date: 2005-11-16 23:25 Message: Logged In: YES user_id=1038590 Closest yet, but I don't think we're quite there yet. The 'except_st = NULL' part should be on the line immediately after except_st is inserted into the inner sequence. As soon as that insertion happens, we want to ensure that the statement is only freed once. What's currently there will technically work, but doesn't really have the right semantics. More importantly, the "body = handlers = orelse = NULL" part should only be executed if the call to TryExcept *succeeds*, not if it fails. Neil's right - we seriously need to find a better way to handle this memory management or it will be a source of significant pain (well, more pain than you've already experienced ;) ---------------------------------------------------------------------- Comment By: Thomas Lee (krumms) Date: 2005-11-16 19:23 Message: Logged In: YES user_id=315535 Okay, here we go: v8! *sighs* this is devestating for my ego :) ---------------------------------------------------------------------- Comment By: Thomas Lee (krumms) Date: 2005-11-16 18:35 Message: Logged In: YES user_id=315535 Arrgh! :) Well ... I'll fix up this patch & submit it again. I might fall back to the 'goto' style of doing things just so we don't have the mix of "do ... break ... while" and goto (which I imagine could be almost as confusing as the mix of check-cleanup and goto-cleanup as described by Nick earlier). Again, if you could check the v8 patch for me it would be much appreciated. After that, I might hit python-dev and read up on what everybody's been saying about pools/arenas & maybe get started on something we can use for the AST ... anyway, I'll discuss that on python-dev. This isn't really the place for it :) ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2005-11-16 15:38 Message: Logged In: YES user_id=33168 ISTM there are a couple of problems. Some of these were likely in there before and I may have told you to do some. :-( I probably made the same error too. :-( :-( One is a new one though. That starts in the for loop. You break in there, but that only breaks out of the for loop, doesn't it? So you really need a goto to break out I think. After setting except_st, it holds references to body, handlers, and orelse, so if you free except_st, it should free all the others. Therefore if except_st was created (after the if (except_st) break;), you should set body = handlers = orelse = NULL; Do you agree? I think if you don't you will get a double free. The same would go for after you asdl_seq_SET(inner, 0, except_st); you should set except_st = NULL; OTOH, you fixed a memory leak. Whenever one does return TryExcept(); (or any other similar AST call), if TryExcept fails, we will return NULL and all the local variables will be leaked. *sigh* Sorry you have to deal with this crap. You've been a very good guinea pig being the first. I really hope we do the arenas as discussed on python-dev. If you aren't too burnt out, it would be a really good way to learn the rest of the AST. :-) ---------------------------------------------------------------------- Comment By: Thomas Lee (krumms) Date: 2005-11-15 23:15 Message: Logged In: YES user_id=315535 Here's the v7 patch against revision 41451, with Neal's last fix :) Using Marek's suggestion for try/except emulation in C from python-dev to avoid the "goto" crap. Any more problems here? *looks hopeful* :) - Tom ---------------------------------------------------------------------- Comment By: Thomas Lee (krumms) Date: 2005-11-15 14:50 Message: Logged In: YES user_id=315535 lol thanks Neal/Nick, that's fine. :) Nick Coghlan and yourself have been extremely helpful throughout this whole process, and it's been a great learning experience. I'll implement your suggested fix for 'handlers' right away. If you like, let me know when you've committed the 700+ line patch and I'll generate the PEP 341 patch from that. - Tom ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2005-11-15 14:43 Message: Logged In: YES user_id=33168 Oh, so close, I'm sorry, I see one more problem. :-) Thomas, I hope you will write up this experience in coding this patch. IMO it clearly demonstrates a problem with the new AST code that needs to be addressed. ie, Memory management is not possible to get right. I've got a 700+ line patch to ast.c to correct many more memory issues (hopefully that won't cause conflicts with this patch). I would like to hear ideas of how the AST code can be improved to make it much easier to not leak memory and be safe at the same time. The problem is that handlers is not an asdl_seq of stmt's, but rather an asdl_seq of exceptionhandlers. There is no utility function to clean out this seq, so you need to do it manually. for (i = 0; i < asdl_seq_LEN(handlers); i++) free_exceptionhandler(asdl_seq_GET(handlers, i)); asdl_seq_free(handlers); I don't see any other problems, but perhaps I will when it gets checked in or I run valgrind on it. The Other Nick :-) ---------------------------------------------------------------------- Comment By: Thomas Lee (krumms) Date: 2005-11-15 14:10 Message: Logged In: YES user_id=315535 Okay, v6 is up. Now using test-goto-cleanup. Also using asdl_stmt_seq_free. Any more suggestions/feedback? Anybody having trouble using this patch? ---------------------------------------------------------------------- Comment By: Thomas Lee (krumms) Date: 2005-11-14 22:14 Message: Logged In: YES user_id=315535 Thanks for your input Nick - I'll sort out a patch taking your suggestions into consideration tomorrow & resubmit it. ---------------------------------------------------------------------- Comment By: Nick Coghlan (ncoghlan) Date: 2005-11-14 18:54 Message: Logged In: YES user_id=1038590 >From a code inspection of v5 of the patch (I haven't actually run the patch anywhere), I'm a little uncomfortable with the mixture of the two error handling styles (that is, test-cleanup-return for most of the function, but test-goto-cleanup for the one specific case). I don't mind either style (and both are used in the Python source), but mixing them in one function bothers me :) Further, there appears to be a bug in the deallocation code, in that all sequences should be freed with adsl_seq_stmt_free. The current direct use of adsl_seq_free means any contained statements are not released. I suggest putting a single 'error' label at the end of the function that uses adsl_seq_stmt_free to clean up all the statement sequences , as well as free_stmt to clean up the nested except statements. As both of these functions handle nulls gracefully, the bodies of the current error cleanup and return branches can all then be replaced with "goto error". ---------------------------------------------------------------------- Comment By: Thomas Lee (krumms) Date: 2005-11-14 15:18 Message: Logged In: YES user_id=315535 Oops - I mean Neal :) ---------------------------------------------------------------------- Comment By: Thomas Lee (krumms) Date: 2005-11-14 15:17 Message: Logged In: YES user_id=315535 Fix for the problem you encountered in the v5 patch, Nick. All tests in the suite now pass for me, no assertion failures when using --with-pydebug. I was stupidly generating a TryFinally in every scenario. This breaks down in the 'trace' unit test when no 'finally' clause is present with the extended syntax. Oops. Also added a little more error checking code and updated the unit test to test nested exception handling. I'm using a few goto statements in the "if (n_except > 0)" branch to reduce duplication deallocating memory. If there's any great objections to this feel free to yell & I'll resubmit a patch without the use of goto. Can you please verify this works for you, Nick? ---------------------------------------------------------------------- Comment By: Thomas Lee (krumms) Date: 2005-11-14 10:02 Message: Logged In: YES user_id=315535 Fixed a bad assumption when parsing a try-finally. Should be fixed now. I'm not sure if this fixes the problem you're experiencing, Neal. I'll have a look into it. ---------------------------------------------------------------------- Comment By: Thomas Lee (krumms) Date: 2005-11-14 09:12 Message: Logged In: YES user_id=315535 Further correction of memory leaks. 'finally' and 'orelse' need to be deallocated if an error occurs in the "if (n_except > 0)" branch. ---------------------------------------------------------------------- Comment By: Thomas Lee (krumms) Date: 2005-11-14 09:12 Message: Logged In: YES user_id=315535 Further correction of memory leaks. 'finally' and 'orelse' need to be deallocated if an error occurs in the "if (n_except > 0)" branch. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2005-11-14 09:10 Message: Logged In: YES user_id=33168 I'm pretty sure this patch causes this problem: python: Objects/frameobject.c:187: frame_setlineno: Assertion `blockstack_top > 0' failed. I'm not sure if it's just my hacked up version or the original. Thomas, can you test your version? ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2005-11-14 07:27 Message: Logged In: YES user_id=33168 Updated patch to correct memory leaks. Put everything in one file. Works for me. There needs to be doc changes done too. ---------------------------------------------------------------------- Comment By: Thomas Lee (krumms) Date: 2005-11-14 01:02 Message: Logged In: YES user_id=315535 Attaching a unit test checking the various different types of exception handling syntax. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1355913&group_id=5470 From noreply at sourceforge.net Thu Nov 17 20:14:34 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 17 Nov 2005 11:14:34 -0800 Subject: [Patches] [ python-Patches-1359217 ] ftplib dir() problem with certain servers Message-ID: Patches item #1359217, was opened at 2005-11-17 14:14 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1359217&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Library (Lib) Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Stuart D. Gathman (customdesigned) Assigned to: Nobody/Anonymous (nobody) Summary: ftplib dir() problem with certain servers Initial Comment: Gets error_reply exception: 200 Command Ok Some ftp servers return a 2xx response before returning a 1xx response to begin transfer. I don't know whether such servers are in error. The C ftp client (netkit-ftp-0.17) handles this case. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1359217&group_id=5470 From noreply at sourceforge.net Fri Nov 18 01:03:08 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 17 Nov 2005 16:03:08 -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 (Tracker Item Submitted) made by Item Submitter 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: Guido van Rossum (gvanrossum) 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. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1359365&group_id=5470 From noreply at sourceforge.net Fri Nov 18 09:00:19 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 18 Nov 2005 00:00:19 -0800 Subject: [Patches] [ python-Patches-1359618 ] Speed charmap encoder Message-ID: Patches item #1359618, was opened at 2005-11-18 09:00 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1359618&group_id=5470 Please note that this 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: Martin v. L?wis (loewis) Assigned to: M.-A. Lemburg (lemburg) Summary: Speed charmap encoder Initial Comment: This patch speeds up the charmap encoder by a factor of 4 to 5, using a trie structure instead of a dictionary; the speedup primarily comes from not creating integer objects in the process. The trie is created by inverting the encoding map; the codec generator is changed to drop the encoding dictionary, and instead emit a function call to create the trie. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1359618&group_id=5470 From noreply at sourceforge.net Fri Nov 18 12:39:56 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 18 Nov 2005 03:39:56 -0800 Subject: [Patches] [ python-Patches-1359879 ] Patch for (Doc) #1357604 Message-ID: Patches item #1359879, was opened at 2005-11-18 12:39 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1359879&group_id=5470 Please note that this 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: Peter van Kampen (pterk) Assigned to: Nobody/Anonymous (nobody) Summary: Patch for (Doc) #1357604 Initial Comment: Patch for doc-bug #1357604 that removes the remark about not working with UNC-paths. Confirmed to work with python 2.3.5 and 2.4.1. It does NOT work in python 2.2.3. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1359879&group_id=5470 From noreply at sourceforge.net Fri Nov 18 17:22:12 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 18 Nov 2005 08:22:12 -0800 Subject: [Patches] [ python-Patches-1360243 ] Add XML-RPC Fault Interoperability to XMLRPC libraries Message-ID: Patches item #1360243, was opened at 2005-11-18 09:22 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1360243&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Library (Lib) Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Joshua Ginsberg (jaginsberg) Assigned to: Nobody/Anonymous (nobody) Summary: Add XML-RPC Fault Interoperability to XMLRPC libraries Initial Comment: Patched against 2.4.2 SimpleXMLRPCServer.py * Added SimpleXMLRPCDispatcher.register_capability() to manage results for system.getCapabilities() RPC call. * Added SimpleXMLRPCDispatcher.register_fault_interop_spec() to make fault codes compliant with the specification * Abstracted fault code constants. xmlrpclib.py * Added more detailed exception raising for failures in XML-RPC request parsing. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1360243&group_id=5470 From noreply at sourceforge.net Fri Nov 18 20:03:19 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 18 Nov 2005 11:03:19 -0800 Subject: [Patches] [ python-Patches-1360443 ] correct display of pathnames in SimpleHTTPServer Message-ID: Patches item #1360443, was opened at 2005-11-18 21: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=1360443&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Library (Lib) Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Ori Avtalion (salty-horse) Assigned to: Nobody/Anonymous (nobody) Summary: correct display of pathnames in SimpleHTTPServer Initial Comment: The patch makes the simple file server display path names that includes reserved and unsafe characters. Previously, a path named dir&a was displayed as dir%26a since "self.path" was processed by urllib.quote. The "path" parameter, however, is untouched. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1360443&group_id=5470 From noreply at sourceforge.net Fri Nov 18 20:55:50 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 18 Nov 2005 11:55:50 -0800 Subject: [Patches] [ python-Patches-936169 ] CodeContext - an extension to show you where you are Message-ID: Patches item #936169, was opened at 2004-04-16 04:40 Message generated for change (Settings changed) made by kbk You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=936169&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: IDLE Group: None >Status: Closed Resolution: Accepted Priority: 5 Submitted By: Noam Raphael (noamr) Assigned to: Kurt B. Kaiser (kbk) Summary: CodeContext - an extension to show you where you are Initial Comment: Have you ever edited a code, and did not know exactly which block you were closing? Or didn't know exactly even in which block you were? This extension solves this problem, by adding a few lines (3 by default) above the IDLE edit box, which show you exactly where you are in your code. For example, you may be editing a code with three indentation levels (has three tabs on its left), but to find the reason for this - to find what is the meaning of your block - you have to scroll upwards a long distance. CodeContext will add three lines of text above your edit box, so your editing window will look like this: ---------------------------------- Class MyClass: def myMethod(self, arg1, arg2): <- auto-updated if something_happens: ---------------------------------- i += 1 print "hello" <- You edit here ... ---------------------------------- So you can know that i is incremented by 1, in the method myMethod of class MyClass, and only if something_happens. To make this extension work, you have to put the attached file, CodeContext.py, in your IDLE directory, and add these lines to config-extensions.def: ---------------------------------- [CodeContext] enable=1 numlines=3 bgcolor=LightGray fgcolor=Black ---------------------------------- A note to KBK: I think this extension can go into the Python distribution. If you don't like it, or if you want a testing period, you can put "enable=0" instead of "enable=1". In this way, most users will not even know CodeContext exists, but "power users" will be able to put "enable=1" and have CodeContext if they like it (- I like it). Best wishes, Noam Raphael ---------------------------------------------------------------------- >Comment By: Kurt B. Kaiser (kbk) Date: 2005-11-18 14:55 Message: Logged In: YES user_id=149084 OK, thanks. ---------------------------------------------------------------------- Comment By: Noam Raphael (noamr) Date: 2005-10-09 18:57 Message: Logged In: YES user_id=679426 It's an optimization: If we scroll up, we know that there can't be a new context line with a smaller indentation than that of the deleted context lines, so it lets us stop searching sooner. For example, take this class: class Babonag(object): # This is a big class, and a lot of methods are defined here... def ping(): print "ping" def pong(): pring "pong" Now say we scroll up: the first line was 'print "pong"', and it is now 'print "ping"'. If we use stopindent, we know that we can stop immediately after we have reached "def ping", because we know that there can't be a line with a smaller indentation than that. If we don't, we have to scan up to "class Babonag" to be certain that there aren't any extra context lines. (By the way, well done for the tweaked comments docstrings and names. They seem a lot cleaner.) Noam ---------------------------------------------------------------------- Comment By: Kurt B. Kaiser (kbk) Date: 2005-10-03 16:13 Message: Logged In: YES user_id=149084 Checked in 03Feb05 patch as rev 1.5 Tweaked comments, docstrings, and names; checked in as rev 1.6 Incorporated Tal Einat's alignment suggestion; checked in as rev 1.7 It appears to me that the stopindent mechanism to terminate processing a region is now redundant. I can comment out the 'break' in get_context() [new name!] and everything still seems to work ok. Am I missing something? ---------------------------------------------------------------------- Comment By: Tal Einat (taleinat) Date: 2005-08-18 11:28 Message: Logged In: YES user_id=1330769 This fixes the text alignment: (just replace te appropriate code in toggle_code_context_event with this) if not self.label: self.padding_frame = Tkinter.Frame(self.editwin.top, bg=self.bgcolor, border=2, relief="sunken", ) self.label = Tkinter.Label(self.padding_frame, text="\n" * (self.numlines - 1), anchor="w", justify="left", font=self.textfont, bg=self.bgcolor, fg=self.fgcolor, border=0, width=1, # Don't request more than we get ) self.label.pack(side="top", fill="x", expand=1, padx=4, pady=0) self.padding_frame.pack(side="top", fill="x", expand=0, padx=0, pady=0, after=self.editwin.status_bar) else: self.label.destroy() self.padding_frame.destroy() self.label = None Sorry it's not a diff... ---------------------------------------------------------------------- Comment By: Noam Raphael (noamr) Date: 2005-02-03 19:17 Message: Logged In: YES user_id=679426 Thanks for your comments. What do you think of the new patch? ---------------------------------------------------------------------- Comment By: Kurt B. Kaiser (kbk) Date: 2005-02-02 17:17 Message: Logged In: YES user_id=149084 1. Please improve the doc string for interesting_lines(), it's no longer a generator. 2. You removed a comment from update_label() which was helpful when studying the code. What does it do now? 3. The variable 'l' should not be used because it's hard to discriminate from '1'. See PEP 8, Naming Conventions. I suggest 'ln' if it must be short, otherwise 'line' ---------------------------------------------------------------------- Comment By: Noam Raphael (noamr) Date: 2004-09-07 18:42 Message: Logged In: YES user_id=679426 I improved the algorithm for finding the context lines, so it now scans the minimum number of lines it needs in order to update the panel - it uses the information it already has in a better way. This makes the scrolling of long modules more "streaming", on my not-that-new computer. I tried it, and it seems to work just as good as the old algorithm - it produces the same results. ---------------------------------------------------------------------- Comment By: Kurt B. Kaiser (kbk) Date: 2004-06-05 21:33 Message: Logged In: YES user_id=149084 Checked in Noam Raphael's improvements. CodeContext.py 1.4 et. al. ---------------------------------------------------------------------- Comment By: Noam Raphael (noamr) Date: 2004-04-27 17:24 Message: Logged In: YES user_id=679426 Hello, I think that showing / not showing the Code Context panel should be a persistent setting - if the user wants it, it will appear, and if he doesn't, it won't. The concept of "it has an initial state, and you can change it afterwards if you like" is confusing. Using a persistent setting makes a keyboard shortcut unnecessary - I think that usually the user will be happy with what he likes, and won't hide/show the panel many times. So I made the <> event save the new setting in the user's configuration file. The new setting will be applied also to new windows opened in the same session. This required me to add a SetOption method to configHandler.IdleConf. Also, the initialization of the CodeContext instance required the menu item to be already installed, but EditorWindow.load_extension installs the menu items after it initializes the extension's instance. It turns out that the menu items can be installed before the instance initialization, so I changed it. Another problem was that the Code Context menu item was installed on shell windows, but wasn't functioning, which was quite confusing. So I added new optional configurations for extensions: enable_shell and enable_editor, which allow you to write extensions only for the editor/shell window, without using the "isinstance(editwin, PyShell)" trick. About using a Text widget instead of a Label - it may work, I don't know, but making the Label behave as I wanted was hard enough, and it looks fine to me as it is, so I leave it for now. Bye Bye, Noam ---------------------------------------------------------------------- Comment By: Kurt B. Kaiser (kbk) Date: 2004-04-26 18:28 Message: Logged In: YES user_id=149084 Yeah, I noticed that problem and wasn't sure if I had caused it. Thanks, fixed. CodeContext.py 1.3. Sorry I took so long getting back, for some reason I'm not getting mail from SF when a Tracker item changes (though I don't have a problem sending mail to myself via users.sourceforge.net). I added an entry for Code Context on the Options menu, it toggles the context pane. Any suggestion for a keybinding? A remaining problem is the text in the Label doesn't quite line up with the text in the main pane. Adding a pad of one space makes it almost perfect. But maybe using a Text widget instead of a Label would fix it 100%? ---------------------------------------------------------------------- Comment By: Noam Raphael (noamr) Date: 2004-04-22 16:11 Message: Logged In: YES user_id=679426 I'm glad you like it! Thanks for the changes - your English is certainly better than mine. A buglet you made - in line 91 you added "elif" as a block opener which should show the previous block opener of the same indentation, which is a good idea, but you wrote: if opener == "else" or "elif": which is an expression which always yields True. It caused all block openers to be displayed, not only the relevant ones. Change it to if opener in ("else", "elif"): and it will work fine. Happy Israel Independence Day! (I know you probably don't celebrate it, but it is on 27 April this year) Noam ---------------------------------------------------------------------- Comment By: Kurt B. Kaiser (kbk) Date: 2004-04-21 16:09 Message: Logged In: YES user_id=149084 Cool Extension! Thanks! CodeContext.py 1.1 config-extensions.def 1.13 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=936169&group_id=5470 From noreply at sourceforge.net Fri Nov 18 23:09:40 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 18 Nov 2005 14:09:40 -0800 Subject: [Patches] [ python-Patches-906702 ] Syntax-related improvements to IDLE Message-ID: Patches item #906702, was opened at 2004-02-28 20:40 Message generated for change (Comment added) made by kbk You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=906702&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: IDLE Group: None Status: Open >Resolution: Accepted Priority: 5 Submitted By: Noam Raphael (noamr) Assigned to: Kurt B. Kaiser (kbk) Summary: Syntax-related improvements to IDLE Initial Comment: Yes! It's finally here! The big bunch of syntax-related improvements to IDLE! Here are a few highlights: * Completion in Visual C++ style! * CallTip windows now disappear when you don't want them! * ParenMatch now works! And in a more general way: * The MultiCall class enables one event to trigger multiple actions, so that you extensions can do whatever they want without fighting who'll know when a key is being released (for example). * The HyperParser class gives extensions a better understanding of Python code, so that CallTips and ParenMatch can now be shown from anywhere in the code (not only after opening/closing parens), and CallTips and AutoCompletion is available for complex expressions, not just for expressions which look like identifier1.identifer2. IDLE with these changes was tested by about 15 people for a few months, and beside some minor inconviniences (for example, concerning when AutoComplete chooses to complete), no critical bugs were found. Here's a complete description of all the changes to files: * Used MultiCall In order to allow multiple actions to happen when one event happens (for example, when closing a bracket, show the opening bracket and close the calltip), I wrote a class called MultiCall, which, in this case, inherits from the Text widget, and overrides binding functions, so that all matching functions will be called when an event takes place. New file: MultiCall.py EditorWindow.py: diff 1, line 8: importing MultiCall diff 2, line 89: Use MultiCallCreator(Text) instead of Text diff 3, line 226: bind set_line_and_column using virtual events, so that it will be handled by MultiCall diff 4, line 333: Control+C, in Windows keys, means both copy and break. The three lines added solve the conflict. diff 5,6,7, line 524: When changing key configuration, first the current keys must be unbinded, then the new ones binded. configDialog.py: diffs 1,2,3: When changing key configuration, first the current keys must be unbinded, then the new ones binded. * Improved parsing abilities - HyperParser The new HyperParser class uses PyParse to find information about the bracketing structure of a Python code, and to find the expression which should be evaluated in CallTips and AutoComplete. New file: HyperParser.py EditorWindow.py: diff 8, 9, line 1072: Previously, the prompt was detected textually, by searching for ">>>". This is not generic, and I changed it to look for a text tagged by the "console" tag. PyParse.py: diff 1, line 16: 'if' and 'for' can't be considered block openers now, since list comprehension was introduced. diff 2-5, line 147: using the "prompt" tag instead of searching for ">>>". diff 6-15, line 357: Now, _study2 also saves information about the bracketing structure of the code. PyShell.py: diff 1, line 1049: use the "prompt" tag instead of searching for ">>>" * Added the AutoComplete extension: This extension opens a completion window after typing a dot or when requesting a completion using tab or control+space. It will evaluate code with function calls only when requested by control+space. New file: AutoComplete.py New file: AutoCompleteWindow.py config-extensions.def: diff 5: three new bindings - force-open-completions opens a completion win and is ready to evaluate functions. autocomplete tries to complete the current word, and if fails, opens a completion window (happens on tab). try-open-completions will open a completion window when no functions calls need to be done. run.py: diffs 1,2,3: Added functions in run.py for fetching the available completions, in a method copied from the method CallTips used when fetching the call tip. * Improved the CallTips extension: This extension is greatly improved, by using HyperParser: CallTips now work for multi-lined function calls, they can be opened from anywhere inside a function brackets, and can evaluate expressions which result in functions. CallTips.py: diff 1, line 6: The future plans are already here. diff 2, line 11: no need to import string diff 3, line 14: import HyperParser diff 4, line 20: Now there's a menu command to open a calltip. diff 5, line 39: cosmetical diff 6-11, line 44: Now there's no paren_open_event and paren_close_event, since you can open CallTips without typing parens. There's force_open_calltip_event, which opens a calltip and is ready to make function calls, and try_open_calltip_event, which will not agree to do such a thing. We also use HyperParser, instead of finding the function by ourselves. diff 12, line 153: It makes more sense to show the repr of default arguments in calltips, not the str of them. CallTipWindow.py: Now, the CallTipWindow is smart - it binds events to hide itself and to position itself. Hiding occurs when the cursor gets out of the parens. config-extensions.def: diffs 1,2, line 42: We have three new bindings: force-open-calltip opens a calltip and make function calls, if needed. try-open-calltip opens a calltip if it doesn't need to make function calls. refresh-calltip will close a calltip if not needed, and change it to another one if needed. It is binded both to parenright and 0, because if the shift was raised before the zero/parenright key, the event generated is KeyRelease-0. * Improved the ParenMatch extension: First, it now works, thanks to MultiCall. Also, it now can be invoked without closing a paren, and the surrounding parens will be highlighted. ParenMatch.py: All the code for event handling and finding the paren area was rewritten, using HyperParser, and relying on MultiCall. config-extensions.def: diff 3, line 50: enable it again diff 4,5: changed the binding so we now have flash-paren, which shows the surrounding parens, and paren-closed, which is instead of flash-open-paren. Patch and enjoy! Noam Raphael ---------------------------------------------------------------------- >Comment By: Kurt B. Kaiser (kbk) Date: 2005-11-18 17:09 Message: Logged In: YES user_id=149084 Merged to svn trunk. Further changes to this line of development should be submitted as diffs against the trunk. ---------------------------------------------------------------------- Comment By: Kurt B. Kaiser (kbk) Date: 2005-10-10 00:02 Message: Logged In: YES user_id=149084 Checked in idlesyntax.10Jul05.diff on a branch: IDLE-syntax-branch. To switch to this branch: cvs up -r IDLE-syntax-branch To switch back to the IDLE trunk: cvs up -A Further changes to this line of development should be submitted as diffs against the branch. ---------------------------------------------------------------------- Comment By: Kurt B. Kaiser (kbk) Date: 2005-10-09 14:30 Message: Logged In: YES user_id=149084 Add Noam Raphael's patch dated 10Jul05 ---------------------------------------------------------------------- Comment By: Noam Raphael (noamr) Date: 2004-04-26 17:49 Message: Logged In: YES user_id=679426 I made a small usability bug, because I didn't parenthesize a boolean expression correctly. Line 298 should be changed to: and (self.mode==AutoComplete.COMPLETE_ATTRIBUTES or self.start): Happy Israel Independence Day! Noam Raphael ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=906702&group_id=5470 From noreply at sourceforge.net Sat Nov 19 06:40:01 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 18 Nov 2005 21:40:01 -0800 Subject: [Patches] [ python-Patches-1361016 ] Auto Complete module for IDLE Message-ID: Patches item #1361016, was opened at 2005-11-19 13: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=1361016&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: IDLE Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Jerry (jerrykingking) Assigned to: Nobody/Anonymous (nobody) Summary: Auto Complete module for IDLE Initial Comment: I think IDLE need this. This is a unattached module. Locate this module on idlelib directory, import it in EditorWindow.py, made it associate with "text" property. OK, it will work. For me it works well. Have a good day, Jerry King ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1361016&group_id=5470 From noreply at sourceforge.net Sat Nov 19 06:45:48 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 18 Nov 2005 21:45:48 -0800 Subject: [Patches] [ python-Patches-1359217 ] ftplib transfer problem with certain servers Message-ID: Patches item #1359217, was opened at 2005-11-17 14:14 Message generated for change (Comment added) made by customdesigned You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1359217&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Library (Lib) Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Stuart D. Gathman (customdesigned) Assigned to: Nobody/Anonymous (nobody) >Summary: ftplib transfer problem with certain servers Initial Comment: Gets error_reply exception: 200 Command Ok Some ftp servers return a 2xx response before returning a 1xx response to begin transfer. I don't know whether such servers are in error. The C ftp client (netkit-ftp-0.17) handles this case. ---------------------------------------------------------------------- >Comment By: Stuart D. Gathman (customdesigned) Date: 2005-11-19 00:45 Message: Logged In: YES user_id=142072 Examples of patch in action, list command: *cmd* 'PASV' *put* 'PASV\r\n' *get* '227 Entering Passive Mode (204,90,130,189,158,118)\r\n' *resp* '227 Entering Passive Mode (204,90,130,189,158,118)' *cmd* 'LIST' *put* 'LIST\r\n' *get* '200 Command Okay.\r\n' *resp* '200 Command Okay.' *get* '150 Opening data connection for transfer.\r\n' *resp* '150 Opening data connection for transfer.' *get* '226-Closing data connection - action successful.\r\n' *get* '\tList command OK, SNRF: 051118183485S0\r\n' *get* '226 \r\n' *resp* '226-Closing data connection - action successful.\n\tList command OK, SNRF: 051118183485S0\n226 ' Store command: *cmd* 'PASV' *put* 'PASV\r\n' *get* '227 Entering Passive Mode (204,90,130,189,138,35)\r\n' *resp* '227 Entering Passive Mode (204,90,130,189,138,35)' *cmd* 'STOR /bms/edi/send/051118.dat' *put* 'STOR /bms/edi/send/051118.dat\r\n' *get* '200 Command Okay.\r\n' *resp* '200 Command Okay.' *get* '150 Opening data connection for transfer.\r\n' *resp* '150 Opening data connection for transfer.' *get* '226-Closing data connection - action successful.\r\n' ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1359217&group_id=5470 From noreply at sourceforge.net Sat Nov 19 06:46:14 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 18 Nov 2005 21:46:14 -0800 Subject: [Patches] [ python-Patches-1361016 ] Auto Complete module for IDLE Message-ID: Patches item #1361016, was opened at 2005-11-19 13:40 Message generated for change (Settings changed) made by jerrykingking You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1361016&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: IDLE >Group: None Status: Open Resolution: None Priority: 5 Submitted By: Jerry (jerrykingking) Assigned to: Nobody/Anonymous (nobody) Summary: Auto Complete module for IDLE Initial Comment: I think IDLE need this. This is a unattached module. Locate this module on idlelib directory, import it in EditorWindow.py, made it associate with "text" property. OK, it will work. For me it works well. Have a good day, Jerry King ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1361016&group_id=5470 From noreply at sourceforge.net Sat Nov 19 07:57:45 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 18 Nov 2005 22:57:45 -0800 Subject: [Patches] [ python-Patches-1361016 ] Auto Complete module for IDLE Message-ID: Patches item #1361016, was opened at 2005-11-19 00:40 Message generated for change (Comment added) made by kbk You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1361016&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: IDLE Group: None Status: Open Resolution: None Priority: 5 Submitted By: Jerry (jerrykingking) Assigned to: Nobody/Anonymous (nobody) Summary: Auto Complete module for IDLE Initial Comment: I think IDLE need this. This is a unattached module. Locate this module on idlelib directory, import it in EditorWindow.py, made it associate with "text" property. OK, it will work. For me it works well. Have a good day, Jerry King ---------------------------------------------------------------------- >Comment By: Kurt B. Kaiser (kbk) Date: 2005-11-19 01:57 Message: Logged In: YES user_id=149084 The module is undocumented, which isn't acceptable. What functionality does this add to IDLE? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1361016&group_id=5470 From noreply at sourceforge.net Sat Nov 19 07:58:20 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 18 Nov 2005 22:58:20 -0800 Subject: [Patches] [ python-Patches-1361016 ] Auto Complete module for IDLE Message-ID: Patches item #1361016, was opened at 2005-11-19 00:40 Message generated for change (Comment added) made by kbk You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1361016&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: IDLE Group: None Status: Open Resolution: None Priority: 5 Submitted By: Jerry (jerrykingking) Assigned to: Nobody/Anonymous (nobody) Summary: Auto Complete module for IDLE Initial Comment: I think IDLE need this. This is a unattached module. Locate this module on idlelib directory, import it in EditorWindow.py, made it associate with "text" property. OK, it will work. For me it works well. Have a good day, Jerry King ---------------------------------------------------------------------- >Comment By: Kurt B. Kaiser (kbk) Date: 2005-11-19 01:58 Message: Logged In: YES user_id=149084 The module is undocumented, which isn't acceptable. What functionality does this add to IDLE? ---------------------------------------------------------------------- Comment By: Kurt B. Kaiser (kbk) Date: 2005-11-19 01:57 Message: Logged In: YES user_id=149084 The module is undocumented, which isn't acceptable. What functionality does this add to IDLE? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1361016&group_id=5470 From noreply at sourceforge.net Mon Nov 21 03:17:24 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 20 Nov 2005 18:17:24 -0800 Subject: [Patches] [ python-Patches-1360200 ] bdist_rpm still can't handle dashes in versions Message-ID: Patches item #1360200, was opened at 2005-11-18 07:41 Message generated for change (Comment added) made by nnorwitz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1360200&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. >Category: None >Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: jared jennings (sarynx) >Assigned to: Sean Reifschneider (jafo) Summary: bdist_rpm still can't handle dashes in versions Initial Comment: I tried to use Python 2.4.2 to create a bdist_rpm of setuptools, whose version string was 0.6a9dev-r41475. The distutils/command/bdist_rpm module's _make_spec_file method mangled the version to 0.6a9dev_r41475 (line 370). Then when the spec file was being built by rpmbuild, it looked for the sdist named setuptools-0.6a9dev_r41475.tar.gz, which didn't exist: it was called setuptools-0.6a9dev-r41475.tar.gz (note dash). So you have to mangle the version to make rpm happy - but you can't expect the sdist to have the mangled version as part of its name. I looked at the nightly Python source as of 17 Nov 2005 and saw that this bug still exists in the development version of Python. A patch is attached which fixed this bug for me. ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2005-11-20 18:17 Message: Logged In: YES user_id=33168 Sean, you seem to know a lot more about rpms than most of us. Any comment on this approach? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1360200&group_id=5470 From noreply at sourceforge.net Mon Nov 21 12:28:39 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 21 Nov 2005 03:28:39 -0800 Subject: [Patches] [ python-Patches-1361016 ] Auto Complete module for IDLE Message-ID: Patches item #1361016, was opened at 2005-11-19 13:40 Message generated for change (Comment added) made by jerrykingking You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1361016&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: IDLE Group: None Status: Open Resolution: None Priority: 5 Submitted By: Jerry (jerrykingking) Assigned to: Nobody/Anonymous (nobody) Summary: Auto Complete module for IDLE Initial Comment: I think IDLE need this. This is a unattached module. Locate this module on idlelib directory, import it in EditorWindow.py, made it associate with "text" property. OK, it will work. For me it works well. Have a good day, Jerry King ---------------------------------------------------------------------- >Comment By: Jerry (jerrykingking) Date: 2005-11-21 19:28 Message: Logged In: YES user_id=1382613 AutoComplete.py is a IDLE module that extends Listbox and Scrollbar controls with autocompletion capabilities. Although the IDLE provides rich foundation for Python application developers, it doesn't provide any built-in autocompletion support! AutoComplete module fills the gap by bringing autocompletion capabilities to IDLE. Users of IDLE can enjoy the same autocomplete functionality they already know from Pythonwin. ---------------------------------------------------------------------- Comment By: Kurt B. Kaiser (kbk) Date: 2005-11-19 14:58 Message: Logged In: YES user_id=149084 The module is undocumented, which isn't acceptable. What functionality does this add to IDLE? ---------------------------------------------------------------------- Comment By: Kurt B. Kaiser (kbk) Date: 2005-11-19 14:57 Message: Logged In: YES user_id=149084 The module is undocumented, which isn't acceptable. What functionality does this add to IDLE? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1361016&group_id=5470 From noreply at sourceforge.net Mon Nov 21 19:06:43 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 21 Nov 2005 10:06:43 -0800 Subject: [Patches] [ python-Patches-1362975 ] CodeContext - Improved text indentation Message-ID: Patches item #1362975, was opened at 2005-11-21 20:06 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1362975&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: IDLE Group: None Status: Open Resolution: None Priority: 5 Submitted By: Tal Einat (taleinat) Assigned to: Nobody/Anonymous (nobody) Summary: CodeContext - Improved text indentation Initial Comment: This is a second patch for the text indentation - the first one was sent by mail and patched directly by KBK. I've touched up the indentation code to be cleaner and more generic. There's no longer need for a pad Frame, the padding is done by the Label widget. More IDLE patches coming - stay tuned ;) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1362975&group_id=5470 From noreply at sourceforge.net Tue Nov 22 16:32:03 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 22 Nov 2005 07:32:03 -0800 Subject: [Patches] [ python-Patches-1350573 ] zlib.crc32 doesn't handle 0xffffffff seed Message-ID: Patches item #1350573, was opened at 2005-11-07 13:25 Message generated for change (Settings changed) made by akuchling You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1350573&group_id=5470 Please note that this 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: Danny Yoo (dyoo) >Assigned to: A.M. Kuchling (akuchling) Summary: zlib.crc32 doesn't handle 0xffffffff seed Initial Comment: Reported by John Schmidt: zlibc.crc32 doesn't appear to properly parse its seed argument. For example: ###### >>> zlib.crc32('foobar',0xFFFFFFFF)) OverflowError: long int too large to convert to int ###### This appears to be fixed if we make the included patch to zlibmodule. I haven't tested this on a 64-bit platform, though; can someone look into this? Hope this helps! ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1350573&group_id=5470 From noreply at sourceforge.net Tue Nov 22 16:39:48 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 22 Nov 2005 07:39:48 -0800 Subject: [Patches] [ python-Patches-1350573 ] zlib.crc32 doesn't handle 0xffffffff seed Message-ID: Patches item #1350573, was opened at 2005-11-07 13:25 Message generated for change (Settings changed) made by akuchling You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1350573&group_id=5470 Please note that this 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: Danny Yoo (dyoo) Assigned to: A.M. Kuchling (akuchling) Summary: zlib.crc32 doesn't handle 0xffffffff seed Initial Comment: Reported by John Schmidt: zlibc.crc32 doesn't appear to properly parse its seed argument. For example: ###### >>> zlib.crc32('foobar',0xFFFFFFFF)) OverflowError: long int too large to convert to int ###### This appears to be fixed if we make the included patch to zlibmodule. I haven't tested this on a 64-bit platform, though; can someone look into this? Hope this helps! ---------------------------------------------------------------------- >Comment By: A.M. Kuchling (akuchling) Date: 2005-11-22 10:39 Message: Logged In: YES user_id=11375 I've applied your suggested fix to the HEAD and release24-maint branches. Thanks! ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1350573&group_id=5470 From noreply at sourceforge.net Tue Nov 22 16:51:49 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 22 Nov 2005 07:51:49 -0800 Subject: [Patches] [ python-Patches-1288056 ] pygettext - provide comments to help translators Message-ID: Patches item #1288056, was opened at 2005-09-11 18:05 Message generated for change (Settings changed) made by akuchling You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1288056&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Demos and tools Group: None Status: Open Resolution: None Priority: 5 Submitted By: Toby Dickenson (htrd) >Assigned to: Barry A. Warsaw (bwarsaw) Summary: pygettext - provide comments to help translators Initial Comment: The .po file format supports "automatic comments". These are comments which have been automatically generated or extracted from the original source along with the "msgid" reference strings. Automatic comments are a good way to communicate extra information to the translator. For example message context, or information about string substitutions. The Gnu gettext tools have good support for "automatic comments". For example msgmerge (which merges updates from a programmer into the master po file maintained by a translator) will preserve the programmer's copy of the "automatic comments" but the translator's copy of the other comments. This patch includes an option to pygettext which automatically copies comments from Python source code into its output .po file. The comment must appear on the same line as the extracted string, and the first character of the comment (immediately after the #) must be a period. Example usage: msg = _('Opening file....') #. status bar message msg = _("Connected on %1") #. eg. connected on com1 Rationale: Why not use any python source code comment on the same line, rather than require the #. prefix? My first variant of this patch worked that way. I found this inadvertently included too many programmer-oriented comments that were inappropriate for the translator. Why the #. notation? This is the same format as used in .po files. Thats not a big advantage, because nobody spends much time reading raw po files. It is concise, which is an advantage since the comment needs to be on the same line as the extracted string. Why should the python source code notation use python comments, rather than an extra parameter to the _ function? Partly tradition.... Gnu gettext for C also looks in specially marked comments. It is also nice to not require changes to other translateable string extraction tools (if there are any) or existing translation functions which currently do not expect an extra parameter. Why a new command line option? Hmmmm - no good reason..... maybe this functionality should always be enabled. Why require the comment to be on the same line? Gnu gettext for C searches the same line *and* the preceeding line. I have experience converting a large python project of approx 800 extracted strings where this hasnt been a problem. Im happy to extend this if necessary. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1288056&group_id=5470 From noreply at sourceforge.net Tue Nov 22 19:54:16 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 22 Nov 2005 10:54:16 -0800 Subject: [Patches] [ python-Patches-1144504 ] Add IEEE Float support to wave.py Message-ID: Patches item #1144504, was opened at 2005-02-19 15:02 Message generated for change (Comment added) made by akuchling You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1144504&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Modules Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Ben Schwartz (bensatmit_edu) Assigned to: Nobody/Anonymous (nobody) Summary: Add IEEE Float support to wave.py Initial Comment: IEEE Float .wav files have almost identical structure to standard PCM .wav files. Currently, wave.py gives an unknown format error when attempting to read IEEE Float .wav files. This patch causes wave.py to read those files properly. No changes were made to wave_write, only wave_read. ---------------------------------------------------------------------- >Comment By: A.M. Kuchling (akuchling) Date: 2005-11-22 13:54 Message: Logged In: YES user_id=11375 Looking at the WAV format description at http://ccrma.stanford.edu/CCRMA/Courses/422/projects/WaveFormat , it looks like the patch isn't correct. There's an ExtraParams field after the header that's only present if the format is not PCM. If this is correct, the patch should also add code to read this field and either store it somewhere or just discard it. ---------------------------------------------------------------------- Comment By: Michael Chermside (mcherm) Date: 2005-02-23 08:11 Message: Logged In: YES user_id=99874 I don't know anything about the .wav format, but the patch is particularly inoffensive... it simply allows a second format constant in the WAVE header without raising an error. I recomend applying the patch as soon as someone else who DOES know the .wav format can confirm that it's being done right. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1144504&group_id=5470 From noreply at sourceforge.net Tue Nov 22 20:05:20 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 22 Nov 2005 11:05:20 -0800 Subject: [Patches] [ python-Patches-1094164 ] xml.dom.minidom.Node.replaceChild(obj, x, x) removes child x Message-ID: Patches item #1094164, was opened at 2005-01-01 14:43 Message generated for change (Comment added) made by akuchling You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1094164&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: XML Group: Python 2.4 >Status: Closed >Resolution: Accepted Priority: 5 Submitted By: Felix Rabe (xitnalta) >Assigned to: A.M. Kuchling (akuchling) Summary: xml.dom.minidom.Node.replaceChild(obj, x, x) removes child x Initial Comment: A child was removed from a node if an attempt was made to replace it with itself. The cause was the comparison "if newChild is oldChild:" happening too late in the function's code, so I moved it before the "newChild.parentNode" check. ---------------------------------------------------------------------- >Comment By: A.M. Kuchling (akuchling) Date: 2005-11-22 14:05 Message: Logged In: YES user_id=11375 Good catch; thanks! Patch applied to HEAD and to release24-maint. ---------------------------------------------------------------------- Comment By: Felix Rabe (xitnalta) Date: 2005-01-01 14:45 Message: Logged In: YES user_id=163986 The patch applies to CVS python/dist/src checked out half an hour ago. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1094164&group_id=5470 From noreply at sourceforge.net Tue Nov 22 20:11:38 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 22 Nov 2005 11:11:38 -0800 Subject: [Patches] [ python-Patches-979658 ] Improve HTML documentation of a directory Message-ID: Patches item #979658, was opened at 2004-06-25 07:29 Message generated for change (Settings changed) made by akuchling You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=979658&group_id=5470 Please note that this 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: Noam Raphael (noamr) >Assigned to: Ka-Ping Yee (ping) Summary: Improve HTML documentation of a directory Initial Comment: Attached is a patch which improves pydoc's HTML documentation of a complete directory. It consists of two parts. The first gives adds functionality to the "pydoc -w " command, mostly in the spirit of compileall.py. The second fixes a bug, which causes pydoc to search for modules in sys.path instead of in the actual directory documented. pydoc -w functionality ========================= Here's my actual situation: There's a package maintainance system, where you first create files in your home directory and then use the system to install them in a common place. For example, if a package is called foo, and includes the modules ya.py and chsia.py, the modules will be named /home/noam/foo/lib/python/{ya,chsia}.py. I want to automatically document them, so that the HTML files will sit in /home/noam/foo/doc. After installing the package, the python modules will be copied to /usr/local/lib/python/, and the documentation will be copied to /usr/local/doc/foo. I want to be able to type one command to generate all the documentation, but I don't want to waste time if I only need the documentation re-generated for one module. So I made "pydoc -w " produce documentation only if the target file was modified before the module was. (pydoc -w still writes the documentation even if it seems up to date.) It is perfectly legitimate to write a HTML documentation for a module by your own. So I made pydoc never overwrite HTML files which weren't created by pydoc. To accomplish this, I added the tag to the head of all HTML files produced by pydoc. A warning is printed if a module was modified after its manually created documentation was modified. I wanted to be able to run "pydoc -w" from any directory, not just from /home/noam/foo/doc, so I added an option "-o ", to specify the output directory. (If it isn't specified, the current directory is used.) I wanted the documentation to refer to the installed file (/usr/local/lib/python/foo.py), not to the file in my home directory. So I added an option "-d ", to specify the directory in which the files will reside after being installed. To summarise, the command which I should now run to produce the documentation is pydoc -w -o doc/ -d /usr/local/ lib/python/ (running it from /home/noam/foo). The -d and -o options are already available in compileall.py, for exactly the same reasons, I think. None of this should cause backward compatibility issues. Module loading =========== Currently, safeimport(), used by writedocs(), gets only a module name, and imports it using __import__(). This means that when you document a complete directory, you can only produce HTML documentation for modules which are already installed, and that a documentation for the wrong version of a module may be produced. I changed safeimport() to get an optional list of directories in which to look for the module/package, in which case it uses imp.find_module and imp.load_module instead of __import__. This means that when producing documentation for a complete directory, the actual files in the directory are used, not installed modules of the same name. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=979658&group_id=5470 From noreply at sourceforge.net Tue Nov 22 20:12:32 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 22 Nov 2005 11:12:32 -0800 Subject: [Patches] [ python-Patches-1038909 ] pydoc method documentation lookup enhancement Message-ID: Patches item #1038909, was opened at 2004-10-02 05:39 Message generated for change (Settings changed) made by akuchling You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1038909&group_id=5470 Please note that this 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: Alexander Schmolck (aschmolck) >Assigned to: Ka-Ping Yee (ping) Summary: pydoc method documentation lookup enhancement Initial Comment: If a method has no docstring, then pydoc.getdoc currently just looks for a comment or returns nothing. A more sensible behavior IMO would be if pydoc tried to get the docstring from the same method in a baseclass (in mro), if it exists. This ought to be "the right thing" (i.e. by the semantics of inheritance if the documentation of a overriden method is not overriden it should still present the same interface to the user) and the current behavior is a royal pain when working with backends or other types of subclasses that are derived from some abstract class that contains all the interface docs. Currently even fixing up docstrings by hand is not simple, because the straightforward ``Child.meth.__doc__ = Parent.meth.__doc__`` fails (one has to go directly via the .__dict__ which is problematic). ---------------------------------------------------------------------- Comment By: Alexander Schmolck (aschmolck) Date: 2004-10-12 05:11 Message: Logged In: YES user_id=559641 OK, another try... ---------------------------------------------------------------------- Comment By: Ilya Sandler (isandler) Date: 2004-10-12 00:14 Message: Logged In: YES user_id=971153 Did you forget to attach the patch? (SF does not show any attachments) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1038909&group_id=5470 From noreply at sourceforge.net Tue Nov 22 20:14:02 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 22 Nov 2005 11:14:02 -0800 Subject: [Patches] [ python-Patches-658407 ] email: minimal header encoding Message-ID: Patches item #658407, was opened at 2002-12-25 02:47 Message generated for change (Settings changed) made by akuchling You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=658407&group_id=5470 Please note that this 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.2.x Status: Open Resolution: Out of Date Priority: 5 Submitted By: Hatuka*nezumi (hatukanezumi) >Assigned to: Barry A. Warsaw (bwarsaw) Summary: email: minimal header encoding Initial Comment: Most implementations using 'B' header encoding (e.g. for ISO-2022-JP) encode 'minimal' portions of header value and do not encode US-ASCII portions as much as possible. This patch does this. Current version (2.4.3) of email.Header module encodes whole of header value. Though this feature is MIME-compliant, especially with 'B' encoding, causes some difficulty. For example: Subject prefix of mailing list postings are usually written in ASCII characters -- GL part of its charset. Encoded form of subject prefix is not only human-readable but also some search, header-rewrite etc. capabilities are forced to implement preprocessing for decoding. ---------------------------------------------------------------------- Comment By: Hatuka*nezumi (hatukanezumi) Date: 2002-12-25 02:50 Message: Logged In: YES user_id=529503 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=658407&group_id=5470 From noreply at sourceforge.net Tue Nov 22 20:44:40 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 22 Nov 2005 11:44:40 -0800 Subject: [Patches] [ python-Patches-1328526 ] Patch for (Doc) #1255218 Message-ID: Patches item #1328526, was opened at 2005-10-17 12:04 Message generated for change (Comment added) made by birkenfeld You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1328526&group_id=5470 Please note that this 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: Peter van Kampen (pterk) Assigned to: Nobody/Anonymous (nobody) Summary: Patch for (Doc) #1255218 Initial Comment: Rewording in libmultifile.tex ---------------------------------------------------------------------- >Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-11-22 20:44 Message: Logged In: YES user_id=1188172 Thanks! Committed in rev 41517, 41518(2.4). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1328526&group_id=5470 From noreply at sourceforge.net Tue Nov 22 20:50:42 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 22 Nov 2005 11:50:42 -0800 Subject: [Patches] [ python-Patches-1328566 ] Patch for (Doc) #1261659 Message-ID: Patches item #1328566, was opened at 2005-10-17 13:05 Message generated for change (Settings changed) made by birkenfeld You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1328566&group_id=5470 Please note that this 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: Peter van Kampen (pterk) Assigned to: Nobody/Anonymous (nobody) Summary: Patch for (Doc) #1261659 Initial Comment: Added ** function call example ---------------------------------------------------------------------- >Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-11-22 20:50 Message: Logged In: YES user_id=1188172 Thanks! Committed in rev 41519, 41520(2.4). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1328566&group_id=5470 From noreply at sourceforge.net Tue Nov 22 21:14:56 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 22 Nov 2005 12:14:56 -0800 Subject: [Patches] [ python-Patches-1359879 ] Patch for (Doc) #1357604 Message-ID: Patches item #1359879, was opened at 2005-11-18 12:39 Message generated for change (Comment added) made by birkenfeld You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1359879&group_id=5470 Please note that this 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: Peter van Kampen (pterk) Assigned to: Nobody/Anonymous (nobody) Summary: Patch for (Doc) #1357604 Initial Comment: Patch for doc-bug #1357604 that removes the remark about not working with UNC-paths. Confirmed to work with python 2.3.5 and 2.4.1. It does NOT work in python 2.2.3. ---------------------------------------------------------------------- >Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-11-22 21:14 Message: Logged In: YES user_id=1188172 Thanks, committed in rev 41521 and 41522(2.4). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1359879&group_id=5470 From noreply at sourceforge.net Wed Nov 23 02:06:28 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 22 Nov 2005 17:06:28 -0800 Subject: [Patches] [ python-Patches-1200038 ] CallTip Modifications Message-ID: Patches item #1200038, was opened at 2005-05-11 13:46 Message generated for change (Comment added) made by kbk You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1200038&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: IDLE Group: Python 2.4 >Status: Closed >Resolution: Rejected Priority: 5 Submitted By: sowjanya (sowjanya) >Assigned to: Kurt B. Kaiser (kbk) Summary: CallTip Modifications Initial Comment: These patches introduce modifications in CallTips, CallTipWindow and config-keys.def modules, 1-We create the global variable 'truncate ' in the CallTipWindow module .If truncate is True documenation string will be displayed till 75 characters ,and if False whole documentation string will be dispalyed. 2-In CallTips module , added if the object is callable then documenatation string describing the arguements of the object from call method is displayed with out truncating. 3-To allow the Up and Down arrow keys to be used to traverse the history of commands . In config-keys.def, history-next= history-previous= to history-next= history-previous= We are submitting the patches for your consideration to be included in to the next release of idlelib1.2a0. The patches were generated using the following comand, diff -c old new Thank you Sowjanya ---------------------------------------------------------------------- >Comment By: Kurt B. Kaiser (kbk) Date: 2005-11-22 20:06 Message: Logged In: YES user_id=149084 >From CallTipWindow.py log: Revision 28727 - (view) (download) (as text) - [select for diffs] Modified Sun Sep 15 21:43:13 2002 UTC (3 years, 2 months ago) by kbk File length: 2172 byte(s) Diff to previous 21669 Merge Py Idle changes Rev 1.4 SF bug 546078: IDLE calltips cause application error. Assorted crashes on Windows and Linux when trying to display a very long calltip, most likely a Tk bug. Wormed around by clamping the calltip display to a maximum of 79 characters (why 79? why not . ..). Bugfix candidate, for all Python releases. * So rejecting Item 1. Item 2: Same problem. We may have a different method in the works. Item 3: If you do this, you can't use the Up/Down keys to navigate in a multiline input in the Shell. You might try etc. I just modified the keybinding dialog so you can do this yourself. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1200038&group_id=5470 From noreply at sourceforge.net Wed Nov 23 02:09:28 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 22 Nov 2005 17:09:28 -0800 Subject: [Patches] [ python-Patches-989712 ] Support using Tk without a mainloop Message-ID: Patches item #989712, was opened at 2004-07-12 16:16 Message generated for change (Comment added) made by kbk You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=989712&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: IDLE Group: None Status: Open Resolution: None Priority: 5 Submitted By: Noam Raphael (noamr) Assigned to: Kurt B. Kaiser (kbk) Summary: Support using Tk without a mainloop Initial Comment: In the regular python shell, you can open Tk windows, and they will operate even though you didn't call Tkinter.mainloop(). This is useful, for example, when you manipulate matplotlib graphs from within the python shell. This is done by a hook, installed when a tkapp object is being initialized, which handles Tk events while the shell is waiting for user input. I imitated this behaviour in IDLE: When the subprocess is idle, it checks whether Tkinter._default_root is set (this happens when the Tkinter.Tk class, which makes a tkapp object, is initialized, unless Tkinter._use_default_root is False), and if so, handles Tk events. For me it works very well. Have a good day, Noam Raphael ---------------------------------------------------------------------- >Comment By: Kurt B. Kaiser (kbk) Date: 2005-11-22 20:09 Message: Logged In: YES user_id=149084 Noam, Michiel, what is the current position on this patch? There have been a lot of related patches and much discussion on python-dev. ---------------------------------------------------------------------- Comment By: Michiel de Hoon (mdehoon) Date: 2005-03-03 00:35 Message: Logged In: YES user_id=488897 Patch #1121234 (see my previous comment) was accepted and is now included in CVS, clearing the way for this patch. ---------------------------------------------------------------------- Comment By: Dick Madden (dickmadden) Date: 2005-02-14 09:57 Message: Logged In: YES user_id=1219007 I've tried the updated patches with Tkinter and my rasmol extension using the new inputhooks scheme and everything seems to be coexisting just fine. ---------------------------------------------------------------------- Comment By: Michiel de Hoon (mdehoon) Date: 2005-02-12 01:27 Message: Logged In: YES user_id=488897 Richard Madden was kind enough to test the patch at http://bonsai.ims.u-tokyo.ac.jp/~mdehoon/inputhooks.diff. This led to the discovery of two bugs in my patch and one preexisting bug in Tkinter.py. For this second bug, I submitted a separate patch (#1121234). I uploaded a fixed patch at http://bonsai.ims.u-tokyo.ac.jp/~mdehoon/inputhooks.diff; together with patch #1121234 the input hooks appear to be working correctly. ---------------------------------------------------------------------- Comment By: Michiel de Hoon (mdehoon) Date: 2005-02-08 03:53 Message: Logged In: YES user_id=488897 I have written a patch that solves this problem more generally via PyOS_InputHook, as suggested by Noam. This patch also solves the related bugs #1053687, #798058, and supersedes patch #1049855. The patch is available at http://bonsai.ims.u-tokyo.ac.jp/~mdehoon/inputhooks.diff Currently, the EventHook function sits in a loop handling Tcl events until keyboard input is detected. The presence of Tcl events is checked every Tkinter_busywaitinterval milliseconds. If a Tcl event arrives during this interval, it won't be handled until the end of the interval. However, with the default value of Tkinter_busywaitinterval = 20 milliseconds, that delay is not noticable. Now consider the situation in which there can be more than one input hook, for example set by different extension modules. We cannot have EventHook sit in a loop until keyboard input is detected, because that would prevent other PyOS_InputHooks from being serviced. So in the EventHook in the patch, the function returns immediately after handling all Tcl events. If we use Python from the command line and open a Tkinter label: >>> from Tkinter import * >>> l = Label() then readline will call PyOS_InputHook ten times per second while Python is idle. Because PyOS_InputHook points to EventHook, we will return to the EventHook function almost immediately. Effectively, we are then in the same situation as before the patch. On Cygwin, however, previously mainloop needed to be run in order for the label to appear; this is no longer necessary with this patch. On Windows, currently PyOS_InputHook is partially broken, as it is called only once per command instead of ten times per second. This patch fixed that also (same as patch #1049855). If we have two or more input hooks, they are called successively by readline. Since each input hook returns after it has no more work to do, all of the input hooks are guaranteed to be serviced. To be able to have more than one input hook, we need to replace PyOS_InputHook by three functions: PyOS_AddInputHook, PyOS_RemoveInputHook, and PyOS_CallInputHooks. For the third function, the corresponding Python function call_input_hooks was created in the readline module. By adding a call to readline.call_input_hooks in run.py, as suggested by Noam, all input hook functions are serviced when IDLE is idle. So we can use Tkinter without calling mainloop, and we can use other extension packages that use input hooks. We can even do both: >>> import Tkinter >>> import gist # my extension module also needs input hooks >>> Tkinter.Label() # label appears >>> gist.window() # Graphics window appears. works both with command-line python and IDLE. I'm interested to hear your comments and suggestions. If this patch seems like the way to go, I'd be happy to write the documentation for it. ---------------------------------------------------------------------- Comment By: Michiel de Hoon (mdehoon) Date: 2005-02-04 08:08 Message: Logged In: YES user_id=488897 I agree, this is basically the same bug as #798058. The call to readline.call_input_hook sounds like a good solution. But the hook function should be different than the current EventHook in _tkinter.c. That hook function sits in a loop until a keyboard event is noticed. A problem occurs if there is more than one hook function. Currently, that is not possible in Python, since there is only one PyOS_InputHook. I am working on a patch in which PyOS_InputHook is replaced by PyOS_AddInputHook and PyOS_RemoveInputHook, so that there can be more than one hook functions. Now suppose that there is one hook function to handle Tk events, and another one e.g. handling messages to windows in Microsoft Windows. (This is a real issue for one of my extension modules). If python sits in a loop in _tkinter.c's EventHook until a key is pressed, the MS windows won't get their messages. The following structure might work better: while(there is no keyboard input or other interesting event) { Call PyOS_InputHook #1 Call PyOS_InputHook #2 etc. } where each of the PyOS_InputHook functions should return if there is no more work for them. The tricky part is to find out which events to wait for; some of the events may be handled by one of the PyOS_InputHook functions. Obviously I need to do some more thinking about this. ---------------------------------------------------------------------- Comment By: Kurt B. Kaiser (kbk) Date: 2005-02-03 20:02 Message: Logged In: YES user_id=149084 Hm, this seems closely related to Bug 798058 I'd lost track of it because it got switched to tkinter. ---------------------------------------------------------------------- Comment By: Noam Raphael (noamr) Date: 2005-01-30 06:58 Message: Logged In: YES user_id=679426 in _tkinter.c, look for EventHook - you'll find the EventHook function, which is called when the interpreter is idle, and the Enable/Disable EventHook functions. In readline.c, line 765, you'll find the call to PyOS_InputHook, when waiting for input. Perhaps a more general approach would be to let Python code call PyOS_InputHook, for example, by defining readline.call_input_hook() and readline.has_input_hook(). Then IDLE would be able to call them when idle, with no Tkinter-specific code. ---------------------------------------------------------------------- Comment By: Kurt B. Kaiser (kbk) Date: 2004-07-14 16:44 Message: Logged In: YES user_id=149084 Can you give me some more information on the hook in the Python interpreter? Where is it in the code? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=989712&group_id=5470 From noreply at sourceforge.net Wed Nov 23 02:25:01 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 22 Nov 2005 17:25:01 -0800 Subject: [Patches] [ python-Patches-1362975 ] CodeContext - Improved text indentation Message-ID: Patches item #1362975, was opened at 2005-11-21 13:06 Message generated for change (Comment added) made by kbk You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1362975&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: IDLE Group: None Status: Open Resolution: None Priority: 5 Submitted By: Tal Einat (taleinat) Assigned to: Nobody/Anonymous (nobody) Summary: CodeContext - Improved text indentation Initial Comment: This is a second patch for the text indentation - the first one was sent by mail and patched directly by KBK. I've touched up the indentation code to be cleaner and more generic. There's no longer need for a pad Frame, the padding is done by the Label widget. More IDLE patches coming - stay tuned ;) ---------------------------------------------------------------------- >Comment By: Kurt B. Kaiser (kbk) Date: 2005-11-22 20:25 Message: Logged In: YES user_id=149084 At first glance the new code seems harder to understand and is longer. What is the advantage of going through the effort to apply, test, check in, and properly document the change? p.s. use Expand=False ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1362975&group_id=5470 From noreply at sourceforge.net Wed Nov 23 03:22:06 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 22 Nov 2005 18:22:06 -0800 Subject: [Patches] [ python-Patches-1314396 ] ensure lock is released if exception is raised Message-ID: Patches item #1314396, was opened at 2005-10-05 19:18 Message generated for change (Comment added) made by bcannon You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1314396&group_id=5470 Please note that this 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: Eric Blossom (eblossom) >Assigned to: Brett Cannon (bcannon) Summary: ensure lock is released if exception is raised Initial Comment: If an exception (typically KeyboardInterrupt) is raised in Thread.join, self.__block will be left locked, and any later attempt to join will block forever. The bug is easy to trigger if you provide a timeout to join. This patch ensures that the lock is released. ---------------------------------------------------------------------- >Comment By: Brett Cannon (bcannon) Date: 2005-11-22 18:22 Message: Logged In: YES user_id=357491 rev. 41524 (2.5) and rev. 41525 (2.4) have the fix. I am really looking forward to the 'with' statement and having all of the locks in 'threading' support it. Then this kind of thing will be avoided. Also, so it is documented, to trigger this, do the following:: import threading import time th = threading.Thread(target=lambda: time.sleep(5.0)) th.start() th.join('blah') th.join # Used to hang Thanks, Eric (tacked you on to Misc/ACKS). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1314396&group_id=5470 From noreply at sourceforge.net Wed Nov 23 10:04:24 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 23 Nov 2005 01:04:24 -0800 Subject: [Patches] [ python-Patches-1362975 ] CodeContext - Improved text indentation Message-ID: Patches item #1362975, was opened at 2005-11-21 20:06 Message generated for change (Comment added) made by taleinat You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1362975&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: IDLE Group: None Status: Open Resolution: None Priority: 5 Submitted By: Tal Einat (taleinat) Assigned to: Nobody/Anonymous (nobody) Summary: CodeContext - Improved text indentation Initial Comment: This is a second patch for the text indentation - the first one was sent by mail and patched directly by KBK. I've touched up the indentation code to be cleaner and more generic. There's no longer need for a pad Frame, the padding is done by the Label widget. More IDLE patches coming - stay tuned ;) ---------------------------------------------------------------------- >Comment By: Tal Einat (taleinat) Date: 2005-11-23 11:04 Message: Logged In: YES user_id=1330769 This patch is an improvement for two reasons: 1. One less TK widget is used 2. Replaces literal values with code that fetches the appropriate values from the editor window's widgets I'll admit it's not that big a deal. If it's really a lot of work, I'll leave it up to you to decide whether it's worth it. ---------------------------------------------------------------------- Comment By: Kurt B. Kaiser (kbk) Date: 2005-11-23 03:25 Message: Logged In: YES user_id=149084 At first glance the new code seems harder to understand and is longer. What is the advantage of going through the effort to apply, test, check in, and properly document the change? p.s. use Expand=False ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1362975&group_id=5470 From noreply at sourceforge.net Wed Nov 23 10:50:36 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 23 Nov 2005 01:50:36 -0800 Subject: [Patches] [ python-Patches-989712 ] Support using Tk without a mainloop Message-ID: Patches item #989712, was opened at 2004-07-12 23:16 Message generated for change (Comment added) made by noamr You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=989712&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: IDLE Group: None Status: Open Resolution: None Priority: 5 Submitted By: Noam Raphael (noamr) Assigned to: Kurt B. Kaiser (kbk) Summary: Support using Tk without a mainloop Initial Comment: In the regular python shell, you can open Tk windows, and they will operate even though you didn't call Tkinter.mainloop(). This is useful, for example, when you manipulate matplotlib graphs from within the python shell. This is done by a hook, installed when a tkapp object is being initialized, which handles Tk events while the shell is waiting for user input. I imitated this behaviour in IDLE: When the subprocess is idle, it checks whether Tkinter._default_root is set (this happens when the Tkinter.Tk class, which makes a tkapp object, is initialized, unless Tkinter._use_default_root is False), and if so, handles Tk events. For me it works very well. Have a good day, Noam Raphael ---------------------------------------------------------------------- >Comment By: Noam Raphael (noamr) Date: 2005-11-23 11:50 Message: Logged In: YES user_id=679426 It seems to me that the python-dev discussion didn't reach a conclusion. My patch is a sort of a workaround that lets you use Tk interactively from IDLE - it doesn't really invoke PyOS_InputHook. Since Tk always sets itself as PyOS_InputHook, it solves the Tk problem, which I think is the most common one. A more "correct" approach, which can be easily implemented, is to give a Python API that will call PyOS_InputHook. This would enable IDLE to imitate the exact behaviour of the textual interactive interpreter. It would have to be written in C, of course, and the question is where to put that C function: should it be in a C module which comes with IDLE, like the old "interrupt" module, or should a function be added to the "sys" or "os" modules? ---------------------------------------------------------------------- Comment By: Kurt B. Kaiser (kbk) Date: 2005-11-23 03:09 Message: Logged In: YES user_id=149084 Noam, Michiel, what is the current position on this patch? There have been a lot of related patches and much discussion on python-dev. ---------------------------------------------------------------------- Comment By: Michiel de Hoon (mdehoon) Date: 2005-03-03 07:35 Message: Logged In: YES user_id=488897 Patch #1121234 (see my previous comment) was accepted and is now included in CVS, clearing the way for this patch. ---------------------------------------------------------------------- Comment By: Dick Madden (dickmadden) Date: 2005-02-14 16:57 Message: Logged In: YES user_id=1219007 I've tried the updated patches with Tkinter and my rasmol extension using the new inputhooks scheme and everything seems to be coexisting just fine. ---------------------------------------------------------------------- Comment By: Michiel de Hoon (mdehoon) Date: 2005-02-12 08:27 Message: Logged In: YES user_id=488897 Richard Madden was kind enough to test the patch at http://bonsai.ims.u-tokyo.ac.jp/~mdehoon/inputhooks.diff. This led to the discovery of two bugs in my patch and one preexisting bug in Tkinter.py. For this second bug, I submitted a separate patch (#1121234). I uploaded a fixed patch at http://bonsai.ims.u-tokyo.ac.jp/~mdehoon/inputhooks.diff; together with patch #1121234 the input hooks appear to be working correctly. ---------------------------------------------------------------------- Comment By: Michiel de Hoon (mdehoon) Date: 2005-02-08 10:53 Message: Logged In: YES user_id=488897 I have written a patch that solves this problem more generally via PyOS_InputHook, as suggested by Noam. This patch also solves the related bugs #1053687, #798058, and supersedes patch #1049855. The patch is available at http://bonsai.ims.u-tokyo.ac.jp/~mdehoon/inputhooks.diff Currently, the EventHook function sits in a loop handling Tcl events until keyboard input is detected. The presence of Tcl events is checked every Tkinter_busywaitinterval milliseconds. If a Tcl event arrives during this interval, it won't be handled until the end of the interval. However, with the default value of Tkinter_busywaitinterval = 20 milliseconds, that delay is not noticable. Now consider the situation in which there can be more than one input hook, for example set by different extension modules. We cannot have EventHook sit in a loop until keyboard input is detected, because that would prevent other PyOS_InputHooks from being serviced. So in the EventHook in the patch, the function returns immediately after handling all Tcl events. If we use Python from the command line and open a Tkinter label: >>> from Tkinter import * >>> l = Label() then readline will call PyOS_InputHook ten times per second while Python is idle. Because PyOS_InputHook points to EventHook, we will return to the EventHook function almost immediately. Effectively, we are then in the same situation as before the patch. On Cygwin, however, previously mainloop needed to be run in order for the label to appear; this is no longer necessary with this patch. On Windows, currently PyOS_InputHook is partially broken, as it is called only once per command instead of ten times per second. This patch fixed that also (same as patch #1049855). If we have two or more input hooks, they are called successively by readline. Since each input hook returns after it has no more work to do, all of the input hooks are guaranteed to be serviced. To be able to have more than one input hook, we need to replace PyOS_InputHook by three functions: PyOS_AddInputHook, PyOS_RemoveInputHook, and PyOS_CallInputHooks. For the third function, the corresponding Python function call_input_hooks was created in the readline module. By adding a call to readline.call_input_hooks in run.py, as suggested by Noam, all input hook functions are serviced when IDLE is idle. So we can use Tkinter without calling mainloop, and we can use other extension packages that use input hooks. We can even do both: >>> import Tkinter >>> import gist # my extension module also needs input hooks >>> Tkinter.Label() # label appears >>> gist.window() # Graphics window appears. works both with command-line python and IDLE. I'm interested to hear your comments and suggestions. If this patch seems like the way to go, I'd be happy to write the documentation for it. ---------------------------------------------------------------------- Comment By: Michiel de Hoon (mdehoon) Date: 2005-02-04 15:08 Message: Logged In: YES user_id=488897 I agree, this is basically the same bug as #798058. The call to readline.call_input_hook sounds like a good solution. But the hook function should be different than the current EventHook in _tkinter.c. That hook function sits in a loop until a keyboard event is noticed. A problem occurs if there is more than one hook function. Currently, that is not possible in Python, since there is only one PyOS_InputHook. I am working on a patch in which PyOS_InputHook is replaced by PyOS_AddInputHook and PyOS_RemoveInputHook, so that there can be more than one hook functions. Now suppose that there is one hook function to handle Tk events, and another one e.g. handling messages to windows in Microsoft Windows. (This is a real issue for one of my extension modules). If python sits in a loop in _tkinter.c's EventHook until a key is pressed, the MS windows won't get their messages. The following structure might work better: while(there is no keyboard input or other interesting event) { Call PyOS_InputHook #1 Call PyOS_InputHook #2 etc. } where each of the PyOS_InputHook functions should return if there is no more work for them. The tricky part is to find out which events to wait for; some of the events may be handled by one of the PyOS_InputHook functions. Obviously I need to do some more thinking about this. ---------------------------------------------------------------------- Comment By: Kurt B. Kaiser (kbk) Date: 2005-02-04 03:02 Message: Logged In: YES user_id=149084 Hm, this seems closely related to Bug 798058 I'd lost track of it because it got switched to tkinter. ---------------------------------------------------------------------- Comment By: Noam Raphael (noamr) Date: 2005-01-30 13:58 Message: Logged In: YES user_id=679426 in _tkinter.c, look for EventHook - you'll find the EventHook function, which is called when the interpreter is idle, and the Enable/Disable EventHook functions. In readline.c, line 765, you'll find the call to PyOS_InputHook, when waiting for input. Perhaps a more general approach would be to let Python code call PyOS_InputHook, for example, by defining readline.call_input_hook() and readline.has_input_hook(). Then IDLE would be able to call them when idle, with no Tkinter-specific code. ---------------------------------------------------------------------- Comment By: Kurt B. Kaiser (kbk) Date: 2004-07-14 23:44 Message: Logged In: YES user_id=149084 Can you give me some more information on the hook in the Python interpreter? Where is it in the code? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=989712&group_id=5470 From noreply at sourceforge.net Wed Nov 23 12:01:02 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 23 Nov 2005 03:01:02 -0800 Subject: [Patches] [ python-Patches-1364545 ] test_cmd_line expecting English error messages Message-ID: Patches item #1364545, was opened at 2005-11-23 11: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=1364545&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Tests Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: A.B., Khalid (abkhd) Assigned to: Nobody/Anonymous (nobody) Summary: test_cmd_line expecting English error messages Initial Comment: Currently test_directories of test_cmd_line fails on the latest Python 2.4.2 from svn branch and from the svn head. The reason it seems is that the test assumes that the local language of Windows is English and so tries to find the string " denied" in the returned system error messages of the commands ("python .") and ("python < ."). But while it is true that the first command ("python .") does return an English string error message even on so-called non-English versions of Windows, the same does not seem to be true for the second command ("python < ."), which seems to return a locale-related string error message. And since the latter test is looking for the English " denied" in a non-English language formated string, the test fails in non-English versions of Windows. Walter asked me to post the patch here, and assign it to him. The patch uses subprocess and uses exitcodes for testing. I tested the patch successfully, but only on Windows. Although subprocess is supposed to work on all platforms, someone'd better test this just to be sure. I don't know what the policy for backporting is. But if allowed, this should be backported to Python 2.4.2 at least. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1364545&group_id=5470 From noreply at sourceforge.net Wed Nov 23 12:03:15 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 23 Nov 2005 03:03:15 -0800 Subject: [Patches] [ python-Patches-1364545 ] test_cmd_line expecting English error messages Message-ID: Patches item #1364545, was opened at 2005-11-23 11:01 Message generated for change (Settings changed) made by abkhd You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1364545&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Tests Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: A.B., Khalid (abkhd) >Assigned to: Walter D?rwald (doerwalter) Summary: test_cmd_line expecting English error messages Initial Comment: Currently test_directories of test_cmd_line fails on the latest Python 2.4.2 from svn branch and from the svn head. The reason it seems is that the test assumes that the local language of Windows is English and so tries to find the string " denied" in the returned system error messages of the commands ("python .") and ("python < ."). But while it is true that the first command ("python .") does return an English string error message even on so-called non-English versions of Windows, the same does not seem to be true for the second command ("python < ."), which seems to return a locale-related string error message. And since the latter test is looking for the English " denied" in a non-English language formated string, the test fails in non-English versions of Windows. Walter asked me to post the patch here, and assign it to him. The patch uses subprocess and uses exitcodes for testing. I tested the patch successfully, but only on Windows. Although subprocess is supposed to work on all platforms, someone'd better test this just to be sure. I don't know what the policy for backporting is. But if allowed, this should be backported to Python 2.4.2 at least. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1364545&group_id=5470 From noreply at sourceforge.net Wed Nov 23 13:28:37 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 23 Nov 2005 04:28:37 -0800 Subject: [Patches] [ python-Patches-1364545 ] test_cmd_line expecting English error messages Message-ID: Patches item #1364545, was opened at 2005-11-23 12:01 Message generated for change (Comment added) made by doerwalter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1364545&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Tests Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: A.B., Khalid (abkhd) Assigned to: Walter D?rwald (doerwalter) Summary: test_cmd_line expecting English error messages Initial Comment: Currently test_directories of test_cmd_line fails on the latest Python 2.4.2 from svn branch and from the svn head. The reason it seems is that the test assumes that the local language of Windows is English and so tries to find the string " denied" in the returned system error messages of the commands ("python .") and ("python < ."). But while it is true that the first command ("python .") does return an English string error message even on so-called non-English versions of Windows, the same does not seem to be true for the second command ("python < ."), which seems to return a locale-related string error message. And since the latter test is looking for the English " denied" in a non-English language formated string, the test fails in non-English versions of Windows. Walter asked me to post the patch here, and assign it to him. The patch uses subprocess and uses exitcodes for testing. I tested the patch successfully, but only on Windows. Although subprocess is supposed to work on all platforms, someone'd better test this just to be sure. I don't know what the policy for backporting is. But if allowed, this should be backported to Python 2.4.2 at least. ---------------------------------------------------------------------- >Comment By: Walter D?rwald (doerwalter) Date: 2005-11-23 13:28 Message: Logged In: YES user_id=89016 The test doesn't work on Linux. I get: Traceback (most recent call last): File "Lib/test/test_cmd_line.py", line 19, in test_directories self.assertTrue(self.exit_code('.') != 0) File "Lib/test/test_cmd_line.py", line 16, in exit_code return subprocess.call("%s %s" % (sys.executable, cmd_line), stderr=subprocess.PIPE) File "/var/home/walter/Python-checkouts/Python-unittest/Lib/subprocess.py", line 431, in call return Popen(*popenargs, **kwargs).wait() File "/var/home/walter/Python-checkouts/Python-unittest/Lib/subprocess.py", line 580, in __init__ errread, errwrite) File "/var/home/walter/Python-checkouts/Python-unittest/Lib/subprocess.py", line 1033, in _execute_child raise child_exception OSError: [Errno 2] No such file or directory Changing call("%s %s" % (sys.executable, cmd_line), stderr=PIPE) to call([sys.executable, cmd_line], stderr=PIPE) leads to Traceback (most recent call last): File "Lib/test/test_cmd_line.py", line 22, in test_directories self.assertTrue(self.exit_code('.') != 0) AssertionError Is there anything else I can try? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1364545&group_id=5470 From noreply at sourceforge.net Wed Nov 23 16:13:15 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 23 Nov 2005 07:13:15 -0800 Subject: [Patches] [ python-Patches-1315161 ] ToolTip.py: fix main() function Message-ID: Patches item #1315161, was opened at 2005-10-06 13:14 Message generated for change (Comment added) made by kbk You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1315161&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: IDLE Group: Python 2.4 >Status: Closed >Resolution: Accepted Priority: 5 Submitted By: sebastien blanchet (blanchet_38) >Assigned to: Kurt B. Kaiser (kbk) Summary: ToolTip.py: fix main() function Initial Comment: The main() function of ToolTip did not work: 1- root.mainloop() was commented, so the example code did not work 2- main() was invoked each time the module was imported because the test "if __name__ == "__main__":" was missing ---------------------------------------------------------------------- >Comment By: Kurt B. Kaiser (kbk) Date: 2005-11-23 10:13 Message: Logged In: YES user_id=149084 r 41526 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1315161&group_id=5470 From noreply at sourceforge.net Wed Nov 23 16:18:10 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 23 Nov 2005 07:18:10 -0800 Subject: [Patches] [ python-Patches-989712 ] Support using Tk without a mainloop Message-ID: Patches item #989712, was opened at 2004-07-12 16:16 Message generated for change (Comment added) made by kbk You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=989712&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: IDLE Group: None Status: Open Resolution: None Priority: 5 Submitted By: Noam Raphael (noamr) Assigned to: Kurt B. Kaiser (kbk) Summary: Support using Tk without a mainloop Initial Comment: In the regular python shell, you can open Tk windows, and they will operate even though you didn't call Tkinter.mainloop(). This is useful, for example, when you manipulate matplotlib graphs from within the python shell. This is done by a hook, installed when a tkapp object is being initialized, which handles Tk events while the shell is waiting for user input. I imitated this behaviour in IDLE: When the subprocess is idle, it checks whether Tkinter._default_root is set (this happens when the Tkinter.Tk class, which makes a tkapp object, is initialized, unless Tkinter._use_default_root is False), and if so, handles Tk events. For me it works very well. Have a good day, Noam Raphael ---------------------------------------------------------------------- >Comment By: Kurt B. Kaiser (kbk) Date: 2005-11-23 10:18 Message: Logged In: YES user_id=149084 IDLE is advertised as 'pure' Python, and we'd like to keep it that way if at all possible, so if an API is added, it would be to Python core. I gather you think the patch could go in as-is for now and we could update later if the API appears. ---------------------------------------------------------------------- Comment By: Noam Raphael (noamr) Date: 2005-11-23 04:50 Message: Logged In: YES user_id=679426 It seems to me that the python-dev discussion didn't reach a conclusion. My patch is a sort of a workaround that lets you use Tk interactively from IDLE - it doesn't really invoke PyOS_InputHook. Since Tk always sets itself as PyOS_InputHook, it solves the Tk problem, which I think is the most common one. A more "correct" approach, which can be easily implemented, is to give a Python API that will call PyOS_InputHook. This would enable IDLE to imitate the exact behaviour of the textual interactive interpreter. It would have to be written in C, of course, and the question is where to put that C function: should it be in a C module which comes with IDLE, like the old "interrupt" module, or should a function be added to the "sys" or "os" modules? ---------------------------------------------------------------------- Comment By: Kurt B. Kaiser (kbk) Date: 2005-11-22 20:09 Message: Logged In: YES user_id=149084 Noam, Michiel, what is the current position on this patch? There have been a lot of related patches and much discussion on python-dev. ---------------------------------------------------------------------- Comment By: Michiel de Hoon (mdehoon) Date: 2005-03-03 00:35 Message: Logged In: YES user_id=488897 Patch #1121234 (see my previous comment) was accepted and is now included in CVS, clearing the way for this patch. ---------------------------------------------------------------------- Comment By: Dick Madden (dickmadden) Date: 2005-02-14 09:57 Message: Logged In: YES user_id=1219007 I've tried the updated patches with Tkinter and my rasmol extension using the new inputhooks scheme and everything seems to be coexisting just fine. ---------------------------------------------------------------------- Comment By: Michiel de Hoon (mdehoon) Date: 2005-02-12 01:27 Message: Logged In: YES user_id=488897 Richard Madden was kind enough to test the patch at http://bonsai.ims.u-tokyo.ac.jp/~mdehoon/inputhooks.diff. This led to the discovery of two bugs in my patch and one preexisting bug in Tkinter.py. For this second bug, I submitted a separate patch (#1121234). I uploaded a fixed patch at http://bonsai.ims.u-tokyo.ac.jp/~mdehoon/inputhooks.diff; together with patch #1121234 the input hooks appear to be working correctly. ---------------------------------------------------------------------- Comment By: Michiel de Hoon (mdehoon) Date: 2005-02-08 03:53 Message: Logged In: YES user_id=488897 I have written a patch that solves this problem more generally via PyOS_InputHook, as suggested by Noam. This patch also solves the related bugs #1053687, #798058, and supersedes patch #1049855. The patch is available at http://bonsai.ims.u-tokyo.ac.jp/~mdehoon/inputhooks.diff Currently, the EventHook function sits in a loop handling Tcl events until keyboard input is detected. The presence of Tcl events is checked every Tkinter_busywaitinterval milliseconds. If a Tcl event arrives during this interval, it won't be handled until the end of the interval. However, with the default value of Tkinter_busywaitinterval = 20 milliseconds, that delay is not noticable. Now consider the situation in which there can be more than one input hook, for example set by different extension modules. We cannot have EventHook sit in a loop until keyboard input is detected, because that would prevent other PyOS_InputHooks from being serviced. So in the EventHook in the patch, the function returns immediately after handling all Tcl events. If we use Python from the command line and open a Tkinter label: >>> from Tkinter import * >>> l = Label() then readline will call PyOS_InputHook ten times per second while Python is idle. Because PyOS_InputHook points to EventHook, we will return to the EventHook function almost immediately. Effectively, we are then in the same situation as before the patch. On Cygwin, however, previously mainloop needed to be run in order for the label to appear; this is no longer necessary with this patch. On Windows, currently PyOS_InputHook is partially broken, as it is called only once per command instead of ten times per second. This patch fixed that also (same as patch #1049855). If we have two or more input hooks, they are called successively by readline. Since each input hook returns after it has no more work to do, all of the input hooks are guaranteed to be serviced. To be able to have more than one input hook, we need to replace PyOS_InputHook by three functions: PyOS_AddInputHook, PyOS_RemoveInputHook, and PyOS_CallInputHooks. For the third function, the corresponding Python function call_input_hooks was created in the readline module. By adding a call to readline.call_input_hooks in run.py, as suggested by Noam, all input hook functions are serviced when IDLE is idle. So we can use Tkinter without calling mainloop, and we can use other extension packages that use input hooks. We can even do both: >>> import Tkinter >>> import gist # my extension module also needs input hooks >>> Tkinter.Label() # label appears >>> gist.window() # Graphics window appears. works both with command-line python and IDLE. I'm interested to hear your comments and suggestions. If this patch seems like the way to go, I'd be happy to write the documentation for it. ---------------------------------------------------------------------- Comment By: Michiel de Hoon (mdehoon) Date: 2005-02-04 08:08 Message: Logged In: YES user_id=488897 I agree, this is basically the same bug as #798058. The call to readline.call_input_hook sounds like a good solution. But the hook function should be different than the current EventHook in _tkinter.c. That hook function sits in a loop until a keyboard event is noticed. A problem occurs if there is more than one hook function. Currently, that is not possible in Python, since there is only one PyOS_InputHook. I am working on a patch in which PyOS_InputHook is replaced by PyOS_AddInputHook and PyOS_RemoveInputHook, so that there can be more than one hook functions. Now suppose that there is one hook function to handle Tk events, and another one e.g. handling messages to windows in Microsoft Windows. (This is a real issue for one of my extension modules). If python sits in a loop in _tkinter.c's EventHook until a key is pressed, the MS windows won't get their messages. The following structure might work better: while(there is no keyboard input or other interesting event) { Call PyOS_InputHook #1 Call PyOS_InputHook #2 etc. } where each of the PyOS_InputHook functions should return if there is no more work for them. The tricky part is to find out which events to wait for; some of the events may be handled by one of the PyOS_InputHook functions. Obviously I need to do some more thinking about this. ---------------------------------------------------------------------- Comment By: Kurt B. Kaiser (kbk) Date: 2005-02-03 20:02 Message: Logged In: YES user_id=149084 Hm, this seems closely related to Bug 798058 I'd lost track of it because it got switched to tkinter. ---------------------------------------------------------------------- Comment By: Noam Raphael (noamr) Date: 2005-01-30 06:58 Message: Logged In: YES user_id=679426 in _tkinter.c, look for EventHook - you'll find the EventHook function, which is called when the interpreter is idle, and the Enable/Disable EventHook functions. In readline.c, line 765, you'll find the call to PyOS_InputHook, when waiting for input. Perhaps a more general approach would be to let Python code call PyOS_InputHook, for example, by defining readline.call_input_hook() and readline.has_input_hook(). Then IDLE would be able to call them when idle, with no Tkinter-specific code. ---------------------------------------------------------------------- Comment By: Kurt B. Kaiser (kbk) Date: 2004-07-14 16:44 Message: Logged In: YES user_id=149084 Can you give me some more information on the hook in the Python interpreter? Where is it in the code? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=989712&group_id=5470 From noreply at sourceforge.net Wed Nov 23 16:42:23 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 23 Nov 2005 07:42:23 -0800 Subject: [Patches] [ python-Patches-989712 ] Support using Tk without a mainloop Message-ID: Patches item #989712, was opened at 2004-07-12 23:16 Message generated for change (Comment added) made by noamr You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=989712&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: IDLE Group: None Status: Open Resolution: None Priority: 5 Submitted By: Noam Raphael (noamr) Assigned to: Kurt B. Kaiser (kbk) Summary: Support using Tk without a mainloop Initial Comment: In the regular python shell, you can open Tk windows, and they will operate even though you didn't call Tkinter.mainloop(). This is useful, for example, when you manipulate matplotlib graphs from within the python shell. This is done by a hook, installed when a tkapp object is being initialized, which handles Tk events while the shell is waiting for user input. I imitated this behaviour in IDLE: When the subprocess is idle, it checks whether Tkinter._default_root is set (this happens when the Tkinter.Tk class, which makes a tkapp object, is initialized, unless Tkinter._use_default_root is False), and if so, handles Tk events. For me it works very well. Have a good day, Noam Raphael ---------------------------------------------------------------------- >Comment By: Noam Raphael (noamr) Date: 2005-11-23 17:42 Message: Logged In: YES user_id=679426 That's right. ---------------------------------------------------------------------- Comment By: Kurt B. Kaiser (kbk) Date: 2005-11-23 17:18 Message: Logged In: YES user_id=149084 IDLE is advertised as 'pure' Python, and we'd like to keep it that way if at all possible, so if an API is added, it would be to Python core. I gather you think the patch could go in as-is for now and we could update later if the API appears. ---------------------------------------------------------------------- Comment By: Noam Raphael (noamr) Date: 2005-11-23 11:50 Message: Logged In: YES user_id=679426 It seems to me that the python-dev discussion didn't reach a conclusion. My patch is a sort of a workaround that lets you use Tk interactively from IDLE - it doesn't really invoke PyOS_InputHook. Since Tk always sets itself as PyOS_InputHook, it solves the Tk problem, which I think is the most common one. A more "correct" approach, which can be easily implemented, is to give a Python API that will call PyOS_InputHook. This would enable IDLE to imitate the exact behaviour of the textual interactive interpreter. It would have to be written in C, of course, and the question is where to put that C function: should it be in a C module which comes with IDLE, like the old "interrupt" module, or should a function be added to the "sys" or "os" modules? ---------------------------------------------------------------------- Comment By: Kurt B. Kaiser (kbk) Date: 2005-11-23 03:09 Message: Logged In: YES user_id=149084 Noam, Michiel, what is the current position on this patch? There have been a lot of related patches and much discussion on python-dev. ---------------------------------------------------------------------- Comment By: Michiel de Hoon (mdehoon) Date: 2005-03-03 07:35 Message: Logged In: YES user_id=488897 Patch #1121234 (see my previous comment) was accepted and is now included in CVS, clearing the way for this patch. ---------------------------------------------------------------------- Comment By: Dick Madden (dickmadden) Date: 2005-02-14 16:57 Message: Logged In: YES user_id=1219007 I've tried the updated patches with Tkinter and my rasmol extension using the new inputhooks scheme and everything seems to be coexisting just fine. ---------------------------------------------------------------------- Comment By: Michiel de Hoon (mdehoon) Date: 2005-02-12 08:27 Message: Logged In: YES user_id=488897 Richard Madden was kind enough to test the patch at http://bonsai.ims.u-tokyo.ac.jp/~mdehoon/inputhooks.diff. This led to the discovery of two bugs in my patch and one preexisting bug in Tkinter.py. For this second bug, I submitted a separate patch (#1121234). I uploaded a fixed patch at http://bonsai.ims.u-tokyo.ac.jp/~mdehoon/inputhooks.diff; together with patch #1121234 the input hooks appear to be working correctly. ---------------------------------------------------------------------- Comment By: Michiel de Hoon (mdehoon) Date: 2005-02-08 10:53 Message: Logged In: YES user_id=488897 I have written a patch that solves this problem more generally via PyOS_InputHook, as suggested by Noam. This patch also solves the related bugs #1053687, #798058, and supersedes patch #1049855. The patch is available at http://bonsai.ims.u-tokyo.ac.jp/~mdehoon/inputhooks.diff Currently, the EventHook function sits in a loop handling Tcl events until keyboard input is detected. The presence of Tcl events is checked every Tkinter_busywaitinterval milliseconds. If a Tcl event arrives during this interval, it won't be handled until the end of the interval. However, with the default value of Tkinter_busywaitinterval = 20 milliseconds, that delay is not noticable. Now consider the situation in which there can be more than one input hook, for example set by different extension modules. We cannot have EventHook sit in a loop until keyboard input is detected, because that would prevent other PyOS_InputHooks from being serviced. So in the EventHook in the patch, the function returns immediately after handling all Tcl events. If we use Python from the command line and open a Tkinter label: >>> from Tkinter import * >>> l = Label() then readline will call PyOS_InputHook ten times per second while Python is idle. Because PyOS_InputHook points to EventHook, we will return to the EventHook function almost immediately. Effectively, we are then in the same situation as before the patch. On Cygwin, however, previously mainloop needed to be run in order for the label to appear; this is no longer necessary with this patch. On Windows, currently PyOS_InputHook is partially broken, as it is called only once per command instead of ten times per second. This patch fixed that also (same as patch #1049855). If we have two or more input hooks, they are called successively by readline. Since each input hook returns after it has no more work to do, all of the input hooks are guaranteed to be serviced. To be able to have more than one input hook, we need to replace PyOS_InputHook by three functions: PyOS_AddInputHook, PyOS_RemoveInputHook, and PyOS_CallInputHooks. For the third function, the corresponding Python function call_input_hooks was created in the readline module. By adding a call to readline.call_input_hooks in run.py, as suggested by Noam, all input hook functions are serviced when IDLE is idle. So we can use Tkinter without calling mainloop, and we can use other extension packages that use input hooks. We can even do both: >>> import Tkinter >>> import gist # my extension module also needs input hooks >>> Tkinter.Label() # label appears >>> gist.window() # Graphics window appears. works both with command-line python and IDLE. I'm interested to hear your comments and suggestions. If this patch seems like the way to go, I'd be happy to write the documentation for it. ---------------------------------------------------------------------- Comment By: Michiel de Hoon (mdehoon) Date: 2005-02-04 15:08 Message: Logged In: YES user_id=488897 I agree, this is basically the same bug as #798058. The call to readline.call_input_hook sounds like a good solution. But the hook function should be different than the current EventHook in _tkinter.c. That hook function sits in a loop until a keyboard event is noticed. A problem occurs if there is more than one hook function. Currently, that is not possible in Python, since there is only one PyOS_InputHook. I am working on a patch in which PyOS_InputHook is replaced by PyOS_AddInputHook and PyOS_RemoveInputHook, so that there can be more than one hook functions. Now suppose that there is one hook function to handle Tk events, and another one e.g. handling messages to windows in Microsoft Windows. (This is a real issue for one of my extension modules). If python sits in a loop in _tkinter.c's EventHook until a key is pressed, the MS windows won't get their messages. The following structure might work better: while(there is no keyboard input or other interesting event) { Call PyOS_InputHook #1 Call PyOS_InputHook #2 etc. } where each of the PyOS_InputHook functions should return if there is no more work for them. The tricky part is to find out which events to wait for; some of the events may be handled by one of the PyOS_InputHook functions. Obviously I need to do some more thinking about this. ---------------------------------------------------------------------- Comment By: Kurt B. Kaiser (kbk) Date: 2005-02-04 03:02 Message: Logged In: YES user_id=149084 Hm, this seems closely related to Bug 798058 I'd lost track of it because it got switched to tkinter. ---------------------------------------------------------------------- Comment By: Noam Raphael (noamr) Date: 2005-01-30 13:58 Message: Logged In: YES user_id=679426 in _tkinter.c, look for EventHook - you'll find the EventHook function, which is called when the interpreter is idle, and the Enable/Disable EventHook functions. In readline.c, line 765, you'll find the call to PyOS_InputHook, when waiting for input. Perhaps a more general approach would be to let Python code call PyOS_InputHook, for example, by defining readline.call_input_hook() and readline.has_input_hook(). Then IDLE would be able to call them when idle, with no Tkinter-specific code. ---------------------------------------------------------------------- Comment By: Kurt B. Kaiser (kbk) Date: 2004-07-14 23:44 Message: Logged In: YES user_id=149084 Can you give me some more information on the hook in the Python interpreter? Where is it in the code? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=989712&group_id=5470 From noreply at sourceforge.net Wed Nov 23 17:53:15 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 23 Nov 2005 08:53:15 -0800 Subject: [Patches] [ python-Patches-1364545 ] test_cmd_line expecting English error messages Message-ID: Patches item #1364545, was opened at 2005-11-23 11:01 Message generated for change (Comment added) made by abkhd You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1364545&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Tests Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: A.B., Khalid (abkhd) Assigned to: Walter D?rwald (doerwalter) Summary: test_cmd_line expecting English error messages Initial Comment: Currently test_directories of test_cmd_line fails on the latest Python 2.4.2 from svn branch and from the svn head. The reason it seems is that the test assumes that the local language of Windows is English and so tries to find the string " denied" in the returned system error messages of the commands ("python .") and ("python < ."). But while it is true that the first command ("python .") does return an English string error message even on so-called non-English versions of Windows, the same does not seem to be true for the second command ("python < ."), which seems to return a locale-related string error message. And since the latter test is looking for the English " denied" in a non-English language formated string, the test fails in non-English versions of Windows. Walter asked me to post the patch here, and assign it to him. The patch uses subprocess and uses exitcodes for testing. I tested the patch successfully, but only on Windows. Although subprocess is supposed to work on all platforms, someone'd better test this just to be sure. I don't know what the policy for backporting is. But if allowed, this should be backported to Python 2.4.2 at least. ---------------------------------------------------------------------- >Comment By: A.B., Khalid (abkhd) Date: 2005-11-23 16:53 Message: Logged In: YES user_id=1079026 Well we seem to have two problems here. The first is the one you changed subprocess' call arguments to avoid as it seems Windows/Linux or subprocess deal with string arguments differently. The second, which is more serious in my view, is how "python ." yeilds an error on Windows, but no error at all on Linux. If other platform behave the same then why is there a need for this test? If the difference is just between these two platforms then I think we can manage with hardcoding the exit codes. Ugly, yes. But it works. #------------------------- # On Windows #------------------------- $ python -i Python 2.5a0 (#66, Nov 22 2005, 23:25:46) [GCC 3.4.2 (mingw-special)] on win32 Type "help", "copyright", "credits" or "license" for more information. >>> import test_cmd_line as t >>> t.test_main() test_directories (test_cmd_line.CmdLineTest) ... ok test_environment (test_cmd_line.CmdLineTest) ... ok test_optimize (test_cmd_line.CmdLineTest) ... ok test_q (test_cmd_line.CmdLineTest) ... ok test_site_flag (test_cmd_line.CmdLineTest) ... ok test_usage (test_cmd_line.CmdLineTest) ... ok test_version (test_cmd_line.CmdLineTest) ... ok ---------------------------------------------------------------------- Ran 7 tests in 6.750s OK >>> #------------------------- # On Linux #------------------------- ubuntu at ubuntu:~/Desktop$ python Python 2.4.1 (#2, Mar 30 2005, 21:51:10) [GCC 3.3.5 (Debian 1:3.3.5-8ubuntu2)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> import test_cmd_line as t >>> t.test_main() test_directories (test_cmd_line.CmdLineTest) ... ok test_environment (test_cmd_line.CmdLineTest) ... ok test_optimize (test_cmd_line.CmdLineTest) ... ok test_q (test_cmd_line.CmdLineTest) ... ok test_site_flag (test_cmd_line.CmdLineTest) ... ok test_usage (test_cmd_line.CmdLineTest) ... ok test_version (test_cmd_line.CmdLineTest) ... ok ---------------------------------------------------------------------- Ran 7 tests in 1.701s OK >>> ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2005-11-23 12:28 Message: Logged In: YES user_id=89016 The test doesn't work on Linux. I get: Traceback (most recent call last): File "Lib/test/test_cmd_line.py", line 19, in test_directories self.assertTrue(self.exit_code('.') != 0) File "Lib/test/test_cmd_line.py", line 16, in exit_code return subprocess.call("%s %s" % (sys.executable, cmd_line), stderr=subprocess.PIPE) File "/var/home/walter/Python-checkouts/Python-unittest/Lib/subprocess.py", line 431, in call return Popen(*popenargs, **kwargs).wait() File "/var/home/walter/Python-checkouts/Python-unittest/Lib/subprocess.py", line 580, in __init__ errread, errwrite) File "/var/home/walter/Python-checkouts/Python-unittest/Lib/subprocess.py", line 1033, in _execute_child raise child_exception OSError: [Errno 2] No such file or directory Changing call("%s %s" % (sys.executable, cmd_line), stderr=PIPE) to call([sys.executable, cmd_line], stderr=PIPE) leads to Traceback (most recent call last): File "Lib/test/test_cmd_line.py", line 22, in test_directories self.assertTrue(self.exit_code('.') != 0) AssertionError Is there anything else I can try? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1364545&group_id=5470 From noreply at sourceforge.net Wed Nov 23 17:56:09 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 23 Nov 2005 08:56:09 -0800 Subject: [Patches] [ python-Patches-1364545 ] test_cmd_line expecting English error messages Message-ID: Patches item #1364545, was opened at 2005-11-23 11:01 Message generated for change (Comment added) made by abkhd You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1364545&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Tests Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: A.B., Khalid (abkhd) Assigned to: Walter D?rwald (doerwalter) Summary: test_cmd_line expecting English error messages Initial Comment: Currently test_directories of test_cmd_line fails on the latest Python 2.4.2 from svn branch and from the svn head. The reason it seems is that the test assumes that the local language of Windows is English and so tries to find the string " denied" in the returned system error messages of the commands ("python .") and ("python < ."). But while it is true that the first command ("python .") does return an English string error message even on so-called non-English versions of Windows, the same does not seem to be true for the second command ("python < ."), which seems to return a locale-related string error message. And since the latter test is looking for the English " denied" in a non-English language formated string, the test fails in non-English versions of Windows. Walter asked me to post the patch here, and assign it to him. The patch uses subprocess and uses exitcodes for testing. I tested the patch successfully, but only on Windows. Although subprocess is supposed to work on all platforms, someone'd better test this just to be sure. I don't know what the policy for backporting is. But if allowed, this should be backported to Python 2.4.2 at least. ---------------------------------------------------------------------- >Comment By: A.B., Khalid (abkhd) Date: 2005-11-23 16:56 Message: Logged In: YES user_id=1079026 Forgot to say the patch is attached. ---------------------------------------------------------------------- Comment By: A.B., Khalid (abkhd) Date: 2005-11-23 16:53 Message: Logged In: YES user_id=1079026 Well we seem to have two problems here. The first is the one you changed subprocess' call arguments to avoid as it seems Windows/Linux or subprocess deal with string arguments differently. The second, which is more serious in my view, is how "python ." yeilds an error on Windows, but no error at all on Linux. If other platform behave the same then why is there a need for this test? If the difference is just between these two platforms then I think we can manage with hardcoding the exit codes. Ugly, yes. But it works. #------------------------- # On Windows #------------------------- $ python -i Python 2.5a0 (#66, Nov 22 2005, 23:25:46) [GCC 3.4.2 (mingw-special)] on win32 Type "help", "copyright", "credits" or "license" for more information. >>> import test_cmd_line as t >>> t.test_main() test_directories (test_cmd_line.CmdLineTest) ... ok test_environment (test_cmd_line.CmdLineTest) ... ok test_optimize (test_cmd_line.CmdLineTest) ... ok test_q (test_cmd_line.CmdLineTest) ... ok test_site_flag (test_cmd_line.CmdLineTest) ... ok test_usage (test_cmd_line.CmdLineTest) ... ok test_version (test_cmd_line.CmdLineTest) ... ok ---------------------------------------------------------------------- Ran 7 tests in 6.750s OK >>> #------------------------- # On Linux #------------------------- ubuntu at ubuntu:~/Desktop$ python Python 2.4.1 (#2, Mar 30 2005, 21:51:10) [GCC 3.3.5 (Debian 1:3.3.5-8ubuntu2)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> import test_cmd_line as t >>> t.test_main() test_directories (test_cmd_line.CmdLineTest) ... ok test_environment (test_cmd_line.CmdLineTest) ... ok test_optimize (test_cmd_line.CmdLineTest) ... ok test_q (test_cmd_line.CmdLineTest) ... ok test_site_flag (test_cmd_line.CmdLineTest) ... ok test_usage (test_cmd_line.CmdLineTest) ... ok test_version (test_cmd_line.CmdLineTest) ... ok ---------------------------------------------------------------------- Ran 7 tests in 1.701s OK >>> ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2005-11-23 12:28 Message: Logged In: YES user_id=89016 The test doesn't work on Linux. I get: Traceback (most recent call last): File "Lib/test/test_cmd_line.py", line 19, in test_directories self.assertTrue(self.exit_code('.') != 0) File "Lib/test/test_cmd_line.py", line 16, in exit_code return subprocess.call("%s %s" % (sys.executable, cmd_line), stderr=subprocess.PIPE) File "/var/home/walter/Python-checkouts/Python-unittest/Lib/subprocess.py", line 431, in call return Popen(*popenargs, **kwargs).wait() File "/var/home/walter/Python-checkouts/Python-unittest/Lib/subprocess.py", line 580, in __init__ errread, errwrite) File "/var/home/walter/Python-checkouts/Python-unittest/Lib/subprocess.py", line 1033, in _execute_child raise child_exception OSError: [Errno 2] No such file or directory Changing call("%s %s" % (sys.executable, cmd_line), stderr=PIPE) to call([sys.executable, cmd_line], stderr=PIPE) leads to Traceback (most recent call last): File "Lib/test/test_cmd_line.py", line 22, in test_directories self.assertTrue(self.exit_code('.') != 0) AssertionError Is there anything else I can try? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1364545&group_id=5470 From noreply at sourceforge.net Wed Nov 23 18:54:12 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 23 Nov 2005 09:54:12 -0800 Subject: [Patches] [ python-Patches-989712 ] Support using Tk without a mainloop Message-ID: Patches item #989712, was opened at 2004-07-13 05:16 Message generated for change (Comment added) made by mdehoon You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=989712&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: IDLE Group: None Status: Open Resolution: None Priority: 5 Submitted By: Noam Raphael (noamr) Assigned to: Kurt B. Kaiser (kbk) Summary: Support using Tk without a mainloop Initial Comment: In the regular python shell, you can open Tk windows, and they will operate even though you didn't call Tkinter.mainloop(). This is useful, for example, when you manipulate matplotlib graphs from within the python shell. This is done by a hook, installed when a tkapp object is being initialized, which handles Tk events while the shell is waiting for user input. I imitated this behaviour in IDLE: When the subprocess is idle, it checks whether Tkinter._default_root is set (this happens when the Tkinter.Tk class, which makes a tkapp object, is initialized, unless Tkinter._use_default_root is False), and if so, handles Tk events. For me it works very well. Have a good day, Noam Raphael ---------------------------------------------------------------------- Comment By: Michiel de Hoon (mdehoon) Date: 2005-11-24 02:54 Message: Logged In: YES user_id=488897 On the one hand, this patch is a bit of a hack, but on the other hand, finding a good solution that everybody can agree on may take a long time. I think therefore that it is OK to accept this patch (as written by Noam) now, and come back to this issue later if and when a more profound solution is found. The patch that I wrote (I put a link to it in one of the comments below) goes beyond what people agreed on on python-dev, so I think it is not appropriate to accept it now. You can just disregard it. ---------------------------------------------------------------------- Comment By: Noam Raphael (noamr) Date: 2005-11-24 00:42 Message: Logged In: YES user_id=679426 That's right. ---------------------------------------------------------------------- Comment By: Kurt B. Kaiser (kbk) Date: 2005-11-24 00:18 Message: Logged In: YES user_id=149084 IDLE is advertised as 'pure' Python, and we'd like to keep it that way if at all possible, so if an API is added, it would be to Python core. I gather you think the patch could go in as-is for now and we could update later if the API appears. ---------------------------------------------------------------------- Comment By: Noam Raphael (noamr) Date: 2005-11-23 18:50 Message: Logged In: YES user_id=679426 It seems to me that the python-dev discussion didn't reach a conclusion. My patch is a sort of a workaround that lets you use Tk interactively from IDLE - it doesn't really invoke PyOS_InputHook. Since Tk always sets itself as PyOS_InputHook, it solves the Tk problem, which I think is the most common one. A more "correct" approach, which can be easily implemented, is to give a Python API that will call PyOS_InputHook. This would enable IDLE to imitate the exact behaviour of the textual interactive interpreter. It would have to be written in C, of course, and the question is where to put that C function: should it be in a C module which comes with IDLE, like the old "interrupt" module, or should a function be added to the "sys" or "os" modules? ---------------------------------------------------------------------- Comment By: Kurt B. Kaiser (kbk) Date: 2005-11-23 10:09 Message: Logged In: YES user_id=149084 Noam, Michiel, what is the current position on this patch? There have been a lot of related patches and much discussion on python-dev. ---------------------------------------------------------------------- Comment By: Michiel de Hoon (mdehoon) Date: 2005-03-03 14:35 Message: Logged In: YES user_id=488897 Patch #1121234 (see my previous comment) was accepted and is now included in CVS, clearing the way for this patch. ---------------------------------------------------------------------- Comment By: Dick Madden (dickmadden) Date: 2005-02-14 23:57 Message: Logged In: YES user_id=1219007 I've tried the updated patches with Tkinter and my rasmol extension using the new inputhooks scheme and everything seems to be coexisting just fine. ---------------------------------------------------------------------- Comment By: Michiel de Hoon (mdehoon) Date: 2005-02-12 15:27 Message: Logged In: YES user_id=488897 Richard Madden was kind enough to test the patch at http://bonsai.ims.u-tokyo.ac.jp/~mdehoon/inputhooks.diff. This led to the discovery of two bugs in my patch and one preexisting bug in Tkinter.py. For this second bug, I submitted a separate patch (#1121234). I uploaded a fixed patch at http://bonsai.ims.u-tokyo.ac.jp/~mdehoon/inputhooks.diff; together with patch #1121234 the input hooks appear to be working correctly. ---------------------------------------------------------------------- Comment By: Michiel de Hoon (mdehoon) Date: 2005-02-08 17:53 Message: Logged In: YES user_id=488897 I have written a patch that solves this problem more generally via PyOS_InputHook, as suggested by Noam. This patch also solves the related bugs #1053687, #798058, and supersedes patch #1049855. The patch is available at http://bonsai.ims.u-tokyo.ac.jp/~mdehoon/inputhooks.diff Currently, the EventHook function sits in a loop handling Tcl events until keyboard input is detected. The presence of Tcl events is checked every Tkinter_busywaitinterval milliseconds. If a Tcl event arrives during this interval, it won't be handled until the end of the interval. However, with the default value of Tkinter_busywaitinterval = 20 milliseconds, that delay is not noticable. Now consider the situation in which there can be more than one input hook, for example set by different extension modules. We cannot have EventHook sit in a loop until keyboard input is detected, because that would prevent other PyOS_InputHooks from being serviced. So in the EventHook in the patch, the function returns immediately after handling all Tcl events. If we use Python from the command line and open a Tkinter label: >>> from Tkinter import * >>> l = Label() then readline will call PyOS_InputHook ten times per second while Python is idle. Because PyOS_InputHook points to EventHook, we will return to the EventHook function almost immediately. Effectively, we are then in the same situation as before the patch. On Cygwin, however, previously mainloop needed to be run in order for the label to appear; this is no longer necessary with this patch. On Windows, currently PyOS_InputHook is partially broken, as it is called only once per command instead of ten times per second. This patch fixed that also (same as patch #1049855). If we have two or more input hooks, they are called successively by readline. Since each input hook returns after it has no more work to do, all of the input hooks are guaranteed to be serviced. To be able to have more than one input hook, we need to replace PyOS_InputHook by three functions: PyOS_AddInputHook, PyOS_RemoveInputHook, and PyOS_CallInputHooks. For the third function, the corresponding Python function call_input_hooks was created in the readline module. By adding a call to readline.call_input_hooks in run.py, as suggested by Noam, all input hook functions are serviced when IDLE is idle. So we can use Tkinter without calling mainloop, and we can use other extension packages that use input hooks. We can even do both: >>> import Tkinter >>> import gist # my extension module also needs input hooks >>> Tkinter.Label() # label appears >>> gist.window() # Graphics window appears. works both with command-line python and IDLE. I'm interested to hear your comments and suggestions. If this patch seems like the way to go, I'd be happy to write the documentation for it. ---------------------------------------------------------------------- Comment By: Michiel de Hoon (mdehoon) Date: 2005-02-04 22:08 Message: Logged In: YES user_id=488897 I agree, this is basically the same bug as #798058. The call to readline.call_input_hook sounds like a good solution. But the hook function should be different than the current EventHook in _tkinter.c. That hook function sits in a loop until a keyboard event is noticed. A problem occurs if there is more than one hook function. Currently, that is not possible in Python, since there is only one PyOS_InputHook. I am working on a patch in which PyOS_InputHook is replaced by PyOS_AddInputHook and PyOS_RemoveInputHook, so that there can be more than one hook functions. Now suppose that there is one hook function to handle Tk events, and another one e.g. handling messages to windows in Microsoft Windows. (This is a real issue for one of my extension modules). If python sits in a loop in _tkinter.c's EventHook until a key is pressed, the MS windows won't get their messages. The following structure might work better: while(there is no keyboard input or other interesting event) { Call PyOS_InputHook #1 Call PyOS_InputHook #2 etc. } where each of the PyOS_InputHook functions should return if there is no more work for them. The tricky part is to find out which events to wait for; some of the events may be handled by one of the PyOS_InputHook functions. Obviously I need to do some more thinking about this. ---------------------------------------------------------------------- Comment By: Kurt B. Kaiser (kbk) Date: 2005-02-04 10:02 Message: Logged In: YES user_id=149084 Hm, this seems closely related to Bug 798058 I'd lost track of it because it got switched to tkinter. ---------------------------------------------------------------------- Comment By: Noam Raphael (noamr) Date: 2005-01-30 20:58 Message: Logged In: YES user_id=679426 in _tkinter.c, look for EventHook - you'll find the EventHook function, which is called when the interpreter is idle, and the Enable/Disable EventHook functions. In readline.c, line 765, you'll find the call to PyOS_InputHook, when waiting for input. Perhaps a more general approach would be to let Python code call PyOS_InputHook, for example, by defining readline.call_input_hook() and readline.has_input_hook(). Then IDLE would be able to call them when idle, with no Tkinter-specific code. ---------------------------------------------------------------------- Comment By: Kurt B. Kaiser (kbk) Date: 2004-07-15 05:44 Message: Logged In: YES user_id=149084 Can you give me some more information on the hook in the Python interpreter? Where is it in the code? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=989712&group_id=5470 From noreply at sourceforge.net Wed Nov 23 20:33:45 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 23 Nov 2005 11:33:45 -0800 Subject: [Patches] [ python-Patches-1364946 ] Add reference for en/decode error types Message-ID: Patches item #1364946, was opened at 2005-11-23 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=1364946&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Documentation Group: None Status: Open Resolution: None Priority: 5 Submitted By: Wummel (calvin) Assigned to: Nobody/Anonymous (nobody) Summary: Add reference for en/decode error types Initial Comment: The string methods encode() and decode() can specify the error handling type. This patch adds a reference link to the definition of the default types to the documentation. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1364946&group_id=5470 From ck80_ at hotmail.com Thu Nov 24 05:06:15 2005 From: ck80_ at hotmail.com (C K) Date: Thu, 24 Nov 2005 04:06:15 +0000 Subject: [Patches] 78.BZM. Stay hard with Cialis Message-ID: how do i order cialis from you? From noreply at sourceforge.net Thu Nov 24 23:22:05 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 24 Nov 2005 14:22:05 -0800 Subject: [Patches] [ python-Patches-1365916 ] [PATCH] mmap fails on AMD64 Message-ID: Patches item #1365916, was opened at 2005-11-24 22:22 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1365916&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Modules Group: None Status: Open Resolution: None Priority: 5 Submitted By: Joe Wreschnig (piman) Assigned to: Nobody/Anonymous (nobody) Summary: [PATCH] mmap fails on AMD64 Initial Comment: mmap_move_method is not 64-bit safe, and fails on the following code: from mmap import mmap f = open('test.out', 'ab+') f.write('ABCDEabcde') f.flush() m = mmap(f.fileno(), 10) m.move(5, 0, 5) m.read(10) To fix this, mmapmodule.c:538 needs to use "LLL:move" instead of "iii:move" (this also fixes #1921169, which changed it from "iii" to "III"). This is in both Python 2.3 and 2.4. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1365916&group_id=5470 From noreply at sourceforge.net Fri Nov 25 00:26:33 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 24 Nov 2005 15:26:33 -0800 Subject: [Patches] [ python-Patches-1324762 ] Compiling and linking main() with C++ compiler Message-ID: Patches item #1324762, was opened at 2005-10-12 13:45 Message generated for change (Comment added) made by jackjansen You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1324762&group_id=5470 Please note that this 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: Christoph Ludwig (cludwig) Assigned to: Nobody/Anonymous (nobody) Summary: Compiling and linking main() with C++ compiler Initial Comment: The attached patch proposes a resolution to the discussion started in regarding the compiler (C vs. C++) used to compile python's main() and to link the executable. The patch contains the following changes: 1) The configure option --with-cxx is renamed --with-cxx-main. This was done to avoid surprising the user by the changed meaning. Furthermore, it is now possible that CXX has a different value than provided by --with-cxx-main, so the old name would have been confusing. 2) The compiler used to translate python's main() function is stored in the configure / Makefile variable MAINCC. By default, MAINCC=$(CC). If --with-cxx-main is given (without an appended compiler name), then MAINCC=$(CXX). If --with-cxx-main= is on the configure command line, then MAINCC=. Additionally, configure sets CXX= unless CXX was already set on the configure command line. 3) The command used to link the python executable is (as before) stored in LINKCC. By default, LINKCC='$(PURIFY) $(MAINCC)', i.e. the linker front-end is the compiler used to translate main(). If necessary, LINKCC can be set on the configure command line in which case it won't be altered. 4) If CXX is not set by the user (on the command line or via --with-cxx-main), then configure tries several likely C++ compiler names. CXX is assigned the first name that refers to a callable program in the system. (CXX is set even if python is built with a C compiler only, so distutils can build C++ extensions.) 5) Modules/ccpython.cc is no longer used and can be removed. ---------------------------------------------------------------------- >Comment By: Jack Jansen (jackjansen) Date: 2005-11-25 00:26 Message: Logged In: YES user_id=45365 Well, as I commented on this patch and you quickly followed my suggestions I felt obliged to test your fix, but I'm not sure about the outcome. I built a C++ extension on MacOSX 10.4, gcc 4, framework Python. The good news is that it worked fine, everything built and worked as before. BUT: both with and without your mods my C++ modules are compiled with "gcc", not "g ++" or "c++". Linking is done with "c++", in both cases. I looked at distutils and it seems that it could indeed be the case that CXX is only used for linking and never for compilation, but I'm not 100% sure. Additionally, the Makefile has CC= gcc CXX= c++ which is technically fine on my machine (g++ == c++), but may not work always. Maybe someone who has a machine with both cc/c++ and gcc/g++ installed, and preferrably incompatible compilers, could give this patch a try too? ---------------------------------------------------------------------- Comment By: Christoph Ludwig (cludwig) Date: 2005-11-10 19:42 Message: Logged In: YES user_id=1266029 I am going to upload a revision of my patch that addresses jackjansen's comment: It sets CXX to g++ or c++ if CC is gcc or cc, respectively. Additionally, it writes a warning if configure had to "guess" the C++ compiler and tells the user how to override this guess. The change is in lin with jackjansen's second suggestion. It is pretty straight forward and avoids fragile configure magic. ---------------------------------------------------------------------- Comment By: Jack Jansen (jackjansen) Date: 2005-11-08 23:51 Message: Logged In: YES user_id=45365 One question: is step 4 a wise idea? Picking a random C++ compiler if multiple are available may result in picking a vendor C++ when the user has specified CC=gcc, for example. OTOH, actually doing the configure magic to determine that the selected C++ works together with the c-compiler selected for Python may be overkill too. Maybe try only standard combinations cc/c++ gcc/g++ and otherwise require --with{out}-cxx? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1324762&group_id=5470 From noreply at sourceforge.net Fri Nov 25 02:41:19 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 24 Nov 2005 17:41:19 -0800 Subject: [Patches] [ python-Patches-1350409 ] Fix for signal related abort in Visual Studio 2005 Message-ID: Patches item #1350409, was opened at 2005-11-07 10:31 Message generated for change (Comment added) made by cculver You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1350409&group_id=5470 Please note that this 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: Adal Chiriliuc (adalx) Assigned to: Nobody/Anonymous (nobody) Summary: Fix for signal related abort in Visual Studio 2005 Initial Comment: See #1167262 and #1311784. ---------------------------------------------------------------------- Comment By: Clay Culver (cculver) Date: 2005-11-24 20:41 Message: Logged In: YES user_id=149773 Fantastic work, this fixed my compile problem with VS 2005 Express. Thanks adalx. ---------------------------------------------------------------------- Comment By: Adal Chiriliuc (adalx) Date: 2005-11-07 18:48 Message: Logged In: YES user_id=1067739 Microsoft Visual Studio 2005 Professional Edition Version 8.0.50727.42 (RTM 050727-4200) It's the final version (RTM=Release To Manufacture), released a week ago on MSDN. I understand that it should be available in stores starting from today. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2005-11-07 18:21 Message: Logged In: YES user_id=21627 What precise version of visual studio did you use to develop this patch? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1350409&group_id=5470 From noreply at sourceforge.net Fri Nov 25 11:51:27 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 25 Nov 2005 02:51:27 -0800 Subject: [Patches] [ python-Patches-1324762 ] Compiling and linking main() with C++ compiler Message-ID: Patches item #1324762, was opened at 2005-10-12 13:45 Message generated for change (Comment added) made by cludwig You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1324762&group_id=5470 Please note that this 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: Christoph Ludwig (cludwig) Assigned to: Nobody/Anonymous (nobody) Summary: Compiling and linking main() with C++ compiler Initial Comment: The attached patch proposes a resolution to the discussion started in regarding the compiler (C vs. C++) used to compile python's main() and to link the executable. The patch contains the following changes: 1) The configure option --with-cxx is renamed --with-cxx-main. This was done to avoid surprising the user by the changed meaning. Furthermore, it is now possible that CXX has a different value than provided by --with-cxx-main, so the old name would have been confusing. 2) The compiler used to translate python's main() function is stored in the configure / Makefile variable MAINCC. By default, MAINCC=$(CC). If --with-cxx-main is given (without an appended compiler name), then MAINCC=$(CXX). If --with-cxx-main= is on the configure command line, then MAINCC=. Additionally, configure sets CXX= unless CXX was already set on the configure command line. 3) The command used to link the python executable is (as before) stored in LINKCC. By default, LINKCC='$(PURIFY) $(MAINCC)', i.e. the linker front-end is the compiler used to translate main(). If necessary, LINKCC can be set on the configure command line in which case it won't be altered. 4) If CXX is not set by the user (on the command line or via --with-cxx-main), then configure tries several likely C++ compiler names. CXX is assigned the first name that refers to a callable program in the system. (CXX is set even if python is built with a C compiler only, so distutils can build C++ extensions.) 5) Modules/ccpython.cc is no longer used and can be removed. ---------------------------------------------------------------------- >Comment By: Christoph Ludwig (cludwig) Date: 2005-11-25 11:51 Message: Logged In: YES user_id=1266029 distutils behaves the same way in Python 2.4.1, as I mentioned . My patch does not address this problem at all. (It should be fixed in distutils, but I did not the time to look into it yet.) I am surprised that, on your machine, CC=gcc and CXX=c++. I will look into this next week. ---------------------------------------------------------------------- Comment By: Jack Jansen (jackjansen) Date: 2005-11-25 00:26 Message: Logged In: YES user_id=45365 Well, as I commented on this patch and you quickly followed my suggestions I felt obliged to test your fix, but I'm not sure about the outcome. I built a C++ extension on MacOSX 10.4, gcc 4, framework Python. The good news is that it worked fine, everything built and worked as before. BUT: both with and without your mods my C++ modules are compiled with "gcc", not "g ++" or "c++". Linking is done with "c++", in both cases. I looked at distutils and it seems that it could indeed be the case that CXX is only used for linking and never for compilation, but I'm not 100% sure. Additionally, the Makefile has CC= gcc CXX= c++ which is technically fine on my machine (g++ == c++), but may not work always. Maybe someone who has a machine with both cc/c++ and gcc/g++ installed, and preferrably incompatible compilers, could give this patch a try too? ---------------------------------------------------------------------- Comment By: Christoph Ludwig (cludwig) Date: 2005-11-10 19:42 Message: Logged In: YES user_id=1266029 I am going to upload a revision of my patch that addresses jackjansen's comment: It sets CXX to g++ or c++ if CC is gcc or cc, respectively. Additionally, it writes a warning if configure had to "guess" the C++ compiler and tells the user how to override this guess. The change is in lin with jackjansen's second suggestion. It is pretty straight forward and avoids fragile configure magic. ---------------------------------------------------------------------- Comment By: Jack Jansen (jackjansen) Date: 2005-11-08 23:51 Message: Logged In: YES user_id=45365 One question: is step 4 a wise idea? Picking a random C++ compiler if multiple are available may result in picking a vendor C++ when the user has specified CC=gcc, for example. OTOH, actually doing the configure magic to determine that the selected C++ works together with the c-compiler selected for Python may be overkill too. Maybe try only standard combinations cc/c++ gcc/g++ and otherwise require --with{out}-cxx? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1324762&group_id=5470 From noreply at sourceforge.net Fri Nov 25 18:02:55 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 25 Nov 2005 09:02:55 -0800 Subject: [Patches] [ python-Patches-1364545 ] test_cmd_line expecting English error messages Message-ID: Patches item #1364545, was opened at 2005-11-23 12:01 Message generated for change (Settings changed) made by doerwalter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1364545&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Tests Group: Python 2.5 >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: A.B., Khalid (abkhd) >Assigned to: Nobody/Anonymous (nobody) Summary: test_cmd_line expecting English error messages Initial Comment: Currently test_directories of test_cmd_line fails on the latest Python 2.4.2 from svn branch and from the svn head. The reason it seems is that the test assumes that the local language of Windows is English and so tries to find the string " denied" in the returned system error messages of the commands ("python .") and ("python < ."). But while it is true that the first command ("python .") does return an English string error message even on so-called non-English versions of Windows, the same does not seem to be true for the second command ("python < ."), which seems to return a locale-related string error message. And since the latter test is looking for the English " denied" in a non-English language formated string, the test fails in non-English versions of Windows. Walter asked me to post the patch here, and assign it to him. The patch uses subprocess and uses exitcodes for testing. I tested the patch successfully, but only on Windows. Although subprocess is supposed to work on all platforms, someone'd better test this just to be sure. I don't know what the policy for backporting is. But if allowed, this should be backported to Python 2.4.2 at least. ---------------------------------------------------------------------- >Comment By: Walter D?rwald (doerwalter) Date: 2005-11-25 18:02 Message: Logged In: YES user_id=89016 Checked in a variant of abkhd's patch as r41541 and r41542. Thanks for the patch. ---------------------------------------------------------------------- Comment By: A.B., Khalid (abkhd) Date: 2005-11-23 17:56 Message: Logged In: YES user_id=1079026 Forgot to say the patch is attached. ---------------------------------------------------------------------- Comment By: A.B., Khalid (abkhd) Date: 2005-11-23 17:53 Message: Logged In: YES user_id=1079026 Well we seem to have two problems here. The first is the one you changed subprocess' call arguments to avoid as it seems Windows/Linux or subprocess deal with string arguments differently. The second, which is more serious in my view, is how "python ." yeilds an error on Windows, but no error at all on Linux. If other platform behave the same then why is there a need for this test? If the difference is just between these two platforms then I think we can manage with hardcoding the exit codes. Ugly, yes. But it works. #------------------------- # On Windows #------------------------- $ python -i Python 2.5a0 (#66, Nov 22 2005, 23:25:46) [GCC 3.4.2 (mingw-special)] on win32 Type "help", "copyright", "credits" or "license" for more information. >>> import test_cmd_line as t >>> t.test_main() test_directories (test_cmd_line.CmdLineTest) ... ok test_environment (test_cmd_line.CmdLineTest) ... ok test_optimize (test_cmd_line.CmdLineTest) ... ok test_q (test_cmd_line.CmdLineTest) ... ok test_site_flag (test_cmd_line.CmdLineTest) ... ok test_usage (test_cmd_line.CmdLineTest) ... ok test_version (test_cmd_line.CmdLineTest) ... ok ---------------------------------------------------------------------- Ran 7 tests in 6.750s OK >>> #------------------------- # On Linux #------------------------- ubuntu at ubuntu:~/Desktop$ python Python 2.4.1 (#2, Mar 30 2005, 21:51:10) [GCC 3.3.5 (Debian 1:3.3.5-8ubuntu2)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> import test_cmd_line as t >>> t.test_main() test_directories (test_cmd_line.CmdLineTest) ... ok test_environment (test_cmd_line.CmdLineTest) ... ok test_optimize (test_cmd_line.CmdLineTest) ... ok test_q (test_cmd_line.CmdLineTest) ... ok test_site_flag (test_cmd_line.CmdLineTest) ... ok test_usage (test_cmd_line.CmdLineTest) ... ok test_version (test_cmd_line.CmdLineTest) ... ok ---------------------------------------------------------------------- Ran 7 tests in 1.701s OK >>> ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2005-11-23 13:28 Message: Logged In: YES user_id=89016 The test doesn't work on Linux. I get: Traceback (most recent call last): File "Lib/test/test_cmd_line.py", line 19, in test_directories self.assertTrue(self.exit_code('.') != 0) File "Lib/test/test_cmd_line.py", line 16, in exit_code return subprocess.call("%s %s" % (sys.executable, cmd_line), stderr=subprocess.PIPE) File "/var/home/walter/Python-checkouts/Python-unittest/Lib/subprocess.py", line 431, in call return Popen(*popenargs, **kwargs).wait() File "/var/home/walter/Python-checkouts/Python-unittest/Lib/subprocess.py", line 580, in __init__ errread, errwrite) File "/var/home/walter/Python-checkouts/Python-unittest/Lib/subprocess.py", line 1033, in _execute_child raise child_exception OSError: [Errno 2] No such file or directory Changing call("%s %s" % (sys.executable, cmd_line), stderr=PIPE) to call([sys.executable, cmd_line], stderr=PIPE) leads to Traceback (most recent call last): File "Lib/test/test_cmd_line.py", line 22, in test_directories self.assertTrue(self.exit_code('.') != 0) AssertionError Is there anything else I can try? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1364545&group_id=5470 From noreply at sourceforge.net Fri Nov 25 18:19:35 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 25 Nov 2005 09:19:35 -0800 Subject: [Patches] [ python-Patches-1364946 ] Add reference for en/decode error types Message-ID: Patches item #1364946, was opened at 2005-11-23 20:33 Message generated for change (Comment added) made by doerwalter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1364946&group_id=5470 Please note that this 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: Fixed Priority: 5 Submitted By: Wummel (calvin) Assigned to: Nobody/Anonymous (nobody) Summary: Add reference for en/decode error types Initial Comment: The string methods encode() and decode() can specify the error handling type. This patch adds a reference link to the definition of the default types to the documentation. ---------------------------------------------------------------------- >Comment By: Walter D?rwald (doerwalter) Date: 2005-11-25 18:19 Message: Logged In: YES user_id=89016 Looks good to me. Checked in as r41543 and r41544. Thanks for the patch. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1364946&group_id=5470 From noreply at sourceforge.net Sat Nov 26 12:39:38 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 26 Nov 2005 03:39:38 -0800 Subject: [Patches] [ python-Patches-1227966 ] solaris 10 should not define _XOPEN_SOURCE_EXTENDED Message-ID: Patches item #1227966, was opened at 2005-06-27 02:32 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1227966&group_id=5470 Please note that this 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: Accepted Priority: 5 Submitted By: Bill Clarke (slashlib) Assigned to: Nobody/Anonymous (nobody) Summary: solaris 10 should not define _XOPEN_SOURCE_EXTENDED Initial Comment: on Solaris 10, defining _XOPEN_SOURCE_EXTENDED implies a maximum _XPG specification of _XPG4v2. what we want is _XPG5. note: see also bug 1116722 , _XOPEN_SOURCE must be 500 for Solaris 10. the effect of this bug is that we cannot build python modules with g++. e.g., with this file: """ #include "Python.h" #include """" you get errors like this: """ $ g++ -m64 -I/usr/local/64/include/python2.4 -c test.cc In file included from /usr/local/64/include/python2.4/Python.h:8, from test.cc:1: /usr/local/64/include/python2.4/pyconfig.h:844:1: warning: "_XOPEN_SOURCE" redefined :84:1: warning: this is the location of the previous definition In file included from test.cc:2: [...]../include/c++/3.4.4/cwchar:145: error: `::btowc' has not been declared [...]../include/c++/3.4.4/cwchar:150: error: `::fwide' has not been declared ... """ a patch for configure.in (against 2.4.1) is attached to fix this. ---------------------------------------------------------------------- >Comment By: Martin v. L?wis (loewis) Date: 2005-11-26 12:39 Message: Logged In: YES user_id=21627 Thanks for the patch. Committed as 41545 and 41546. It complained to me that XPG6 requires a C99 compile, hence I limited _XOPEN_SOURCE to 500 as well. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1227966&group_id=5470 From noreply at sourceforge.net Sat Nov 26 12:40:47 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 26 Nov 2005 03:40:47 -0800 Subject: [Patches] [ python-Patches-1116722 ] Solaris 10 fails to compile complexobject.c [FIX incl.] Message-ID: Patches item #1116722, was opened at 2005-02-05 08:02 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1116722&group_id=5470 Please note that this 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: Case Van Horsen (casevh) Assigned to: Martin v. L?wis (loewis) Summary: Solaris 10 fails to compile complexobject.c [FIX incl.] Initial Comment: This is a duplicate of 970334. The fix I used was to make the following change in pyport.h: Change #define Py_HUGE_VAL HUGE_VAL to #define PY_HUGE_VAL DBL_MAX. DBL_MAX is found in float.h Versions used: Python 2.4 gcc 3.4.3 Solaris 10 x86 GA release. ---------------------------------------------------------------------- >Comment By: Martin v. L?wis (loewis) Date: 2005-11-26 12:40 Message: Logged In: YES user_id=21627 This is now fixed as a side effect of 41546 and 41545: _XOPEN_SOURCE is restricted to 500 on Solaris 10, causing math_c99.h not to be used. ---------------------------------------------------------------------- Comment By: Case Van Horsen (casevh) Date: 2005-06-28 07:43 Message: Logged In: YES user_id=1212585 GCC 3.4.3 is shipped with Solaris 10. I think it would be unfortunate to mandate GCC 3.4.5 or 4.0.1. At my real job, requiring a different version of GCC would be unacceptable. Comments in the README file documenting the problem and listing the word-arounds would be acceptable. I would be willing to write a draft version of the comments. BTW, OpenSolaris and the latest Solaris Express releases from Sun report the OS version as 5.11 and still come with GCC 3.4.3. Some intervening versions report themselves as 5.10.1. Sun's Studio 10 compiler is available for free for use with OpenSolaris and it does compile python properly as is. ---------------------------------------------------------------------- Comment By: Bill Clarke (slashlib) Date: 2005-06-27 02:38 Message: Logged In: YES user_id=421902 >For the specific bug reported in this report (Py_HUGE_VAL > HUGE_VAL), I would like to close this as a third-party bug, > and mandate that GCC users use 3.4.5 or 4.0.1 on Solaris 10. sounds fine to me, except neither of those versions have been released yet (-: > slashlib: this bug is only about the HUGE_VAL problem. If > additional problems exist, please report them in a separate > report. my apologies. new bug report is 1227966 ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2005-06-26 20:33 Message: Logged In: YES user_id=21627 For the specific bug reported in this report (Py_HUGE_VAL HUGE_VAL), I would like to close this as a third-party bug, and mandate that GCC users use 3.4.5 or 4.0.1 on Solaris 10. However, it appears that the original problem (of g++ pre-defining _XOPEN_SOURCE) also persists. So we just extend the existing configure test to 5.10. slashlib: this bug is only about the HUGE_VAL problem. If additional problems exist, please report them in a separate report. ---------------------------------------------------------------------- Comment By: Bill Clarke (slashlib) Date: 2005-06-23 10:10 Message: Logged In: YES user_id=421902 to fix the XOPEN_SOURCE problem on Solaris 10 (and hence to be able to compile python modules with g++) you must _not_ define _XOPEN_SOURCE_EXTENDED. XOPEN_SOURCE must be 500 as well. here's a patch for configure.in for the XOPEN_SOURCE_EXTENDED change: """ --- configure.in~ 2005-03-29 09:23:34.000000000 +1000 +++ configure.in 2005-06-23 18:00:39.596747000 +1000 @@ -198,8 +198,15 @@ # definition of _XOPEN_SOURCE_EXTENDED and _POSIX_C_SOURCE, or else # several APIs are not declared. Since this is also needed in some # cases for HP-UX, we define it globally. - - AC_DEFINE(_XOPEN_SOURCE_EXTENDED, 1, Define to activate Unix95-and-earlier features) + # except for Solaris 10, where it must not be defined! + case $ac_sys_system/$ac_sys_release in + SunOS/5.10) + ;; + *) + AC_DEFINE(_XOPEN_SOURCE_EXTENDED, 1, + Define to activate Unix95-and-earlier features) + ;; + esac AC_DEFINE(_POSIX_C_SOURCE, 200112L, Define to activate features from IEEE Stds 1003.1-2001) """ this fix (along with _XOPEN_SOURCE == 500) means i can compile python modules with g++ now. yay! also note: Solaris 10's feature_tests header will override the setting of _POSIX_C_SOURCE (to 199506L) since _XOPEN_SOURCE is 500. from my reading, _POSIX_C_SOURCE should only be 200112L if _XOPEN_SOURCE is 600, so perhaps the _POSIX_C_SOURCE define should also be disabled for Solaris 10 (although this will make no material difference usually). ---------------------------------------------------------------------- Comment By: Bill Clarke (slashlib) Date: 2005-06-23 08:50 Message: Logged In: YES user_id=421902 i should clarify my comments, the thing that was recently fixed in gcc is the HUGE_VAL problem, not the XOPEN_SOURCE problem. note: an easy test for the XOPEN_SOURCE problem with g++ is: """ #include #include """ ---------------------------------------------------------------------- Comment By: Case Van Horsen (casevh) Date: 2005-06-23 07:35 Message: Logged In: YES user_id=1212585 "make testall" fails with an error in _curses: missing typeahead(). I don't know it that is normal or not. I will try some additional tests this weekend, including using the new iso/math_c99.h file. A more subtle issue is that some of the the Solaris Express releases identified themselves as 5.10.1 and the latest Solaris Express (and I believe OpenSolaris) identify themselves as 5.11 and will probably use 5.11.x in the future. I will try to upgrade to the latest Solaris Express release this weekend and report how that behaves. ---------------------------------------------------------------------- Comment By: Bill Clarke (slashlib) Date: 2005-06-23 06:54 Message: Logged In: YES user_id=421902 i hit this bug too. this has been fixed in gcc (will be in gcc 3.4.5 and 4.0.1). to workaround with (say) an installed gcc 3.4.4 build current gcc 3.4 cvs and copy the fixed iso/math_c99.h file from the build to the installed gcc fixed includes directory. ---------------------------------------------------------------------- Comment By: Anthony Baxter (anthonybaxter) Date: 2005-06-22 16:47 Message: Logged In: YES user_id=29957 I haven't had time to try installing Solaris 10 on anything yet - does setting _XOPEN_SOURCE in this way break anything else? (does make testall complete ok?) If you could confirm it doesn't break anything else, I'll make the change for 2.5 and 2.4.2... ---------------------------------------------------------------------- Comment By: Case Van Horsen (casevh) Date: 2005-03-19 07:06 Message: Logged In: YES user_id=1212585 I found a reference in the 2.4a3 release notes that this problem was fixed for Solaris 8 and 9 with Patch #1006629. That patch set _XOPEN_SOURCE to 500. Using 2.4.1c2 source, I patched line 1521 from SunOS/5.8|SunOS/5.9) to SunOS/5.8|SunOS/5.9|SunOS/5.10) I successfully completed a make; make test with a generic Solaris 10 x86 install. I verified that it failed without the patch. ---------------------------------------------------------------------- Comment By: Case Van Horsen (casevh) Date: 2005-03-04 23:28 Message: Logged In: YES user_id=1212585 Below is the official response from Sun. It doesn't look like Sun sees it as a problem. Document Audience: SPECTRUM Document ID: 6173815 Title: bug 6173815 Synopsis: POSSIBLE ERROR AT /USR/INCLUDE/ISO/MATH_C99.H LINE 24 Update Date: Tue Oct 05 06:44:47 MDT 2004 Bug ID: 6173815 Synopsis: POSSIBLE ERROR AT /USR/INCLUDE/ISO/MATH_C99.H LINE 24 Category: c++ Subcategory: compiler State: 11-Closed Description: * * This is a problem I ran into trying to compile Python 2.3.4 on a Solaris * 10 beta 63 (x86) system. I worked with Martin v. Lowis * to isolate the problem as it affects Python, but our * conclusion is that this is really a GCC/Solaris problem. * * -- Chris Wicklein * * ---------------------------------------- * * $ uname -a * SunOS solaris1 5.10 s10_63 i86pc i386 i86pc * * $ gcc -v * Reading specs from /opt/gcc/lib/gcc/i386-pc- solaris2.10/3.4.2/specs * Configured with: ../gcc-3.4.2/configure --with- as=/usr/ccs/bin/as --with-ld=/usr/ccs/bin/ld --disable-nls -- prefix=/opt/gcc * Thread model: posix * gcc version 3.4.2 * * $ gcc -o foo foo.c * * $ gcc -D_STDC_C99 -o foo foo.c * foo.c: In function `main': * foo.c:26: error: invalid operands to binary == * * $ gcc -D_STDC_C99 -o foo foo.c --save-temps * foo.c: In function `main': * foo.c:26: error: invalid operands to binary == * * $ grep __builtin_huge_val foo.i * if (x == __builtin_huge_val) { * * ---------------------------------------- * The problem for GCC is having HUGE_VAL expanded to __builtin_huge_val * (pointer to a function returning a double) rather than to * __builtin_huge_val() (call to a function returning a double.) * * Is this an error in the header file /usr/include/iso/math_c99.h * or something that was done intentionally to support the * Sun ONE compiler? (Is this something for Sun to fix, or should * this be addressed on the GCC end?) */ #include int main (int argc, char **argv) { double x = 3.14; if (x == HUGE_VAL) { x = 2.7; } return 0; } Customer comments: It is my understanding that HUGE_VAL is a standard C feature, and the function __builtin_huge_val() is a GCC- specific extension for implementing this standard C feature. If this is correct, then by referencing __builtin_huge_val in /usr/include/iso/math_c99.h, Solaris 10 is providing GCC- specific header support. (As an aside, it's remotely possible that my copy of math_c99.h was locally modified as part of installing GCC from a third-party package, but I doubt this happened.) Assuming then that Solaris 10 is providing support for a GCC- specific built-in function (__builtin_huge_val) in math_c99.h, then that support should be corrected (by adding the missing parens.) Otherwise, it will be necessary for GCC to work- around this header problem. Here then is the crux of the matter: assuming that math_c99.h contains this reference to __builtin_huge_val without the required parens, was this done to support GCC, or is this also used by the Sun Pro compiler? If this is present only for GCC, then the missing parens should be added by Sun, or I would like to know that Sun sees this as not-a-bug, in which case GCC will have to work around this itself. At any rate, I am not requesting support for GCC, but rather trying to understand 1) why math_c99.h references __builtin_huge_val as it does in Solaris 10, and 2) if this is something Sun views as a problem on the Solaris side to be fixed. > HI Chris, > > We do not support gcc A third-party C compiler; not supported. > ---------------------------------------------------------------------- Comment By: Case Van Horsen (casevh) Date: 2005-03-04 23:26 Message: Logged In: YES user_id=1212585 Below is the official response from Sun. It doesn't look like Sun sees it as a problem. Document Audience: SPECTRUM Document ID: 6173815 Title: bug 6173815 Synopsis: POSSIBLE ERROR AT /USR/INCLUDE/ISO/MATH_C99.H LINE 24 Update Date: Tue Oct 05 06:44:47 MDT 2004 Bug ID: 6173815 Synopsis: POSSIBLE ERROR AT /USR/INCLUDE/ISO/MATH_C99.H LINE 24 Category: c++ Subcategory: compiler State: 11-Closed Description: * * This is a problem I ran into trying to compile Python 2.3.4 on a Solaris * 10 beta 63 (x86) system. I worked with Martin v. Lowis * to isolate the problem as it affects Python, but our * conclusion is that this is really a GCC/Solaris problem. * * -- Chris Wicklein * * ---------------------------------------- * * $ uname -a * SunOS solaris1 5.10 s10_63 i86pc i386 i86pc * * $ gcc -v * Reading specs from /opt/gcc/lib/gcc/i386-pc- solaris2.10/3.4.2/specs * Configured with: ../gcc-3.4.2/configure --with- as=/usr/ccs/bin/as --with-ld=/usr/ccs/bin/ld --disable-nls -- prefix=/opt/gcc * Thread model: posix * gcc version 3.4.2 * * $ gcc -o foo foo.c * * $ gcc -D_STDC_C99 -o foo foo.c * foo.c: In function `main': * foo.c:26: error: invalid operands to binary == * * $ gcc -D_STDC_C99 -o foo foo.c --save-temps * foo.c: In function `main': * foo.c:26: error: invalid operands to binary == * * $ grep __builtin_huge_val foo.i * if (x == __builtin_huge_val) { * * ---------------------------------------- * The problem for GCC is having HUGE_VAL expanded to __builtin_huge_val * (pointer to a function returning a double) rather than to * __builtin_huge_val() (call to a function returning a double.) * * Is this an error in the header file /usr/include/iso/math_c99.h * or something that was done intentionally to support the * Sun ONE compiler? (Is this something for Sun to fix, or should * this be addressed on the GCC end?) */ #include int main (int argc, char **argv) { double x = 3.14; if (x == HUGE_VAL) { x = 2.7; } return 0; } Customer comments: It is my understanding that HUGE_VAL is a standard C feature, and the function __builtin_huge_val() is a GCC- specific extension for implementing this standard C feature. If this is correct, then by referencing __builtin_huge_val in /usr/include/iso/math_c99.h, Solaris 10 is providing GCC- specific header support. (As an aside, it's remotely possible that my copy of math_c99.h was locally modified as part of installing GCC from a third-party package, but I doubt this happened.) Assuming then that Solaris 10 is providing support for a GCC- specific built-in function (__builtin_huge_val) in math_c99.h, then that support should be corrected (by adding the missing parens.) Otherwise, it will be necessary for GCC to work- around this header problem. Here then is the crux of the matter: assuming that math_c99.h contains this reference to __builtin_huge_val without the required parens, was this done to support GCC, or is this also used by the Sun Pro compiler? If this is present only for GCC, then the missing parens should be added by Sun, or I would like to know that Sun sees this as not-a-bug, in which case GCC will have to work around this itself. At any rate, I am not requesting support for GCC, but rather trying to understand 1) why math_c99.h references __builtin_huge_val as it does in Solaris 10, and 2) if this is something Sun views as a problem on the Solaris side to be fixed. > HI Chris, > > We do not support gcc A third-party C compiler; not supported. > ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2005-03-04 20:04 Message: Logged In: YES user_id=21627 Turns out casevh's report is http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19933 ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2005-03-04 15:18 Message: Logged In: YES user_id=21627 I have now reported this bug to gcc as http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20317 ---------------------------------------------------------------------- Comment By: Case Van Horsen (casevh) Date: 2005-02-11 07:33 Message: Logged In: YES user_id=1212585 Oops. I made a typo in one of my tests. It does include in /include/iso/math_c99.h when you type it correctly. I will work with Sun / gcc to determine a resolution. ---------------------------------------------------------------------- Comment By: Case Van Horsen (casevh) Date: 2005-02-11 07:03 Message: Logged In: YES user_id=1212585 I poked around in the preprocessor outputs and it appears gcc doesn't its specific directory for math_c99.h. It only appears to look in /usr/include/iso. I changed the definition of HUGE_VAL in /usr/include/iso/math_c99.h to read: #define HUGE_VAL __builtin_huge_val() The hv2.c compiled completely and so did Python 2.4. I'll open a bug report with GCC and also with Sun since I used the version of GCC that was distributed by Sun. ---------------------------------------------------------------------- Comment By: Case Van Horsen (casevh) Date: 2005-02-11 06:16 Message: Logged In: YES user_id=1212585 I ran mkheaders to rebuild the gcc headers but that made no difference. The following program (hv.c) compiled correctly: #define _XOPEN_SOURCE 500 #include int main() { double f=HUGE_VAL; } The following program (hv2.c) did not compile. #define _XOPEN_SOURCE 1000 #include int main() { double f=HUGE_VAL; } Output is: $ gcc --save-temps hv.c $ gcc --save-temp hv2.c hv2.c: In function `main': hv2.c:5: error: incompatible types in initialization $ I have attached hv.i and hv2.i. I have also attached complexobject.i I'm not a C programmer so please let me know what else I can do to help. ---------------------------------------------------------------------- Comment By: Case Van Horsen (casevh) Date: 2005-02-10 17:50 Message: Logged In: YES user_id=1212585 I tried steps 1 through 4 and it fails, with and with the (). I'm not sure how to do step 5. I will try the short program snippet later and report back. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2005-02-10 05:44 Message: Logged In: YES user_id=31435 Doubt this will help: googling suggests that -Xc has to be passed to Sun's native C compiler to get HUGE_VAL defined correctly. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2005-02-10 04:23 Message: Logged In: YES user_id=21627 I have the Solaris 10 iso/math_c99.h in front of me, but no gcc, so it is somewhat difficult to get through the ifdefery. It appears that we should have _XOPEN_SOURCE - 0 >= 600, so we should be using #define HUGE_VAL __builtin_huge_val The problem apparently is that in Sun CC, __builtin_huge_val appears to be a constant, whereas in gcc, it probably is a function, so the definition should read #define HUGE_VAL __builtin_huge_val() So there is a bug in the gcc port of Solaris here - fixincludes should adjust the definition of HUGE_VAL when installing its adjusted copy of math_c99.h. I'm willing to accept patches to work around this gcc bug, but only if the bug gets reported to gcc first. So, please, 1. find out the gcc installation directory on your system, using gcc --print-search-dirs 2a. check whether /include/iso/math_c99.h exists 2b. if it does not exist, copy if from /usr/include/iso/math_c99.h 3. edit /include/iso/math_c99.h to add the parentheses after builtin_huge_val 4. check whether this fixes the problem 5a. if not, provide the preprocessor output for complexobject.i, using --save-temps 5b. if it does, make a bug report to gcc, indicating that the program #include int main() { double f=HUGE_VAL; } fails on Solaris 10. For that report - check whether it actually fails without the update math_c99, and succeeds with it (you might have to #define _XOPEN_SOURCE to make it fail) - include the preprocessor output for this sample program, using the original math_c99 - indicate that a solution is to add parentheses 6. Come up with a patch that checks for Solaris 10 and all gcc versions showing the problem (i.e. 3.4.x, with x<=3, perhaps also 3.y, y<=3), and defines Py_HUGE_VAL correctly for this system. 7. Report the gcc bug number and the patch in this report. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2005-02-10 02:43 Message: Logged In: YES user_id=31435 The C standard requires that "The macro HUGE_VAL expands to a positive double constant expression, not necessarily representable as a float". Python requires that too. #define'ing to worm around a broken compilation environment isn't acceptable to me; finding a switch to make this environment conform to the standard would be OK. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1116722&group_id=5470 From bethfnaq at imacinc.com Sun Nov 27 12:31:01 2005 From: bethfnaq at imacinc.com (Dewey Bradford) Date: Sun, 27 Nov 2005 06:31:01 -0500 Subject: [Patches] Ref. Registration notification # 820665793046086. all Message-ID: <5282815875.8440547032@imacinc.com> Just start 0ut $crewy cata10gue of y*ung gir1$ Unb0unded list of grotesque bonk http://nahevypopou.net S>> coit luruw ndhz on 34085 S>> miracles unless trolio everybody eastern S>> itself rmino electrodepos earg some vogtland From noreply at sourceforge.net Sun Nov 27 17:38:17 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 27 Nov 2005 08:38:17 -0800 Subject: [Patches] [ python-Patches-955928 ] use PyOS_ReadlineFunctionPointer in non-interractive input Message-ID: Patches item #955928, was opened at 2004-05-18 15:41 Message generated for change (Settings changed) made by greglielens You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=955928&group_id=5470 Please note that this 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: Duplicate Priority: 5 Submitted By: Gregory Lielens (greglielens) Assigned to: Martin v. L?wis (loewis) Summary: use PyOS_ReadlineFunctionPointer in non-interractive input Initial Comment: Extend the control provided by PyOS_ReadlineFunctionPointer to non-interractive inputs. In addition, initialize PyOS_ReadlineFunctionPointer to the default input function, so that it can be retrieved by extern code (allowing for embedding the old input function and modifying it). Readline Module changed accordingly (only modify PyOS_ReadlineFunctionPointer to call_readline if input is interractive). This was neccessary to modify the input behavior of PyRun_InteractiveLoop, in case input is not interractive... The application is a python driven parallel framework using MPI, where the interractive process broadcast the input lines to the non-interractive processes, who listen...but other applications may benefit also. patched: Modules/readline.c Parser/myreadline.c ---------------------------------------------------------------------- Comment By: Gregory Lielens (greglielens) Date: 2004-08-13 10:52 Message: Logged In: YES user_id=1044428 Hi, as you are the last one which has worked on this subject, I think it is best I reassign this patch to you. As you will see from my discussion with mwh, the main point of these modif is to remove the test of the interractiveness of stdin/stdout that prevent the use of PyOS_ReadlineFunctionPointer when one is not interactive... Hope this re-assignment is not rude, I do not know well python development group usage in this matter... Best regards, Greg ---------------------------------------------------------------------- Comment By: Gregory Lielens (greglielens) Date: 2004-08-05 14:02 Message: Logged In: YES user_id=1044428 I edited the patch to comply with the tab style (or hope so). For the reverse, I used cvs diff -c and assumed it would produce it in the correct order, is it not the case? Anyway, here is the new patch... (If it is still reversed and you have a special option for cvs diff to produce the patch in correct order, I am very interrested! ;-) ) Regarding the origin of the tty test, it is done (at least for the stdin) since the first revision that used a mechanism similar to the current one (PyOS_ReadlineFunctionPointer), and this was done by Guido (r2.11) The test was removed just after (r2.12, again guido), and finally re-introduced in it's final form in revision 2.28, by loewis. Maybe I can assign him so that he gives us a idea of the intention of this, and his feeling about this patch? ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2004-08-05 13:21 Message: Logged In: YES user_id=6656 Uh, no, scratch that: I think your attempt to upload a new patch failed. Try again? ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2004-08-05 13:11 Message: Logged In: YES user_id=6656 A chance, yes. I'm a bit loath to change this, as I have no idea why things were done this way in the first place. If it's the traditional "no good reason", then I guess this can go in... Also, I think your patch is backwards and doesn't adhere to the local style wrt tabs and spaces. ---------------------------------------------------------------------- Comment By: Gregory Lielens (greglielens) Date: 2004-08-05 09:56 Message: Logged In: YES user_id=1044428 I updated the patch to python current CVS, and do similar modification in /Python/bltinmodule.c for builtin_raw_input fonction. builtin_raw_input now call PyOS_Readline when stdin and stdout objects are file, regardless if they are tty or not. This one was forgotten in the first version of the patch, and is needed to be able to use the same broadcasting technique for parrallel interractive session when using IPython. I now think that all functions implementing possibly interractive input have been patched... All regression tests pass except test_grp and test_pwd, but those fail exactly the same way (KeyError) with non-patched cvs... Any chance to have this considered for 2.4? Regards, Greg. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=955928&group_id=5470 From noreply at sourceforge.net Sun Nov 27 17:39:35 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 27 Nov 2005 08:39:35 -0800 Subject: [Patches] [ python-Patches-955928 ] use PyOS_ReadlineFunctionPointer in non-interractive input Message-ID: Patches item #955928, was opened at 2004-05-18 15:41 Message generated for change (Settings changed) made by greglielens You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=955928&group_id=5470 Please note that this 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: Closed Resolution: Duplicate Priority: 5 Submitted By: Gregory Lielens (greglielens) Assigned to: Martin v. L?wis (loewis) Summary: use PyOS_ReadlineFunctionPointer in non-interractive input Initial Comment: Extend the control provided by PyOS_ReadlineFunctionPointer to non-interractive inputs. In addition, initialize PyOS_ReadlineFunctionPointer to the default input function, so that it can be retrieved by extern code (allowing for embedding the old input function and modifying it). Readline Module changed accordingly (only modify PyOS_ReadlineFunctionPointer to call_readline if input is interractive). This was neccessary to modify the input behavior of PyRun_InteractiveLoop, in case input is not interractive... The application is a python driven parallel framework using MPI, where the interractive process broadcast the input lines to the non-interractive processes, who listen...but other applications may benefit also. patched: Modules/readline.c Parser/myreadline.c ---------------------------------------------------------------------- Comment By: Gregory Lielens (greglielens) Date: 2004-08-13 10:52 Message: Logged In: YES user_id=1044428 Hi, as you are the last one which has worked on this subject, I think it is best I reassign this patch to you. As you will see from my discussion with mwh, the main point of these modif is to remove the test of the interractiveness of stdin/stdout that prevent the use of PyOS_ReadlineFunctionPointer when one is not interactive... Hope this re-assignment is not rude, I do not know well python development group usage in this matter... Best regards, Greg ---------------------------------------------------------------------- Comment By: Gregory Lielens (greglielens) Date: 2004-08-05 14:02 Message: Logged In: YES user_id=1044428 I edited the patch to comply with the tab style (or hope so). For the reverse, I used cvs diff -c and assumed it would produce it in the correct order, is it not the case? Anyway, here is the new patch... (If it is still reversed and you have a special option for cvs diff to produce the patch in correct order, I am very interrested! ;-) ) Regarding the origin of the tty test, it is done (at least for the stdin) since the first revision that used a mechanism similar to the current one (PyOS_ReadlineFunctionPointer), and this was done by Guido (r2.11) The test was removed just after (r2.12, again guido), and finally re-introduced in it's final form in revision 2.28, by loewis. Maybe I can assign him so that he gives us a idea of the intention of this, and his feeling about this patch? ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2004-08-05 13:21 Message: Logged In: YES user_id=6656 Uh, no, scratch that: I think your attempt to upload a new patch failed. Try again? ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2004-08-05 13:11 Message: Logged In: YES user_id=6656 A chance, yes. I'm a bit loath to change this, as I have no idea why things were done this way in the first place. If it's the traditional "no good reason", then I guess this can go in... Also, I think your patch is backwards and doesn't adhere to the local style wrt tabs and spaces. ---------------------------------------------------------------------- Comment By: Gregory Lielens (greglielens) Date: 2004-08-05 09:56 Message: Logged In: YES user_id=1044428 I updated the patch to python current CVS, and do similar modification in /Python/bltinmodule.c for builtin_raw_input fonction. builtin_raw_input now call PyOS_Readline when stdin and stdout objects are file, regardless if they are tty or not. This one was forgotten in the first version of the patch, and is needed to be able to use the same broadcasting technique for parrallel interractive session when using IPython. I now think that all functions implementing possibly interractive input have been patched... All regression tests pass except test_grp and test_pwd, but those fail exactly the same way (KeyError) with non-patched cvs... Any chance to have this considered for 2.4? Regards, Greg. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=955928&group_id=5470 From noreply at sourceforge.net Sun Nov 27 17:45:06 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 27 Nov 2005 08:45:06 -0800 Subject: [Patches] [ python-Patches-955928 ] use PyOS_ReadlineFunctionPointer in non-interractive input Message-ID: Patches item #955928, was opened at 2004-05-18 15:41 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=955928&group_id=5470 Please note that this 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: Closed Resolution: Duplicate Priority: 5 Submitted By: Gregory Lielens (greglielens) Assigned to: Martin v. L?wis (loewis) Summary: use PyOS_ReadlineFunctionPointer in non-interractive input Initial Comment: Extend the control provided by PyOS_ReadlineFunctionPointer to non-interractive inputs. In addition, initialize PyOS_ReadlineFunctionPointer to the default input function, so that it can be retrieved by extern code (allowing for embedding the old input function and modifying it). Readline Module changed accordingly (only modify PyOS_ReadlineFunctionPointer to call_readline if input is interractive). This was neccessary to modify the input behavior of PyRun_InteractiveLoop, in case input is not interractive... The application is a python driven parallel framework using MPI, where the interractive process broadcast the input lines to the non-interractive processes, who listen...but other applications may benefit also. patched: Modules/readline.c Parser/myreadline.c ---------------------------------------------------------------------- >Comment By: Martin v. L?wis (loewis) Date: 2005-11-27 17:45 Message: Logged In: YES user_id=21627 I don't consider this assignment rude, but I don't think I can do much about this patch for the next few months, either. ---------------------------------------------------------------------- Comment By: Gregory Lielens (greglielens) Date: 2004-08-13 10:52 Message: Logged In: YES user_id=1044428 Hi, as you are the last one which has worked on this subject, I think it is best I reassign this patch to you. As you will see from my discussion with mwh, the main point of these modif is to remove the test of the interractiveness of stdin/stdout that prevent the use of PyOS_ReadlineFunctionPointer when one is not interactive... Hope this re-assignment is not rude, I do not know well python development group usage in this matter... Best regards, Greg ---------------------------------------------------------------------- Comment By: Gregory Lielens (greglielens) Date: 2004-08-05 14:02 Message: Logged In: YES user_id=1044428 I edited the patch to comply with the tab style (or hope so). For the reverse, I used cvs diff -c and assumed it would produce it in the correct order, is it not the case? Anyway, here is the new patch... (If it is still reversed and you have a special option for cvs diff to produce the patch in correct order, I am very interrested! ;-) ) Regarding the origin of the tty test, it is done (at least for the stdin) since the first revision that used a mechanism similar to the current one (PyOS_ReadlineFunctionPointer), and this was done by Guido (r2.11) The test was removed just after (r2.12, again guido), and finally re-introduced in it's final form in revision 2.28, by loewis. Maybe I can assign him so that he gives us a idea of the intention of this, and his feeling about this patch? ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2004-08-05 13:21 Message: Logged In: YES user_id=6656 Uh, no, scratch that: I think your attempt to upload a new patch failed. Try again? ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2004-08-05 13:11 Message: Logged In: YES user_id=6656 A chance, yes. I'm a bit loath to change this, as I have no idea why things were done this way in the first place. If it's the traditional "no good reason", then I guess this can go in... Also, I think your patch is backwards and doesn't adhere to the local style wrt tabs and spaces. ---------------------------------------------------------------------- Comment By: Gregory Lielens (greglielens) Date: 2004-08-05 09:56 Message: Logged In: YES user_id=1044428 I updated the patch to python current CVS, and do similar modification in /Python/bltinmodule.c for builtin_raw_input fonction. builtin_raw_input now call PyOS_Readline when stdin and stdout objects are file, regardless if they are tty or not. This one was forgotten in the first version of the patch, and is needed to be able to use the same broadcasting technique for parrallel interractive session when using IPython. I now think that all functions implementing possibly interractive input have been patched... All regression tests pass except test_grp and test_pwd, but those fail exactly the same way (KeyError) with non-patched cvs... Any chance to have this considered for 2.4? Regards, Greg. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=955928&group_id=5470 From noreply at sourceforge.net Sun Nov 27 17:45:47 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 27 Nov 2005 08:45:47 -0800 Subject: [Patches] [ python-Patches-955928 ] use PyOS_ReadlineFunctionPointer in non-interractive input Message-ID: Patches item #955928, was opened at 2004-05-18 15:41 Message generated for change (Settings changed) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=955928&group_id=5470 Please note that this 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: Gregory Lielens (greglielens) Assigned to: Martin v. L?wis (loewis) Summary: use PyOS_ReadlineFunctionPointer in non-interractive input Initial Comment: Extend the control provided by PyOS_ReadlineFunctionPointer to non-interractive inputs. In addition, initialize PyOS_ReadlineFunctionPointer to the default input function, so that it can be retrieved by extern code (allowing for embedding the old input function and modifying it). Readline Module changed accordingly (only modify PyOS_ReadlineFunctionPointer to call_readline if input is interractive). This was neccessary to modify the input behavior of PyRun_InteractiveLoop, in case input is not interractive... The application is a python driven parallel framework using MPI, where the interractive process broadcast the input lines to the non-interractive processes, who listen...but other applications may benefit also. patched: Modules/readline.c Parser/myreadline.c ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2005-11-27 17:45 Message: Logged In: YES user_id=21627 I don't consider this assignment rude, but I don't think I can do much about this patch for the next few months, either. ---------------------------------------------------------------------- Comment By: Gregory Lielens (greglielens) Date: 2004-08-13 10:52 Message: Logged In: YES user_id=1044428 Hi, as you are the last one which has worked on this subject, I think it is best I reassign this patch to you. As you will see from my discussion with mwh, the main point of these modif is to remove the test of the interractiveness of stdin/stdout that prevent the use of PyOS_ReadlineFunctionPointer when one is not interactive... Hope this re-assignment is not rude, I do not know well python development group usage in this matter... Best regards, Greg ---------------------------------------------------------------------- Comment By: Gregory Lielens (greglielens) Date: 2004-08-05 14:02 Message: Logged In: YES user_id=1044428 I edited the patch to comply with the tab style (or hope so). For the reverse, I used cvs diff -c and assumed it would produce it in the correct order, is it not the case? Anyway, here is the new patch... (If it is still reversed and you have a special option for cvs diff to produce the patch in correct order, I am very interrested! ;-) ) Regarding the origin of the tty test, it is done (at least for the stdin) since the first revision that used a mechanism similar to the current one (PyOS_ReadlineFunctionPointer), and this was done by Guido (r2.11) The test was removed just after (r2.12, again guido), and finally re-introduced in it's final form in revision 2.28, by loewis. Maybe I can assign him so that he gives us a idea of the intention of this, and his feeling about this patch? ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2004-08-05 13:21 Message: Logged In: YES user_id=6656 Uh, no, scratch that: I think your attempt to upload a new patch failed. Try again? ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2004-08-05 13:11 Message: Logged In: YES user_id=6656 A chance, yes. I'm a bit loath to change this, as I have no idea why things were done this way in the first place. If it's the traditional "no good reason", then I guess this can go in... Also, I think your patch is backwards and doesn't adhere to the local style wrt tabs and spaces. ---------------------------------------------------------------------- Comment By: Gregory Lielens (greglielens) Date: 2004-08-05 09:56 Message: Logged In: YES user_id=1044428 I updated the patch to python current CVS, and do similar modification in /Python/bltinmodule.c for builtin_raw_input fonction. builtin_raw_input now call PyOS_Readline when stdin and stdout objects are file, regardless if they are tty or not. This one was forgotten in the first version of the patch, and is needed to be able to use the same broadcasting technique for parrallel interractive session when using IPython. I now think that all functions implementing possibly interractive input have been patched... All regression tests pass except test_grp and test_pwd, but those fail exactly the same way (KeyError) with non-patched cvs... Any chance to have this considered for 2.4? Regards, Greg. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=955928&group_id=5470 From noreply at sourceforge.net Sun Nov 27 17:59:40 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 27 Nov 2005 08:59:40 -0800 Subject: [Patches] [ python-Patches-1162825 ] EditorWindow's title with non-ASCII chars. Message-ID: Patches item #1162825, was opened at 2005-03-14 09:19 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1162825&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: IDLE Group: Python 2.4 >Status: Closed >Resolution: Accepted Priority: 5 Submitted By: SUZUKI Hisao (suzuki_hisao) Assigned to: Martin v. L?wis (loewis) Summary: EditorWindow's title with non-ASCII chars. Initial Comment: This small patch makes it possible to display a path including non- ASCII chars as the title of Editor Window. See the screen shots of original IDLE and patched one. ---------------------------------------------------------------------- >Comment By: Martin v. L?wis (loewis) Date: 2005-11-27 17:59 Message: Logged In: YES user_id=21627 Thanks for the patch. Committed as r41551. ---------------------------------------------------------------------- Comment By: SUZUKI Hisao (suzuki_hisao) Date: 2005-03-22 13:33 Message: Logged In: YES user_id=495142 I have revised the patch so that any unicode results from tkFileDialog are always converted to strings. Now it is more conservative in that unicodes are used minimally for file names. ---------------------------------------------------------------------- Comment By: SUZUKI Hisao (suzuki_hisao) Date: 2005-03-19 09:19 Message: Logged In: YES user_id=495142 I was afraid you might not notice that the patch has to do with freezing of IDLE. Indeed my IDLE on Windows XP has been very freeze-free since applying it. ---------------------------------------------------------------------- Comment By: Kurt B. Kaiser (kbk) Date: 2005-03-19 05:05 Message: Logged In: YES user_id=149084 I'm monitoring :-) Martin knows far more than I do about these things. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2005-03-18 19:16 Message: Logged In: YES user_id=21627 Yes, IMO it is really said that there is no programmatic way to determine the encoding of Terminal.app (an ioctl would be nice). ---------------------------------------------------------------------- Comment By: SUZUKI Hisao (suzuki_hisao) Date: 2005-03-18 12:08 Message: Logged In: YES user_id=495142 On OS X, any command line which you type in is encoded to what Terminal.app specifies. If it is other than UTF-8, you will see broken display for non-ASCII file names when listing them in Terminal.app. If does not match with LANG, line editing in bash will be somewhat useless for multi-byte characters. In Japan, seasoned Unix users tend to use EUC-JP on OS X, and they also tend to restrict their file names to ASCII. They use EUC-JP in their program sources, LaTeX files, command messages, etc. It has been a long tradition how you use Unix in Japan since circa 1990. Thus the broken display for non-ASCII file names does not bother them. Some newfangled Unix users use UTF-8 characters in command line on OS X. And many other OS X users, who use national characters for their file names natullay, do not use command line at all. In theory, you can use some non-UTF8 encoding for a non-ASCII file name in your command line. However, in practice for now, it seems very unlikely on OS X. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2005-03-18 07:49 Message: Logged In: YES user_id=21627 On Windows, both argv and file names are encoded as "mbcs", which is both the locale's encoding, and the file system encoding. The interesting question is: how are command line arguments encoded on OSX (which is the only system which has a file system encoding independent of the locale)? ---------------------------------------------------------------------- Comment By: SUZUKI Hisao (suzuki_hisao) Date: 2005-03-18 03:47 Message: Logged In: YES user_id=495142 When you install Python in Windows, you will get "Edit with IDLE" entry in the context menu for *.py file. The entry launches the pythonw.exe with the name of *.py file as one of the sys.argv[] parameters. See the registry: HKEY_CLASSES_ROOT\Python.File\shell\Edit with IDLE\command There you will see: "C:\Python24\pythonw.exe" "C:\Python24\Lib\idlelib\idle.pyw" -n -e "%1" I thought the file name given here as "%1" would be what open(2) accepts. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2005-03-17 22:33 Message: Logged In: YES user_id=21627 On what operating system is sys.argv in file system encoding (i.e. in the encoding that open(2) expects), and not in the locale's encoding? AFAIK, both Linux and Windows use the locale's encoding for sys.argv (but then, they also use the same encoding for the file system). ---------------------------------------------------------------------- Comment By: SUZUKI Hisao (suzuki_hisao) Date: 2005-03-17 10:25 Message: Logged In: YES user_id=495142 In the typical usage of IDLE, sys.argv[] are given to "pythonw" command by the window system. Thus, in almost all cases, they are in the filesystem encoding. I believe IDLE with the last patch will run well on OS X (as well as on Windows etc.) if the Tcl/Tk bug of OS X is fixed someday, or the environment variable LANG is set to use UTF-8 for now. ---------------------------------------------------------------------- Comment By: SUZUKI Hisao (suzuki_hisao) Date: 2005-03-17 09:40 Message: Logged In: YES user_id=495142 I'm sorry, but the previous patches are insufficient to handle non-ASCII file names. The menu "Recent Files" in "File" in the menu-bar does not display such names correctly. In addition, when updating the "Recent Files" menu, UnicodeDecodeError raises in _implicit_ conversion of unicode filename given by tkFileDialog to ASCII string. So I made a new patch. Do not use the previous patches, please. The new patch converts every multi-byte file name into unicode early in IOBinding; thus the file path is correctly displayed in the title bar. And it converts every unicode name into multi-byte string explicitly when updating the menu. Note that IDLE writes the recent file names as a text file. Conversion into string is necessary anyway. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2005-03-17 09:00 Message: Logged In: YES user_id=21627 Hmm. When the string comes from sys.argv, it should be in the user's preferred encoding, not in the file system encoding, which would suggest that the current code is right. When the string comes from tk_getOpenFile, I would expect to get a Unicode string back instead of a byte string. I can believe that Tk fails for OSX here: it relies on Tcl's glob command, which apparently assumes that "encoding system" is used for the file system; try >>> [unicode(x) for x in t.tk.call(('glob','*'))] There are more issues OSX glob, e.g. for Latin characters, it processes the decomposed form inconveniently, see http://sourceforge.net/tracker/?func=detail&aid=823330&group_id=10894&atid=110894 So I think it is fine to display question marks on OSX if necessary;in general, it now seems that the locale's encoding should be used indeed. ---------------------------------------------------------------------- Comment By: SUZUKI Hisao (suzuki_hisao) Date: 2005-03-17 05:39 Message: Logged In: YES user_id=495142 Thank you for your comment. First, indeed some titles may fail to be decoded, but it will be sufficient to use 'ignore' as the error handling scheme. At least it gives more readable titles than the present "mojibake'd" ones. Second, the title comes from either sys.argv or tkFileDialog. tkFileDialog calls tk_getOpenFile and tk_getSaveFile of Tck/Tk. So you are right. It would be better to use sys.getfilesystemencoding(). Note that the patch does not affect any unicode titles. As for OSX, it seems that tk_getOpenFile sometimes returns a broken string unless you set LANG so as to use UTF-8 (en_US.UTF-8, ja_JP.UTF-8 etc.). You can see it as follows: $ LANG=ja_JP.SJIS wish8.4 % tk_getOpenFile For a folder name of Japanese characters, you will get a broken result; it is neither UTF-8 nor SJIS. The same problem applies to eucJP. It is a bug of Tcl/Tk (I found it in Aqua Tcl/Tk 8.4.9) and affects the original IDLE, too. All in all, it would be the most reasonable to use sys.getfilesystemencoding() and 'ignore' scheme for now. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2005-03-16 00:04 Message: Logged In: YES user_id=21627 I think the patch is wrong/not general enough: - if decoding fails for some reason, it should continue anyway - I'm not sure where the title comes from, but it might be that it is a file name. If so, it should use sys.getfilesystemencoding() instead of IOBinding.encoding. This matters only on systems where these might differ, e.g. MacOSX. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1162825&group_id=5470 From noreply at sourceforge.net Sun Nov 27 18:34:31 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 27 Nov 2005 09:34:31 -0800 Subject: [Patches] [ python-Patches-1367628 ] use PyOS_ReadlineFunctionPointer in non-interractive input Message-ID: Patches item #1367628, was opened at 2005-11-27 18:34 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1367628&group_id=5470 Please note that this 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: Gregory Lielens (greglielens) Assigned to: Nobody/Anonymous (nobody) Summary: use PyOS_ReadlineFunctionPointer in non-interractive input Initial Comment: Python provide a nice input hook for overiding it's input mechanism: User can define set PyOS_ReadlineFunctionPointer to point to an input function, and this function will be used instead of the default input function (PyOS_StdioReadline, or vms__StdioReadline for VMS). This mechanism can be very handy when implementing a parallel python interpreter: the main process can simply brodcast to listening input functions its own input strings. However, the current implementation does not use the hook (PyOS_ReadlineFunctionPointer) when it detect that the input or output are non-interractive (non-tty), but instead call directly the default implementation PyOS_StdioReadline. A snippet of "Parser/myreadline.c": ... if (!isatty (fileno (sys_stdin)) || !isatty (fileno (sys_stdout))) rv = PyOS_StdioReadline (sys_stdin, sys_stdout, prompt); else rv = (*PyOS_ReadlineFunctionPointer)(sys_stdin, sys_stdout, prompt); ... This makes impossible to override the input behavior for non-interractive input. In particular, this prevent implementing parallel python interpreter because only the main python interpreter process have tty input/output, but even in non-parralel context I feel this uneccessarily limit the hook mechanism... I submitted a patch some time ago [id 955928], and Lisandro Dalcin submitted his own patch [id 1232343]to solve the same problem in the same context (parallel python interpreter). Since then, we collaborated for producing a single patch, cleaner than the previous ones. We also used input from the python-dev list [http://mail.python.org/pipermail/python-dev/2005-August/055761.html] and from the author of the VMS patch in PyOS_Readline (Jean-Fran??ois Pi??ronne). This new patch thus replace the 2 precedent ones that should be marked as "duplicate". This patch passes 'Lib/test/regrtest.py' (of course, all those tests are non-interactive!). Lisandro and my company use this patched Python interpreter every day in the standard way and also in MPI-parallelized interactive sessions, and we never had any problem. The patch is relative to the current svn repository, and implement modification in Include/pythonrun.h, Parser/myreadline.c, Modules/readline.c and Python/bltinmodule.c. This last modification is needed for correcting the current behavior (not use the hook for non-interractive input/output) for the raw_input builtin. It is not needed for using the standard python interractive mode, but is needed if one want to use the ipython interpreter (or any interpreter implementing the input loop in python itself). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1367628&group_id=5470 From noreply at sourceforge.net Sun Nov 27 18:43:17 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 27 Nov 2005 09:43:17 -0800 Subject: [Patches] [ python-Patches-955928 ] use PyOS_ReadlineFunctionPointer in non-interractive input Message-ID: Patches item #955928, was opened at 2004-05-18 15:41 Message generated for change (Comment added) made by greglielens You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=955928&group_id=5470 Please note that this 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: Gregory Lielens (greglielens) Assigned to: Martin v. L?wis (loewis) Summary: use PyOS_ReadlineFunctionPointer in non-interractive input Initial Comment: Extend the control provided by PyOS_ReadlineFunctionPointer to non-interractive inputs. In addition, initialize PyOS_ReadlineFunctionPointer to the default input function, so that it can be retrieved by extern code (allowing for embedding the old input function and modifying it). Readline Module changed accordingly (only modify PyOS_ReadlineFunctionPointer to call_readline if input is interractive). This was neccessary to modify the input behavior of PyRun_InteractiveLoop, in case input is not interractive... The application is a python driven parallel framework using MPI, where the interractive process broadcast the input lines to the non-interractive processes, who listen...but other applications may benefit also. patched: Modules/readline.c Parser/myreadline.c ---------------------------------------------------------------------- >Comment By: Gregory Lielens (greglielens) Date: 2005-11-27 18:43 Message: Logged In: YES user_id=1044428 OK. I still think it is best to close this patch though: Since my patch, lisandro Dalcin submitted a very similar patch and we collaborated on this and produced a new patch (cleaner, against the current svn repository). I just submitted this new patch, hence I propose to close my old one (and Lisandro will do the same with his) and mark it as duplicate. Do you think it is best to let the new patch unassigned or to assign it to you? ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2005-11-27 17:45 Message: Logged In: YES user_id=21627 I don't consider this assignment rude, but I don't think I can do much about this patch for the next few months, either. ---------------------------------------------------------------------- Comment By: Gregory Lielens (greglielens) Date: 2004-08-13 10:52 Message: Logged In: YES user_id=1044428 Hi, as you are the last one which has worked on this subject, I think it is best I reassign this patch to you. As you will see from my discussion with mwh, the main point of these modif is to remove the test of the interractiveness of stdin/stdout that prevent the use of PyOS_ReadlineFunctionPointer when one is not interactive... Hope this re-assignment is not rude, I do not know well python development group usage in this matter... Best regards, Greg ---------------------------------------------------------------------- Comment By: Gregory Lielens (greglielens) Date: 2004-08-05 14:02 Message: Logged In: YES user_id=1044428 I edited the patch to comply with the tab style (or hope so). For the reverse, I used cvs diff -c and assumed it would produce it in the correct order, is it not the case? Anyway, here is the new patch... (If it is still reversed and you have a special option for cvs diff to produce the patch in correct order, I am very interrested! ;-) ) Regarding the origin of the tty test, it is done (at least for the stdin) since the first revision that used a mechanism similar to the current one (PyOS_ReadlineFunctionPointer), and this was done by Guido (r2.11) The test was removed just after (r2.12, again guido), and finally re-introduced in it's final form in revision 2.28, by loewis. Maybe I can assign him so that he gives us a idea of the intention of this, and his feeling about this patch? ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2004-08-05 13:21 Message: Logged In: YES user_id=6656 Uh, no, scratch that: I think your attempt to upload a new patch failed. Try again? ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2004-08-05 13:11 Message: Logged In: YES user_id=6656 A chance, yes. I'm a bit loath to change this, as I have no idea why things were done this way in the first place. If it's the traditional "no good reason", then I guess this can go in... Also, I think your patch is backwards and doesn't adhere to the local style wrt tabs and spaces. ---------------------------------------------------------------------- Comment By: Gregory Lielens (greglielens) Date: 2004-08-05 09:56 Message: Logged In: YES user_id=1044428 I updated the patch to python current CVS, and do similar modification in /Python/bltinmodule.c for builtin_raw_input fonction. builtin_raw_input now call PyOS_Readline when stdin and stdout objects are file, regardless if they are tty or not. This one was forgotten in the first version of the patch, and is needed to be able to use the same broadcasting technique for parrallel interractive session when using IPython. I now think that all functions implementing possibly interractive input have been patched... All regression tests pass except test_grp and test_pwd, but those fail exactly the same way (KeyError) with non-patched cvs... Any chance to have this considered for 2.4? Regards, Greg. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=955928&group_id=5470 From noreply at sourceforge.net Sun Nov 27 18:43:55 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 27 Nov 2005 09:43:55 -0800 Subject: [Patches] [ python-Patches-955928 ] use PyOS_ReadlineFunctionPointer in non-interractive input Message-ID: Patches item #955928, was opened at 2004-05-18 15:41 Message generated for change (Settings changed) made by greglielens You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=955928&group_id=5470 Please note that this 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: Closed >Resolution: Duplicate Priority: 5 Submitted By: Gregory Lielens (greglielens) Assigned to: Martin v. L?wis (loewis) Summary: use PyOS_ReadlineFunctionPointer in non-interractive input Initial Comment: Extend the control provided by PyOS_ReadlineFunctionPointer to non-interractive inputs. In addition, initialize PyOS_ReadlineFunctionPointer to the default input function, so that it can be retrieved by extern code (allowing for embedding the old input function and modifying it). Readline Module changed accordingly (only modify PyOS_ReadlineFunctionPointer to call_readline if input is interractive). This was neccessary to modify the input behavior of PyRun_InteractiveLoop, in case input is not interractive... The application is a python driven parallel framework using MPI, where the interractive process broadcast the input lines to the non-interractive processes, who listen...but other applications may benefit also. patched: Modules/readline.c Parser/myreadline.c ---------------------------------------------------------------------- Comment By: Gregory Lielens (greglielens) Date: 2005-11-27 18:43 Message: Logged In: YES user_id=1044428 OK. I still think it is best to close this patch though: Since my patch, lisandro Dalcin submitted a very similar patch and we collaborated on this and produced a new patch (cleaner, against the current svn repository). I just submitted this new patch, hence I propose to close my old one (and Lisandro will do the same with his) and mark it as duplicate. Do you think it is best to let the new patch unassigned or to assign it to you? ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2005-11-27 17:45 Message: Logged In: YES user_id=21627 I don't consider this assignment rude, but I don't think I can do much about this patch for the next few months, either. ---------------------------------------------------------------------- Comment By: Gregory Lielens (greglielens) Date: 2004-08-13 10:52 Message: Logged In: YES user_id=1044428 Hi, as you are the last one which has worked on this subject, I think it is best I reassign this patch to you. As you will see from my discussion with mwh, the main point of these modif is to remove the test of the interractiveness of stdin/stdout that prevent the use of PyOS_ReadlineFunctionPointer when one is not interactive... Hope this re-assignment is not rude, I do not know well python development group usage in this matter... Best regards, Greg ---------------------------------------------------------------------- Comment By: Gregory Lielens (greglielens) Date: 2004-08-05 14:02 Message: Logged In: YES user_id=1044428 I edited the patch to comply with the tab style (or hope so). For the reverse, I used cvs diff -c and assumed it would produce it in the correct order, is it not the case? Anyway, here is the new patch... (If it is still reversed and you have a special option for cvs diff to produce the patch in correct order, I am very interrested! ;-) ) Regarding the origin of the tty test, it is done (at least for the stdin) since the first revision that used a mechanism similar to the current one (PyOS_ReadlineFunctionPointer), and this was done by Guido (r2.11) The test was removed just after (r2.12, again guido), and finally re-introduced in it's final form in revision 2.28, by loewis. Maybe I can assign him so that he gives us a idea of the intention of this, and his feeling about this patch? ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2004-08-05 13:21 Message: Logged In: YES user_id=6656 Uh, no, scratch that: I think your attempt to upload a new patch failed. Try again? ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2004-08-05 13:11 Message: Logged In: YES user_id=6656 A chance, yes. I'm a bit loath to change this, as I have no idea why things were done this way in the first place. If it's the traditional "no good reason", then I guess this can go in... Also, I think your patch is backwards and doesn't adhere to the local style wrt tabs and spaces. ---------------------------------------------------------------------- Comment By: Gregory Lielens (greglielens) Date: 2004-08-05 09:56 Message: Logged In: YES user_id=1044428 I updated the patch to python current CVS, and do similar modification in /Python/bltinmodule.c for builtin_raw_input fonction. builtin_raw_input now call PyOS_Readline when stdin and stdout objects are file, regardless if they are tty or not. This one was forgotten in the first version of the patch, and is needed to be able to use the same broadcasting technique for parrallel interractive session when using IPython. I now think that all functions implementing possibly interractive input have been patched... All regression tests pass except test_grp and test_pwd, but those fail exactly the same way (KeyError) with non-patched cvs... Any chance to have this considered for 2.4? Regards, Greg. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=955928&group_id=5470 From noreply at sourceforge.net Sun Nov 27 19:11:00 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 27 Nov 2005 10:11:00 -0800 Subject: [Patches] [ python-Patches-955928 ] use PyOS_ReadlineFunctionPointer in non-interractive input Message-ID: Patches item #955928, was opened at 2004-05-18 15:41 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=955928&group_id=5470 Please note that this 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: Closed Resolution: Duplicate Priority: 5 Submitted By: Gregory Lielens (greglielens) Assigned to: Martin v. L?wis (loewis) Summary: use PyOS_ReadlineFunctionPointer in non-interractive input Initial Comment: Extend the control provided by PyOS_ReadlineFunctionPointer to non-interractive inputs. In addition, initialize PyOS_ReadlineFunctionPointer to the default input function, so that it can be retrieved by extern code (allowing for embedding the old input function and modifying it). Readline Module changed accordingly (only modify PyOS_ReadlineFunctionPointer to call_readline if input is interractive). This was neccessary to modify the input behavior of PyRun_InteractiveLoop, in case input is not interractive... The application is a python driven parallel framework using MPI, where the interractive process broadcast the input lines to the non-interractive processes, who listen...but other applications may benefit also. patched: Modules/readline.c Parser/myreadline.c ---------------------------------------------------------------------- >Comment By: Martin v. L?wis (loewis) Date: 2005-11-27 19:11 Message: Logged In: YES user_id=21627 I would leave it unassigned. ---------------------------------------------------------------------- Comment By: Gregory Lielens (greglielens) Date: 2005-11-27 18:43 Message: Logged In: YES user_id=1044428 OK. I still think it is best to close this patch though: Since my patch, lisandro Dalcin submitted a very similar patch and we collaborated on this and produced a new patch (cleaner, against the current svn repository). I just submitted this new patch, hence I propose to close my old one (and Lisandro will do the same with his) and mark it as duplicate. Do you think it is best to let the new patch unassigned or to assign it to you? ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2005-11-27 17:45 Message: Logged In: YES user_id=21627 I don't consider this assignment rude, but I don't think I can do much about this patch for the next few months, either. ---------------------------------------------------------------------- Comment By: Gregory Lielens (greglielens) Date: 2004-08-13 10:52 Message: Logged In: YES user_id=1044428 Hi, as you are the last one which has worked on this subject, I think it is best I reassign this patch to you. As you will see from my discussion with mwh, the main point of these modif is to remove the test of the interractiveness of stdin/stdout that prevent the use of PyOS_ReadlineFunctionPointer when one is not interactive... Hope this re-assignment is not rude, I do not know well python development group usage in this matter... Best regards, Greg ---------------------------------------------------------------------- Comment By: Gregory Lielens (greglielens) Date: 2004-08-05 14:02 Message: Logged In: YES user_id=1044428 I edited the patch to comply with the tab style (or hope so). For the reverse, I used cvs diff -c and assumed it would produce it in the correct order, is it not the case? Anyway, here is the new patch... (If it is still reversed and you have a special option for cvs diff to produce the patch in correct order, I am very interrested! ;-) ) Regarding the origin of the tty test, it is done (at least for the stdin) since the first revision that used a mechanism similar to the current one (PyOS_ReadlineFunctionPointer), and this was done by Guido (r2.11) The test was removed just after (r2.12, again guido), and finally re-introduced in it's final form in revision 2.28, by loewis. Maybe I can assign him so that he gives us a idea of the intention of this, and his feeling about this patch? ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2004-08-05 13:21 Message: Logged In: YES user_id=6656 Uh, no, scratch that: I think your attempt to upload a new patch failed. Try again? ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2004-08-05 13:11 Message: Logged In: YES user_id=6656 A chance, yes. I'm a bit loath to change this, as I have no idea why things were done this way in the first place. If it's the traditional "no good reason", then I guess this can go in... Also, I think your patch is backwards and doesn't adhere to the local style wrt tabs and spaces. ---------------------------------------------------------------------- Comment By: Gregory Lielens (greglielens) Date: 2004-08-05 09:56 Message: Logged In: YES user_id=1044428 I updated the patch to python current CVS, and do similar modification in /Python/bltinmodule.c for builtin_raw_input fonction. builtin_raw_input now call PyOS_Readline when stdin and stdout objects are file, regardless if they are tty or not. This one was forgotten in the first version of the patch, and is needed to be able to use the same broadcasting technique for parrallel interractive session when using IPython. I now think that all functions implementing possibly interractive input have been patched... All regression tests pass except test_grp and test_pwd, but those fail exactly the same way (KeyError) with non-patched cvs... Any chance to have this considered for 2.4? Regards, Greg. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=955928&group_id=5470 From noreply at sourceforge.net Sun Nov 27 20:25:41 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 27 Nov 2005 11:25:41 -0800 Subject: [Patches] [ python-Patches-1365916 ] [PATCH] mmap fails on AMD64 Message-ID: Patches item #1365916, was opened at 2005-11-24 16:22 Message generated for change (Comment added) made by jepler You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1365916&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Modules Group: None Status: Open Resolution: None Priority: 5 Submitted By: Joe Wreschnig (piman) Assigned to: Nobody/Anonymous (nobody) Summary: [PATCH] mmap fails on AMD64 Initial Comment: mmap_move_method is not 64-bit safe, and fails on the following code: from mmap import mmap f = open('test.out', 'ab+') f.write('ABCDEabcde') f.flush() m = mmap(f.fileno(), 10) m.move(5, 0, 5) m.read(10) To fix this, mmapmodule.c:538 needs to use "LLL:move" instead of "iii:move" (this also fixes #1921169, which changed it from "iii" to "III"). This is in both Python 2.3 and 2.4. ---------------------------------------------------------------------- Comment By: Jeff Epler (jepler) Date: 2005-11-27 13:25 Message: Logged In: YES user_id=2772 I haven't tested the patch, but the above testcase does fail on my linux x86_64 machine with "ValueError: source or destination out of range" on the call to m.move(), but succeed on my linux x86 machine. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1365916&group_id=5470 From noreply at sourceforge.net Sun Nov 27 21:18:37 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 27 Nov 2005 12:18:37 -0800 Subject: [Patches] [ python-Patches-1367711 ] Remove usage of UserDict from os.py Message-ID: Patches item #1367711, was opened at 2005-11-27 20:18 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1367711&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Library (Lib) Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: Wolfgang Langner (tds33) Assigned to: Nobody/Anonymous (nobody) Summary: Remove usage of UserDict from os.py Initial Comment: This patch removes UserDict usage from os.py. It uses the new dict base class instead of UserDict. Patch was generated against Revision 41544 of python subersion repository. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1367711&group_id=5470 From noreply at sourceforge.net Sun Nov 27 21:30:33 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 27 Nov 2005 12:30:33 -0800 Subject: [Patches] [ python-Patches-1367717 ] replace usage of UserDict with new dict class Message-ID: Patches item #1367717, was opened at 2005-11-27 20: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=1367717&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Library (Lib) Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: Wolfgang Langner (tds33) Assigned to: Nobody/Anonymous (nobody) Summary: replace usage of UserDict with new dict class Initial Comment: replaces UserDict with new dict base class. Patch against python subversion repository revision 41544 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1367717&group_id=5470 From noreply at sourceforge.net Mon Nov 28 01:24:06 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 27 Nov 2005 16:24:06 -0800 Subject: [Patches] [ python-Patches-403693 ] tupleobject.c: implement tuple.index() and tuple.count() Message-ID: Patches item #403693, was opened at 2001-02-08 23:05 Message generated for change (Comment added) made by cito You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=403693&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Core (C code) Group: None Status: Closed Resolution: Rejected Priority: 5 Submitted By: Markus F.X.J. Oberhumer (mfx) Assigned to: Nobody/Anonymous (nobody) Summary: tupleobject.c: implement tuple.index() and tuple.count() Initial Comment: This patch adds support for two methods that are useful for immutable tupels, namely index() and count(). The semantics is exactly like those on list objects. ---------------------------------------------------------------------- Comment By: Christoph Zwerschke (cito) Date: 2005-11-28 01:24 Message: Logged In: YES user_id=193957 I really do not understand why this fix was rejected. Why should Python programmers have to bother about casting sequences to lists and be punished with runtime errors if they forget doing, so if this could easily be avoided? I think it is an unnecessary stumbling block. If I know that lists and strings have index and count methods, I simply expect that this is a rule for all sequence types and tuples have them as well. So it contradicts "special cases aren't special enough to break the rules", the "principle of least astonishment" and orthogonal design. Only the following reasons were given: 1) "index" and "count" are "list-ish" things: I dare to disagree. "index" and "count" are not "list-ish" things, they are "sequence-ish" things. Actually they have been implemented for strings as well. Why should they only make sense for mutable sequence types and not for immutable sequences types such as tuples? 2) Python will become too large by adding this fix: Even if there is no code-reuse between lists and tuples, would adding these few bytes really hurt so much? Isn't it better to waste some bytes if you can improve orthogonality and convenience for programmers? How much cost a handfull of bytes today? Fixing the doco wouldn't be a big deal either. The explanation of "index" and "count" could simply move from the section "mutable sequence types" to "sequence types", plus maybe a remark that they show an extended behavior for strings (they look for substrings as well) and do not exist for xrange (where they are really not needed). ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-02-16 09:21 Message: Changed Status from Closed to Rejected, and assigned to None, in accord with rejection procedure. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-02-15 14:49 Message: Why bother? I like the fact that when you want to do list-ish things you have to use lists. Use list(t).count(x) if you really want this for a tuple. I'm rejecting this in the name of all those users who want Python to be small. ---------------------------------------------------------------------- Comment By: Jeremy Hylton (jhylton) Date: 2001-02-10 01:13 Message: interested in adding this to 2.1? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=403693&group_id=5470 From noreply at sourceforge.net Mon Nov 28 02:27:30 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 27 Nov 2005 17:27:30 -0800 Subject: [Patches] [ python-Patches-403693 ] tupleobject.c: implement tuple.index() and tuple.count() Message-ID: Patches item #403693, was opened at 2001-02-08 17:05 Message generated for change (Comment added) made by gvanrossum You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=403693&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Core (C code) Group: None Status: Closed Resolution: Rejected Priority: 5 Submitted By: Markus F.X.J. Oberhumer (mfx) Assigned to: Nobody/Anonymous (nobody) Summary: tupleobject.c: implement tuple.index() and tuple.count() Initial Comment: This patch adds support for two methods that are useful for immutable tupels, namely index() and count(). The semantics is exactly like those on list objects. ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2005-11-27 20:27 Message: Logged In: YES user_id=6380 The answer is still no. If you don't appreciate the difference in purpose between lists and tuples perhaps you should go ask about this on c.l.py instead of arguing on SF. ---------------------------------------------------------------------- Comment By: Christoph Zwerschke (cito) Date: 2005-11-27 19:24 Message: Logged In: YES user_id=193957 I really do not understand why this fix was rejected. Why should Python programmers have to bother about casting sequences to lists and be punished with runtime errors if they forget doing, so if this could easily be avoided? I think it is an unnecessary stumbling block. If I know that lists and strings have index and count methods, I simply expect that this is a rule for all sequence types and tuples have them as well. So it contradicts "special cases aren't special enough to break the rules", the "principle of least astonishment" and orthogonal design. Only the following reasons were given: 1) "index" and "count" are "list-ish" things: I dare to disagree. "index" and "count" are not "list-ish" things, they are "sequence-ish" things. Actually they have been implemented for strings as well. Why should they only make sense for mutable sequence types and not for immutable sequences types such as tuples? 2) Python will become too large by adding this fix: Even if there is no code-reuse between lists and tuples, would adding these few bytes really hurt so much? Isn't it better to waste some bytes if you can improve orthogonality and convenience for programmers? How much cost a handfull of bytes today? Fixing the doco wouldn't be a big deal either. The explanation of "index" and "count" could simply move from the section "mutable sequence types" to "sequence types", plus maybe a remark that they show an extended behavior for strings (they look for substrings as well) and do not exist for xrange (where they are really not needed). ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-02-16 03:21 Message: Changed Status from Closed to Rejected, and assigned to None, in accord with rejection procedure. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-02-15 08:49 Message: Why bother? I like the fact that when you want to do list-ish things you have to use lists. Use list(t).count(x) if you really want this for a tuple. I'm rejecting this in the name of all those users who want Python to be small. ---------------------------------------------------------------------- Comment By: Jeremy Hylton (jhylton) Date: 2001-02-09 19:13 Message: interested in adding this to 2.1? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=403693&group_id=5470 From noreply at sourceforge.net Mon Nov 28 15:15:40 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 28 Nov 2005 06:15:40 -0800 Subject: [Patches] [ python-Patches-1368247 ] email/Charset.py Message-ID: Patches item #1368247, was opened at 2005-11-28 15: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=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: Nobody/Anonymous (nobody) Summary: 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 Mon Nov 28 15:16:30 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 28 Nov 2005 06:16:30 -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 15:15 Message generated for change (Settings changed) made by gdamjan 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: Nobody/Anonymous (nobody) >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 Mon Nov 28 18:36:26 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 28 Nov 2005 09:36:26 -0800 Subject: [Patches] [ python-Patches-1350409 ] Fix for signal related abort in Visual Studio 2005 Message-ID: Patches item #1350409, was opened at 2005-11-07 16:31 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1350409&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Core (C code) Group: Python 2.4 >Status: Closed >Resolution: Accepted Priority: 5 Submitted By: Adal Chiriliuc (adalx) Assigned to: Nobody/Anonymous (nobody) Summary: Fix for signal related abort in Visual Studio 2005 Initial Comment: See #1167262 and #1311784. ---------------------------------------------------------------------- >Comment By: Martin v. L?wis (loewis) Date: 2005-11-28 18:36 Message: Logged In: YES user_id=21627 Thanks for the patch. Committed as rev 41554. ---------------------------------------------------------------------- Comment By: Clay Culver (cculver) Date: 2005-11-25 02:41 Message: Logged In: YES user_id=149773 Fantastic work, this fixed my compile problem with VS 2005 Express. Thanks adalx. ---------------------------------------------------------------------- Comment By: Adal Chiriliuc (adalx) Date: 2005-11-08 00:48 Message: Logged In: YES user_id=1067739 Microsoft Visual Studio 2005 Professional Edition Version 8.0.50727.42 (RTM 050727-4200) It's the final version (RTM=Release To Manufacture), released a week ago on MSDN. I understand that it should be available in stores starting from today. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2005-11-08 00:21 Message: Logged In: YES user_id=21627 What precise version of visual studio did you use to develop this patch? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1350409&group_id=5470 From noreply at sourceforge.net Mon Nov 28 21:45:06 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 28 Nov 2005 12:45:06 -0800 Subject: [Patches] [ python-Patches-1232343 ] PyOS_Readline Message-ID: Patches item #1232343, was opened at 2005-07-04 15:03 Message generated for change (Settings changed) made by dalcinl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1232343&group_id=5470 Please note that this 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: Deleted >Resolution: Duplicate Priority: 5 Submitted By: Lisandro Dalcin (dalcinl) Assigned to: Nobody/Anonymous (nobody) Summary: PyOS_Readline Initial Comment: Greg Lielens submitted some time ago a patch [id 955928] about 'PyOS_Readline()' behavior with non-interactive tty's. Basically, there is no way to properly override 'PyOS_ReadlineFunctionPointer' as 'PyOS_Readline()' calls 'PyOS_StdioReadline()' when 'stdin' or 'stdout' are not tty's. A snippet of "Parser/myreadline.c": ... if (!isatty (fileno (sys_stdin)) || !isatty (fileno (sys_stdout))) rv = PyOS_StdioReadline (sys_stdin, sys_stdout, prompt); else rv = (*PyOS_ReadlineFunctionPointer)(sys_stdin, sys_stdout, prompt); ... Greg Lielens is completely right about the problem, but his patch is perhaps a bit crude, it also modifies "Python/bltinmodule.c" to solve the same issue with 'raw_input'. I think I have found a not so crude solution, and completely backward compatible. Basically, I moved 'isatty()' test from 'PyOS_Readline()' in file "Parser/myreadline.c" to 'call_readline()' in file "Modules/readline.c". In order to do that, I believe 'PyOS_StdioReadline' have to be added to file "Include/pythonrun.h". All those changes will not affect in any way the behavior in interactive sessions. Now 'PyOS_ReadlineFunctionPointer' can be properly overrode and users of 'readline' module will not see any change: in non-interactive tty's 'PyOS_StdioReadline()' will be called anyway. The problem in 'input' and 'raw_input' builtins remains, but its solution is not so clear to me, I think this part should not be touched right now. This patch passes 'Lib/test/regrtest.py' (of course, all those tests are non-interactive!). I use Python interpreter every day in the standard way and also in MPI-parallelized interactive sessions with this patch applied, and I never have any problem. I send my patch obtained with 'cvs diff -c' from current sources. ---------------------------------------------------------------------- Comment By: Gregory Lielens (greglielens) Date: 2005-08-06 16:35 Message: Logged In: YES user_id=1044428 Oups: please forget my previous message, I clicked on submit too fast and there is no correction/unsubmit option on sourceforge... Hi Lisandro, sorry that I did not follow this matter, we had other short term focus in our company and I had trouble finding time for it. Good that you subject this though, I have checked it fast and from what I understand it would have the same effect as my older patch... However, I still prefer some aspects of my patch over your?s ;) in Parser/myreadline.c, I removed the test about PyOS_ReadlineFunctionPointer being null: instead I initialize it at creation (to the correct value depending to system, vms or not): This initialization was important because it allows me to use this default function in my parallel Readline function... In general, ithe idea is to allow re-using the default in the new Readline function, incrementing functionalities instead of re-implementing full functionality. You will have the same mechanism with the inclusion of PyOS_StdioReadline in the pythonrun API, but I personally find this solution less appealing: it increase the size of the API, and you do not have the correct readline on VMS...That's why I have done it like this, even if it may seems hackish ;) Of course manual has to be updated to say that PyOS_ReadlineFunctionPointer has a meaningful default value...but it would also have to be updated in your approach, to tell about PyOS_StdioReadline... Well, a matter of taste I guess, but if the general opinion is that this initialization is unclean, I would then advice for renaming of PyOS_StdioReadline in the API to something like PyOS_ReadlineFunction, that would defined as PyOS_StdioReadline/vms__StdioReadline depending on the environment... Regarding your modify of the Modules/readline.c, I have the feeling that your approach is cleaner...because It seems nicer to check for tty inside the new readline function, instead of installing the new readline function only if stdin/stdout are tty....You have to use PyOS_StdioReadline though, again that would not be accessible if one does not add it to the pythonrun.h API (again that is not correct on vms system, but could be corrected taking my previous remark into account). An alternative approach would be to cache the original PyOS_ReadlineFunctionPointer in the readline module, and re-use it if stdin/stdout are non-tty? This would be close to the approach I used for implementing my MPI readline: cache PyOS_ReadlineFunctionPointer and re-use it for modif... Again, a matter of choice, I guess, more experienced python developers may have something to say about it. Now for my patch on "Python/bltinmodule.c" to solve the same issue with 'raw_input', I think it was necessary to be able to use ipython in an interactive MPI session...Our embedded python interpreter had the possibility to use this (it gives a far nicer shell than the standard one), but I think It uses raw_input as entry mechanism... Could you test your patch to see if it work also with ipython? If not then this modify has to stay I think... The only drawback I see with this is that it could slow down a bit the parsing when using this function on a non-interactive file...but I doubt this is significative and could be optimized by keeping the call to PyOS_Readline but stripping out the prompt treatment in this case... We now are moving from an embedded python interpreter to using a standard python...which make the acceptance of the patch all the more interesting for us: it would allows to use stock python interpreters > 2.x, no need to distribute our own interpreter anymore!!! :) ---------------------------------------------------------------------- Comment By: Gregory Lielens (greglielens) Date: 2005-08-06 16:14 Message: Logged In: YES user_id=1044428 Hi Lisandro, sorry that I did not follow this matter, we had other short term focus in our company and I had trouble finding time for it. Good that you subject this though, I have checked it fast and from what I understand it would have the same effect as my older patch... However, I used some features of my patch that are not present in yours: in Parser/myreadline.c, I removed the test about PyOS_ReadlineFunctionPointer being null to instead initialising it at creation to the correct value depending to system: This was important because it allows me in my specific MPI Readline function to use this defautl functio for the process 0...In general, it allows to re-use the default in the new Readline function, incrementing functionalities instead of re-implementing full functionality. You will have the same mechanism with the inclusion of PyOS_StdioReadline in the pythonrun API, but I personally find this solution less appealing: it increase the size of the API, and you do not have the correct readline on VMS...That's why I have done it like this, even if it may seems hackish ;) Of sourse manual has to be updated to say that PyOS_ReadlineFunctionPointer has a meaningfull defautl value...but it would also have to be updated in your approach, to tell about PyOS_StdioReadline... Regarding your modif of the Modules/readline.c, I have the feeling that your approach is cleaner...because It seems nicer to check for tty inside the new readline function, instead of installing the new readline function only if stdin/stdout are tty....You have to use PyOS_StdioReadline though, that would not be accessible if one does not add it to the pythonrun.h API, and that is not correct on vms system anyway (at least that's how I understand it...but I have no vms system to check ;) ). Maybe a better approach would be to cache the original PyOS_ReadlineFunctionPointer in the readline module, and re-use it if stdin/stdout are non-tty? This would be close to the approach I used for implementing my MPI readline: cache PyOS_ReadlineFunctionPointer and re-use it for modif... If this is considerd unclean, the approach putting PyOS_StdioReadline in the API can be kept, but It would have to be renamed something like PyOS_ReadlineFunction and be defined as PyOS_StdioReadline/vms__StdioReadline depending on the environment... Now for my patch on "Python/bltinmodule.c" to solve the same issue with 'raw_input', I think it was necessary to be able to use ipython in an interractive MPI session...Our embedded python interpreter had the possibility to use this (it gives a far nicier shell than the standard one), but I think It uses raw_input as entry mechanism...Could you test your patch to see if it work with this? The only drawback I see with this is that it could slow down a bit the parsing when using this function on a non-interractive file...but I doubt this is significative and could be optimized by keeping the call to PyOS_Readline but stripping out the prompt treatment in this case... We now are moving from an embbedded python interpreter to using a standard python...which make the acceptance of the patch more interresting: it would allows us to uses stock python interpreters > 2.x, no need to distribute our own interpretter anymore!!! :) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1232343&group_id=5470 From noreply at sourceforge.net Mon Nov 28 21:47:47 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 28 Nov 2005 12:47:47 -0800 Subject: [Patches] [ python-Patches-1232343 ] PyOS_Readline Message-ID: Patches item #1232343, was opened at 2005-07-04 15:03 Message generated for change (Settings changed) made by dalcinl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1232343&group_id=5470 Please note that this 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: Duplicate Priority: 5 Submitted By: Lisandro Dalcin (dalcinl) Assigned to: Nobody/Anonymous (nobody) Summary: PyOS_Readline Initial Comment: Greg Lielens submitted some time ago a patch [id 955928] about 'PyOS_Readline()' behavior with non-interactive tty's. Basically, there is no way to properly override 'PyOS_ReadlineFunctionPointer' as 'PyOS_Readline()' calls 'PyOS_StdioReadline()' when 'stdin' or 'stdout' are not tty's. A snippet of "Parser/myreadline.c": ... if (!isatty (fileno (sys_stdin)) || !isatty (fileno (sys_stdout))) rv = PyOS_StdioReadline (sys_stdin, sys_stdout, prompt); else rv = (*PyOS_ReadlineFunctionPointer)(sys_stdin, sys_stdout, prompt); ... Greg Lielens is completely right about the problem, but his patch is perhaps a bit crude, it also modifies "Python/bltinmodule.c" to solve the same issue with 'raw_input'. I think I have found a not so crude solution, and completely backward compatible. Basically, I moved 'isatty()' test from 'PyOS_Readline()' in file "Parser/myreadline.c" to 'call_readline()' in file "Modules/readline.c". In order to do that, I believe 'PyOS_StdioReadline' have to be added to file "Include/pythonrun.h". All those changes will not affect in any way the behavior in interactive sessions. Now 'PyOS_ReadlineFunctionPointer' can be properly overrode and users of 'readline' module will not see any change: in non-interactive tty's 'PyOS_StdioReadline()' will be called anyway. The problem in 'input' and 'raw_input' builtins remains, but its solution is not so clear to me, I think this part should not be touched right now. This patch passes 'Lib/test/regrtest.py' (of course, all those tests are non-interactive!). I use Python interpreter every day in the standard way and also in MPI-parallelized interactive sessions with this patch applied, and I never have any problem. I send my patch obtained with 'cvs diff -c' from current sources. ---------------------------------------------------------------------- Comment By: Gregory Lielens (greglielens) Date: 2005-08-06 16:35 Message: Logged In: YES user_id=1044428 Oups: please forget my previous message, I clicked on submit too fast and there is no correction/unsubmit option on sourceforge... Hi Lisandro, sorry that I did not follow this matter, we had other short term focus in our company and I had trouble finding time for it. Good that you subject this though, I have checked it fast and from what I understand it would have the same effect as my older patch... However, I still prefer some aspects of my patch over your?s ;) in Parser/myreadline.c, I removed the test about PyOS_ReadlineFunctionPointer being null: instead I initialize it at creation (to the correct value depending to system, vms or not): This initialization was important because it allows me to use this default function in my parallel Readline function... In general, ithe idea is to allow re-using the default in the new Readline function, incrementing functionalities instead of re-implementing full functionality. You will have the same mechanism with the inclusion of PyOS_StdioReadline in the pythonrun API, but I personally find this solution less appealing: it increase the size of the API, and you do not have the correct readline on VMS...That's why I have done it like this, even if it may seems hackish ;) Of course manual has to be updated to say that PyOS_ReadlineFunctionPointer has a meaningful default value...but it would also have to be updated in your approach, to tell about PyOS_StdioReadline... Well, a matter of taste I guess, but if the general opinion is that this initialization is unclean, I would then advice for renaming of PyOS_StdioReadline in the API to something like PyOS_ReadlineFunction, that would defined as PyOS_StdioReadline/vms__StdioReadline depending on the environment... Regarding your modify of the Modules/readline.c, I have the feeling that your approach is cleaner...because It seems nicer to check for tty inside the new readline function, instead of installing the new readline function only if stdin/stdout are tty....You have to use PyOS_StdioReadline though, again that would not be accessible if one does not add it to the pythonrun.h API (again that is not correct on vms system, but could be corrected taking my previous remark into account). An alternative approach would be to cache the original PyOS_ReadlineFunctionPointer in the readline module, and re-use it if stdin/stdout are non-tty? This would be close to the approach I used for implementing my MPI readline: cache PyOS_ReadlineFunctionPointer and re-use it for modif... Again, a matter of choice, I guess, more experienced python developers may have something to say about it. Now for my patch on "Python/bltinmodule.c" to solve the same issue with 'raw_input', I think it was necessary to be able to use ipython in an interactive MPI session...Our embedded python interpreter had the possibility to use this (it gives a far nicer shell than the standard one), but I think It uses raw_input as entry mechanism... Could you test your patch to see if it work also with ipython? If not then this modify has to stay I think... The only drawback I see with this is that it could slow down a bit the parsing when using this function on a non-interactive file...but I doubt this is significative and could be optimized by keeping the call to PyOS_Readline but stripping out the prompt treatment in this case... We now are moving from an embedded python interpreter to using a standard python...which make the acceptance of the patch all the more interesting for us: it would allows to use stock python interpreters > 2.x, no need to distribute our own interpreter anymore!!! :) ---------------------------------------------------------------------- Comment By: Gregory Lielens (greglielens) Date: 2005-08-06 16:14 Message: Logged In: YES user_id=1044428 Hi Lisandro, sorry that I did not follow this matter, we had other short term focus in our company and I had trouble finding time for it. Good that you subject this though, I have checked it fast and from what I understand it would have the same effect as my older patch... However, I used some features of my patch that are not present in yours: in Parser/myreadline.c, I removed the test about PyOS_ReadlineFunctionPointer being null to instead initialising it at creation to the correct value depending to system: This was important because it allows me in my specific MPI Readline function to use this defautl functio for the process 0...In general, it allows to re-use the default in the new Readline function, incrementing functionalities instead of re-implementing full functionality. You will have the same mechanism with the inclusion of PyOS_StdioReadline in the pythonrun API, but I personally find this solution less appealing: it increase the size of the API, and you do not have the correct readline on VMS...That's why I have done it like this, even if it may seems hackish ;) Of sourse manual has to be updated to say that PyOS_ReadlineFunctionPointer has a meaningfull defautl value...but it would also have to be updated in your approach, to tell about PyOS_StdioReadline... Regarding your modif of the Modules/readline.c, I have the feeling that your approach is cleaner...because It seems nicer to check for tty inside the new readline function, instead of installing the new readline function only if stdin/stdout are tty....You have to use PyOS_StdioReadline though, that would not be accessible if one does not add it to the pythonrun.h API, and that is not correct on vms system anyway (at least that's how I understand it...but I have no vms system to check ;) ). Maybe a better approach would be to cache the original PyOS_ReadlineFunctionPointer in the readline module, and re-use it if stdin/stdout are non-tty? This would be close to the approach I used for implementing my MPI readline: cache PyOS_ReadlineFunctionPointer and re-use it for modif... If this is considerd unclean, the approach putting PyOS_StdioReadline in the API can be kept, but It would have to be renamed something like PyOS_ReadlineFunction and be defined as PyOS_StdioReadline/vms__StdioReadline depending on the environment... Now for my patch on "Python/bltinmodule.c" to solve the same issue with 'raw_input', I think it was necessary to be able to use ipython in an interractive MPI session...Our embedded python interpreter had the possibility to use this (it gives a far nicier shell than the standard one), but I think It uses raw_input as entry mechanism...Could you test your patch to see if it work with this? The only drawback I see with this is that it could slow down a bit the parsing when using this function on a non-interractive file...but I doubt this is significative and could be optimized by keeping the call to PyOS_Readline but stripping out the prompt treatment in this case... We now are moving from an embbedded python interpreter to using a standard python...which make the acceptance of the patch more interresting: it would allows us to uses stock python interpreters > 2.x, no need to distribute our own interpretter anymore!!! :) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1232343&group_id=5470 From noreply at sourceforge.net Mon Nov 28 22:36:56 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 28 Nov 2005 13:36:56 -0800 Subject: [Patches] [ python-Patches-1365916 ] [PATCH] mmap fails on AMD64 Message-ID: Patches item #1365916, was opened at 2005-11-24 22:22 Message generated for change (Comment added) made by piman You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1365916&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Modules Group: None Status: Open Resolution: None >Priority: 9 Submitted By: Joe Wreschnig (piman) Assigned to: Nobody/Anonymous (nobody) Summary: [PATCH] mmap fails on AMD64 Initial Comment: mmap_move_method is not 64-bit safe, and fails on the following code: from mmap import mmap f = open('test.out', 'ab+') f.write('ABCDEabcde') f.flush() m = mmap(f.fileno(), 10) m.move(5, 0, 5) m.read(10) To fix this, mmapmodule.c:538 needs to use "LLL:move" instead of "iii:move" (this also fixes #1921169, which changed it from "iii" to "III"). This is in both Python 2.3 and 2.4. ---------------------------------------------------------------------- >Comment By: Joe Wreschnig (piman) Date: 2005-11-28 21:36 Message: Logged In: YES user_id=796 This is causing data corruption. There is also a trivial patch. There is no good reason not to fix it immediately. ---------------------------------------------------------------------- Comment By: Jeff Epler (jepler) Date: 2005-11-27 19:25 Message: Logged In: YES user_id=2772 I haven't tested the patch, but the above testcase does fail on my linux x86_64 machine with "ValueError: source or destination out of range" on the call to m.move(), but succeed on my linux x86 machine. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1365916&group_id=5470 From noreply at sourceforge.net Tue Nov 29 09:58:44 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 29 Nov 2005 00:58:44 -0800 Subject: [Patches] [ python-Patches-1368955 ] UUID module for Python Message-ID: Patches item #1368955, was opened at 2005-11-29 00: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=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. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1368955&group_id=5470 From noreply at sourceforge.net Tue Nov 29 10:14:15 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 29 Nov 2005 01:14:15 -0800 Subject: [Patches] [ python-Patches-1368955 ] UUID module for Python Message-ID: Patches item #1368955, was opened at 2005-11-29 00:58 Message generated for change (Comment added) made by ping 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: Ka-Ping Yee (ping) Date: 2005-11-29 01: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 Nov 29 10:14:37 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 29 Nov 2005 01:14:37 -0800 Subject: [Patches] [ python-Patches-1368955 ] UUID module for Python Message-ID: Patches item #1368955, was opened at 2005-11-29 00:58 Message generated for change (Comment added) made by ping 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: Ka-Ping Yee (ping) Date: 2005-11-29 01: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 01: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 Nov 29 10:14:54 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 29 Nov 2005 01:14:54 -0800 Subject: [Patches] [ python-Patches-1368955 ] UUID module for Python Message-ID: Patches item #1368955, was opened at 2005-11-29 00:58 Message generated for change (Comment added) made by ping 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: Ka-Ping Yee (ping) Date: 2005-11-29 01: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 01: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 01: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 Nov 29 11:54:50 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 29 Nov 2005 02:54:50 -0800 Subject: [Patches] [ python-Patches-1369028 ] Module fixedlenfields for standard lib Message-ID: Patches item #1369028, was opened at 2005-11-29 11: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=1369028&group_id=5470 Please note that this 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: Michael Str?der (stroeder) Assigned to: Nobody/Anonymous (nobody) Summary: Module fixedlenfields for standard lib Initial Comment: Module fixedlenfields for reading and splitting text files with fixed-length fields. It's inspired by module csv, implemented as iterator and I'm using it exactly like module csv. I've used Python 2.4.2 to develop it. Please consider it for inclusion into Python's standard lib. I'll grant copyright to Python Software Foundation. Ciao, Michael. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1369028&group_id=5470 From noreply at sourceforge.net Tue Nov 29 17:36:13 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 29 Nov 2005 08:36:13 -0800 Subject: [Patches] [ python-Patches-1359365 ] Iterating closed StringIO.StringIO Message-ID: Patches item #1359365, was opened at 2005-11-18 01:03 Message generated for change (Comment added) made by 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: Guido van Rossum (gvanrossum) 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: 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 Nov 30 05:28:58 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 29 Nov 2005 20:28:58 -0800 Subject: [Patches] [ python-Patches-1367717 ] replace usage of UserDict with new dict class Message-ID: Patches item #1367717, was opened at 2005-11-27 15:30 Message generated for change (Comment added) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1367717&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Library (Lib) Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: Wolfgang Langner (tds33) Assigned to: Nobody/Anonymous (nobody) Summary: replace usage of UserDict with new dict class Initial Comment: replaces UserDict with new dict base class. Patch against python subversion repository revision 41544 ---------------------------------------------------------------------- >Comment By: Raymond Hettinger (rhettinger) Date: 2005-11-29 23:28 Message: Logged In: YES user_id=80475 Wouldn't this change public cgi classes from old-style to new-style? Could it break user subclasses? Could it break code relying on the existence of self.data (which is unfortunately not a private variable name)? If so, I don't it is worth changing classes that are already documented as obsolete. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1367717&group_id=5470 From noreply at sourceforge.net Wed Nov 30 12:54:34 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 30 Nov 2005 03:54:34 -0800 Subject: [Patches] [ python-Patches-1368955 ] UUID module for Python Message-ID: Patches item #1368955, was opened at 2005-11-29 00:58 Message generated for change (Comment added) made by ping 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: Ka-Ping Yee (ping) Date: 2005-11-30 03: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 01: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 01: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 01: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 Wed Nov 30 16:32:01 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 30 Nov 2005 07:32:01 -0800 Subject: [Patches] [ python-Patches-1370147 ] Fix of bug 1366000 Message-ID: Patches item #1370147, was opened at 2005-11-30 16:32 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1370147&group_id=5470 Please note that this 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: STINNER Victor (haypo) Assigned to: Nobody/Anonymous (nobody) Summary: Fix of bug 1366000 Initial Comment: Here is a fix to bug #1366000 (Bug in bz2 : bz2.BZ2File(...).seek(0,2)) Haypo ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1370147&group_id=5470 From noreply at sourceforge.net Wed Nov 30 19:07:41 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 30 Nov 2005 10:07:41 -0800 Subject: [Patches] [ python-Patches-1324762 ] Compiling and linking main() with C++ compiler Message-ID: Patches item #1324762, was opened at 2005-10-12 13:45 Message generated for change (Comment added) made by cludwig You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1324762&group_id=5470 Please note that this 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: Christoph Ludwig (cludwig) Assigned to: Nobody/Anonymous (nobody) Summary: Compiling and linking main() with C++ compiler Initial Comment: The attached patch proposes a resolution to the discussion started in regarding the compiler (C vs. C++) used to compile python's main() and to link the executable. The patch contains the following changes: 1) The configure option --with-cxx is renamed --with-cxx-main. This was done to avoid surprising the user by the changed meaning. Furthermore, it is now possible that CXX has a different value than provided by --with-cxx-main, so the old name would have been confusing. 2) The compiler used to translate python's main() function is stored in the configure / Makefile variable MAINCC. By default, MAINCC=$(CC). If --with-cxx-main is given (without an appended compiler name), then MAINCC=$(CXX). If --with-cxx-main= is on the configure command line, then MAINCC=. Additionally, configure sets CXX= unless CXX was already set on the configure command line. 3) The command used to link the python executable is (as before) stored in LINKCC. By default, LINKCC='$(PURIFY) $(MAINCC)', i.e. the linker front-end is the compiler used to translate main(). If necessary, LINKCC can be set on the configure command line in which case it won't be altered. 4) If CXX is not set by the user (on the command line or via --with-cxx-main), then configure tries several likely C++ compiler names. CXX is assigned the first name that refers to a callable program in the system. (CXX is set even if python is built with a C compiler only, so distutils can build C++ extensions.) 5) Modules/ccpython.cc is no longer used and can be removed. ---------------------------------------------------------------------- >Comment By: Christoph Ludwig (cludwig) Date: 2005-11-30 19:07 Message: Logged In: YES user_id=1266029 My second patch was indeed broken since it referred to $CC before the call to AC_PROG_CC in configure.in. That caused CC=gcc and CXX=c++ if neither --with-cxx-main nor CC was given on the command line. I am going to upload a third version (cxx-main.patch3) that fixes this problem by moving the code that evaluates --with-cxx-main below AC_PROG_CC. To repeat what I wrote in my last comment: This patch does not address the issue that distutils calls $CC in order to compile C++ source files and calls $CXX in the linking step only. Howevr, the patch tries to ensure that CXX is always set to a sensible value in the Makefile - even if Python is built exclusively with $CC. Thus, distutils has a fighting chance to do the right thing (whatever that is) when building C++ extensions since it uses the value of CXX found in Python's Makefile. ---------------------------------------------------------------------- Comment By: Christoph Ludwig (cludwig) Date: 2005-11-25 11:51 Message: Logged In: YES user_id=1266029 distutils behaves the same way in Python 2.4.1, as I mentioned . My patch does not address this problem at all. (It should be fixed in distutils, but I did not the time to look into it yet.) I am surprised that, on your machine, CC=gcc and CXX=c++. I will look into this next week. ---------------------------------------------------------------------- Comment By: Jack Jansen (jackjansen) Date: 2005-11-25 00:26 Message: Logged In: YES user_id=45365 Well, as I commented on this patch and you quickly followed my suggestions I felt obliged to test your fix, but I'm not sure about the outcome. I built a C++ extension on MacOSX 10.4, gcc 4, framework Python. The good news is that it worked fine, everything built and worked as before. BUT: both with and without your mods my C++ modules are compiled with "gcc", not "g ++" or "c++". Linking is done with "c++", in both cases. I looked at distutils and it seems that it could indeed be the case that CXX is only used for linking and never for compilation, but I'm not 100% sure. Additionally, the Makefile has CC= gcc CXX= c++ which is technically fine on my machine (g++ == c++), but may not work always. Maybe someone who has a machine with both cc/c++ and gcc/g++ installed, and preferrably incompatible compilers, could give this patch a try too? ---------------------------------------------------------------------- Comment By: Christoph Ludwig (cludwig) Date: 2005-11-10 19:42 Message: Logged In: YES user_id=1266029 I am going to upload a revision of my patch that addresses jackjansen's comment: It sets CXX to g++ or c++ if CC is gcc or cc, respectively. Additionally, it writes a warning if configure had to "guess" the C++ compiler and tells the user how to override this guess. The change is in lin with jackjansen's second suggestion. It is pretty straight forward and avoids fragile configure magic. ---------------------------------------------------------------------- Comment By: Jack Jansen (jackjansen) Date: 2005-11-08 23:51 Message: Logged In: YES user_id=45365 One question: is step 4 a wise idea? Picking a random C++ compiler if multiple are available may result in picking a vendor C++ when the user has specified CC=gcc, for example. OTOH, actually doing the configure magic to determine that the selected C++ works together with the c-compiler selected for Python may be overkill too. Maybe try only standard combinations cc/c++ gcc/g++ and otherwise require --with{out}-cxx? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1324762&group_id=5470