[ python-Bugs-1729277 ] SVNVERSION redefined during compilation
Bugs item #1729277, was opened at 2007-06-01 04:28 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1729277&group_id=5470 Please note that this 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.6 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Brett Cannon (bcannon) Assigned to: Kristj�n Valur (krisvale) Summary: SVNVERSION redefined during compilation Initial Comment: I sometimes get the following warning during a build: ./Modules/getbuildinfo.c:23:1: warning: "SVNVERSION" redefined :1:1: warning: this is the location of the previous definition It looks like SVNVERSION is defined in getbuildinfo.c, but a value is also passed in on the command-line in the Makefile when the module is built (line 460). I have no clue why this is being done. -- >Comment By: Martin v. Löwis (loewis) Date: 2007-06-05 09:50 Message: Logged In: YES user_id=21627 Originator: NO The define is indeed needed on Windows. On a Windows installation, there is typically no svnversion binary. However, TortoiseSVN ships with a similar tool, calls subwcrev.exe, which does string interpolation on a template file. So the define in getbuildinfo is the template, and the link process creates a second C file (getbuildinfo1.c) which is then compiled and linked into the interpreter. As subwcrev.exe might not be installed, the build process used to pass a define SUBWCREV on the command line, which was a condition to the definition of SVNVERSION. As Kristjan removed the condition, the Unix build broke. -- Comment By: Brett Cannon (bcannon) Date: 2007-06-04 23:30 Message: Logged In: YES user_id=357491 Originator: YES I figure that much from my experiment. What I am wondering is if the #define in getbuildinfo.c is needed. Does the Windows build need it? Or is it that just to guarantee that the file is self-supported and won't fail to compile if the compile-time define is not passed in? If the #define in the file is required then I vote for the #ifndef solution with an explanation. -- Comment By: Martin v. Löwis (loewis) Date: 2007-06-04 21:58 Message: Logged In: YES user_id=21627 Originator: NO SVNVERSION is passed on Unix. On Unix, there is no subwcrev program. Instead, there is an svnversion program which computes the same string as subwcrev, but prints it on stdout (rather than substituting it in some template file). Therefore, SVNVERSION needs to be passed on the command line. -- Comment By: Brett Cannon (bcannon) Date: 2007-06-04 21:41 Message: Logged In: YES user_id=357491 Originator: YES Well, when I remove the command-line def (the entire -D argument when building getbuildinfo.c) I get no subversion number out of sys.subversion. But when I comment out the SVNVERSION definition instead in getbuildinfo.c I do have the subversion number show up. And I just noticed that when both are defined I have no subversion number (as is the case in the trunk at the moment). I just wrapped the SVNVERSION definition in getbuildinfo.c in a #ifndef and that fixed the problem. but I don't know if doing that will just mask an issue where SVNVERSION should not be defined in getbuildinfo.c at all if it is being passed in during compilation. -- Comment By: Kristj�n Valur (krisvale) Date: 2007-06-04 11:46 Message: Logged In: YES user_id=1262199 Originator: NO The intent was to remove the reliance on the define SUBWCREV so to simplify the actions of make_buildinfo.c. It then only needs to either copy it or run it through subwcrev.exe. Now the code autodetects whether it was passed through subwcrev.exe or not by examining if the string was interpolated. What is the purpose of the SVNVERSION macro passed on the command line? If it has the same value, then maybe a conditional #define will fix this back? Otherwise, rolling back the change will mean that make_buildinfo.c will have to create some other info for the subsequent compilation of getbuildinfo.c to define or undefin SVNWCREV -- Comment By: Martin v. Löwis (loewis) Date: 2007-06-02 01:28 Message: Logged In: YES user_id=21627 Originator: NO This was broken in r55024 | kristjan.jonsson | 2007-04-30 17:17:46 +0200 (Mo, 30 Apr 2007) | 1 line Complete revamp of PCBuild8 directory. Use subdirectories for each project under the main pcbuild solution. Now ma
[ python-Bugs-1729014 ] 0.0 and -0.0 end up referring to the same object
Bugs item #1729014, was opened at 2007-05-31 15:27 Message generated for change (Comment added) made by swfiua You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1729014&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Interpreter Core Group: Python 2.5 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Johnnyg (swfiua) Assigned to: Nobody/Anonymous (nobody) Summary: 0.0 and -0.0 end up referring to the same object Initial Comment: I am not really sure whether this is a bug or a feature. The attached code attempts to demonstrate the problem. I had some code that was trying to change -0.0 to 0.0 so that the accountants I work with don't panic. The code was something like this: if n == -0.0: n = 0.0 Regardless of whether n is -0.0 or 0.0 the test passes (which is good). However after the assignment n is actually -0.0 It looks like python is creating a single object for both -0.0 and 0.0. Whichever appears first within the local scope seems to be the value that actually gets stored. Eg changing the code to if n == 0.0: n = 0.0 gets me the behaviour I wanted. -- >Comment By: Johnnyg (swfiua) Date: 2007-06-05 10:52 Message: Logged In: YES user_id=1529783 Originator: YES I'm happy to flag this as undefined behaviour. I have worked around it in my code, the only issue is that the code is brittle, since I think it relies on the scope of constants -- I'm guessing that is what has changed between 2.4 and 2.5 and could well change in the future. John -- Comment By: Raymond Hettinger (rhettinger) Date: 2007-06-03 06:50 Message: Logged In: YES user_id=80475 Originator: NO I don't see an easy way to make this a defined behavior. FWIW, the OP's code suggests that it makes a more specific test than it does (since -0.0 == 0.0) so the test succeed when n is either -0.0 or 0.0. A quick fix in his code would be to eliminate the -0.0 from the code. def r(n): if n == 0.0: return 0.0 return n or more succinctly: def r(n): return n or 0.0 -- Comment By: Neal Norwitz (nnorwitz) Date: 2007-06-01 05:49 Message: Logged In: YES user_id=33168 Originator: NO This is a regression from 2.4. This seems to always have been undefined behaviour. It looks like it was the result of the compiler changes (code is the same in both versions, but co_consts is diff): Python 2.4.4c1 (#2, Oct 11 2006, 20:00:03) >>> def r(n): ... if n == -0.0: n = 0.0 ... return n ... >>> r.func_code.co_consts (None, 0.0) Python 2.6a0 (trunk, May 30 2007, 21:02:18) >>> def r(n): ... if n == -0.0: n = 0.0 ... return n ... >>> r.func_code.co_consts (None, -0.0) -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1729014&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1729277 ] SVNVERSION redefined during compilation
Bugs item #1729277, was opened at 2007-06-01 02:28 Message generated for change (Comment added) made by krisvale You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1729277&group_id=5470 Please note that this 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.6 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Brett Cannon (bcannon) Assigned to: Kristj�n Valur (krisvale) Summary: SVNVERSION redefined during compilation Initial Comment: I sometimes get the following warning during a build: ./Modules/getbuildinfo.c:23:1: warning: "SVNVERSION" redefined :1:1: warning: this is the location of the previous definition It looks like SVNVERSION is defined in getbuildinfo.c, but a value is also passed in on the command-line in the Makefile when the module is built (line 460). I have no clue why this is being done. -- >Comment By: Kristj�n Valur (krisvale) Date: 2007-06-05 12:18 Message: Logged In: YES user_id=1262199 Originator: NO Here is a suggested patch. I don't have a linux setup to test with this, what do you think? Oh, and sorry for messing this up, I thought subwcrev was used on all platforms :( File Added: woo.patch -- Comment By: Martin v. Löwis (loewis) Date: 2007-06-05 07:50 Message: Logged In: YES user_id=21627 Originator: NO The define is indeed needed on Windows. On a Windows installation, there is typically no svnversion binary. However, TortoiseSVN ships with a similar tool, calls subwcrev.exe, which does string interpolation on a template file. So the define in getbuildinfo is the template, and the link process creates a second C file (getbuildinfo1.c) which is then compiled and linked into the interpreter. As subwcrev.exe might not be installed, the build process used to pass a define SUBWCREV on the command line, which was a condition to the definition of SVNVERSION. As Kristjan removed the condition, the Unix build broke. -- Comment By: Brett Cannon (bcannon) Date: 2007-06-04 21:30 Message: Logged In: YES user_id=357491 Originator: YES I figure that much from my experiment. What I am wondering is if the #define in getbuildinfo.c is needed. Does the Windows build need it? Or is it that just to guarantee that the file is self-supported and won't fail to compile if the compile-time define is not passed in? If the #define in the file is required then I vote for the #ifndef solution with an explanation. -- Comment By: Martin v. Löwis (loewis) Date: 2007-06-04 19:58 Message: Logged In: YES user_id=21627 Originator: NO SVNVERSION is passed on Unix. On Unix, there is no subwcrev program. Instead, there is an svnversion program which computes the same string as subwcrev, but prints it on stdout (rather than substituting it in some template file). Therefore, SVNVERSION needs to be passed on the command line. -- Comment By: Brett Cannon (bcannon) Date: 2007-06-04 19:41 Message: Logged In: YES user_id=357491 Originator: YES Well, when I remove the command-line def (the entire -D argument when building getbuildinfo.c) I get no subversion number out of sys.subversion. But when I comment out the SVNVERSION definition instead in getbuildinfo.c I do have the subversion number show up. And I just noticed that when both are defined I have no subversion number (as is the case in the trunk at the moment). I just wrapped the SVNVERSION definition in getbuildinfo.c in a #ifndef and that fixed the problem. but I don't know if doing that will just mask an issue where SVNVERSION should not be defined in getbuildinfo.c at all if it is being passed in during compilation. -- Comment By: Kristj�n Valur (krisvale) Date: 2007-06-04 09:46 Message: Logged In: YES user_id=1262199 Originator: NO The intent was to remove the reliance on the define SUBWCREV so to simplify the actions of make_buildinfo.c. It then only needs to either copy it or run it through subwcrev.exe. Now the code autodetects whether it was passed through subwcrev.exe or not by examining if the string was interpolated. What is the purpose of the SVNVERSION macro passed on the command line? If it has the same value, then maybe a conditional #define will fix this back? Otherwise, rolling back the change will mean that make_buildinfo.c will have to create some other info for the subsequent compilation of getbuildinfo.c to define or undefin SVNWCREV -- Comment By: Mar
[ python-Bugs-1729014 ] 0.0 and -0.0 end up referring to the same object
Bugs item #1729014, was opened at 2007-05-31 15:27 Message generated for change (Comment added) made by gbrandl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1729014&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Interpreter Core Group: Python 2.5 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Johnnyg (swfiua) Assigned to: Nobody/Anonymous (nobody) Summary: 0.0 and -0.0 end up referring to the same object Initial Comment: I am not really sure whether this is a bug or a feature. The attached code attempts to demonstrate the problem. I had some code that was trying to change -0.0 to 0.0 so that the accountants I work with don't panic. The code was something like this: if n == -0.0: n = 0.0 Regardless of whether n is -0.0 or 0.0 the test passes (which is good). However after the assignment n is actually -0.0 It looks like python is creating a single object for both -0.0 and 0.0. Whichever appears first within the local scope seems to be the value that actually gets stored. Eg changing the code to if n == 0.0: n = 0.0 gets me the behaviour I wanted. -- >Comment By: Georg Brandl (gbrandl) Date: 2007-06-05 14:07 Message: Logged In: YES user_id=849994 Originator: NO See also patch #1678668. -- Comment By: Johnnyg (swfiua) Date: 2007-06-05 10:52 Message: Logged In: YES user_id=1529783 Originator: YES I'm happy to flag this as undefined behaviour. I have worked around it in my code, the only issue is that the code is brittle, since I think it relies on the scope of constants -- I'm guessing that is what has changed between 2.4 and 2.5 and could well change in the future. John -- Comment By: Raymond Hettinger (rhettinger) Date: 2007-06-03 06:50 Message: Logged In: YES user_id=80475 Originator: NO I don't see an easy way to make this a defined behavior. FWIW, the OP's code suggests that it makes a more specific test than it does (since -0.0 == 0.0) so the test succeed when n is either -0.0 or 0.0. A quick fix in his code would be to eliminate the -0.0 from the code. def r(n): if n == 0.0: return 0.0 return n or more succinctly: def r(n): return n or 0.0 -- Comment By: Neal Norwitz (nnorwitz) Date: 2007-06-01 05:49 Message: Logged In: YES user_id=33168 Originator: NO This is a regression from 2.4. This seems to always have been undefined behaviour. It looks like it was the result of the compiler changes (code is the same in both versions, but co_consts is diff): Python 2.4.4c1 (#2, Oct 11 2006, 20:00:03) >>> def r(n): ... if n == -0.0: n = 0.0 ... return n ... >>> r.func_code.co_consts (None, 0.0) Python 2.6a0 (trunk, May 30 2007, 21:02:18) >>> def r(n): ... if n == -0.0: n = 0.0 ... return n ... >>> r.func_code.co_consts (None, -0.0) -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1729014&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1729277 ] SVNVERSION redefined during compilation
Bugs item #1729277, was opened at 2007-06-01 04:28 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1729277&group_id=5470 Please note that this 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.6 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Brett Cannon (bcannon) Assigned to: Kristj�n Valur (krisvale) Summary: SVNVERSION redefined during compilation Initial Comment: I sometimes get the following warning during a build: ./Modules/getbuildinfo.c:23:1: warning: "SVNVERSION" redefined :1:1: warning: this is the location of the previous definition It looks like SVNVERSION is defined in getbuildinfo.c, but a value is also passed in on the command-line in the Makefile when the module is built (line 460). I have no clue why this is being done. -- >Comment By: Martin v. Löwis (loewis) Date: 2007-06-05 19:23 Message: Logged In: YES user_id=21627 Originator: NO Looks fine to me, please apply. -- Comment By: Kristj�n Valur (krisvale) Date: 2007-06-05 14:18 Message: Logged In: YES user_id=1262199 Originator: NO Here is a suggested patch. I don't have a linux setup to test with this, what do you think? Oh, and sorry for messing this up, I thought subwcrev was used on all platforms :( File Added: woo.patch -- Comment By: Martin v. Löwis (loewis) Date: 2007-06-05 09:50 Message: Logged In: YES user_id=21627 Originator: NO The define is indeed needed on Windows. On a Windows installation, there is typically no svnversion binary. However, TortoiseSVN ships with a similar tool, calls subwcrev.exe, which does string interpolation on a template file. So the define in getbuildinfo is the template, and the link process creates a second C file (getbuildinfo1.c) which is then compiled and linked into the interpreter. As subwcrev.exe might not be installed, the build process used to pass a define SUBWCREV on the command line, which was a condition to the definition of SVNVERSION. As Kristjan removed the condition, the Unix build broke. -- Comment By: Brett Cannon (bcannon) Date: 2007-06-04 23:30 Message: Logged In: YES user_id=357491 Originator: YES I figure that much from my experiment. What I am wondering is if the #define in getbuildinfo.c is needed. Does the Windows build need it? Or is it that just to guarantee that the file is self-supported and won't fail to compile if the compile-time define is not passed in? If the #define in the file is required then I vote for the #ifndef solution with an explanation. -- Comment By: Martin v. Löwis (loewis) Date: 2007-06-04 21:58 Message: Logged In: YES user_id=21627 Originator: NO SVNVERSION is passed on Unix. On Unix, there is no subwcrev program. Instead, there is an svnversion program which computes the same string as subwcrev, but prints it on stdout (rather than substituting it in some template file). Therefore, SVNVERSION needs to be passed on the command line. -- Comment By: Brett Cannon (bcannon) Date: 2007-06-04 21:41 Message: Logged In: YES user_id=357491 Originator: YES Well, when I remove the command-line def (the entire -D argument when building getbuildinfo.c) I get no subversion number out of sys.subversion. But when I comment out the SVNVERSION definition instead in getbuildinfo.c I do have the subversion number show up. And I just noticed that when both are defined I have no subversion number (as is the case in the trunk at the moment). I just wrapped the SVNVERSION definition in getbuildinfo.c in a #ifndef and that fixed the problem. but I don't know if doing that will just mask an issue where SVNVERSION should not be defined in getbuildinfo.c at all if it is being passed in during compilation. -- Comment By: Kristj�n Valur (krisvale) Date: 2007-06-04 11:46 Message: Logged In: YES user_id=1262199 Originator: NO The intent was to remove the reliance on the define SUBWCREV so to simplify the actions of make_buildinfo.c. It then only needs to either copy it or run it through subwcrev.exe. Now the code autodetects whether it was passed through subwcrev.exe or not by examining if the string was interpolated. What is the purpose of the SVNVERSION macro passed on the command line? If it has the same value, then maybe a conditional #define will fix this back? Otherwise, rolling back the change will mean that m
[ python-Bugs-1715581 ] Const(None) in compiler.ast.Return.value
Bugs item #1715581, was opened at 2007-05-09 05:53 Message generated for change (Comment added) made by collinwinter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1715581&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library Group: Python 2.5 >Status: Closed >Resolution: Wont Fix Priority: 5 Private: No Submitted By: Ali Gholami Rudi (aligrudi) >Assigned to: Collin Winter (collinwinter) Summary: Const(None) in compiler.ast.Return.value Initial Comment: The problem happens when:: import compiler class Visitor(object): def visitReturn(self, node): print node.value source = """ def f(): return """ compiler.walk(compiler.parse(source), Visitor()) I think the value of `node.value` should have been `None` instead of `Const(None)` as it is for most other nodes when an optional part is missing. The same problem (getting `Const(None)` instead of `None`) exists for `Sliceobj.nodes[i]` and `Discard.expr`. -- >Comment By: Collin Winter (collinwinter) Date: 2007-06-05 13:47 Message: Logged In: YES user_id=1344176 Originator: NO "return" is syntactic shorthand for "return None", so Const(None) is the right value; same thing for Sliceobj. This isn't a bug. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1715581&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1711608 ] CGIHttpServer fails if python exe has spaces
Bugs item #1711608, was opened at 2007-05-02 20:34 Message generated for change (Comment added) made by collinwinter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1711608&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Extension Modules Group: Python 2.5 >Status: Closed >Resolution: Duplicate Priority: 5 Private: No Submitted By: Steve Cassidy (stevecassidy) Assigned to: Nobody/Anonymous (nobody) Summary: CGIHttpServer fails if python exe has spaces Initial Comment: In addition to the problem noted in #1436206 with spaces in the file names of scripts being executed, if Python has been installed in a directory with spaces (C:\Program Files\Python) the server will fail to execute the script because the name of the executable is not quoted properly. My attempts to fix this have failed since just putting quotes around the exe name "C:\\Program Files\..." doesn't work, however we have found that just quoting the part of the path with spaces 'C:\\"Program Files"\\...' will work. It seems a bit odd that this bug has persisted for so long. A fix would be nice since this module is really good to give to my students (doing python web development for the first time) so they don't have to worry about server installation issues. Steve -- >Comment By: Collin Winter (collinwinter) Date: 2007-06-05 13:56 Message: Logged In: YES user_id=1344176 Originator: NO This issue is a duplicate of #1436206. Closing. -- Comment By: Martin v. Löwis (loewis) Date: 2007-05-08 15:11 Message: Logged In: YES user_id=21627 Originator: NO I don't find it odd that the bug persisted for so long: there is a reason that the default installation of Python does *not* go into "Program Files", as spaces in file names produce endless problems. Quoting the paths should work, though - don't forget to quote arguments as well. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1711608&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-994023 ] threads duplicated on fork() prevent child from terminating
Bugs item #994023, was opened at 2004-07-19 20:59 Message generated for change (Comment added) made by imbaczek You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=994023&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Threads Group: Python 2.3 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Laurentiu C. Badea (L.C.) (wotevah) Assigned to: Nobody/Anonymous (nobody) Summary: threads duplicated on fork() prevent child from terminating Initial Comment: (This is a repost from an older c.l.py submission to prevent losing track of it) It looks as if fork() duplicates the entire threads info structure in the new process. This causes child processes to attempt to handle or wait for nonexistent threads and causes them to hang on exit. Perhaps clearing Python's internal thread info after the fork() is all that is needed to fix this (the fact that the threads themselves are not duplicated seems to suggest that this was indeed the intention - and also is POSIXly correct). Original post with sample code for the problem is here (also attached for your convenience): http://groups.google.com/groups?hl=en&lr=&ie=UTF-8&selm=e0bf36b5.0306191548.73b7383%40posting.google.com The "bug" manifests itself by the program not exiting voluntarily. The two processes created need to be terminated individually. Last tested on 2.3.3 (Fedora Core 2), but present since 2.1 I believe. -- Comment By: Marek Baczynski (imbaczek) Date: 2007-06-05 20:00 Message: Logged In: YES user_id=838849 Originator: NO Just ran into this in 2.5 on debian testing. Workaround is to setDaemon(True) on the offending threads; this is not documented anywhere, though. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=994023&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1730322 ] getattr([], '__eq__')(some-object) is NotImplemented
Bugs item #1730322, was opened at 2007-06-03 13:10 Message generated for change (Comment added) made by collinwinter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1730322&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Type/class unification Group: Python 2.5 >Status: Closed >Resolution: Wont Fix Priority: 5 Private: No Submitted By: L. Peter Deutsch (lpd) Assigned to: Nobody/Anonymous (nobody) Summary: getattr([], '__eq__')(some-object) is NotImplemented Initial Comment: Consider: a = [] class B: pass class C(object): pass print a == B() print a == C() m = getattr(a, '__eq__') print m(B()) print m(C()) I think this should print 'False' 4 times, but it actually prints: False False NotImplemented NotImplemented If this isn't a bug, please explain why. -- >Comment By: Collin Winter (collinwinter) Date: 2007-06-05 14:23 Message: Logged In: YES user_id=1344176 Originator: NO This isn't a bug because a.__eq__() isn't the whole story on equivalence testing. NotImplemented is a perfectly valid return value for a comparison method; in this case, it signals the == operator to try a different approach. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1730322&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1713252 ] character set in Japanese on Ubuntu distribution
Bugs item #1713252, was opened at 2007-05-05 01:16 Message generated for change (Comment added) made by collinwinter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1713252&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: IDLE Group: Python 2.5 Status: Open Resolution: Fixed Priority: 5 Private: No Submitted By: Christopher Grell (cgrell) Assigned to: Nobody/Anonymous (nobody) Summary: character set in Japanese on Ubuntu distribution Initial Comment: I tried to use IDLE on new Ubuntu 7.04 and the window opens with Japanese character set -- >Comment By: Collin Winter (collinwinter) Date: 2007-06-05 14:26 Message: Logged In: YES user_id=1344176 Originator: NO Please post a legible screenshot. -- Comment By: Martin v. Löwis (loewis) Date: 2007-05-10 18:35 Message: Logged In: YES user_id=21627 Originator: NO Why do you think it is Japanese? It is fairly unreadable, but it looks like Latin to me. In particular, I can recognize the text "Personal firewall software may warn..." -- Comment By: Christopher Grell (cgrell) Date: 2007-05-10 16:11 Message: Logged In: YES user_id=1785859 Originator: YES File Added: Screenshot-Python Shell.png -- Comment By: Martin v. Löwis (loewis) Date: 2007-05-08 15:05 Message: Logged In: YES user_id=21627 Originator: NO What do you mean by "opens with Japanese character set"? Can you provide a screenshot? Can you figure out what font it is using? -- Comment By: Christopher Grell (cgrell) Date: 2007-05-06 22:42 Message: Logged In: YES user_id=1785859 Originator: YES Changing default character size to 20 removes the issue -- Comment By: Georg Brandl (gbrandl) Date: 2007-05-05 03:08 Message: Logged In: YES user_id=849994 Originator: NO As this is certainly not the case in other distributions, this is something you should file with the Ubuntu bug tracker. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1713252&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1712742 ] pprint handles depth argument incorrectly
Bugs item #1712742, was opened at 2007-05-04 09:47 Message generated for change (Comment added) made by collinwinter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1712742&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. >Category: Python Library Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Dmitrii Tisnek (dimaq) >Assigned to: Neal Norwitz (nnorwitz) Summary: pprint handles depth argument incorrectly Initial Comment: pprint.pprint( [ ], depth=0) AssertionError: depth must be > 0 pprint.pprint( [ ], depth=0.5) [[...]] pprint.pprint( [ ], depth=1) [[[...]]] I would like to see the root (that is [...]) with depth=0 (or depth=1 if you insist), either way, [[[...]]] for depth=1 is incorrect. -- >Comment By: Collin Winter (collinwinter) Date: 2007-06-05 14:32 Message: Logged In: YES user_id=1344176 Originator: NO The correct patch number is 1713041. Neal, assigning to you so you can close this at the same time as the patch. -- Comment By: Raghuram Devarakonda (draghuram) Date: 2007-05-04 15:17 Message: Logged In: YES user_id=984087 Originator: NO I created patch 1712742 to fix this. BTW, I think that a depth of 1 should mean the top level object. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1712742&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1719423 ] Python package support not properly documented
Bugs item #1719423, was opened at 2007-05-15 12:39 Message generated for change (Comment added) made by collinwinter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1719423&group_id=5470 Please note that this 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: 6 Private: No Submitted By: Michael Abbott (araneidae) Assigned to: Nobody/Anonymous (nobody) Summary: Python package support not properly documented Initial Comment: I can sum this report up most simply by quoting the message below: http://mail.python.org/pipermail/python-list/2001-October/107699.html Note that this message was posted 5 1/2 years ago (by myself, as it happens), had no follow up, and the problem referred to remains current! (The chapter on "import" is now section 6.12: nothing else has changed.) The comment below that "presum[ably] nothing significant has changed" seems less than probable now! I was looking to understand modules and packages a bit better: they don't behave like proper first class objects (is module.sub_module an attribute? not really), and so the lack of definitive documentation in this area is sad, particularly after such a long time. Body of original message follows Package support in Python 2 Michael Abbott michael at rcp.co.uk Wed Oct 3 10:58:08 CEST 2001 Is there up to date documentation for package support in Python 2? Section 6.11 of the "Python Reference Manual" has the following nice quote: [XXX Can't be bothered to spell this out right now; see the URL http://www.python.org/doc/essays/packages.html for more details, also about how the module search works from inside a package.] and the referred URL documents Python 1.5. I presume that nothing significant has changed recently, but it's certainly disconcerting for something as fundamental as module importing to not actually be part of the core language documentation! -- >Comment By: Collin Winter (collinwinter) Date: 2007-06-05 14:35 Message: Logged In: YES user_id=1344176 Originator: NO Hi Michael, would you be interested in working on a docs patch for this? -- Comment By: Georg Brandl (gbrandl) Date: 2007-05-15 16:41 Message: Logged In: YES user_id=849994 Originator: NO You are certainly right that this should be documented properly. BTW, after you import x.y, y is an attribute of module x. When you write "x.y.foo", Python knows nothing about modules any more, it just handles attribute access of arbitrary objects which happen to be modules. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1719423&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1714451 ] subprocess.py problems errors when calling cmd.exe
Bugs item #1714451, was opened at 2007-05-07 13:13
Message generated for change (Comment added) made by collinwinter
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1714451&group_id=5470
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Windows
Group: Python 2.5
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: tzellman (tzellman)
Assigned to: Nobody/Anonymous (nobody)
Summary: subprocess.py problems errors when calling cmd.exe
Initial Comment:
An example:
>>> import subprocess
>>> proc = subprocess.Popen('"c:\Windows\system\ping.exe" "localhost"',
>>> shell=1, stdout=subprocess.PIPE, stderr=subprocess.PIPE)
'c:\Windows\system32\ping.exe" "localhost' is not recognized as an internal or
external command, operable program or batch file.
This normally works from the cmd.exe prompt, so the command line is being
passed incorrectly in the subprocess module.
My ACTUAL use case arises when I want to call the Microsoft compiler (CL.exe),
and add include directories that have spaces in the name. For example:
"C:\Program Files\Microsoft Visual Studio 8\VC\BIN\CL.exe" /TC /O2 /DNDEBUG /W3
/nologo /c /EHsc /errorReport:prompt /Idefault\ /I.. /I. /Idefault
/I"C:\Program Files\GnuWin32" /DWIN32 ..\pcreposix.c /Fodefault\pcreposix.obj
The fix for this problem is to modify line 765 in subprocess.py, replacing it
with:
args = comspec + " /s /c \"%s\"" % args.replace('""', '"')
The /s tells cmd.exe not to re-format the command line. We then encase the
entire command line in double quotes. I also replace occurrences of "" with "
in the arg string, in case the user already encased the command in double
quotes.
With this fix, the commands execute correctly.
--
>Comment By: Collin Winter (collinwinter)
Date: 2007-06-05 14:36
Message:
Logged In: YES
user_id=1344176
Originator: NO
tzellman, could you work up a real patch and a test case for this? Thanks.
--
Comment By: Gabriel Genellina (gagenellina)
Date: 2007-05-07 17:06
Message:
Logged In: YES
user_id=479790
Originator: NO
Use a list of arguments instead, and please remember to use raw strings or
double backslashes:
proc = subprocess.Popen([r"c:\Windows\system\ping.exe","localhost"],
shell=1, stdout=subprocess.PIPE, stderr=subprocess.PIPE)
--
Comment By: tzellman (tzellman)
Date: 2007-05-07 13:20
Message:
Logged In: YES
user_id=1090960
Originator: YES
This could likely be rejected.
I realize a solution to this w/o modifying the Python source is to encase
the expression yourself in double quotes. So, the example given would look
like:
>>> import subprocess
>>> proc = subprocess.Popen('""c:\Windows\system\ping.exe" "localhost""',
shell=1, stdout=subprocess.PIPE, stderr=subprocess.PIPE)
And that will work.
Sorry for any confusion.
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1714451&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1704287 ] must run "make" before "make install"
Bugs item #1704287, was opened at 2007-04-20 09:01 Message generated for change (Comment added) made by collinwinter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1704287&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Build Group: Python 2.5 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Joseph VanAndel (vanandel) Assigned to: Nobody/Anonymous (nobody) Summary: must run "make" before "make install" Initial Comment: "make install" fails unless you've already run "make". Not a show-stopper, but specifying the correct dependencies for "make install" would force everything to be built before it was installed. -- >Comment By: Collin Winter (collinwinter) Date: 2007-06-05 14:43 Message: Logged In: YES user_id=1344176 Originator: NO What do you mean by "fails"? What platform are you using? What version of make are you using? I'm unable to reproduce this on Ubuntu Dapper Drake (using GNU Make 3.81beta4). -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1704287&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1712742 ] pprint handles depth argument incorrectly
Bugs item #1712742, was opened at 2007-05-04 09:47 Message generated for change (Comment added) made by draghuram You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1712742&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Dmitrii Tisnek (dimaq) Assigned to: Neal Norwitz (nnorwitz) Summary: pprint handles depth argument incorrectly Initial Comment: pprint.pprint( [ ], depth=0) AssertionError: depth must be > 0 pprint.pprint( [ ], depth=0.5) [[...]] pprint.pprint( [ ], depth=1) [[[...]]] I would like to see the root (that is [...]) with depth=0 (or depth=1 if you insist), either way, [[[...]]] for depth=1 is incorrect. -- Comment By: Raghuram Devarakonda (draghuram) Date: 2007-06-05 15:12 Message: Logged In: YES user_id=984087 Originator: NO Of course. Thanks for the correction. -- Comment By: Collin Winter (collinwinter) Date: 2007-06-05 14:32 Message: Logged In: YES user_id=1344176 Originator: NO The correct patch number is 1713041. Neal, assigning to you so you can close this at the same time as the patch. -- Comment By: Raghuram Devarakonda (draghuram) Date: 2007-05-04 15:17 Message: Logged In: YES user_id=984087 Originator: NO I created patch 1712742 to fix this. BTW, I think that a depth of 1 should mean the top level object. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1712742&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1728403 ] reading from malformed big5 document hangs cpython
Bugs item #1728403, was opened at 2007-05-31 00:36
Message generated for change (Comment added) made by perky
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1728403&group_id=5470
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Interpreter Core
Group: Python 2.4
>Status: Closed
>Resolution: Fixed
Priority: 7
Private: No
Submitted By: tsuraan (tsuraan3)
Assigned to: Hye-Shik Chang (perky)
Summary: reading from malformed big5 document hangs cpython
Initial Comment:
Python enters some sort of infinite loop when attempting to read data from a
malformed file that is big5 encoded (using the codecs library). This behaviour
can be observed under Linux and FreeBSD, using Python 2.4 and 2.5 . A really
simple example illustrating the bug follows:
Python 2.4.4 (#1, May 15 2007, 13:33:55)
[GCC 4.1.1 (Gentoo 4.1.1-r3)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import codecs
>>> fname='out'
>>> outfd=open(fname,'w')
>>> outfd.write(chr(243))
>>> outfd.close()
>>>
>>> infd= codecs.open(fname, encoding='big5')
>>> infd.read(1024)
And then, it hangs forever. If I instead use the following code:
Python 2.5 (r25:51908, Jan 8 2007, 19:09:28)
[GCC 3.4.5 (Gentoo 3.4.5-r1, ssp-3.4.5-1.0, pie-8.7.9)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import codecs, signal
>>> fname='out'
>>> def handler(*args):
... raise Exception("boo!")
...
>>> signal.signal(signal.SIGALRM, handler)
0
>>> outfd=open(fname, 'w')
>>> outfd.write (chr(243))
>>> outfd.close()
>>>
>>> infd=codecs.open(fname, encoding='big5')
>>> signal.alarm(5)
0
>>> infd.read(1024)
The program still hangs forever. The program can be made to crash if I don't
install a signal handler at all, but that's pretty lame. It looks like the
entire interpreter is being locked up by this read, so I don't think there's
likely to be a pure-python workaround, but I thought it would be a good but to
have out there so a future version of python can (hopefully) fix this.
--
>Comment By: Hye-Shik Chang (perky)
Date: 2007-06-06 04:31
Message:
Logged In: YES
user_id=55188
Originator: NO
Thank you for the reporting, tsuraan, and thank you for the investigation,
Neal.
The bug is related to a logic that detects whether file reached end of
file. I verified that any other part of CJKCodecs has such a logic.
Fixed and committed in SVN.
trunk 55770, release25-maint 55774, release24-maint 55772.
--
Comment By: Neal Norwitz (nnorwitz)
Date: 2007-05-31 13:51
Message:
Logged In: YES
user_id=33168
Originator: NO
Bumping the priority since this is about as bad as a crash.
--
Comment By: Neal Norwitz (nnorwitz)
Date: 2007-05-31 13:49
Message:
Logged In: YES
user_id=33168
Originator: NO
Hye-Shik, could you take a look at this. There's an infinite loop in
Modules/cjkcodecs/multibytecodec.c mbstreamreader_iread(). rsize == 1 each
iteration. I don't know if there are more places that might have this
problem.
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1728403&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1728403 ] reading from malformed big5 document hangs cpython
Bugs item #1728403, was opened at 2007-05-31 00:36
Message generated for change (Comment added) made by perky
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1728403&group_id=5470
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Interpreter Core
Group: Python 2.4
Status: Closed
Resolution: Fixed
Priority: 7
Private: No
Submitted By: tsuraan (tsuraan3)
Assigned to: Hye-Shik Chang (perky)
Summary: reading from malformed big5 document hangs cpython
Initial Comment:
Python enters some sort of infinite loop when attempting to read data from a
malformed file that is big5 encoded (using the codecs library). This behaviour
can be observed under Linux and FreeBSD, using Python 2.4 and 2.5 . A really
simple example illustrating the bug follows:
Python 2.4.4 (#1, May 15 2007, 13:33:55)
[GCC 4.1.1 (Gentoo 4.1.1-r3)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import codecs
>>> fname='out'
>>> outfd=open(fname,'w')
>>> outfd.write(chr(243))
>>> outfd.close()
>>>
>>> infd= codecs.open(fname, encoding='big5')
>>> infd.read(1024)
And then, it hangs forever. If I instead use the following code:
Python 2.5 (r25:51908, Jan 8 2007, 19:09:28)
[GCC 3.4.5 (Gentoo 3.4.5-r1, ssp-3.4.5-1.0, pie-8.7.9)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import codecs, signal
>>> fname='out'
>>> def handler(*args):
... raise Exception("boo!")
...
>>> signal.signal(signal.SIGALRM, handler)
0
>>> outfd=open(fname, 'w')
>>> outfd.write (chr(243))
>>> outfd.close()
>>>
>>> infd=codecs.open(fname, encoding='big5')
>>> signal.alarm(5)
0
>>> infd.read(1024)
The program still hangs forever. The program can be made to crash if I don't
install a signal handler at all, but that's pretty lame. It looks like the
entire interpreter is being locked up by this read, so I don't think there's
likely to be a pure-python workaround, but I thought it would be a good but to
have out there so a future version of python can (hopefully) fix this.
--
>Comment By: Hye-Shik Chang (perky)
Date: 2007-06-06 04:34
Message:
Logged In: YES
user_id=55188
Originator: NO
in my comment:
> The bug is related to a logic that detects whether file reached end of
file. I verified that any other part of CJKCodecs has such a logic.
I meant "no part". sorry. :)
--
Comment By: Hye-Shik Chang (perky)
Date: 2007-06-06 04:31
Message:
Logged In: YES
user_id=55188
Originator: NO
Thank you for the reporting, tsuraan, and thank you for the investigation,
Neal.
The bug is related to a logic that detects whether file reached end of
file. I verified that any other part of CJKCodecs has such a logic.
Fixed and committed in SVN.
trunk 55770, release25-maint 55774, release24-maint 55772.
--
Comment By: Neal Norwitz (nnorwitz)
Date: 2007-05-31 13:51
Message:
Logged In: YES
user_id=33168
Originator: NO
Bumping the priority since this is about as bad as a crash.
--
Comment By: Neal Norwitz (nnorwitz)
Date: 2007-05-31 13:49
Message:
Logged In: YES
user_id=33168
Originator: NO
Hye-Shik, could you take a look at this. There's an infinite loop in
Modules/cjkcodecs/multibytecodec.c mbstreamreader_iread(). rsize == 1 each
iteration. I don't know if there are more places that might have this
problem.
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1728403&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1731706 ] tkinter memory leak problem
Bugs item #1731706, was opened at 2007-06-05 15:47 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1731706&group_id=5470 Please note that this 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 Private: No Submitted By: Robert Hancock (robhancock) Assigned to: Martin v. Löwis (loewis) Summary: tkinter memory leak problem Initial Comment: We have a Python application which displays a GUI using Tkinter and Pmw. We have seen that over time the memory usage of the app seems to continuously increase and eventually use up all of the system's RAM. I ran the app under Valgrind, and this leak seems to account for most of the memory that it detects as being leaked: ==31141== 2,630,208 (806,400 direct, 1,823,808 indirect) bytes in 21 blocks are definitely lost in loss record 156 of 159 ==31141==at 0x4A05809: malloc (vg_replace_malloc.c:149) ==31141==by 0x368268844A: TclThreadAllocObj (in /usr/lib64/libtcl8.4.so) ==31141==by 0x3682686BA0: Tcl_NewStringObj (in /usr/lib64/libtcl8.4.so) ==31141==by 0x8B3B258: AsObj (_tkinter.c:902) ==31141==by 0x8B3BB1C: Tkapp_CallArgs (_tkinter.c:1149) ==31141==by 0x8B3BD67: Tkapp_CallProc (_tkinter.c:1224) ==31141==by 0x36826786D4: Tcl_ServiceEvent (in /usr/lib64/libtcl8.4.so) ==31141==by 0x3682678A20: Tcl_DoOneEvent (in /usr/lib64/libtcl8.4.so) ==31141==by 0x8B3F55B: Tkapp_MainLoop (_tkinter.c:2532) ==31141==by 0x36900949D9: PyEval_EvalFrame (in /usr/lib64/libpython2.4.so.1.0) ==31141==by 0x3690095904: PyEval_EvalCodeEx (in /usr/lib64/libpython2.4.so.1.0) ==31141==by 0x369009405E: PyEval_EvalFrame (in /usr/lib64/libpython2.4.so.1.0) ==31141==by 0x3690094485: PyEval_EvalFrame (in /usr/lib64/libpython2.4.so.1.0) ==31141==by 0x3690095904: PyEval_EvalCodeEx (in /usr/lib64/libpython2.4.so.1.0) ==31141==by 0x3690095951: PyEval_EvalCode (in /usr/lib64/libpython2.4.so.1.0) ==31141==by 0x36900B1EA8: (within /usr/lib64/libpython2.4.so.1.0) ==31141==by 0x36900B3357: PyRun_SimpleFileExFlags (in /usr/lib64/libpython2.4.so.1.0) ==31141==by 0x36900B979C: Py_Main (in /usr/lib64/libpython2.4.so.1.0) ==31141==by 0x368161D8A3: (below main) (in /lib64/libc-2.5.so) Looking at the code in _tkinter.c, I am not sure how the Tkapp_CallDeallocArgs function is supposed to get called in the case where we push the request onto the Tcl interpreter thread in Tkapp_Call. That call is what would presumably release this allocated memory. This is using Python 2.4.3 and tcl/tk 8.4.13. Looking at Python SVN, there does not seem to be any relevant code changes in _tkinter.c in later versions.. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1731706&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1704287 ] must run "make" before "make install"
Bugs item #1704287, was opened at 2007-04-20 07:01 Message generated for change (Comment added) made by vanandel You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1704287&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Build Group: Python 2.5 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Joseph VanAndel (vanandel) Assigned to: Nobody/Anonymous (nobody) Summary: must run "make" before "make install" Initial Comment: "make install" fails unless you've already run "make". Not a show-stopper, but specifying the correct dependencies for "make install" would force everything to be built before it was installed. -- >Comment By: Joseph VanAndel (vanandel) Date: 2007-06-05 15:55 Message: Logged In: YES user_id=6581 Originator: YES With CentOS 5 (clone of Redhat Enterprise 5), if you run "make install" before running "make", the make stops with the error: Compiling /opt/local/lib/python2.5/xml/sax/saxutils.py ... Compiling /opt/local/lib/python2.5/xml/sax/xmlreader.py ... Compiling /opt/local/lib/python2.5/xmllib.py ... Compiling /opt/local/lib/python2.5/xmlrpclib.py ... Compiling /opt/local/lib/python2.5/zipfile.py ... make: *** [libinstall] Error 1 make version is 3.81 -- Comment By: Collin Winter (collinwinter) Date: 2007-06-05 12:43 Message: Logged In: YES user_id=1344176 Originator: NO What do you mean by "fails"? What platform are you using? What version of make are you using? I'm unable to reproduce this on Ubuntu Dapper Drake (using GNU Make 3.81beta4). -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1704287&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1719423 ] Python package support not properly documented
Bugs item #1719423, was opened at 2007-05-15 17:39 Message generated for change (Comment added) made by araneidae You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1719423&group_id=5470 Please note that this 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: 6 Private: No Submitted By: Michael Abbott (araneidae) Assigned to: Nobody/Anonymous (nobody) Summary: Python package support not properly documented Initial Comment: I can sum this report up most simply by quoting the message below: http://mail.python.org/pipermail/python-list/2001-October/107699.html Note that this message was posted 5 1/2 years ago (by myself, as it happens), had no follow up, and the problem referred to remains current! (The chapter on "import" is now section 6.12: nothing else has changed.) The comment below that "presum[ably] nothing significant has changed" seems less than probable now! I was looking to understand modules and packages a bit better: they don't behave like proper first class objects (is module.sub_module an attribute? not really), and so the lack of definitive documentation in this area is sad, particularly after such a long time. Body of original message follows Package support in Python 2 Michael Abbott michael at rcp.co.uk Wed Oct 3 10:58:08 CEST 2001 Is there up to date documentation for package support in Python 2? Section 6.11 of the "Python Reference Manual" has the following nice quote: [XXX Can't be bothered to spell this out right now; see the URL http://www.python.org/doc/essays/packages.html for more details, also about how the module search works from inside a package.] and the referred URL documents Python 1.5. I presume that nothing significant has changed recently, but it's certainly disconcerting for something as fundamental as module importing to not actually be part of the core language documentation! -- >Comment By: Michael Abbott (araneidae) Date: 2007-06-05 22:46 Message: Logged In: YES user_id=250634 Originator: YES Hi Collin, Well, that's not a terrible idea. I'll take a look and follow up later. -- Comment By: Collin Winter (collinwinter) Date: 2007-06-05 19:35 Message: Logged In: YES user_id=1344176 Originator: NO Hi Michael, would you be interested in working on a docs patch for this? -- Comment By: Georg Brandl (gbrandl) Date: 2007-05-15 21:41 Message: Logged In: YES user_id=849994 Originator: NO You are certainly right that this should be documented properly. BTW, after you import x.y, y is an attribute of module x. When you write "x.y.foo", Python knows nothing about modules any more, it just handles attribute access of arbitrary objects which happen to be modules. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1719423&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1731717 ] race condition in subprocess module
Bugs item #1731717, was opened at 2007-06-05 17:19
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1731717&group_id=5470
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Library
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: dsagal (dsagal)
Assigned to: Nobody/Anonymous (nobody)
Summary: race condition in subprocess module
Initial Comment:
Python's subprocess module has a race condition: Popen() constructor has a call
to global "_cleanup()" function on whenever a Popen object gets created, and
that call causes a check for all pending Popen objects whether their subprocess
has exited - i.e. the poll() method is called for every active Popen object.
Now, if I create Popen object "foo" in one thread, and then a.wait(), and
meanwhile I create another Popen object "bar" in another thread, then a.poll()
might get called by _clean() right at the time when my first thread is running
a.wait(). But those are not synchronized - each calls os.waitpid() if
returncode is None, but the section which checks returncode and calls
os.waitpid() is not protected as a critical section should be.
The following code illustrates the problem, and is known to break reasonably
consistenly with Python2.4. Changes to subprocess in Python2.5 seems to address
a somewhat related problem, but not this one.
import sys, os, threading, subprocess, time
class X(threading.Thread):
def __init__(self, *args, **kwargs):
super(X, self).__init__(*args, **kwargs)
self.start()
def tt():
s = subprocess.Popen(("/bin/ls", "-a", "/tmp"), stdout=subprocess.PIPE,
universal_newlines=True)
# time.sleep(1)
s.communicate()[0]
for i in xrange(1000):
X(target = tt)
This typically gives a few dozen errors like these:
Exception in thread Thread-795:
Traceback (most recent call last):
File "/usr/lib/python2.4/threading.py", line 442, in __bootstrap
self.run()
File "/usr/lib/python2.4/threading.py", line 422, in run
self.__target(*self.__args, **self.__kwargs)
File "z.py", line 21, in tt
s.communicate()[0]
File "/usr/lib/python2.4/subprocess.py", line 1083, in communicate
self.wait()
File "/usr/lib/python2.4/subprocess.py", line 1007, in wait
pid, sts = os.waitpid(self.pid, 0)
OSError: [Errno 10] No child processes
Note that uncommenting time.sleep(1) fixes the problem. So does wrapping
subprocess.poll() and wait() with a lock. So does removing the call to global
_cleanup() in Popen constructor.
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1731717&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1711608 ] CGIHttpServer fails if python exe has spaces
Bugs item #1711608, was opened at 2007-05-03 10:34 Message generated for change (Comment added) made by stevecassidy You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1711608&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Extension Modules Group: Python 2.5 Status: Closed Resolution: Duplicate Priority: 5 Private: No Submitted By: Steve Cassidy (stevecassidy) Assigned to: Nobody/Anonymous (nobody) Summary: CGIHttpServer fails if python exe has spaces Initial Comment: In addition to the problem noted in #1436206 with spaces in the file names of scripts being executed, if Python has been installed in a directory with spaces (C:\Program Files\Python) the server will fail to execute the script because the name of the executable is not quoted properly. My attempts to fix this have failed since just putting quotes around the exe name "C:\\Program Files\..." doesn't work, however we have found that just quoting the part of the path with spaces 'C:\\"Program Files"\\...' will work. It seems a bit odd that this bug has persisted for so long. A fix would be nice since this module is really good to give to my students (doing python web development for the first time) so they don't have to worry about server installation issues. Steve -- >Comment By: Steve Cassidy (stevecassidy) Date: 2007-06-06 09:28 Message: Logged In: YES user_id=105411 Originator: YES I understand that the default install location is non-standard becuase Python has trouble at times with spaces in filenames. However, if this is an engineering decision is there a trace of the bugs that are avoided because of it? The user isn't warned on installation not to choose a location with spaces to avoid problems x y and z. A regular windows user will find it odd that Python wants to be installed in C:\Python and I would imagine that in many managed environments this won't be possible. So the response to this bug shouldn't be just to close it, maybe it needs a patch to warn people of the issue when installing python at the least. In the longer term though it seems really odd that Python can't solve this relatively simple problem that other envionments have no trouble with. Steve -- Comment By: Collin Winter (collinwinter) Date: 2007-06-06 03:56 Message: Logged In: YES user_id=1344176 Originator: NO This issue is a duplicate of #1436206. Closing. -- Comment By: Martin v. Löwis (loewis) Date: 2007-05-09 05:11 Message: Logged In: YES user_id=21627 Originator: NO I don't find it odd that the bug persisted for so long: there is a reason that the default installation of Python does *not* go into "Program Files", as spaces in file names produce endless problems. Quoting the paths should work, though - don't forget to quote arguments as well. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1711608&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1711608 ] CGIHttpServer fails if python exe has spaces
Bugs item #1711608, was opened at 2007-05-02 20:34 Message generated for change (Comment added) made by collinwinter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1711608&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Extension Modules Group: Python 2.5 Status: Closed Resolution: Duplicate Priority: 5 Private: No Submitted By: Steve Cassidy (stevecassidy) Assigned to: Nobody/Anonymous (nobody) Summary: CGIHttpServer fails if python exe has spaces Initial Comment: In addition to the problem noted in #1436206 with spaces in the file names of scripts being executed, if Python has been installed in a directory with spaces (C:\Program Files\Python) the server will fail to execute the script because the name of the executable is not quoted properly. My attempts to fix this have failed since just putting quotes around the exe name "C:\\Program Files\..." doesn't work, however we have found that just quoting the part of the path with spaces 'C:\\"Program Files"\\...' will work. It seems a bit odd that this bug has persisted for so long. A fix would be nice since this module is really good to give to my students (doing python web development for the first time) so they don't have to worry about server installation issues. Steve -- >Comment By: Collin Winter (collinwinter) Date: 2007-06-05 19:37 Message: Logged In: YES user_id=1344176 Originator: NO I did not close this bug because it's unimportant; I closed it because it's already on file (#1436206), and there's no sense in having multiple tracker entries for the same issue. That said, problems on Windows are less likely to get fixed or noticed because relatively few core developers have access to Windows platforms. We would greatly appreciate a patch that fixes this. -- Comment By: Steve Cassidy (stevecassidy) Date: 2007-06-05 19:28 Message: Logged In: YES user_id=105411 Originator: YES I understand that the default install location is non-standard becuase Python has trouble at times with spaces in filenames. However, if this is an engineering decision is there a trace of the bugs that are avoided because of it? The user isn't warned on installation not to choose a location with spaces to avoid problems x y and z. A regular windows user will find it odd that Python wants to be installed in C:\Python and I would imagine that in many managed environments this won't be possible. So the response to this bug shouldn't be just to close it, maybe it needs a patch to warn people of the issue when installing python at the least. In the longer term though it seems really odd that Python can't solve this relatively simple problem that other envionments have no trouble with. Steve -- Comment By: Collin Winter (collinwinter) Date: 2007-06-05 13:56 Message: Logged In: YES user_id=1344176 Originator: NO This issue is a duplicate of #1436206. Closing. -- Comment By: Martin v. Löwis (loewis) Date: 2007-05-08 15:11 Message: Logged In: YES user_id=21627 Originator: NO I don't find it odd that the bug persisted for so long: there is a reason that the default installation of Python does *not* go into "Program Files", as spaces in file names produce endless problems. Quoting the paths should work, though - don't forget to quote arguments as well. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1711608&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1712522 ] urllib.quote throws exception on Unicode URL
Bugs item #1712522, was opened at 2007-05-04 02:11 Message generated for change (Comment added) made by collinwinter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1712522&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: John Nagle (nagle) Assigned to: Nobody/Anonymous (nobody) Summary: urllib.quote throws exception on Unicode URL Initial Comment: The code in urllib.quote fails on Unicode input, when called by robotparser with a Unicode URL. Traceback (most recent call last): File "./sitetruth/InfoSitePage.py", line 415, in run pagetree = self.httpfetch() # fetch page File "./sitetruth/InfoSitePage.py", line 368, in httpfetch if not self.owner().checkrobotaccess(self.requestedurl) : # if access disallowed by robots.txt file File "./sitetruth/InfoSiteContent.py", line 446, in checkrobotaccess return(self.robotcheck.can_fetch(config.kuseragent, url)) # return can fetch File "/usr/local/lib/python2.5/robotparser.py", line 159, in can_fetch url = urllib.quote(urlparse.urlparse(urllib.unquote(url))[2]) or "/" File "/usr/local/lib/python2.5/urllib.py", line 1197, in quote res = map(safe_map.__getitem__, s) KeyError: u'\xe2' That bit of code needs some attention. - It still assumes ASCII goes up to 255, which hasn't been true in Python for a while now. - The initialization may not be thread-safe; a table is being initialized on first use. "robotparser" was trying to check if a URL with a Unicode character in it was allowed. Note the "KeyError: u'\xe2'" -- >Comment By: Collin Winter (collinwinter) Date: 2007-06-05 19:39 Message: Logged In: YES user_id=1344176 Originator: NO Could you possibly provide a patch to fix this? -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1712522&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1711800 ] SequenceMatcher bug with insert/delete block after "replace"
Bugs item #1711800, was opened at 2007-05-03 06:24 Message generated for change (Comment added) made by collinwinter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1711800&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library Group: Python 2.6 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Christian Hammond (chipx86) Assigned to: Nobody/Anonymous (nobody) Summary: SequenceMatcher bug with insert/delete block after "replace" Initial Comment: difflib.SequenceMatcher fails to distinguish between a "replace" block and an "insert" or "delete" block when the "insert/delete" immediately follows a "replace". It will lump both changes together as one big "replace" block. This happens due to how get_opcodes() works. get_opcodes() loops through the matching blocks, grouping them into tags and ranges. However, if a block of text is changed and then new text is immediately added, it can't see this. All it knows is that the next matching block is after the added text. As an example, consider these strings: "ABC" "ABCD EFG." Any diffing program will show that the first line was replaced and the second was inserted. SequenceMatcher, however, just shows that there was one replace, and includes both lines in the range. I've attached a testcase that reproduces this for both replace>insert and replace>delete blocks. -- >Comment By: Collin Winter (collinwinter) Date: 2007-06-05 19:40 Message: Logged In: YES user_id=1344176 Originator: NO Thanks for the test case! Is there any chance you could also provide a patch to fix it? -- Comment By: Gabriel Genellina (gagenellina) Date: 2007-05-07 01:40 Message: Logged In: YES user_id=479790 Originator: NO Maybe you are more interested on a Differ object. These are the results from your example using '\n'.join(difflib.Differ().compare(a,b)) - This is my old file, containing only one line. + This is my new file. + It contains multiple lines. + SequenceMatcher should see two blocks as a result. and + This is my new file, containing only one line. - This is my old file. - It contains multiple lines. - SequenceMatcher should see two blocks as a result. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1711800&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-886488 ] WinPython 2.3.3 crashes using popen2 to spawn lots of child
Bugs item #886488, was opened at 2004-01-28 15:28 Message generated for change (Comment added) made by rupole You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=886488&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Windows Group: Python 2.3 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Frank Terhaar-Yonkers (frankty) Assigned to: Nobody/Anonymous (nobody) Summary: WinPython 2.3.3 crashes using popen2 to spawn lots of child Initial Comment: WinPython 2.3.3 crashes when using popen2 to spawn *lots* of children > 100. Running the test case on either W2k or Wxp causes Python 2.3.3 to crash. Looking at the drwatson file, it appears to be a race condition where the child is in the process of crashing, while the popen2 code in posixmodule.c is attempting to PyFile_SetBufSize() on one of the pipes. Evil juju in ntdll.dll .. I've no idea what system resource is being exhausted (heap memory?) causing the crash. If you look at the hacks in posixmodule.c, the Python crash can be eliminated by simply commenting out the calls to PyFile_SetBufSize. There is still the problem of resource exhaustion. To gain more child processes I included a hack such that with the setting of an env-var (NOPYCMD) popen2 will NOT use cmd.exe /c to run a child, but simply run the child command as passed (yeah, I know that is has to be an absolute path or in the CWD then ..). I'm sure there is a better way to eliminate the cmd.exe /c - like maybe a new method: popen2.popenXabspath .. In any case, it appears we have an NT kernel bug combined with an inefficient way of doing popen2 that is making a mess. I started doing some exploration of heap_chunk_size to attack to resource issue but haven't gotten very far. As for *why* I'm doing this, it's because we're using Pyton as a system simulator tool to emulate a large pile of PCs. The actual work *must* be done by external .exe code that cannot be changed. The attached zip contains a test case, the posixmodule hack, drwatson file and a sample program written in VisC++ which does basically the same as the Python test case. cheers, - Frank -- Comment By: Roger Upole (rupole) Date: 2007-06-05 21:40 Message: Logged In: YES user_id=771074 Originator: NO The code for the popen* functions doesn't check the return value of _fdopen, which will return null when the limit of open stdio streams is reached. A similar issue exists in the win32pipe module, which uses almost exactly the same code. See Pywin32 bug 1731778 ( http://sourceforge.net/tracker/?func=detail&atid=551954&aid=1731778&group_id=78018 ) for more details. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=886488&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1445210 ] embedding Python causes memory leaks
Bugs item #1445210, was opened at 2006-03-08 04:50
Message generated for change (Comment added) made by suresh_sf
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1445210&group_id=5470
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Interpreter Core
Group: None
Status: Closed
Resolution: Wont Fix
Priority: 5
Private: No
Submitted By: Andrew Trevorrow (andykt)
Assigned to: Nobody/Anonymous (nobody)
Summary: embedding Python causes memory leaks
Initial Comment:
[This bug has been submitted by others but for some reason it
has been marked Closed. I consider it to be an extremely serious
bug -- if I can't solve it I'm going to have to abandon Python as
my app's scripting language, even though I've fallen in love!]
I've added Python script support to my cross-platfom wxWidgets app
so that users can run .py scripts from within the app to automate the
GUI and do other fancy things. It all works very nicely, except for
one nasty problem: *every* time a script is run there is a memory leak,
usually small (about 10K) but sometimes massive (about 4MB in the
case of one rather complicated script).
The problem occurs on both Mac OS 10.3.9 and Windows 2000.
I'm using Python 2.3 on the Mac and 2.4.2 on Windows.
Every time the user runs a script, my app makes these calls:
(I've removed a lot of irrelevant stuff.)
Py_Initialize();
PyRun_SimpleString("execfile('foo.py')");
Py_Finalize();
It's definitely not a wxWidgets problem. In fact it's quite easy to
see the memory leak using a simple command-line program:
#include
#include
main(int argc, char *argv[])
{
int i;
for (i=0; i<1000; i++) {
Py_Initialize();
Py_Finalize();
printf(".");
if ((i+1) % 50 == 0) printf("\n");
}
}
Note that it doesn't even execute a script. If I run this program on
my Mac and watch its memory usage with Activity Monitor, I see a leak
of about 10K each time through the loop. Similar result on Windows.
Curiously, on both machines, the Py_Finalize() call takes longer and
longer to complete whatever it's doing. The above program takes a
few *minutes* to complete on my 400MHz Mac.
Andrew
--
Comment By: suresh (suresh_sf)
Date: 2007-06-06 11:52
Message:
Logged In: YES
user_id=1809507
Originator: NO
I too am having the exact similar problem with embedded python. Is this a
expected behaviour? if so how can we use python for long running tasks
without running out of memory eventually? We even tried doing Py_Initialize
once during startup and executing scripts before calling Py_Finalize. Even
this runs out of memory after some time. BTW, I am running Python 2.5.1.
--
Comment By: Martin v. Löwis (loewis)
Date: 2006-04-13 12:59
Message:
Logged In: YES
user_id=21627
That the documentation claims Py_Finalize releases all
memory is a bug; I just fixed this in r45344. The original
problem cannot be fixed (atleast not until Python 3000);
closing it as "won't fix".
--
Comment By: Andrew Trevorrow (andykt)
Date: 2006-03-10 11:13
Message:
Logged In: YES
user_id=1281947
See http://evanjones.ca/python-memory.html for some
useful info. Apparently the Python memory allocator never
releases memory back to the OS! So if a complicated script
happens to consume 100MB of interpreter memory then
that amount is no longer available to the app in which
Python is embedded. Even worse, if a script has a
(Python) memory leak then there's nothing the app can
do about it. It would be great if wrapping each script
inside Py_Initialize/Py_Finalize could avoid all that.
There should be some way to tell Python "release all
the memory you've ever allocated and start again
with a clean slate".
--
Comment By: Andrew Trevorrow (andykt)
Date: 2006-03-08 15:20
Message:
Logged In: YES
user_id=1281947
Bloody hell -- sorry for the bad line breaks.
One day I'll figure out how to use sf properly!
--
Comment By: Andrew Trevorrow (andykt)
Date: 2006-03-08 15:16
Message:
Logged In: YES
user_id=1281947
> Why do you call Py_Initialize/Py_Finalize more than once?
How else do I tell Python to free up memory after each PyRun_SimpleString
call?
I want users to be able to run scripts many times from within my app.
If I just keep calling PyRun_SimpleString then my app will leak more and
more memory until it becomes unusable.
From http://docs.python.org/api/embedding.html:
Sometimes, it is desirable to ``uninitialize'' Python. For instance,
the
application may want to start over (make another call to
Py_In
