From noreply at sourceforge.net Sun May 1 11:20:01 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sun May 1 11:20:04 2005 Subject: [Patches] [ python-Patches-827386 ] absolute paths cause problems for MSVC Message-ID: Patches item #827386, was opened at 2003-10-21 18:11 Message generated for change (Comment added) made by mdehoon You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=827386&group_id=5470 Category: Distutils and setup.py Group: None Status: Open Resolution: None Priority: 5 Submitted By: eric jones (eaj) Assigned to: Nobody/Anonymous (nobody) Summary: absolute paths cause problems for MSVC Initial Comment: When source files are given in the form: c:\foo\bar.c the object file is written to: c:\foo\bar.o instead of the build\temp.win32-2.3 directory. This is because the object_filenames method doesn't chop off the drive name from source file name base before trying to concatenate the build directory with the base. This results in the build directory being ignored. The ccompiler.py object_filenames does it right, so I just copied its behavior. ---------------------------------------------------------------------- Comment By: Michiel de Hoon (mdehoon) Date: 2005-05-01 18:20 Message: Logged In: YES user_id=488897 I have tested your patch and found that it works as intended. I am a bit surprised about the approach taken in ccompiler.py: 1) Using absolute paths is not portable, so I'm not sure why somebody would want to do that. 2) With this patch, If the source file is in c:\foo\bar.c, then the object file is written to build\temp.win32-2.3\Release\foo\bar.o. However, if the source file is written with a relative patch ("bar.c"), the object file is written to build\temp.win32-2.3\Release\bar.o (so without "foo"). Hence, even though the source file bar.c is in the exact same location in these two cases, the object file ends up in a different location depending on whether the path is specified as absolute or relative. Is that really what we want? But I agree that the behavior of msvccompiler.py and ccompiler.py should be consistent. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=827386&group_id=5470 From noreply at sourceforge.net Mon May 2 04:52:14 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 01 May 2005 19:52:14 -0700 Subject: [Patches] [ python-Patches-1049855 ] PyOS_InputHook inconsistency on Windows Message-ID: Patches item #1049855, was opened at 2004-10-19 18:03 Message generated for change (Comment added) made by mdehoon You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1049855&group_id=5470 Category: IDLE Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Michiel de Hoon (mdehoon) Assigned to: Nobody/Anonymous (nobody) Summary: PyOS_InputHook inconsistency on Windows Initial Comment: PyOS_InputHook is a pointer to a function to be called periodically when Python is idle. It is used, for example, to get messages delivered to graphics windows. If I compile Python from source (which uses Modules/readline.c), PyOS_InputHook is called ten times per second. However, with the Windows-version of Python, PyOS_InputHook is called only once for each command typed by the user. It seems that the problem resides in Parser/myreadline.c (which I presume is used for the Windows-version of Python): if (PyOS_InputHook != NULL) (void)(PyOS_InputHook)(); ... p = fgets(buf, len, fp); Python idles at "fgets", but PyOS_InputHook is not being called while Python is idle. The attached patch solves this problem by using the "select" function, basically in the same way as what is in Module/readline.c. I don't know how to compile Python for Windows, so I wasn't able to test this patch. ---------------------------------------------------------------------- >Comment By: Michiel de Hoon (mdehoon) Date: 2005-05-02 11:52 Message: Logged In: YES user_id=488897 Thanks for looking at this patch. Today I found out that it is possible to compile Python 2.4.1 with the older Microsoft Visual Studio 6.0, which I happen to have in my office. It turned out that the patch does not work correctly on Windows, due to the fact that the "select" function doesn't work with stdin on Windows. I will fix the patch so it'll work on Windows too. ---------------------------------------------------------------------- Comment By: Kurt B. Kaiser (kbk) Date: 2005-05-01 03:21 Message: Logged In: YES user_id=149084 The revised patch looks ok to me. ---------------------------------------------------------------------- Comment By: Michiel de Hoon (mdehoon) Date: 2005-03-26 22:33 Message: Logged In: YES user_id=488897 I have now tested this patch. After fixing one error (I had forgotton to declare one variable), the patch works correctly. I have uploaded a fixed patch. Note that this bug occurs not only on Windows, but on any Python compiled without readline. (which allowed me to test this patch by compiling Python without readline support). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1049855&group_id=5470 From noreply at sourceforge.net Mon May 2 05:40:02 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 01 May 2005 20:40:02 -0700 Subject: [Patches] [ python-Patches-1049855 ] PyOS_InputHook inconsistency on Windows Message-ID: Patches item #1049855, was opened at 2004-10-19 04:03 Message generated for change (Comment added) made by kbk You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1049855&group_id=5470 Category: IDLE Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Michiel de Hoon (mdehoon) Assigned to: Nobody/Anonymous (nobody) Summary: PyOS_InputHook inconsistency on Windows Initial Comment: PyOS_InputHook is a pointer to a function to be called periodically when Python is idle. It is used, for example, to get messages delivered to graphics windows. If I compile Python from source (which uses Modules/readline.c), PyOS_InputHook is called ten times per second. However, with the Windows-version of Python, PyOS_InputHook is called only once for each command typed by the user. It seems that the problem resides in Parser/myreadline.c (which I presume is used for the Windows-version of Python): if (PyOS_InputHook != NULL) (void)(PyOS_InputHook)(); ... p = fgets(buf, len, fp); Python idles at "fgets", but PyOS_InputHook is not being called while Python is idle. The attached patch solves this problem by using the "select" function, basically in the same way as what is in Module/readline.c. I don't know how to compile Python for Windows, so I wasn't able to test this patch. ---------------------------------------------------------------------- >Comment By: Kurt B. Kaiser (kbk) Date: 2005-05-01 22:40 Message: Logged In: YES user_id=149084 Yeah, that's why I didn't want to check it in, I can't build on Windows ithe VC 5. ---------------------------------------------------------------------- Comment By: Michiel de Hoon (mdehoon) Date: 2005-05-01 21:52 Message: Logged In: YES user_id=488897 Thanks for looking at this patch. Today I found out that it is possible to compile Python 2.4.1 with the older Microsoft Visual Studio 6.0, which I happen to have in my office. It turned out that the patch does not work correctly on Windows, due to the fact that the "select" function doesn't work with stdin on Windows. I will fix the patch so it'll work on Windows too. ---------------------------------------------------------------------- Comment By: Kurt B. Kaiser (kbk) Date: 2005-04-30 13:21 Message: Logged In: YES user_id=149084 The revised patch looks ok to me. ---------------------------------------------------------------------- Comment By: Michiel de Hoon (mdehoon) Date: 2005-03-26 08:33 Message: Logged In: YES user_id=488897 I have now tested this patch. After fixing one error (I had forgotton to declare one variable), the patch works correctly. I have uploaded a fixed patch. Note that this bug occurs not only on Windows, but on any Python compiled without readline. (which allowed me to test this patch by compiling Python without readline support). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1049855&group_id=5470 From noreply at sourceforge.net Mon May 2 16:00:39 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 02 May 2005 07:00:39 -0700 Subject: [Patches] [ python-Patches-1191489 ] Simplify logic in random.py Message-ID: Patches item #1191489, was opened at 2005-04-28 07:31 Message generated for change (Comment added) made by calvin You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1191489&group_id=5470 Category: Library (Lib) Group: Python 2.5 Status: Closed Resolution: Accepted Priority: 5 Submitted By: Raymond Hettinger (rhettinger) Assigned to: Raymond Hettinger (rhettinger) Summary: Simplify logic in random.py Initial Comment: Simplify the logic in several methods for better readability, maintainability, and speed: * while True --> while 1 * apply de'morgan's theorem to simplify compound conditionals * factor out repeated test: (p>1.0) and (p <= 1.0) * replace pow() with ** ---------------------------------------------------------------------- Comment By: Wummel (calvin) Date: 2005-05-02 16:00 Message: Logged In: YES user_id=9205 I agree with mdehoon. Why is "while 1" faster than "while True"? I think "while True" is more readable. So instead of replacing with "while 1" the speed issue itself should be fixed. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2005-04-30 11:03 Message: Logged In: YES user_id=80475 Thanks. Checked in as Lib/random.py 1.71 ---------------------------------------------------------------------- Comment By: Michiel de Hoon (mdehoon) Date: 2005-04-30 07:29 Message: Logged In: YES user_id=488897 OK, if ** and "while 1" give better performance than pow and "while true", I'm all for it. To double-check if the logic is correct, I generated a million variates with vonmisesvariate and gammavariate with and without the patch, for various values for the parameters. I found no problems with it. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2005-04-30 07:07 Message: Logged In: YES user_id=31435 Raymond, I checked the semantics, and aver that all the transformations here are semantically correct. Marked as Accepted -- go for it. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2005-04-29 08:12 Message: Logged In: YES user_id=80475 Thanks for looking at the patch. What I really need is for a second person to verify that the transformations are semantically neutral (no change in overall logic). FWIW, I was the one who did rev 1.39. It turns out that it was a premature modernization that cost some performance. Only the while 1 form is optimized by CPython, Jython, and Pysco. Have to disagree with you on pow(). The operator form runs faster and corresponds more closely to the way formulas are written in math textbooks and in other languages (except C which doesn't have a pow operator). This is the reason we write a+b instead operator.add(a, b). If you can a chance, please look closely at the logic transformations to make sure I did them accurately. Thanks again. ---------------------------------------------------------------------- Comment By: Michiel de Hoon (mdehoon) Date: 2005-04-29 07:42 Message: Logged In: YES user_id=488897 * I don't see how "while 1" is more readable than "while True". Note also that in older Python versions, this actually was "while 1"; it was changed to "while True" in revision 1.39. I can't recommend changing it back. * This pertains to line 424. I agree that the line in the patch is more readable and perhaps faster (though marginally so). * I agree with you that there is a repeated test in the current code. In the patch, I would stick with pow() instead of ** (see my next comment) * Unnecessary change. Some people like pow(), others like **. I see no reason to change. General comment: It is usually better to have different changes in separate patches. True, the changes in the patch all apply to random.py, but otherwise they don't have much in common. (I'm just a patch reviewer, not an official Python developer, so you don't need to take my comments too seriously.) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1191489&group_id=5470 From noreply at sourceforge.net Tue May 3 06:41:38 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 02 May 2005 21:41:38 -0700 Subject: [Patches] [ python-Patches-1190163 ] Minimal cleanup of run.py Message-ID: Patches item #1190163, was opened at 2005-04-26 05:50 Message generated for change (Settings changed) made by kbk You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1190163&group_id=5470 Category: IDLE Group: None Status: Open Resolution: None Priority: 5 Submitted By: Michiel de Hoon (mdehoon) >Assigned to: Kurt B. Kaiser (kbk) Summary: Minimal cleanup of run.py Initial Comment: In the main function in run.py in Lib/idlelib, we have try: seq, request = rpc.request_queue.get(0) except Queue.Empty: time.sleep(0.05) continue The get method of rpc.request_queue already has the option of a timeout, so we can use that instead of inlining time.sleep: try: seq, request = rpc.request_queue.get(block=True, timeout=0.05) except Queue.Empty: continue resulting in a (small) simplication of the code. The patch was tested on Windows, Linux, and Mac OS X. In case you are wondering why I care about this: My real interest is in PyOS_InputHook, a pointer to a function which is called ten times per second when Python is idle (e.g., waiting for user input). Currently, calls to PyOS_InputHook are missing in some cases where Python goes idle. I am going through the code to fix this. Now, since both the original code in run.py and rpc.request_queue.get cause Python to go idle (by calling the sleep function), it means that I would have to fix both cases. By making use of the existing code in rpc.request_queue.get, I need to fix this routine only (which I will do in a later patch), and avoids having calls to PyOS_InputHook all over the place. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1190163&group_id=5470 From noreply at sourceforge.net Tue May 3 13:19:56 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 03 May 2005 04:19:56 -0700 Subject: [Patches] [ python-Patches-1194378 ] Feature enhancement for C socket module Message-ID: Patches item #1194378, was opened at 2005-05-03 13: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=1194378&group_id=5470 Category: Modules Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Heiko Wundram (hwundram) Assigned to: Nobody/Anonymous (nobody) Summary: Feature enhancement for C socket module Initial Comment: The following tar.bz2 contains a feature enhancement proposal for the socket module to create wrappings of the recvmsg and sendmsg primitives. These are sometimes useful, especially when dealing with ancillary messages, such as communicating the process, user and group id of a remote process to a server for proper identification. These functions have so far been available in a separate module (python-eunuchs from the twisted project), but as they are standard POSIX and have been available on *BSD, AIX, Linux and several other OSs for some time they should be integrated into the core socket module. The attached file contains patches for configure.in the socket module, socket.py and pyconfig.h.in. I've yet to write a test-suite, and the documentation could use some reworking. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1194378&group_id=5470 From noreply at sourceforge.net Tue May 3 13:22:58 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 03 May 2005 04:22:58 -0700 Subject: [Patches] [ python-Patches-1194378 ] Feature enhancement for C socket module Message-ID: Patches item #1194378, was opened at 2005-05-03 13:19 Message generated for change (Settings changed) made by hwundram You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1194378&group_id=5470 Category: Modules Group: Python 2.4 Status: Open Resolution: None >Priority: 3 Submitted By: Heiko Wundram (hwundram) Assigned to: Nobody/Anonymous (nobody) Summary: Feature enhancement for C socket module Initial Comment: The following tar.bz2 contains a feature enhancement proposal for the socket module to create wrappings of the recvmsg and sendmsg primitives. These are sometimes useful, especially when dealing with ancillary messages, such as communicating the process, user and group id of a remote process to a server for proper identification. These functions have so far been available in a separate module (python-eunuchs from the twisted project), but as they are standard POSIX and have been available on *BSD, AIX, Linux and several other OSs for some time they should be integrated into the core socket module. The attached file contains patches for configure.in the socket module, socket.py and pyconfig.h.in. I've yet to write a test-suite, and the documentation could use some reworking. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1194378&group_id=5470 From noreply at sourceforge.net Tue May 3 15:18:26 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 03 May 2005 06:18:26 -0700 Subject: [Patches] [ python-Patches-1194449 ] pydoc requires o.__nonzero__() == True Message-ID: Patches item #1194449, was opened at 2005-05-03 09: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=1194449&group_id=5470 Category: Library (Lib) Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Jay T Miller (jaytmiller) Assigned to: Nobody/Anonymous (nobody) Summary: pydoc requires o.__nonzero__() == True Initial Comment: On Tue, 2005-05-03 at 07:44, Nadav Horesh wrote: >>> import numarray as N > >>> a = N.array((2.3, 4.3)) > >>> N.__version__ > '1.3.1' > >>> help(a.stddev) > > Traceback (most recent call last): > File "", line 1, in -toplevel- > help(a.stddev) > File "/usr/local/lib/python2.4/site.py", line 328, in __call__ > return pydoc.help(*args, **kwds) > File "/usr/local/lib/python2.4/pydoc.py", line 1647, in __call__ > self.help(request) > File "/usr/local/lib/python2.4/pydoc.py", line 1691, in help > else: doc(request, 'Help on %s:') > File "/usr/local/lib/python2.4/pydoc.py", line 1475, in doc > pager(title % desc + '\n\n' + text.document(object, name)) > File "/usr/local/lib/python2.4/pydoc.py", line 297, in document > if inspect.isroutine(object): return self.docroutine(*args) > File "/usr/local/lib/python2.4/pydoc.py", line 1226, in docroutine > if object.im_self: > File "/usr/local/lib/python2.4/site-packages/numarray/generic.py", > line 537, in __nonzero__ > raise RuntimeError("An array doesn't make sense as a truth value. > Use any(a) or all(a).") > RuntimeError: An array doesn't make sense as a truth value. Use any(a) > or all(a). > >>> help(a.sum) > > In my opinion, this is a limitation (bug is maybe too strong) of pydoc, in that pydoc's docroutine method requires that an object be evaluable as a truth value and that the result be True. I think that's a common, but wrong, idiom. I believe it's widely recognized that array's don't make much sense as truth values because it leads to code like this: >>> a = array(5); b = array(8) >>> a & b array(0) >>> if a & b: ... print "foo!" foo! Numeric expressions like the above implicitly mean any(a & b) and appear to work but really contain subtle bugs. Hence, in numarray and Numeric3 (now or eventually), the exception: >>> if a & b: ... print "foo!" ... Traceback (most recent call last): ... RuntimeError: An array doesn't make sense as a truth value. Use any(a) or all(a). I think the pydoc docroutine() code should be changed to read: if object.im_self is not None: and that particular limitation will be removed. I submitted a patch. Regards, Todd ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1194449&group_id=5470 From noreply at sourceforge.net Tue May 3 15:26:26 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 03 May 2005 06:26:26 -0700 Subject: [Patches] [ python-Patches-1194449 ] pydoc requires o.__nonzero__() == True Message-ID: Patches item #1194449, was opened at 2005-05-03 09:18 Message generated for change (Comment added) made by jaytmiller You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1194449&group_id=5470 Category: Library (Lib) Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Jay T Miller (jaytmiller) Assigned to: Nobody/Anonymous (nobody) Summary: pydoc requires o.__nonzero__() == True Initial Comment: On Tue, 2005-05-03 at 07:44, Nadav Horesh wrote: >>> import numarray as N > >>> a = N.array((2.3, 4.3)) > >>> N.__version__ > '1.3.1' > >>> help(a.stddev) > > Traceback (most recent call last): > File "", line 1, in -toplevel- > help(a.stddev) > File "/usr/local/lib/python2.4/site.py", line 328, in __call__ > return pydoc.help(*args, **kwds) > File "/usr/local/lib/python2.4/pydoc.py", line 1647, in __call__ > self.help(request) > File "/usr/local/lib/python2.4/pydoc.py", line 1691, in help > else: doc(request, 'Help on %s:') > File "/usr/local/lib/python2.4/pydoc.py", line 1475, in doc > pager(title % desc + '\n\n' + text.document(object, name)) > File "/usr/local/lib/python2.4/pydoc.py", line 297, in document > if inspect.isroutine(object): return self.docroutine(*args) > File "/usr/local/lib/python2.4/pydoc.py", line 1226, in docroutine > if object.im_self: > File "/usr/local/lib/python2.4/site-packages/numarray/generic.py", > line 537, in __nonzero__ > raise RuntimeError("An array doesn't make sense as a truth value. > Use any(a) or all(a).") > RuntimeError: An array doesn't make sense as a truth value. Use any(a) > or all(a). > >>> help(a.sum) > > In my opinion, this is a limitation (bug is maybe too strong) of pydoc, in that pydoc's docroutine method requires that an object be evaluable as a truth value and that the result be True. I think that's a common, but wrong, idiom. I believe it's widely recognized that array's don't make much sense as truth values because it leads to code like this: >>> a = array(5); b = array(8) >>> a & b array(0) >>> if a & b: ... print "foo!" foo! Numeric expressions like the above implicitly mean any(a & b) and appear to work but really contain subtle bugs. Hence, in numarray and Numeric3 (now or eventually), the exception: >>> if a & b: ... print "foo!" ... Traceback (most recent call last): ... RuntimeError: An array doesn't make sense as a truth value. Use any(a) or all(a). I think the pydoc docroutine() code should be changed to read: if object.im_self is not None: and that particular limitation will be removed. I submitted a patch. Regards, Todd ---------------------------------------------------------------------- >Comment By: Jay T Miller (jaytmiller) Date: 2005-05-03 09:26 Message: Logged In: YES user_id=320512 The attached patch fixed my immediate problem but is untested against the Python test suites. I did not do a careful analysis for other uses of the "if o:" idiom but noted that there are many of which I'm fixing two. I only have anonymous access to Python CVS and it is unusable. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1194449&group_id=5470 From noreply at sourceforge.net Wed May 4 03:16:00 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 03 May 2005 18:16:00 -0700 Subject: [Patches] [ python-Patches-1185444 ] urllib2 dloads failing through HTTP proxy w/ auth Message-ID: Patches item #1185444, was opened at 2005-04-18 14:07 Message generated for change (Comment added) made by jwpye You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1185444&group_id=5470 Category: Library (Lib) Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Mike Fleetwood (mfleetwo) Assigned to: Nobody/Anonymous (nobody) Summary: urllib2 dloads failing through HTTP proxy w/ auth Initial Comment: When using urllib2 to download through a HTTP proxy, which requires authorisation, a broken HTTP request is sent. The initial request might work but subsequent requests send using the same socket definitely fail. Problem occurs on Fedora Core 3 with python 2.3.4. Buggy code still exists in Python Library in 2.4.1. Found the problem using yum to download files via my companies Microsoft ISA web proxy. The proxy requires authorisation. I set the HTTP_PROXY environment variable to define the proxy like this: export HTTP_PROXY=http://username:password at proxy. example.com:8080/ Analysis from my yum bugzilla report http://devel.linux.duke.edu/bugzilla/show_bug.cgi?id=441 , follows: Location is: File: urllib2.py Class: ProxyHandler Function: proxy_open() The basic proxy authorisation string is created using base64.encodestring() and passed to add_header() method of a Request object. However base64.encodestring() specifically adds a trailing '\n' but when the headers are sent over the socket each is followed by '\r\n'. The server sees this double new line as the end of the HTTP request and the rest of the HTTP headers as a second invalid request. The broken request looks like this: GET ... Host: ... Accept-Encoding: identity Proxy-authorization: Basic xxxxxxxxxxxxxxxx <-- Blank line which shouldn't be there User-agent: urlgrabber/2.9.2 <-- Blank line ending HTTP request The fix is just to remove the '\n' which base64.encodestring() added before calling add_header(). Just use string method strip() as is done in the only other location base64.encodestring() is used in file urllib2.py. ---------------------------------------------------------------------- Comment By: James William Pye (jwpye) Date: 2005-05-03 18:15 Message: Logged In: YES user_id=1044177 Seems like a valid issue to me. Each header in HTTP must be followed with a CRLF, not a LFCRLF: http://www.w3.org/Protocols/rfc2616/rfc2616-sec2.html#sec2.2 http://www.w3.org/Protocols/rfc2616/rfc2616-sec4.html#sec4 And I don't think it consistutes continuation of the field-content either as the LF is not followed by at least 1 SP or HT, rather a CRLF(per LWS). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1185444&group_id=5470 From noreply at sourceforge.net Wed May 4 03:23:31 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 03 May 2005 18:23:31 -0700 Subject: [Patches] [ python-Patches-1194895 ] [AST] throw SyntaxError in "from x import y, " Message-ID: Patches item #1194895, was opened at 2005-05-03 20:23 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1194895&group_id=5470 Category: Parser/Compiler Group: AST Status: Open Resolution: None Priority: 5 Submitted By: logistix (logistix) Assigned to: Nobody/Anonymous (nobody) Summary: [AST] throw SyntaxError in "from x import y," Initial Comment: This patch adds invalid trailing comma detection to the compiler. This is the root cause of one of the errors currently thrown in test compile. One down, one to go. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1194895&group_id=5470 From noreply at sourceforge.net Wed May 4 03:23:51 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 03 May 2005 18:23:51 -0700 Subject: [Patches] [ python-Patches-1194895 ] [AST] throw SyntaxError in "from x import y, " Message-ID: Patches item #1194895, was opened at 2005-05-03 20:23 Message generated for change (Settings changed) made by logistix You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1194895&group_id=5470 Category: Parser/Compiler Group: AST Status: Open Resolution: None Priority: 5 Submitted By: logistix (logistix) >Assigned to: Brett Cannon (bcannon) Summary: [AST] throw SyntaxError in "from x import y," Initial Comment: This patch adds invalid trailing comma detection to the compiler. This is the root cause of one of the errors currently thrown in test compile. One down, one to go. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1194895&group_id=5470 From noreply at sourceforge.net Wed May 4 15:32:11 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 04 May 2005 06:32:11 -0700 Subject: [Patches] [ python-Patches-1191489 ] Simplify logic in random.py Message-ID: Patches item #1191489, was opened at 2005-04-28 00:31 Message generated for change (Comment added) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1191489&group_id=5470 Category: Library (Lib) Group: Python 2.5 Status: Closed Resolution: Accepted Priority: 5 Submitted By: Raymond Hettinger (rhettinger) Assigned to: Raymond Hettinger (rhettinger) Summary: Simplify logic in random.py Initial Comment: Simplify the logic in several methods for better readability, maintainability, and speed: * while True --> while 1 * apply de'morgan's theorem to simplify compound conditionals * factor out repeated test: (p>1.0) and (p <= 1.0) * replace pow() with ** ---------------------------------------------------------------------- >Comment By: Raymond Hettinger (rhettinger) Date: 2005-05-04 08:32 Message: Logged In: YES user_id=80475 Calvin, that won't work. The "while 1" is optimized because 1 is a constant. In contrast, "while True" cannot be precalculated because True is not a constant. ---------------------------------------------------------------------- Comment By: Wummel (calvin) Date: 2005-05-02 09:00 Message: Logged In: YES user_id=9205 I agree with mdehoon. Why is "while 1" faster than "while True"? I think "while True" is more readable. So instead of replacing with "while 1" the speed issue itself should be fixed. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2005-04-30 04:03 Message: Logged In: YES user_id=80475 Thanks. Checked in as Lib/random.py 1.71 ---------------------------------------------------------------------- Comment By: Michiel de Hoon (mdehoon) Date: 2005-04-30 00:29 Message: Logged In: YES user_id=488897 OK, if ** and "while 1" give better performance than pow and "while true", I'm all for it. To double-check if the logic is correct, I generated a million variates with vonmisesvariate and gammavariate with and without the patch, for various values for the parameters. I found no problems with it. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2005-04-30 00:07 Message: Logged In: YES user_id=31435 Raymond, I checked the semantics, and aver that all the transformations here are semantically correct. Marked as Accepted -- go for it. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2005-04-29 01:12 Message: Logged In: YES user_id=80475 Thanks for looking at the patch. What I really need is for a second person to verify that the transformations are semantically neutral (no change in overall logic). FWIW, I was the one who did rev 1.39. It turns out that it was a premature modernization that cost some performance. Only the while 1 form is optimized by CPython, Jython, and Pysco. Have to disagree with you on pow(). The operator form runs faster and corresponds more closely to the way formulas are written in math textbooks and in other languages (except C which doesn't have a pow operator). This is the reason we write a+b instead operator.add(a, b). If you can a chance, please look closely at the logic transformations to make sure I did them accurately. Thanks again. ---------------------------------------------------------------------- Comment By: Michiel de Hoon (mdehoon) Date: 2005-04-29 00:42 Message: Logged In: YES user_id=488897 * I don't see how "while 1" is more readable than "while True". Note also that in older Python versions, this actually was "while 1"; it was changed to "while True" in revision 1.39. I can't recommend changing it back. * This pertains to line 424. I agree that the line in the patch is more readable and perhaps faster (though marginally so). * I agree with you that there is a repeated test in the current code. In the patch, I would stick with pow() instead of ** (see my next comment) * Unnecessary change. Some people like pow(), others like **. I see no reason to change. General comment: It is usually better to have different changes in separate patches. True, the changes in the patch all apply to random.py, but otherwise they don't have much in common. (I'm just a patch reviewer, not an official Python developer, so you don't need to take my comments too seriously.) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1191489&group_id=5470 From noreply at sourceforge.net Wed May 4 16:11:13 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 04 May 2005 07:11:13 -0700 Subject: [Patches] [ python-Patches-1191489 ] Simplify logic in random.py Message-ID: Patches item #1191489, was opened at 2005-04-28 07:31 Message generated for change (Comment added) made by calvin You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1191489&group_id=5470 Category: Library (Lib) Group: Python 2.5 Status: Closed Resolution: Accepted Priority: 5 Submitted By: Raymond Hettinger (rhettinger) Assigned to: Raymond Hettinger (rhettinger) Summary: Simplify logic in random.py Initial Comment: Simplify the logic in several methods for better readability, maintainability, and speed: * while True --> while 1 * apply de'morgan's theorem to simplify compound conditionals * factor out repeated test: (p>1.0) and (p <= 1.0) * replace pow() with ** ---------------------------------------------------------------------- Comment By: Wummel (calvin) Date: 2005-05-04 16:11 Message: Logged In: YES user_id=9205 Oh, I did not realize that True/False are not constants. Grr, I can even do this: >>> True, False = False, True >>> True False >>> False True This could be handy for the pyobfuscation project :) ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2005-05-04 15:32 Message: Logged In: YES user_id=80475 Calvin, that won't work. The "while 1" is optimized because 1 is a constant. In contrast, "while True" cannot be precalculated because True is not a constant. ---------------------------------------------------------------------- Comment By: Wummel (calvin) Date: 2005-05-02 16:00 Message: Logged In: YES user_id=9205 I agree with mdehoon. Why is "while 1" faster than "while True"? I think "while True" is more readable. So instead of replacing with "while 1" the speed issue itself should be fixed. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2005-04-30 11:03 Message: Logged In: YES user_id=80475 Thanks. Checked in as Lib/random.py 1.71 ---------------------------------------------------------------------- Comment By: Michiel de Hoon (mdehoon) Date: 2005-04-30 07:29 Message: Logged In: YES user_id=488897 OK, if ** and "while 1" give better performance than pow and "while true", I'm all for it. To double-check if the logic is correct, I generated a million variates with vonmisesvariate and gammavariate with and without the patch, for various values for the parameters. I found no problems with it. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2005-04-30 07:07 Message: Logged In: YES user_id=31435 Raymond, I checked the semantics, and aver that all the transformations here are semantically correct. Marked as Accepted -- go for it. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2005-04-29 08:12 Message: Logged In: YES user_id=80475 Thanks for looking at the patch. What I really need is for a second person to verify that the transformations are semantically neutral (no change in overall logic). FWIW, I was the one who did rev 1.39. It turns out that it was a premature modernization that cost some performance. Only the while 1 form is optimized by CPython, Jython, and Pysco. Have to disagree with you on pow(). The operator form runs faster and corresponds more closely to the way formulas are written in math textbooks and in other languages (except C which doesn't have a pow operator). This is the reason we write a+b instead operator.add(a, b). If you can a chance, please look closely at the logic transformations to make sure I did them accurately. Thanks again. ---------------------------------------------------------------------- Comment By: Michiel de Hoon (mdehoon) Date: 2005-04-29 07:42 Message: Logged In: YES user_id=488897 * I don't see how "while 1" is more readable than "while True". Note also that in older Python versions, this actually was "while 1"; it was changed to "while True" in revision 1.39. I can't recommend changing it back. * This pertains to line 424. I agree that the line in the patch is more readable and perhaps faster (though marginally so). * I agree with you that there is a repeated test in the current code. In the patch, I would stick with pow() instead of ** (see my next comment) * Unnecessary change. Some people like pow(), others like **. I see no reason to change. General comment: It is usually better to have different changes in separate patches. True, the changes in the patch all apply to random.py, but otherwise they don't have much in common. (I'm just a patch reviewer, not an official Python developer, so you don't need to take my comments too seriously.) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1191489&group_id=5470 From noreply at sourceforge.net Wed May 4 20:43:23 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 04 May 2005 11:43:23 -0700 Subject: [Patches] [ python-Patches-1093253 ] Refactoring Python/import.c Message-ID: Patches item #1093253, was opened at 2004-12-30 13:50 Message generated for change (Comment added) made by theller You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1093253&group_id=5470 Category: Core (C code) Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: Thomas Heller (theller) >Assigned to: Nobody/Anonymous (nobody) Summary: Refactoring Python/import.c Initial Comment: This patch refactores Python/import.c. find_module() was changed to return an PyObject* pointer which contains the module's pathname, instead of filling out a char* buffer. load_module() accepts the PyObject* pathname instead of a char*. The patch is probably missing some error checking, and the 8 character hack for loading extensions on OS2 is not implemented, but the test case runs without errors on Windows XP pro. If a change in spirit of this patch is accepted, I'm willing to further work on it so that eventually unicode entries on sys.path, which can not be encoded with the default file system encodings, will work as expected (currently they don't). See also: http://mail.python.org/pipermail/python-list/2004-December/256969.html ---------------------------------------------------------------------- >Comment By: Thomas Heller (theller) Date: 2005-05-04 20:43 Message: Logged In: YES user_id=11105 Unassigning from MvL. ---------------------------------------------------------------------- Comment By: Thomas Heller (theller) Date: 2005-01-06 21:20 Message: Logged In: YES user_id=11105 Martin, this is the first step for making unicode entries on sys.path work the way that is expected on Windows. You requested patches, so please take a look, if you have time. Otherwise, unassign yourself. ---------------------------------------------------------------------- Comment By: Thomas Heller (theller) Date: 2005-01-06 21:17 Message: Logged In: YES user_id=11105 For easier reading, I've attached the complete, new Python/import.c file. ---------------------------------------------------------------------- Comment By: Thomas Heller (theller) Date: 2005-01-04 20:20 Message: Logged In: YES user_id=11105 New patch attached with multiple implementations of case_ok, and more error checking: import.c.patch2 Slightly tested on OSX, Linux, Windows. The case_ok function still needs to be fixed for RISCOS (which I cannot test). ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2004-12-31 15:17 Message: Logged In: YES user_id=6656 Perhaps there should be multiple implementations of case_ok ... i.e. #if PLAT1 int case_ok(...) { ... } #elif PLAT2 int case_ok(...) { ... } #endif the current spaghetti is confusing, even by the standards of import.c... ---------------------------------------------------------------------- Comment By: Thomas Heller (theller) Date: 2004-12-31 15:11 Message: Logged In: YES user_id=11105 Yes, I overlooked that the initialization of the variables is inside an #if defined(MS_WINDOWS) block. Probably it would be better to leave the signature of case_ok() as before and call it through a wrapper which converts the arguments. I will prepare a new patch in a few days. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2004-12-31 14:57 Message: Logged In: YES user_id=6656 Applied the patch and built on OS X. This was the result: $ ./python.exe 'import site' failed; use -v for traceback ../Python/import.c:1496: failed assertion `dirlen <= MAXPATHLEN' Abort trap dirlen is 796092779, which seems fishy :) An uninitialized variable, maybe? Haven't looked, really... ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1093253&group_id=5470 From noreply at sourceforge.net Thu May 5 00:57:12 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 04 May 2005 15:57:12 -0700 Subject: [Patches] [ python-Patches-1195571 ] simple callback system for Py_FatalError Message-ID: Patches item #1195571, was opened at 2005-05-05 01:57 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1195571&group_id=5470 Category: Core (C code) Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: m utku (mutkuk) Assigned to: Nobody/Anonymous (nobody) Summary: simple callback system for Py_FatalError Initial Comment: Included implementation of a simple callback system for Py_FatalError. Everything is done in "pythonrun.c" and "pydebug.h" ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1195571&group_id=5470 From b-pop at radar.axi.fr Wed May 4 19:56:16 2005 From: b-pop at radar.axi.fr (CARGO) Date: Wed, 04 May 2005 19:56:16 +0200 Subject: [Patches] Vente priv?e Gucci, Von Dutch, D&G Message-ID: Votre client mail ne lit pas les messages HTML. Copier coller cet url dans votre navigateur web: http://www.axipub.com/mirroir/EMM-EMk5n4.php -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.python.org/pipermail/patches/attachments/20050504/68d7efc9/attachment.html From noreply at sourceforge.net Thu May 5 08:47:21 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 04 May 2005 23:47:21 -0700 Subject: [Patches] [ python-Patches-1195571 ] simple callback system for Py_FatalError Message-ID: Patches item #1195571, was opened at 2005-05-04 15:57 Message generated for change (Comment added) made by jwpye You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1195571&group_id=5470 Category: Core (C code) Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: m utku (mutkuk) Assigned to: Nobody/Anonymous (nobody) Summary: simple callback system for Py_FatalError Initial Comment: Included implementation of a simple callback system for Py_FatalError. Everything is done in "pythonrun.c" and "pydebug.h" ---------------------------------------------------------------------- Comment By: James William Pye (jwpye) Date: 2005-05-04 23:47 Message: Logged In: YES user_id=1044177 Again, I think this should be explicitly exclusive to an embedding application, as I cannot imagine a situation where an extension module should even have access to this facility. I have done rather limited tests. My application doesn't seem to like Python 2.5alpha, so I'm going to test the patch against 2.4. Sorry to butt into your patch, mutkuk, but here's my recommendation with docs(ugh, cant attach files): Index: Doc/api/init.tex =================================================================== RCS file: /cvsroot/python/python/dist/src/Doc/api/init.tex,v retrieving revision 1.23 diff -r1.23 init.tex 39a40,53 > \begin{cfuncdesc}{void}{Py_InitializeFatalHook}{PyFatalHook fp} > Force \cfunction{Py_FatalError()} to invoke the given function > instead of printing to standard error and aborting out of the > process. This is intended for use in embedded applications that > want to define their own route for handling fatal errors. Giving > the application the ability to log the error to a special > destination, and to do any appropriate cleanups before exiting. > > If used, this \emph{must} be called prior to > \cfunction{Py_Initialize()}. Otherwise, \cfunction{Py_Initialize()} > will set the hook to the default, and future attempts to > \cfunction{Py_InitializeFatalHook()} will be ignored. > \end{cfuncdesc} > Index: Include/pythonrun.h =================================================================== RCS file: /cvsroot/python/python/dist/src/Include/pythonrun.h,v retrieving revision 2.65 diff -r2.65 pythonrun.h 24a25,27 > typedef void (*PyFatalHook)(const char *); > PyAPI_FUNC(void) Py_InitializeFatalHook(PyFatalHook); > Index: Python/pythonrun.c =================================================================== RCS file: /cvsroot/python/python/dist/src/Python/pythonrun.c,v retrieving revision 2.213 diff -r2.213 pythonrun.c 99a100,109 > static PyFatalHook _fatalhook = NULL; > > void > Py_InitializeFatalHook(PyFatalHook f) > { > /* Only set it if it is uninitialized. */ > if (_fatalhook == NULL) > _fatalhook = f; > } > 150a161,162 > Py_InitializeFatalHook(Py_FatalError); > 1507a1520,1523 > if (_fatalhook != Py_FatalError && _fatalhook != NULL) > _fatalhook(msg); > /* If the hook fell through, finish the process anyways. */ > ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1195571&group_id=5470 From noreply at sourceforge.net Thu May 5 09:21:06 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 05 May 2005 00:21:06 -0700 Subject: [Patches] [ python-Patches-1195571 ] simple callback system for Py_FatalError Message-ID: Patches item #1195571, was opened at 2005-05-05 01:57 Message generated for change (Comment added) made by mutkuk You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1195571&group_id=5470 Category: Core (C code) Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: m utku (mutkuk) Assigned to: Nobody/Anonymous (nobody) Summary: simple callback system for Py_FatalError Initial Comment: Included implementation of a simple callback system for Py_FatalError. Everything is done in "pythonrun.c" and "pydebug.h" ---------------------------------------------------------------------- >Comment By: m utku (mutkuk) Date: 2005-05-05 10:21 Message: Logged In: YES user_id=1272056 Extension case: Extension developers may mess up too, why leave them orphaned? Doc case: UGGGHHH Your patch is just slicker, why dont I delete this patch and you submit. What do you say? I have just 2 suggestions: 1. Declaration of register func would better be in pydebug.h near Py_FatalError. 2. Last one to call register func owns the hook, this is just expected case so IMHO remove NULL check from register func. ---------------------------------------------------------------------- Comment By: James William Pye (jwpye) Date: 2005-05-05 09:47 Message: Logged In: YES user_id=1044177 Again, I think this should be explicitly exclusive to an embedding application, as I cannot imagine a situation where an extension module should even have access to this facility. I have done rather limited tests. My application doesn't seem to like Python 2.5alpha, so I'm going to test the patch against 2.4. Sorry to butt into your patch, mutkuk, but here's my recommendation with docs(ugh, cant attach files): Index: Doc/api/init.tex =================================================================== RCS file: /cvsroot/python/python/dist/src/Doc/api/init.tex,v retrieving revision 1.23 diff -r1.23 init.tex 39a40,53 > \begin{cfuncdesc}{void}{Py_InitializeFatalHook}{PyFatalHook fp} > Force \cfunction{Py_FatalError()} to invoke the given function > instead of printing to standard error and aborting out of the > process. This is intended for use in embedded applications that > want to define their own route for handling fatal errors. Giving > the application the ability to log the error to a special > destination, and to do any appropriate cleanups before exiting. > > If used, this \emph{must} be called prior to > \cfunction{Py_Initialize()}. Otherwise, \cfunction{Py_Initialize()} > will set the hook to the default, and future attempts to > \cfunction{Py_InitializeFatalHook()} will be ignored. > \end{cfuncdesc} > Index: Include/pythonrun.h =================================================================== RCS file: /cvsroot/python/python/dist/src/Include/pythonrun.h,v retrieving revision 2.65 diff -r2.65 pythonrun.h 24a25,27 > typedef void (*PyFatalHook)(const char *); > PyAPI_FUNC(void) Py_InitializeFatalHook(PyFatalHook); > Index: Python/pythonrun.c =================================================================== RCS file: /cvsroot/python/python/dist/src/Python/pythonrun.c,v retrieving revision 2.213 diff -r2.213 pythonrun.c 99a100,109 > static PyFatalHook _fatalhook = NULL; > > void > Py_InitializeFatalHook(PyFatalHook f) > { > /* Only set it if it is uninitialized. */ > if (_fatalhook == NULL) > _fatalhook = f; > } > 150a161,162 > Py_InitializeFatalHook(Py_FatalError); > 1507a1520,1523 > if (_fatalhook != Py_FatalError && _fatalhook != NULL) > _fatalhook(msg); > /* If the hook fell through, finish the process anyways. */ > ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1195571&group_id=5470 From noreply at sourceforge.net Thu May 5 09:56:46 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 05 May 2005 00:56:46 -0700 Subject: [Patches] [ python-Patches-1195571 ] simple callback system for Py_FatalError Message-ID: Patches item #1195571, was opened at 2005-05-04 15:57 Message generated for change (Comment added) made by jwpye You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1195571&group_id=5470 Category: Core (C code) Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: m utku (mutkuk) Assigned to: Nobody/Anonymous (nobody) Summary: simple callback system for Py_FatalError Initial Comment: Included implementation of a simple callback system for Py_FatalError. Everything is done in "pythonrun.c" and "pydebug.h" ---------------------------------------------------------------------- Comment By: James William Pye (jwpye) Date: 2005-05-05 00:56 Message: Logged In: YES user_id=1044177 Extension case: Really, if an extension requires special cleanup, chances are the application will take notice of it and probably handle that cleanup itself. If extension developers thought that it was okay to overload the hook, then they might make the mistake of overloading the hook in an embedded application where fatal cleanup was a necessity. If a stack of hooks were provided, who or what determines which hook should cause the exit? I don't actually have control over what PostgreSQL does with its FATAL ereport, so if it hit my hook first, the application will go bye bye, without touching the others. Also, it might be possible for extensions to tap into some signal to allow cleanup. For instance abort(3) sends the process a SIGABRT. All in all, I still think it's bad mojo. 1: I see your reasoning, but I disagree as when the developer pokes around the headers it will be more useful for it, the typedef, to be around the *only* call that the typedef is used for. Thus showing the complete expectation for the function's argument, without having to find it in another file. Matter of fact, I think the typedef isn't really all that useful except to declare the static function pointer in pythonrun.c, so I'd rather do without it... = 2. Oh, yeah the NULL check is there just in case someone gets smart and tries to start running Python calls before Python is initialized(ala Py_InitializeEx()). Besides that it, Py_FatalError should only be called once during the process lifetime, so the extra condition isn't really much of a performance issue. I'll e-mail you the patch. ---------------------------------------------------------------------- Comment By: m utku (mutkuk) Date: 2005-05-05 00:21 Message: Logged In: YES user_id=1272056 Extension case: Extension developers may mess up too, why leave them orphaned? Doc case: UGGGHHH Your patch is just slicker, why dont I delete this patch and you submit. What do you say? I have just 2 suggestions: 1. Declaration of register func would better be in pydebug.h near Py_FatalError. 2. Last one to call register func owns the hook, this is just expected case so IMHO remove NULL check from register func. ---------------------------------------------------------------------- Comment By: James William Pye (jwpye) Date: 2005-05-04 23:47 Message: Logged In: YES user_id=1044177 Again, I think this should be explicitly exclusive to an embedding application, as I cannot imagine a situation where an extension module should even have access to this facility. I have done rather limited tests. My application doesn't seem to like Python 2.5alpha, so I'm going to test the patch against 2.4. Sorry to butt into your patch, mutkuk, but here's my recommendation with docs(ugh, cant attach files): Index: Doc/api/init.tex =================================================================== RCS file: /cvsroot/python/python/dist/src/Doc/api/init.tex,v retrieving revision 1.23 diff -r1.23 init.tex 39a40,53 > \begin{cfuncdesc}{void}{Py_InitializeFatalHook}{PyFatalHook fp} > Force \cfunction{Py_FatalError()} to invoke the given function > instead of printing to standard error and aborting out of the > process. This is intended for use in embedded applications that > want to define their own route for handling fatal errors. Giving > the application the ability to log the error to a special > destination, and to do any appropriate cleanups before exiting. > > If used, this \emph{must} be called prior to > \cfunction{Py_Initialize()}. Otherwise, \cfunction{Py_Initialize()} > will set the hook to the default, and future attempts to > \cfunction{Py_InitializeFatalHook()} will be ignored. > \end{cfuncdesc} > Index: Include/pythonrun.h =================================================================== RCS file: /cvsroot/python/python/dist/src/Include/pythonrun.h,v retrieving revision 2.65 diff -r2.65 pythonrun.h 24a25,27 > typedef void (*PyFatalHook)(const char *); > PyAPI_FUNC(void) Py_InitializeFatalHook(PyFatalHook); > Index: Python/pythonrun.c =================================================================== RCS file: /cvsroot/python/python/dist/src/Python/pythonrun.c,v retrieving revision 2.213 diff -r2.213 pythonrun.c 99a100,109 > static PyFatalHook _fatalhook = NULL; > > void > Py_InitializeFatalHook(PyFatalHook f) > { > /* Only set it if it is uninitialized. */ > if (_fatalhook == NULL) > _fatalhook = f; > } > 150a161,162 > Py_InitializeFatalHook(Py_FatalError); > 1507a1520,1523 > if (_fatalhook != Py_FatalError && _fatalhook != NULL) > _fatalhook(msg); > /* If the hook fell through, finish the process anyways. */ > ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1195571&group_id=5470 From noreply at sourceforge.net Thu May 5 18:55:31 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 05 May 2005 09:55:31 -0700 Subject: [Patches] [ python-Patches-1195571 ] simple callback system for Py_FatalError Message-ID: Patches item #1195571, was opened at 2005-05-05 01:57 Message generated for change (Comment added) made by mutkuk You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1195571&group_id=5470 Category: Core (C code) Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: m utku (mutkuk) Assigned to: Nobody/Anonymous (nobody) Summary: simple callback system for Py_FatalError Initial Comment: Included implementation of a simple callback system for Py_FatalError. Everything is done in "pythonrun.c" and "pydebug.h" ---------------------------------------------------------------------- >Comment By: m utku (mutkuk) Date: 2005-05-05 19:55 Message: Logged In: YES user_id=1272056 Uploaded new patch unchanged. Extension case: This func categorizes with PyThreadSatate_*. For debugger implementors(generally implmented as extension) it is invaluable. Indeed that's the reason I needed it in the first place. >1: I see your reasoning, but I disagree as when the >developer pokes around the headers it will be more useful >for it, the typedef, to be around the *only* call that the.... Not worth to remove it IMHO just feels OK >2. Oh, yeah the NULL check is there just in case someone >gets smart and tries to start running Python calls before >Python is initialized(ala Py_InitializeEx()). Besides that >it, Py_FatalError should only be called once during the >process lifetime, so the extra condition isn't really much >of a performance issue. Got it, agreed. ---------------------------------------------------------------------- Comment By: James William Pye (jwpye) Date: 2005-05-05 10:56 Message: Logged In: YES user_id=1044177 Extension case: Really, if an extension requires special cleanup, chances are the application will take notice of it and probably handle that cleanup itself. If extension developers thought that it was okay to overload the hook, then they might make the mistake of overloading the hook in an embedded application where fatal cleanup was a necessity. If a stack of hooks were provided, who or what determines which hook should cause the exit? I don't actually have control over what PostgreSQL does with its FATAL ereport, so if it hit my hook first, the application will go bye bye, without touching the others. Also, it might be possible for extensions to tap into some signal to allow cleanup. For instance abort(3) sends the process a SIGABRT. All in all, I still think it's bad mojo. 1: I see your reasoning, but I disagree as when the developer pokes around the headers it will be more useful for it, the typedef, to be around the *only* call that the typedef is used for. Thus showing the complete expectation for the function's argument, without having to find it in another file. Matter of fact, I think the typedef isn't really all that useful except to declare the static function pointer in pythonrun.c, so I'd rather do without it... = 2. Oh, yeah the NULL check is there just in case someone gets smart and tries to start running Python calls before Python is initialized(ala Py_InitializeEx()). Besides that it, Py_FatalError should only be called once during the process lifetime, so the extra condition isn't really much of a performance issue. I'll e-mail you the patch. ---------------------------------------------------------------------- Comment By: m utku (mutkuk) Date: 2005-05-05 10:21 Message: Logged In: YES user_id=1272056 Extension case: Extension developers may mess up too, why leave them orphaned? Doc case: UGGGHHH Your patch is just slicker, why dont I delete this patch and you submit. What do you say? I have just 2 suggestions: 1. Declaration of register func would better be in pydebug.h near Py_FatalError. 2. Last one to call register func owns the hook, this is just expected case so IMHO remove NULL check from register func. ---------------------------------------------------------------------- Comment By: James William Pye (jwpye) Date: 2005-05-05 09:47 Message: Logged In: YES user_id=1044177 Again, I think this should be explicitly exclusive to an embedding application, as I cannot imagine a situation where an extension module should even have access to this facility. I have done rather limited tests. My application doesn't seem to like Python 2.5alpha, so I'm going to test the patch against 2.4. Sorry to butt into your patch, mutkuk, but here's my recommendation with docs(ugh, cant attach files): Index: Doc/api/init.tex =================================================================== RCS file: /cvsroot/python/python/dist/src/Doc/api/init.tex,v retrieving revision 1.23 diff -r1.23 init.tex 39a40,53 > \begin{cfuncdesc}{void}{Py_InitializeFatalHook}{PyFatalHook fp} > Force \cfunction{Py_FatalError()} to invoke the given function > instead of printing to standard error and aborting out of the > process. This is intended for use in embedded applications that > want to define their own route for handling fatal errors. Giving > the application the ability to log the error to a special > destination, and to do any appropriate cleanups before exiting. > > If used, this \emph{must} be called prior to > \cfunction{Py_Initialize()}. Otherwise, \cfunction{Py_Initialize()} > will set the hook to the default, and future attempts to > \cfunction{Py_InitializeFatalHook()} will be ignored. > \end{cfuncdesc} > Index: Include/pythonrun.h =================================================================== RCS file: /cvsroot/python/python/dist/src/Include/pythonrun.h,v retrieving revision 2.65 diff -r2.65 pythonrun.h 24a25,27 > typedef void (*PyFatalHook)(const char *); > PyAPI_FUNC(void) Py_InitializeFatalHook(PyFatalHook); > Index: Python/pythonrun.c =================================================================== RCS file: /cvsroot/python/python/dist/src/Python/pythonrun.c,v retrieving revision 2.213 diff -r2.213 pythonrun.c 99a100,109 > static PyFatalHook _fatalhook = NULL; > > void > Py_InitializeFatalHook(PyFatalHook f) > { > /* Only set it if it is uninitialized. */ > if (_fatalhook == NULL) > _fatalhook = f; > } > 150a161,162 > Py_InitializeFatalHook(Py_FatalError); > 1507a1520,1523 > if (_fatalhook != Py_FatalError && _fatalhook != NULL) > _fatalhook(msg); > /* If the hook fell through, finish the process anyways. */ > ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1195571&group_id=5470 From noreply at sourceforge.net Fri May 6 01:30:33 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 05 May 2005 16:30:33 -0700 Subject: [Patches] [ python-Patches-1190163 ] Minimal cleanup of run.py Message-ID: Patches item #1190163, was opened at 2005-04-26 05:50 Message generated for change (Comment added) made by kbk You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1190163&group_id=5470 Category: IDLE Group: None >Status: Closed >Resolution: Accepted Priority: 5 Submitted By: Michiel de Hoon (mdehoon) Assigned to: Kurt B. Kaiser (kbk) Summary: Minimal cleanup of run.py Initial Comment: In the main function in run.py in Lib/idlelib, we have try: seq, request = rpc.request_queue.get(0) except Queue.Empty: time.sleep(0.05) continue The get method of rpc.request_queue already has the option of a timeout, so we can use that instead of inlining time.sleep: try: seq, request = rpc.request_queue.get(block=True, timeout=0.05) except Queue.Empty: continue resulting in a (small) simplication of the code. The patch was tested on Windows, Linux, and Mac OS X. In case you are wondering why I care about this: My real interest is in PyOS_InputHook, a pointer to a function which is called ten times per second when Python is idle (e.g., waiting for user input). Currently, calls to PyOS_InputHook are missing in some cases where Python goes idle. I am going through the code to fix this. Now, since both the original code in run.py and rpc.request_queue.get cause Python to go idle (by calling the sleep function), it means that I would have to fix both cases. By making use of the existing code in rpc.request_queue.get, I need to fix this routine only (which I will do in a later patch), and avoids having calls to PyOS_InputHook all over the place. ---------------------------------------------------------------------- >Comment By: Kurt B. Kaiser (kbk) Date: 2005-05-05 18:30 Message: Logged In: YES user_id=149084 run.py rev 1.32 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1190163&group_id=5470 From noreply at sourceforge.net Fri May 6 09:06:38 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 06 May 2005 00:06:38 -0700 Subject: [Patches] [ python-Patches-1166195 ] Using size_t where appropriate Message-ID: Patches item #1166195, was opened at 2005-03-18 20:59 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1166195&group_id=5470 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Martin v. L?wis (loewis) Assigned to: Nobody/Anonymous (nobody) Summary: Using size_t where appropriate Initial Comment: This patch is (a first draft of) an attempt to make Python properly use size_t where necessary. This work is triggered by compilation on Win64 (where the compiler warns about potential truncation errors a lot). The rationale for the patch is that size_t might be larger than int, in particular on 64-bit platforms, and that the size of a memory chunk cannot reliably be measured with an int. It turns out that using size_t is not enough, since values can sometimes also be negative. For these cases, a "signed" size_t is used, which is called Py_ssize_t and is a define for ssize_t if the compiler supports the latter. The guideline for converting int to size_t used in this patch is this: - if the variable is meant to store the number of bytes, and is always guaranteed to be positive, and could get arbitrarily large, use size_t - if the value could be negative also, use ssize_t - if the value is meant to store a number of "things", but this directly translates into size_t (e.g. number of pointers, number of characters), also use size_t/ssize_t - if the value is in a range limited to 32-bit int (e.g. the number of characters in a path name), convert the size_t to int, after asserting that the value really is in the range. This version is work in progress, and needs review. I hope to work on it during the sprints at PyConDC. ---------------------------------------------------------------------- >Comment By: Martin v. L?wis (loewis) Date: 2005-05-06 09:06 Message: Logged In: YES user_id=21627 Second version of the patch attached (PyCon version). It turns out that changing everything from signed to unsigned breaks too many things, so this version of the patch uses Py_ssize_t in nearly all places. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1166195&group_id=5470 From noreply at sourceforge.net Fri May 6 23:26:03 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 06 May 2005 14:26:03 -0700 Subject: [Patches] [ python-Patches-1196895 ] in IDLE, assume new text files are python source by default Message-ID: Patches item #1196895, was opened at 2005-05-06 17:25 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=1196895&group_id=5470 Category: IDLE Group: None Status: Open Resolution: None Priority: 5 Submitted By: Jeff Shute (jshute) Assigned to: Nobody/Anonymous (nobody) Summary: in IDLE, assume new text files are python source by default Initial Comment: This changes IDLE so that when you use File->New Window, it assumes that the file will be python source by default, so syntax highlighting will be enabled. Currently, when you make a new window, it assumes that it is not python source by default, so you do not get syntax highlighting until you save the file with extension .py. I believe this was the original intent of the code, based on the test for a missing filename, but it got broken at some point when the code was modified to accept a path instead of a missing filename. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1196895&group_id=5470 From noreply at sourceforge.net Fri May 6 23:33:37 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 06 May 2005 14:33:37 -0700 Subject: [Patches] [ python-Patches-1196903 ] smarter behaviour for home key in IDLE Message-ID: Patches item #1196903, was opened at 2005-05-06 17: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=1196903&group_id=5470 Category: IDLE Group: None Status: Open Resolution: None Priority: 5 Submitted By: Jeff Shute (jshute) Assigned to: Nobody/Anonymous (nobody) Summary: smarter behaviour for home key in IDLE Initial Comment: This patch modifies IDLE to have behaviour similar to other IDEs when you press home. Pressing ones takes you to the start of text on the line (skipping whitespace or the prompt characters). Pressing home again toggles between that position and the absolute start of the line. There was already some code in PyShell.py that attempted to do part of this for the prompt characters, but it did not work. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1196903&group_id=5470 From noreply at sourceforge.net Fri May 6 23:55:23 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 06 May 2005 14:55:23 -0700 Subject: [Patches] [ python-Patches-1196917 ] change recall in IDLE shell to not overwrite current command Message-ID: Patches item #1196917, was opened at 2005-05-06 17: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=1196917&group_id=5470 Category: IDLE Group: None Status: Open Resolution: None Priority: 5 Submitted By: Jeff Shute (jshute) Assigned to: Nobody/Anonymous (nobody) Summary: change recall in IDLE shell to not overwrite current command Initial Comment: Currently, when you move the cursor over any previous command/output and press enter, IDLE replaces the command you are currently typing with that text. I find this behaviour very annoying because I often end up doing it by accident when I switch from another window back to IDLE, and it cannot be undone, so I lose whatever command I was building up. This patch changes the behaviour so that instead of replacing your current text with the text under the cursor, the text under the cursor is inserted at the current location, using the auto-indenter to make sure it is put in the correct place. The operation also becomes undoable. This allows sequences like the following: >>> comp1() 5.436436 >>> comp2() 3.655546 >>> print 5.436436 + 3.655546 9.091982 where I have generated the third command like this: print [up, up, up, enter] + [up, enter][enter] or like this: >>> for a in set1: for b in set2: print a,b ... >>> for c in set3: for a in set1: for b in set2: print a,b I generate the second command by typing the first line, and then cursoring up to the previous command and pressing enter. The old loop is inserted properly indented into the new loop. (This does not work with copy and paste.) I can then continue to edit the combined command or press enter to run it. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1196917&group_id=5470 From noreply at sourceforge.net Sat May 7 00:21:04 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 06 May 2005 15:21:04 -0700 Subject: [Patches] [ python-Patches-1196895 ] in IDLE, assume new text files are python source by default Message-ID: Patches item #1196895, was opened at 2005-05-06 17:25 Message generated for change (Comment added) made by tim_one You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1196895&group_id=5470 Category: IDLE Group: None Status: Open Resolution: None Priority: 5 Submitted By: Jeff Shute (jshute) Assigned to: Nobody/Anonymous (nobody) Summary: in IDLE, assume new text files are python source by default Initial Comment: This changes IDLE so that when you use File->New Window, it assumes that the file will be python source by default, so syntax highlighting will be enabled. Currently, when you make a new window, it assumes that it is not python source by default, so you do not get syntax highlighting until you save the file with extension .py. I believe this was the original intent of the code, based on the test for a missing filename, but it got broken at some point when the code was modified to accept a path instead of a missing filename. ---------------------------------------------------------------------- >Comment By: Tim Peters (tim_one) Date: 2005-05-06 18:21 Message: Logged In: YES user_id=31435 I haven't looked at the patch, but +1 on the idea. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1196895&group_id=5470 From noreply at sourceforge.net Sat May 7 01:26:20 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 06 May 2005 16:26:20 -0700 Subject: [Patches] [ python-Patches-1196946 ] allow using normal indent width in shell in IDLE Message-ID: Patches item #1196946, was opened at 2005-05-06 19: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=1196946&group_id=5470 Category: IDLE Group: None Status: Open Resolution: None Priority: 5 Submitted By: Jeff Shute (jshute) Assigned to: Nobody/Anonymous (nobody) Summary: allow using normal indent width in shell in IDLE Initial Comment: IDLE currently ignores the indent width setting in the main shell window, and forces it to use tab characters, 8 spaces wide. This is ugly, and causes problems when you write code in the shell and then cut-and-paste it into a real editor window. This patch adds an option (off by default) to honour the indent width setting in the PyShell window rather than using tabs. This makes it much nicer to edit commands that use several levels of indenting. The only reason for this to be an option, and for it to be off by default, is that it looks a little weird when the second line of code is indented, but still lines up with the first indented line because the prompt is also 4 characters wide. Fixing it so this would not look weird would be nice, but would require a lot of Tk hacking and might make the gui slower. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1196946&group_id=5470 From noreply at sourceforge.net Sat May 7 11:47:27 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 07 May 2005 02:47:27 -0700 Subject: [Patches] [ python-Patches-1197150 ] _ssl.mak Makefile patch (Win32) Message-ID: Patches item #1197150, was opened at 2005-05-07 11:47 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1197150&group_id=5470 Category: Modules Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Joachim Kessel (counter) Assigned to: Nobody/Anonymous (nobody) Summary: _ssl.mak Makefile patch (Win32) Initial Comment: Hi, please find attached a small patch for the '_ssl.mak' Makefile in the 'PCbuild' Directory of Python 2.4.1 ('user32.lib' was missing). Here are the versions that I used ======================== Openssl: openssl-0.9.7-stable-SNAP-20050505 Python: 2.4.1 Error description ============ I was trying to compile Python 2.4.1 with SSL support using one of the latest snapshots from openssl, 'openssl-0.9.7-stable-SNAP-20050505'. While compiling in Visual Studio 2003 I got the following error: --- snip --- cl /nologo ../Modules/_ssl.c c:\temp\python_build\openssl-0.9.7-stable-SNAP-20050505/out32.dbg/libeay32.lib c:\temp\python_build\openssl-0.9.7-stable-SNAP-20050505/out32.dbg/ssleay32.lib /Od /Zi /MDd /LDd /DDEBUG /D_DEBUG /Fox86-temp-debug/_ssl\_ssl_d.obj -I ../Include -I ../PC -I c:\temp\python_build\openssl-0.9.7-stable-SNAP-20050505/inc32 /link /out:_ssl_d.pyd gdi32.lib wsock32.lib /libpath:c:\temp\python_build\openssl-0.9.7-stable-SNAP-20050505/out32.dbg libeay32.lib ssleay32.lib _ssl.c Creating library _ssl_d.lib and object _ssl_d.exp libeay32.lib(cryptlib.obj) : error LNK2019: unresolved external symbol __imp__MessageBoxIndirectA at 4 referenced in function _OPENSSL_showfatal _ssl_d.pyd : fatal error LNK1120: 1 unresolved externals NMAKE : fatal error U1077: 'cl' : return code '0x2' Stop. [7083 refs] Project : error PRJ0019: A tool returned an error code from "Performing Makefile project actions" --- snap --- The 'unresolved external symbol' relates to the missing 'user32.lib' in the '_ssl.mak' makefile. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1197150&group_id=5470 From noreply at sourceforge.net Sat May 7 14:21:31 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 07 May 2005 05:21:31 -0700 Subject: [Patches] [ python-Patches-1197207 ] Add proxies arg to urllib.urlretrieve Message-ID: Patches item #1197207, was opened at 2005-05-07 13: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=1197207&group_id=5470 Category: Library (Lib) Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: John Dubery (jdubery) Assigned to: Nobody/Anonymous (nobody) Summary: Add proxies arg to urllib.urlretrieve Initial Comment: Hi, The attached file is a modified version of the standard library's urllib.py (renamed to avoid import confusion on my system). I've done a simple addition of a "proxies" argument to function urlretrieve in a manner that is consistent with the proxies argument to urlopen. cheers, John Dubery ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1197207&group_id=5470 From noreply at sourceforge.net Sat May 7 14:58:08 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 07 May 2005 05:58:08 -0700 Subject: [Patches] [ python-Patches-1197218 ] test_locale fix on modern linux Message-ID: Patches item #1197218, was opened at 2005-05-07 22: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=1197218&group_id=5470 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Anthony Baxter (anthonybaxter) Assigned to: Nobody/Anonymous (nobody) Summary: test_locale fix on modern linux Initial Comment: At least on this Linux (Ubuntu Hoary), test_locale fails because en_US is not a valid locale. en_US.UTF-8 is, tho. This patch makes the test_locale try each of en_US.UTF-8, en_US.US-ASCII, and en_US in turn, failing only if none of them work. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1197218&group_id=5470 From noreply at sourceforge.net Sat May 7 17:56:50 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 07 May 2005 08:56:50 -0700 Subject: [Patches] [ python-Patches-1197318 ] Cygwin case-sensitive import patch Message-ID: Patches item #1197318, was opened at 2005-05-07 07:56 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1197318&group_id=5470 Category: Core (C code) Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: Jason Tishler (jlt63) Assigned to: Jason Tishler (jlt63) Summary: Cygwin case-sensitive import patch Initial Comment: A problem regarding importing symlinked modules was recently reported on the Cygwin mailing list: http://cygwin.com/ml/cygwin/2005-04/msg00257.html The following test case demonstrates the problem: $ ls -l total 1 lrwxrwxrwx 1 jt None 6 Apr 23 13:32 bar.py -> foo.py -rw-r--r-- 1 jt None 24 Apr 18 20:13 foo.py $ python -c 'import bar' Traceback (most recent call last): File "", line 1, in ? ImportError: No module named bar Since Cygwin's case_ok() uses a modified version of the Windows's version, the symlinked bar module actually resolves to file foo.py instead of bar.py. This obviously causes the matching code to fail (regardless of case). The attached patch fixes this problem. All that it does it make Cygwin use the Mac OS X case_ok() instead of a modified Window's version. Is this OK to apply? Or, would someone like to make sure I didn't break the Windows and Mac builds first? AFAICT, I didn't, but you never know... :,) Additionally, can I apply this patch to the 2.4 maintence branch? If so, is "release24-maint" the correct CVS tag to use? Thanks. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1197318&group_id=5470 From noreply at sourceforge.net Sun May 8 01:05:12 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 07 May 2005 16:05:12 -0700 Subject: [Patches] [ python-Patches-1166602 ] Decimal interaction with __rop__ Message-ID: Patches item #1166602, was opened at 2005-03-19 16:10 Message generated for change (Settings changed) made by facundobatista You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1166602&group_id=5470 Category: Library (Lib) Group: Python 2.4 >Status: Closed Resolution: None Priority: 5 Submitted By: Facundo Batista (facundobatista) Assigned to: Facundo Batista (facundobatista) Summary: Decimal interaction with __rop__ Initial Comment: Ok, this is the result of last discussion in python-dev. I changed _convert_other() to make it return NotImplemented, and check in every place where it's called to pass back the NotImplemented (something similar suggested Michael Hudson in the discussion: he passed back "other", but I think is cleaner just to pass the signal, and let the architecture to do whatever it should). The tests runs ok, seeing a +1.8% in test_decimal time. I'm sending this to you, because I... - Don't get to understand from the discussion if this is something that should be fixed at this level or at another. - Don't really know if this solution is as clean as it seems. Thanks! . Facundo ---------------------------------------------------------------------- >Comment By: Facundo Batista (facundobatista) Date: 2005-05-07 20:05 Message: Logged In: YES user_id=752496 Yours is slightly better, :). ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2005-04-10 13:44 Message: Logged In: YES user_id=80475 I had checked in my own patch for the rop issue. Please cross- check these two patches to see if one did something that the other had not. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1166602&group_id=5470 From noreply at sourceforge.net Mon May 9 01:26:32 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 08 May 2005 16:26:32 -0700 Subject: [Patches] [ python-Patches-1153056 ] PyXxx_Check() speed-up Message-ID: Patches item #1153056, was opened at 2005-02-27 22:14 Message generated for change (Comment added) made by sonderblade You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1153056&group_id=5470 Category: Core (C code) Group: None Status: Open Resolution: None Priority: 5 Submitted By: Armin Rigo (arigo) Assigned to: Nobody/Anonymous (nobody) Summary: PyXxx_Check() speed-up Initial Comment: Once upon a time, the macros PyInt_Check(), PyString_Check(), etc., used to be very fast: just a pointer comparison. But 2.2 came. Suddenly, types could inherit from each other. Thus the macros became: (ob->type == &PyXxx_Check || PyType_IsSubType(ob->type, &PyXxx_Check) Subtyping of built-in types still being rare, the common cases here are: (1) ob is indeed exactly of type Xxx, (2) ob is absolutely not an instance of Xxx. The macro is fast for case 1 but becomes a call to a slow function in case 2. It sounds minor -- but a program can make half a million "case 2" calls in 5 seconds. The following patch proposes to fix that, based on a few measurements that show which are the more common "case 2" calls in a few applications. It adds a family of type flags meaning "this type is not at all an Xxx", for Xxx in [module, tuple, float, int, unicode, long, complex, str]. I cannot measure the performance gain on this machine (figures vary all the time) but it looks like some 0.2s for the above-mentioned 5s program. ---------------------------------------------------------------------- Comment By: Bj?rn Lindqvist (sonderblade) Date: 2005-05-09 01:26 Message: Logged In: YES user_id=51702 With pystone.py I could measure a speedup of atleast 1000 pystones. From 36764 stones without the patch to 38461 with the patch. Granted, I didn't test very scientifically but the speedup is noticeable. ---------------------------------------------------------------------- Comment By: Armin Rigo (arigo) Date: 2005-04-14 15:48 Message: Logged In: YES user_id=4771 There might be problems with types that don't go through PyType_Ready(). We can't just compute the correct flags in there and do a single bit test in PyXxx_Check(), as far as I can see. Hence the idea to add the flag to a type only when it is dynamically found not to be a subtype of the given base type. I can't think of anything bad happening because of this mutation... ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2005-04-14 12:57 Message: Logged In: YES user_id=6656 I suppose I should read the patch then :) It seems very odd that _PyType_FastTypeCheck mutates a->tp_flags. In fact, shoudn't it be possible to not have _PyType_FastTypeCheck at all? ---------------------------------------------------------------------- Comment By: Armin Rigo (arigo) Date: 2005-04-14 11:22 Message: Logged In: YES user_id=4771 I am convinced now by #1153075 that PyCheck_Xxx should not be semantically changed, and really means walking the mro. So the patch here remains valid. Yes, I know that N is unbounded, that's why the next sentence was "let's only include the most common of them". Where to stop? Don't guess, measure. That's what I did, and in a few applications there were systematically a set of types that were PyChecked quite more often than the others. So my patch special-cases exactly these types. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2005-04-14 10:05 Message: Logged In: YES user_id=6656 (I haven't seen any mail about this patch!) > array of N bits, where N is the number of C-level PyXxxObject > structures That's unbounded too, in the presence of extension modules. (I still think my fix for #1153075 suffices, and is probably a good thing). I can believe that special casing int and str subclasses is worth it -- but where to stop? ---------------------------------------------------------------------- Comment By: Armin Rigo (arigo) Date: 2005-02-28 10:26 Message: Logged In: YES user_id=4771 Ah, but that's not so different: M can still be arbitrarily large... However, see also bug #1153075. I think that PyInt_Check() using PyType_IsSubtype() is essentially buggy: the purpose of PyInt_Check() is to check if the PyObject* is a PyIntObject*, not if its type pretends to have 'int' in its mro. If we fix this, then making PyType_IsSubtype() faster will become unrelated to making PyXxx_Check() faster. If we want to fix PyXxx_Check() for the bug described above and make it fast too, then we probably only need an array of N bits, where N is the number of C-level PyXxxObject structures. The idea of only including the most common such structures instead of all of them was based on simplicity and performance (it's faster and easier to check for a known bit than for a bit which itself is computed at run-time). If we want to make PyType_IsSubtype() fast, it might be worth the effort or not; we should measure it. But I think it's unrelated. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2005-02-28 07:20 Message: Logged In: YES user_id=21627 No. Each type would have an array of M bits, where M is the maximum number of a super class; each type would also store the value of M. As types are created and deleted dynamically, it might be necessary to keep track of assigned type numbers, and recycle them as types are deleted. ---------------------------------------------------------------------- Comment By: Armin Rigo (arigo) Date: 2005-02-28 00:56 Message: Logged In: YES user_id=4771 I'm not sure I understand your suggestion. Would each type have an array of N bits, where N is the total number of types that exist? That looks quite unreasonable in any program that builds a lot of types (I know some that build them programatically in loops). What I did is a limited version of that: a bitfield with room for only some commonly checked-for superclasses. (With some care, my patch could be modified to build the bitfield in PyType_Ready(); this would allow the PyXxx_Check() macros to become a single bit check operation.) Changing the base classes isn't an issue in my limited patch because you cannot ever add or remove the core built-in types I check for from the bases of an existing type. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2005-02-28 00:44 Message: Logged In: YES user_id=21627 I would rather see a constant-time subtype check implemented in Python, using strategies that other interpreters have been using for a long time. Essentially, each type gets a unique number (e.g. in the order of PyType_Ready calls), and a bit-field of all supertypes, with a bit set for each type that is one of its supertypes. Creation of the bitfield could be delayed until a subtype check is actually needed. The tricky part is to update the supertype bitmask when __super__ is assigned. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1153056&group_id=5470 From noreply at sourceforge.net Mon May 9 02:02:29 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 08 May 2005 17:02:29 -0700 Subject: [Patches] [ python-Patches-1107656 ] Add Thread.isActive() Message-ID: Patches item #1107656, was opened at 2005-01-23 06:43 Message generated for change (Comment added) made by sonderblade You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1107656&group_id=5470 Category: Library (Lib) Group: None Status: Open Resolution: None Priority: 5 Submitted By: Alan Green (alanvgreen) Assigned to: Nobody/Anonymous (nobody) Summary: Add Thread.isActive() Initial Comment: The documentation for threading.Thread states: """Once the thread's activity is started, the thread is considered 'alive' and 'active' (these concepts are almost, but not quite exactly, the same; their definition is intentionally somewhat vague). It stops being alive and active when its run() method terminates - either normally, or by raising an unhandled exception.""" This is confusing. There doesn't seem to be a need to expose both 'alive' and 'active' concepts in the API. The confusion was reported as part of Issue 912943 "7.5.6 Thread Objects is too vague" This patch: - adds an isActive() method to Thread, that tests whether the thread is active. - adds documentation for isActive() - modifies the documentation for isAlive(), noting that it is deprecated and explaining why. ---------------------------------------------------------------------- Comment By: Bj?rn Lindqvist (sonderblade) Date: 2005-05-09 02:02 Message: Logged In: YES user_id=51702 I'm confused. Wouldn't it be better to just keep the isAlive() method instead of deprecating it and introducing isActive() in its place? In that way you only have to change the documentation and the API can remain intact. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1107656&group_id=5470 From noreply at sourceforge.net Tue May 10 04:47:27 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 09 May 2005 19:47:27 -0700 Subject: [Patches] [ python-Patches-1192789 ] Use GCC4 ELF symbol visibility Message-ID: Patches item #1192789, was opened at 2005-04-30 07:46 Message generated for change (Comment added) made by jhenstridge You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1192789&group_id=5470 Category: Core (C code) Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: James Henstridge (jhenstridge) Assigned to: Nobody/Anonymous (nobody) Summary: Use GCC4 ELF symbol visibility Initial Comment: GCC4 includes some new features that make it easier to control what symbols are exported from a library for linking. The attached patch makes Python use these features, limiting the exported symbols to the public Python C API (i.e. the same symbols as are exported under Windows). The patch sets the ELF visibility of the public Python APIs to "protected", which means that the symbol is exported but internal calls to those symbols are done as direct function calls. In my local tests on i386 Linux, pystone and parrotbench run about 5% faster on a "--enable-shared" build of Python with the patch applied. For a non shared library build of Python, performance is pretty much identical (I'll probably need to do some more tests). However it still has the benefit of not exporting private Python API. The patch also touches the init routines of a number of extension modules, since they weren't marked with PyMODINIT_FUNC, which caused them to build incorrectly with the patch (the init function ended up being private, so Python couldn't load the module). I've only tested this patch against 2.4.1, but it probably applies without too much trouble to the 2.5 development line. ---------------------------------------------------------------------- >Comment By: James Henstridge (jhenstridge) Date: 2005-05-10 10:47 Message: Logged In: YES user_id=146903 I just tried out the patch on an AMD64 Linux machine. There is some improvement in the --enable-shared case, but it doesn't seem to be as big as on i386. I only tested pystone though, since parrotbench gives an assertion error on this box. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1192789&group_id=5470 From noreply at sourceforge.net Tue May 10 06:31:30 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 09 May 2005 21:31:30 -0700 Subject: [Patches] [ python-Patches-1123430 ] Python memory allocator: Free memory Message-ID: Patches item #1123430, was opened at 2005-02-15 16:27 Message generated for change (Comment added) made by vulturex You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1123430&group_id=5470 Category: Core (C code) Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: Evan Jones (vulturex) Assigned to: Nobody/Anonymous (nobody) Summary: Python memory allocator: Free memory Initial Comment: This is the second version of my Python memory allocator patch. The first version was discussed on the python-dev mailing list here: http://mail.python.org/pipermail/python-dev/2005-January/ 051255.html This patch enables Python to actually return memory to the system. The current version's memory usage will only grow. This version maintains the same backwards compatability guarantees as the previous version: Calling PyObject_Free with a pointer that was returned by malloc() while NOT holding the GIL will work, and will not corrupt the state of the memory allocator. The patch modifies obmalloc.c. If it is accepted, other modifications to that file are required. In particular, I have not yet updated the WITH_MEMORY_LIMITS implementation, nor have I looked closely at the PYMALLOC_DEBUG code to see what changes (if any) are required. ---------------------------------------------------------------------- >Comment By: Evan Jones (vulturex) Date: 2005-05-10 00:31 Message: Logged In: YES user_id=539295 Whoops! I uploaded a "fixed" version a while ago, but I guess I didn't update the comments. The patch currently attached to this is the most up- to-date version. Sorry about that. ---------------------------------------------------------------------- Comment By: Evan Jones (vulturex) Date: 2005-02-19 09:07 Message: Logged In: YES user_id=539295 As per the discussion on python-dev, I've removed the concurrency hack. The routines in obmalloc.c now *must* be called while holding the GIL, even if the pointer was allocated with malloc(). I also finally fixed the PYMALLOC_DEBUG routines, so I believe this patch is now "complete." ---------------------------------------------------------------------- Comment By: Evan Jones (vulturex) Date: 2005-02-18 17:08 Message: Logged In: YES user_id=539295 Please ignore this patch for the moment: I'm in the process of making some fixes. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1123430&group_id=5470 From watchara at email.thns.co.th Tue May 10 15:33:54 2005 From: watchara at email.thns.co.th (Watchara) Date: Tue, 10 May 2005 20:33:54 +0700 Subject: [Patches] Hi Message-ID: An HTML attachment was scrubbed... URL: http://mail.python.org/pipermail/patches/attachments/20050510/b4e9625e/attachment.html -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/gif Size: 14234 bytes Desc: not available Url : http://mail.python.org/pipermail/patches/attachments/20050510/b4e9625e/attachment.gif From noreply at sourceforge.net Wed May 11 19:16:31 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 11 May 2005 10:16:31 -0700 Subject: [Patches] [ python-Patches-1200018 ] Restore GC support to set objects Message-ID: Patches item #1200018, was opened at 2005-05-11 13:16 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1200018&group_id=5470 Category: Core (C code) Group: Python 2.4 Status: Open Resolution: None Priority: 7 Submitted By: Barry A. Warsaw (bwarsaw) Assigned to: Raymond Hettinger (rhettinger) Summary: Restore GC support to set objects Initial Comment: Contrary to what the log message for setobject.c 1.26 implies, built-in sets can indeed participate in cycles, so they must support GC. This patch restores GC support to built-in sets for Python 2.4. It should be ported to Python 2.5. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1200018&group_id=5470 From noreply at sourceforge.net Wed May 11 19:46:49 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 11 May 2005 10:46:49 -0700 Subject: [Patches] [ python-Patches-1200038 ] idlelib patch Message-ID: Patches item #1200038, was opened at 2005-05-11 17:46 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1200038&group_id=5470 Category: IDLE Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: sowjanya (sowjanya) Assigned to: Nobody/Anonymous (nobody) Summary: idlelib patch 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 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1200038&group_id=5470 From noreply at sourceforge.net Wed May 11 20:02:31 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 11 May 2005 11:02:31 -0700 Subject: [Patches] [ python-Patches-1200051 ] Small optimization for PyDict_Merge() Message-ID: Patches item #1200051, was opened at 2005-05-11 14:02 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=1200051&group_id=5470 Category: Core (C code) Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Barry A. Warsaw (bwarsaw) Assigned to: Raymond Hettinger (rhettinger) Summary: Small optimization for PyDict_Merge() Initial Comment: This patch avoids repeated PyDict_GetItem() calls when 'a' in PyDict_Merge() is known to be empty. Optimization found by Matt Messier. This could also be applied to Python 2.5. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1200051&group_id=5470 From noreply at sourceforge.net Wed May 11 21:58:48 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 11 May 2005 12:58:48 -0700 Subject: [Patches] [ python-Patches-1200018 ] Restore GC support to set objects Message-ID: Patches item #1200018, was opened at 2005-05-11 13:16 Message generated for change (Comment added) made by bwarsaw You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1200018&group_id=5470 Category: Core (C code) Group: Python 2.4 Status: Open Resolution: None Priority: 7 Submitted By: Barry A. Warsaw (bwarsaw) Assigned to: Raymond Hettinger (rhettinger) Summary: Restore GC support to set objects Initial Comment: Contrary to what the log message for setobject.c 1.26 implies, built-in sets can indeed participate in cycles, so they must support GC. This patch restores GC support to built-in sets for Python 2.4. It should be ported to Python 2.5. ---------------------------------------------------------------------- >Comment By: Barry A. Warsaw (bwarsaw) Date: 2005-05-11 15:58 Message: Logged In: YES user_id=12800 Actually, use set-patch2.txt because I don't believe you need to clear so->data in set_tp_clear(). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1200018&group_id=5470 From noreply at sourceforge.net Wed May 11 21:59:25 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 11 May 2005 12:59:25 -0700 Subject: [Patches] [ python-Patches-1200018 ] Restore GC support to set objects Message-ID: Patches item #1200018, was opened at 2005-05-11 13:16 Message generated for change (Comment added) made by bwarsaw You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1200018&group_id=5470 Category: Core (C code) Group: Python 2.4 Status: Open Resolution: None Priority: 7 Submitted By: Barry A. Warsaw (bwarsaw) Assigned to: Raymond Hettinger (rhettinger) Summary: Restore GC support to set objects Initial Comment: Contrary to what the log message for setobject.c 1.26 implies, built-in sets can indeed participate in cycles, so they must support GC. This patch restores GC support to built-in sets for Python 2.4. It should be ported to Python 2.5. ---------------------------------------------------------------------- >Comment By: Barry A. Warsaw (bwarsaw) Date: 2005-05-11 15:59 Message: Logged In: YES user_id=12800 cycle.py demonstrates the need for this patch ---------------------------------------------------------------------- Comment By: Barry A. Warsaw (bwarsaw) Date: 2005-05-11 15:58 Message: Logged In: YES user_id=12800 Actually, use set-patch2.txt because I don't believe you need to clear so->data in set_tp_clear(). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1200018&group_id=5470 From noreply at sourceforge.net Wed May 11 22:15:09 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 11 May 2005 13:15:09 -0700 Subject: [Patches] [ python-Patches-1200134 ] buffer overflow in _cursesmodule.c Message-ID: Patches item #1200134, was opened at 2005-05-11 22: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=1200134&group_id=5470 Category: Modules Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Jan Michael H?lsbergen (avu) Assigned to: Nobody/Anonymous (nobody) Summary: buffer overflow in _cursesmodule.c Initial Comment: In PyCursesWindow_GetStr(), a buffer with a fixed size of 1024 byte is used for reading the input from the user. This leads to a buffer overflow. If the user does not provide a limit to win.getstr(), wgetstr() is used, enforcing no limit at all, if the user provides a limit, it can be greater than 1024, leading to the same problem. My Patch replaces the buffer with a dynamicly allocated one, if the user does not provide a limit the maximum still is 1024. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1200134&group_id=5470 From noreply at sourceforge.net Thu May 12 00:20:09 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 11 May 2005 15:20:09 -0700 Subject: [Patches] [ python-Patches-1200018 ] Restore GC support to set objects Message-ID: Patches item #1200018, was opened at 2005-05-11 13:16 Message generated for change (Comment added) made by jimjjewett You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1200018&group_id=5470 Category: Core (C code) Group: Python 2.4 Status: Open Resolution: None Priority: 7 Submitted By: Barry A. Warsaw (bwarsaw) Assigned to: Raymond Hettinger (rhettinger) Summary: Restore GC support to set objects Initial Comment: Contrary to what the log message for setobject.c 1.26 implies, built-in sets can indeed participate in cycles, so they must support GC. This patch restores GC support to built-in sets for Python 2.4. It should be ported to Python 2.5. ---------------------------------------------------------------------- Comment By: Jim Jewett (jimjjewett) Date: 2005-05-11 18:20 Message: Logged In: YES user_id=764593 Clarification: cycle.py *as posted* does not demonstrate the problem, but if you uncomment the __del__ method in class foo, you will get uncollectable garbage. ---------------------------------------------------------------------- Comment By: Barry A. Warsaw (bwarsaw) Date: 2005-05-11 15:59 Message: Logged In: YES user_id=12800 cycle.py demonstrates the need for this patch ---------------------------------------------------------------------- Comment By: Barry A. Warsaw (bwarsaw) Date: 2005-05-11 15:58 Message: Logged In: YES user_id=12800 Actually, use set-patch2.txt because I don't believe you need to clear so->data in set_tp_clear(). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1200018&group_id=5470 From noreply at sourceforge.net Thu May 12 00:28:19 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 11 May 2005 15:28:19 -0700 Subject: [Patches] [ python-Patches-1166602 ] Decimal interaction with __rop__ Message-ID: Patches item #1166602, was opened at 2005-03-19 14:10 Message generated for change (Settings changed) made by tjreedy You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1166602&group_id=5470 Category: Library (Lib) Group: Python 2.4 Status: Closed >Resolution: Out of Date Priority: 5 Submitted By: Facundo Batista (facundobatista) Assigned to: Facundo Batista (facundobatista) Summary: Decimal interaction with __rop__ Initial Comment: Ok, this is the result of last discussion in python-dev. I changed _convert_other() to make it return NotImplemented, and check in every place where it's called to pass back the NotImplemented (something similar suggested Michael Hudson in the discussion: he passed back "other", but I think is cleaner just to pass the signal, and let the architecture to do whatever it should). The tests runs ok, seeing a +1.8% in test_decimal time. I'm sending this to you, because I... - Don't get to understand from the discussion if this is something that should be fixed at this level or at another. - Don't really know if this solution is as clean as it seems. Thanks! . Facundo ---------------------------------------------------------------------- Comment By: Facundo Batista (facundobatista) Date: 2005-05-07 19:05 Message: Logged In: YES user_id=752496 Yours is slightly better, :). ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2005-04-10 12:44 Message: Logged In: YES user_id=80475 I had checked in my own patch for the rop issue. Please cross- check these two patches to see if one did something that the other had not. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1166602&group_id=5470 From noreply at sourceforge.net Thu May 12 00:41:06 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 11 May 2005 15:41:06 -0700 Subject: [Patches] [ python-Patches-1200018 ] Restore GC support to set objects Message-ID: Patches item #1200018, was opened at 2005-05-11 13:16 Message generated for change (Comment added) made by bwarsaw You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1200018&group_id=5470 Category: Core (C code) Group: Python 2.4 Status: Open Resolution: None Priority: 7 Submitted By: Barry A. Warsaw (bwarsaw) Assigned to: Raymond Hettinger (rhettinger) Summary: Restore GC support to set objects Initial Comment: Contrary to what the log message for setobject.c 1.26 implies, built-in sets can indeed participate in cycles, so they must support GC. This patch restores GC support to built-in sets for Python 2.4. It should be ported to Python 2.5. ---------------------------------------------------------------------- >Comment By: Barry A. Warsaw (bwarsaw) Date: 2005-05-11 18:41 Message: Logged In: YES user_id=12800 Even without the __del__() method, notice how the second gc.collect() prints 0. With the patch it prints 4. ---------------------------------------------------------------------- Comment By: Jim Jewett (jimjjewett) Date: 2005-05-11 18:20 Message: Logged In: YES user_id=764593 Clarification: cycle.py *as posted* does not demonstrate the problem, but if you uncomment the __del__ method in class foo, you will get uncollectable garbage. ---------------------------------------------------------------------- Comment By: Barry A. Warsaw (bwarsaw) Date: 2005-05-11 15:59 Message: Logged In: YES user_id=12800 cycle.py demonstrates the need for this patch ---------------------------------------------------------------------- Comment By: Barry A. Warsaw (bwarsaw) Date: 2005-05-11 15:58 Message: Logged In: YES user_id=12800 Actually, use set-patch2.txt because I don't believe you need to clear so->data in set_tp_clear(). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1200018&group_id=5470 From noreply at sourceforge.net Thu May 12 01:02:19 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 11 May 2005 16:02:19 -0700 Subject: [Patches] [ python-Patches-1196946 ] allow using normal indent width in shell in IDLE Message-ID: Patches item #1196946, was opened at 2005-05-06 19:26 Message generated for change (Comment added) made by jimjjewett You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1196946&group_id=5470 Category: IDLE Group: None Status: Open Resolution: None Priority: 5 Submitted By: Jeff Shute (jshute) Assigned to: Nobody/Anonymous (nobody) Summary: allow using normal indent width in shell in IDLE Initial Comment: IDLE currently ignores the indent width setting in the main shell window, and forces it to use tab characters, 8 spaces wide. This is ugly, and causes problems when you write code in the shell and then cut-and-paste it into a real editor window. This patch adds an option (off by default) to honour the indent width setting in the PyShell window rather than using tabs. This makes it much nicer to edit commands that use several levels of indenting. The only reason for this to be an option, and for it to be off by default, is that it looks a little weird when the second line of code is indented, but still lines up with the first indented line because the prompt is also 4 characters wide. Fixing it so this would not look weird would be nice, but would require a lot of Tk hacking and might make the gui slower. ---------------------------------------------------------------------- Comment By: Jim Jewett (jimjjewett) Date: 2005-05-11 19:02 Message: Logged In: YES user_id=764593 Would using a continuation prompt of " "*len(sys.ps1) solve the problem? (standard module) code uses a continuation prompt of "... " which gets the spacing right, though it doesn't do your indents for you. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1196946&group_id=5470 From noreply at sourceforge.net Thu May 12 01:10:32 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 11 May 2005 16:10:32 -0700 Subject: [Patches] [ python-Patches-1196980 ] trivial bug in error message text Message-ID: Patches item #1196980, was opened at 2005-05-06 21:08 Message generated for change (Settings changed) made by tjreedy You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1196980&group_id=5470 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Jeff Shute (jshute) Assigned to: Nobody/Anonymous (nobody) Summary: trivial bug in error message text Initial Comment: This is a trivial patch to fix an error message in IDLE that refers to the Untabify menu choice as being in the Edit submenu when it is actually in the Format submenu. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1196980&group_id=5470 From noreply at sourceforge.net Thu May 12 06:46:11 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 11 May 2005 21:46:11 -0700 Subject: [Patches] [ python-Patches-1196946 ] allow using normal indent width in shell in IDLE Message-ID: Patches item #1196946, was opened at 2005-05-06 19:26 Message generated for change (Comment added) made by jshute You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1196946&group_id=5470 Category: IDLE Group: None Status: Open Resolution: None Priority: 5 Submitted By: Jeff Shute (jshute) Assigned to: Nobody/Anonymous (nobody) Summary: allow using normal indent width in shell in IDLE Initial Comment: IDLE currently ignores the indent width setting in the main shell window, and forces it to use tab characters, 8 spaces wide. This is ugly, and causes problems when you write code in the shell and then cut-and-paste it into a real editor window. This patch adds an option (off by default) to honour the indent width setting in the PyShell window rather than using tabs. This makes it much nicer to edit commands that use several levels of indenting. The only reason for this to be an option, and for it to be off by default, is that it looks a little weird when the second line of code is indented, but still lines up with the first indented line because the prompt is also 4 characters wide. Fixing it so this would not look weird would be nice, but would require a lot of Tk hacking and might make the gui slower. ---------------------------------------------------------------------- >Comment By: Jeff Shute (jshute) Date: 2005-05-12 00:46 Message: Logged In: YES user_id=39615 Hmm, I had only considered using a continuation of "...". Using spaces would make things look mostly right, and will have odd behaviour only when you cut-and-paste into an editor, since you will get an extra indentation level, but that won't cause errors and is easily fixed. Here is a new patch that implements it this way. I think doing it this way solves the problem well enough that the preference is not necessary. (Or both patches can be applied to get this behaviour and the preference.) ---------------------------------------------------------------------- Comment By: Jim Jewett (jimjjewett) Date: 2005-05-11 19:02 Message: Logged In: YES user_id=764593 Would using a continuation prompt of " "*len(sys.ps1) solve the problem? (standard module) code uses a continuation prompt of "... " which gets the spacing right, though it doesn't do your indents for you. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1196946&group_id=5470 From noreply at sourceforge.net Thu May 12 06:48:04 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 11 May 2005 21:48:04 -0700 Subject: [Patches] [ python-Patches-1196980 ] trivial bug in error message text Message-ID: Patches item #1196980, was opened at 2005-05-06 21:08 Message generated for change (Settings changed) made by jshute You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1196980&group_id=5470 >Category: IDLE Group: None Status: Open Resolution: None Priority: 5 Submitted By: Jeff Shute (jshute) Assigned to: Nobody/Anonymous (nobody) Summary: trivial bug in error message text Initial Comment: This is a trivial patch to fix an error message in IDLE that refers to the Untabify menu choice as being in the Edit submenu when it is actually in the Format submenu. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1196980&group_id=5470 From eurosemi at eurosemi.eu.com Thu May 12 12:33:08 2005 From: eurosemi at eurosemi.eu.com (eurosemi@eurosemi.eu.com) Date: Thu, 12 May 2005 11:33:08 +0100 (BST) Subject: [Patches] 300, 000 visitors in the last 4 months have turned to the European Semiconductor Directory Message-ID: <20050512103308.E890FD5FFA@silux.angelbc.co.uk> charset="iso-8859-1" Content-Transfer-Encoding:8bit More than 300,000 visitors in the last 4 months have turned to the European Semiconductor Directory to source products and services Make sure you're a part of it. Click Here For more information. Developed by the publishers of European Semiconductor Magazine, the Directory has exposure to over 1 million Semiconductor professionals every year. Are you missing out on new business? Make sure you're a part of it. Click Here For more information. Or Contact: Scott Adams scott at angelbc.co.uk To unsubscribe from this newsletter please CLICK HERE. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.python.org/pipermail/patches/attachments/20050512/1f3a7b53/attachment.htm From noreply at sourceforge.net Thu May 12 16:27:05 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 12 May 2005 07:27:05 -0700 Subject: [Patches] [ python-Patches-1196946 ] allow using normal indent width in shell in IDLE Message-ID: Patches item #1196946, was opened at 2005-05-06 18:26 Message generated for change (Settings changed) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1196946&group_id=5470 Category: IDLE Group: None Status: Open Resolution: None Priority: 5 Submitted By: Jeff Shute (jshute) >Assigned to: Kurt B. Kaiser (kbk) Summary: allow using normal indent width in shell in IDLE Initial Comment: IDLE currently ignores the indent width setting in the main shell window, and forces it to use tab characters, 8 spaces wide. This is ugly, and causes problems when you write code in the shell and then cut-and-paste it into a real editor window. This patch adds an option (off by default) to honour the indent width setting in the PyShell window rather than using tabs. This makes it much nicer to edit commands that use several levels of indenting. The only reason for this to be an option, and for it to be off by default, is that it looks a little weird when the second line of code is indented, but still lines up with the first indented line because the prompt is also 4 characters wide. Fixing it so this would not look weird would be nice, but would require a lot of Tk hacking and might make the gui slower. ---------------------------------------------------------------------- Comment By: Jeff Shute (jshute) Date: 2005-05-11 23:46 Message: Logged In: YES user_id=39615 Hmm, I had only considered using a continuation of "...". Using spaces would make things look mostly right, and will have odd behaviour only when you cut-and-paste into an editor, since you will get an extra indentation level, but that won't cause errors and is easily fixed. Here is a new patch that implements it this way. I think doing it this way solves the problem well enough that the preference is not necessary. (Or both patches can be applied to get this behaviour and the preference.) ---------------------------------------------------------------------- Comment By: Jim Jewett (jimjjewett) Date: 2005-05-11 18:02 Message: Logged In: YES user_id=764593 Would using a continuation prompt of " "*len(sys.ps1) solve the problem? (standard module) code uses a continuation prompt of "... " which gets the spacing right, though it doesn't do your indents for you. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1196946&group_id=5470 From noreply at sourceforge.net Thu May 12 16:31:28 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 12 May 2005 07:31:28 -0700 Subject: [Patches] [ python-Patches-1200051 ] Small optimization for PyDict_Merge() Message-ID: Patches item #1200051, was opened at 2005-05-11 13:02 Message generated for change (Settings changed) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1200051&group_id=5470 Category: Core (C code) >Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: Barry A. Warsaw (bwarsaw) Assigned to: Raymond Hettinger (rhettinger) Summary: Small optimization for PyDict_Merge() Initial Comment: This patch avoids repeated PyDict_GetItem() calls when 'a' in PyDict_Merge() is known to be empty. Optimization found by Matt Messier. This could also be applied to Python 2.5. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1200051&group_id=5470 From noreply at sourceforge.net Thu May 12 16:45:15 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 12 May 2005 07:45:15 -0700 Subject: [Patches] [ python-Patches-1200051 ] Small optimization for PyDict_Merge() Message-ID: Patches item #1200051, was opened at 2005-05-11 14:02 Message generated for change (Comment added) made by bwarsaw You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1200051&group_id=5470 Category: Core (C code) Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: Barry A. Warsaw (bwarsaw) Assigned to: Raymond Hettinger (rhettinger) Summary: Small optimization for PyDict_Merge() Initial Comment: This patch avoids repeated PyDict_GetItem() calls when 'a' in PyDict_Merge() is known to be empty. Optimization found by Matt Messier. This could also be applied to Python 2.5. ---------------------------------------------------------------------- >Comment By: Barry A. Warsaw (bwarsaw) Date: 2005-05-12 10:45 Message: Logged In: YES user_id=12800 Does changing the group mean you don't think this should be applied to 2.4? It doesn't change semantics at all. (I'm not necessarily disagreeing with you, but am just asking for some justification in the issue tracker.) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1200051&group_id=5470 From noreply at sourceforge.net Thu May 12 18:03:48 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 12 May 2005 09:03:48 -0700 Subject: [Patches] [ python-Patches-1200051 ] Small optimization for PyDict_Merge() Message-ID: Patches item #1200051, was opened at 2005-05-11 14:02 Message generated for change (Comment added) made by tim_one You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1200051&group_id=5470 Category: Core (C code) Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: Barry A. Warsaw (bwarsaw) Assigned to: Raymond Hettinger (rhettinger) Summary: Small optimization for PyDict_Merge() Initial Comment: This patch avoids repeated PyDict_GetItem() calls when 'a' in PyDict_Merge() is known to be empty. Optimization found by Matt Messier. This could also be applied to Python 2.5. ---------------------------------------------------------------------- >Comment By: Tim Peters (tim_one) Date: 2005-05-12 12:03 Message: Logged In: YES user_id=31435 Well, in general we don't backport optimizations: that something _could_ be made faster is rarely considered to be "a bug". If, e.g., this was very much faster in 2.3 than in 2.4, then _maybe_ it could be sold as a 2.4 bug. Otherwise presumption favors that it's just one more of the literally thousands of speedups that could always be made. In this case, it's not a pure win, so is especially dubious for a bugfix release: it adds a test + taken-branch to the critical path whenever the function is called with a _non_-empty target dict. So it slows what's probably the most common case a little, in order to speed a probably-rarer case. Is that a net win or net loss? Depends on the app, I suppose. Did you try this in your app and _measure_ a net win? ---------------------------------------------------------------------- Comment By: Barry A. Warsaw (bwarsaw) Date: 2005-05-12 10:45 Message: Logged In: YES user_id=12800 Does changing the group mean you don't think this should be applied to 2.4? It doesn't change semantics at all. (I'm not necessarily disagreeing with you, but am just asking for some justification in the issue tracker.) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1200051&group_id=5470 From noreply at sourceforge.net Thu May 12 18:41:49 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 12 May 2005 09:41:49 -0700 Subject: [Patches] [ python-Patches-1200051 ] Small optimization for PyDict_Merge() Message-ID: Patches item #1200051, was opened at 2005-05-11 13:02 Message generated for change (Comment added) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1200051&group_id=5470 Category: Core (C code) Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: Barry A. Warsaw (bwarsaw) Assigned to: Raymond Hettinger (rhettinger) Summary: Small optimization for PyDict_Merge() Initial Comment: This patch avoids repeated PyDict_GetItem() calls when 'a' in PyDict_Merge() is known to be empty. Optimization found by Matt Messier. This could also be applied to Python 2.5. ---------------------------------------------------------------------- >Comment By: Raymond Hettinger (rhettinger) Date: 2005-05-12 11:41 Message: Logged In: YES user_id=80475 Right. I marked it for 2.5 because optimizations usually do not get backported. With respect to Tim's comment about slowing the common case, I don't see it. The test is outside the inner loop. The variable that it sets helps short-circuit the inner-loop tests. All-in-all, it's a net win. With respect to measurement, I would be surprised if the OP could easily demonstrate a speed-up. Grepping through Objects and Modules shows zero calls to PyDict_Merge() where the override argument is zero. The idea looks sound, but it looks like you're optimizing a case the doesn't occur in practice. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2005-05-12 11:03 Message: Logged In: YES user_id=31435 Well, in general we don't backport optimizations: that something _could_ be made faster is rarely considered to be "a bug". If, e.g., this was very much faster in 2.3 than in 2.4, then _maybe_ it could be sold as a 2.4 bug. Otherwise presumption favors that it's just one more of the literally thousands of speedups that could always be made. In this case, it's not a pure win, so is especially dubious for a bugfix release: it adds a test + taken-branch to the critical path whenever the function is called with a _non_-empty target dict. So it slows what's probably the most common case a little, in order to speed a probably-rarer case. Is that a net win or net loss? Depends on the app, I suppose. Did you try this in your app and _measure_ a net win? ---------------------------------------------------------------------- Comment By: Barry A. Warsaw (bwarsaw) Date: 2005-05-12 09:45 Message: Logged In: YES user_id=12800 Does changing the group mean you don't think this should be applied to 2.4? It doesn't change semantics at all. (I'm not necessarily disagreeing with you, but am just asking for some justification in the issue tracker.) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1200051&group_id=5470 From noreply at sourceforge.net Thu May 12 19:38:51 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 12 May 2005 10:38:51 -0700 Subject: [Patches] [ python-Patches-1200051 ] Small optimization for PyDict_Merge() Message-ID: Patches item #1200051, was opened at 2005-05-11 14:02 Message generated for change (Comment added) made by bwarsaw You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1200051&group_id=5470 Category: Core (C code) Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: Barry A. Warsaw (bwarsaw) Assigned to: Raymond Hettinger (rhettinger) Summary: Small optimization for PyDict_Merge() Initial Comment: This patch avoids repeated PyDict_GetItem() calls when 'a' in PyDict_Merge() is known to be empty. Optimization found by Matt Messier. This could also be applied to Python 2.5. ---------------------------------------------------------------------- >Comment By: Barry A. Warsaw (bwarsaw) Date: 2005-05-12 13:38 Message: Logged In: YES user_id=12800 Thanks for the clarification. It happens in our code, but I can't say I've done much benchmarking. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2005-05-12 12:41 Message: Logged In: YES user_id=80475 Right. I marked it for 2.5 because optimizations usually do not get backported. With respect to Tim's comment about slowing the common case, I don't see it. The test is outside the inner loop. The variable that it sets helps short-circuit the inner-loop tests. All-in-all, it's a net win. With respect to measurement, I would be surprised if the OP could easily demonstrate a speed-up. Grepping through Objects and Modules shows zero calls to PyDict_Merge() where the override argument is zero. The idea looks sound, but it looks like you're optimizing a case the doesn't occur in practice. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2005-05-12 12:03 Message: Logged In: YES user_id=31435 Well, in general we don't backport optimizations: that something _could_ be made faster is rarely considered to be "a bug". If, e.g., this was very much faster in 2.3 than in 2.4, then _maybe_ it could be sold as a 2.4 bug. Otherwise presumption favors that it's just one more of the literally thousands of speedups that could always be made. In this case, it's not a pure win, so is especially dubious for a bugfix release: it adds a test + taken-branch to the critical path whenever the function is called with a _non_-empty target dict. So it slows what's probably the most common case a little, in order to speed a probably-rarer case. Is that a net win or net loss? Depends on the app, I suppose. Did you try this in your app and _measure_ a net win? ---------------------------------------------------------------------- Comment By: Barry A. Warsaw (bwarsaw) Date: 2005-05-12 10:45 Message: Logged In: YES user_id=12800 Does changing the group mean you don't think this should be applied to 2.4? It doesn't change semantics at all. (I'm not necessarily disagreeing with you, but am just asking for some justification in the issue tracker.) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1200051&group_id=5470 From noreply at sourceforge.net Fri May 13 05:57:33 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 12 May 2005 20:57:33 -0700 Subject: [Patches] [ python-Patches-1049855 ] PyOS_InputHook inconsistency on Windows Message-ID: Patches item #1049855, was opened at 2004-10-19 18:03 Message generated for change (Comment added) made by mdehoon You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1049855&group_id=5470 Category: IDLE Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Michiel de Hoon (mdehoon) Assigned to: Nobody/Anonymous (nobody) Summary: PyOS_InputHook inconsistency on Windows Initial Comment: PyOS_InputHook is a pointer to a function to be called periodically when Python is idle. It is used, for example, to get messages delivered to graphics windows. If I compile Python from source (which uses Modules/readline.c), PyOS_InputHook is called ten times per second. However, with the Windows-version of Python, PyOS_InputHook is called only once for each command typed by the user. It seems that the problem resides in Parser/myreadline.c (which I presume is used for the Windows-version of Python): if (PyOS_InputHook != NULL) (void)(PyOS_InputHook)(); ... p = fgets(buf, len, fp); Python idles at "fgets", but PyOS_InputHook is not being called while Python is idle. The attached patch solves this problem by using the "select" function, basically in the same way as what is in Module/readline.c. I don't know how to compile Python for Windows, so I wasn't able to test this patch. ---------------------------------------------------------------------- >Comment By: Michiel de Hoon (mdehoon) Date: 2005-05-13 12:57 Message: Logged In: YES user_id=488897 I have rewritten the patch to include Windows support. I compiled Python on Windows with VC98, and on Linux and Mac OS X and found no problems with it. The new patch is attached. ---------------------------------------------------------------------- Comment By: Kurt B. Kaiser (kbk) Date: 2005-05-02 12:40 Message: Logged In: YES user_id=149084 Yeah, that's why I didn't want to check it in, I can't build on Windows ithe VC 5. ---------------------------------------------------------------------- Comment By: Michiel de Hoon (mdehoon) Date: 2005-05-02 11:52 Message: Logged In: YES user_id=488897 Thanks for looking at this patch. Today I found out that it is possible to compile Python 2.4.1 with the older Microsoft Visual Studio 6.0, which I happen to have in my office. It turned out that the patch does not work correctly on Windows, due to the fact that the "select" function doesn't work with stdin on Windows. I will fix the patch so it'll work on Windows too. ---------------------------------------------------------------------- Comment By: Kurt B. Kaiser (kbk) Date: 2005-05-01 03:21 Message: Logged In: YES user_id=149084 The revised patch looks ok to me. ---------------------------------------------------------------------- Comment By: Michiel de Hoon (mdehoon) Date: 2005-03-26 22:33 Message: Logged In: YES user_id=488897 I have now tested this patch. After fixing one error (I had forgotton to declare one variable), the patch works correctly. I have uploaded a fixed patch. Note that this bug occurs not only on Windows, but on any Python compiled without readline. (which allowed me to test this patch by compiling Python without readline support). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1049855&group_id=5470 From noreply at sourceforge.net Fri May 13 19:09:03 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 13 May 2005 10:09:03 -0700 Subject: [Patches] [ python-Patches-1201522 ] patch IDLE to allow running anonymous code in editor window Message-ID: Patches item #1201522, was opened at 2005-05-13 13: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=1201522&group_id=5470 Category: IDLE Group: None Status: Open Resolution: None Priority: 5 Submitted By: Jeff Shute (jshute) Assigned to: Nobody/Anonymous (nobody) Summary: patch IDLE to allow running anonymous code in editor window Initial Comment: This patch modifies IDLE so that when you can run code in an editor window that does not have a filename without first having to save the code. When you are editing an existing file, or have already saved the code once (giving it a filename), you are still required to save before you can run. This is useful when using IDLE for interactive hacking or calculating. Having to save and choose a filename is annoying when typing and running code that you have no intention of keeping, and tends to encourage editing big blocks of code in the shell when using an editor window would really be more convenient. I think the only reason that the save is required is because the debugger was getting confused when it did not have a backing file with the code. This patch fixes the debugger so it can handle unsaved anonymous code, and can highlight the correct source line in the edit window when the show source box is checked. The enhancement also works for the shell window, so the debugger can highlight the source line in the shell window (which may be something other than the last command, eg a function definition). The stack viewer and goto line command are also fixed to handle unsaved edit windows and the shell. It probably makes sense to apply this trivial patch also so you can get syntax highlighting in unsaved editor windows. http://sourceforge.net/tracker/index.php?func=detail&aid=1196895&group_id=5470&atid=305470 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1201522&group_id=5470 From noreply at sourceforge.net Fri May 13 20:03:15 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 13 May 2005 11:03:15 -0700 Subject: [Patches] [ python-Patches-1201569 ] allow running multiple instances of IDLE Message-ID: Patches item #1201569, was opened at 2005-05-13 14:03 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1201569&group_id=5470 Category: IDLE Group: None Status: Open Resolution: None Priority: 5 Submitted By: Jeff Shute (jshute) Assigned to: Nobody/Anonymous (nobody) Summary: allow running multiple instances of IDLE Initial Comment: This patch will allow running multiple instances of IDLE in the default (mutli-process) mode by choosing the first available port from 8833-8893 instead of failing when another IDLE has already bound port 8833. (Not tested on windows.) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1201569&group_id=5470 From noreply at sourceforge.net Sat May 14 20:08:58 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 14 May 2005 11:08:58 -0700 Subject: [Patches] [ python-Patches-1200051 ] Small optimization for PyDict_Merge() Message-ID: Patches item #1200051, was opened at 2005-05-11 13:02 Message generated for change (Comment added) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1200051&group_id=5470 Category: Core (C code) Group: Python 2.5 >Status: Closed >Resolution: Accepted Priority: 5 Submitted By: Barry A. Warsaw (bwarsaw) Assigned to: Raymond Hettinger (rhettinger) Summary: Small optimization for PyDict_Merge() Initial Comment: This patch avoids repeated PyDict_GetItem() calls when 'a' in PyDict_Merge() is known to be empty. Optimization found by Matt Messier. This could also be applied to Python 2.5. ---------------------------------------------------------------------- >Comment By: Raymond Hettinger (rhettinger) Date: 2005-05-14 13:08 Message: Logged In: YES user_id=80475 Applied as Objects/dictobject.c 2.165 ---------------------------------------------------------------------- Comment By: Barry A. Warsaw (bwarsaw) Date: 2005-05-12 12:38 Message: Logged In: YES user_id=12800 Thanks for the clarification. It happens in our code, but I can't say I've done much benchmarking. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2005-05-12 11:41 Message: Logged In: YES user_id=80475 Right. I marked it for 2.5 because optimizations usually do not get backported. With respect to Tim's comment about slowing the common case, I don't see it. The test is outside the inner loop. The variable that it sets helps short-circuit the inner-loop tests. All-in-all, it's a net win. With respect to measurement, I would be surprised if the OP could easily demonstrate a speed-up. Grepping through Objects and Modules shows zero calls to PyDict_Merge() where the override argument is zero. The idea looks sound, but it looks like you're optimizing a case the doesn't occur in practice. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2005-05-12 11:03 Message: Logged In: YES user_id=31435 Well, in general we don't backport optimizations: that something _could_ be made faster is rarely considered to be "a bug". If, e.g., this was very much faster in 2.3 than in 2.4, then _maybe_ it could be sold as a 2.4 bug. Otherwise presumption favors that it's just one more of the literally thousands of speedups that could always be made. In this case, it's not a pure win, so is especially dubious for a bugfix release: it adds a test + taken-branch to the critical path whenever the function is called with a _non_-empty target dict. So it slows what's probably the most common case a little, in order to speed a probably-rarer case. Is that a net win or net loss? Depends on the app, I suppose. Did you try this in your app and _measure_ a net win? ---------------------------------------------------------------------- Comment By: Barry A. Warsaw (bwarsaw) Date: 2005-05-12 09:45 Message: Logged In: YES user_id=12800 Does changing the group mean you don't think this should be applied to 2.4? It doesn't change semantics at all. (I'm not necessarily disagreeing with you, but am just asking for some justification in the issue tracker.) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1200051&group_id=5470 From noreply at sourceforge.net Sat May 14 22:55:16 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 14 May 2005 13:55:16 -0700 Subject: [Patches] [ python-Patches-1120353 ] better datetime support for xmlrpclib Message-ID: Patches item #1120353, was opened at 2005-02-10 15:25 Message generated for change (Settings changed) made by montanaro You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1120353&group_id=5470 Category: Library (Lib) Group: Python 2.5 >Status: Closed >Resolution: Accepted Priority: 5 Submitted By: Fred L. Drake, Jr. (fdrake) Assigned to: Skip Montanaro (montanaro) Summary: better datetime support for xmlrpclib Initial Comment: This patch makes it possible for an application to ask that datetime objects be used instead of xmlrpclib.DateTime instances. I'm submitting this as a patch instead of checking this in since it's a more invasive change to Fredrik's module than my earlier change to make it accept datetime objects as valid date/time values. ---------------------------------------------------------------------- >Comment By: Skip Montanaro (montanaro) Date: 2005-05-14 15:55 Message: Logged In: YES user_id=44345 libxmlrpclib.tex 1.23, xmlrpclib.py 1.41, test_xmlrpc.py 1.9 ---------------------------------------------------------------------- Comment By: Fredrik Lundh (effbot) Date: 2005-03-24 05:09 Message: Logged In: YES user_id=38376 I don't have time to review the patches, but I agree that this would be a good thing, and that it's better to support it at both ends. Skip, I'm assigning this one to you. Can you check Fred's patch, merge relevant portions with your patch, and check it all in? ---------------------------------------------------------------------- Comment By: Skip Montanaro (montanaro) Date: 2005-03-17 20:27 Message: Logged In: YES user_id=44345 I just implemented something similar in a copy of xmlrpclib I installed on a 2.3 system. In addition to allowing strings to decode to datetime.datetime objects, I allowed datetime.time and datetime.date objects as input. The former is accomodated by setting the date part to the current date, the latter by setting the time to 00:00:00. Fredrik, any comment? I think it would improve the transparency of Python's xmlrpc interface if datetime objects worked at both ends of the transmission. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1120353&group_id=5470 From noreply at sourceforge.net Mon May 16 04:43:12 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 15 May 2005 19:43:12 -0700 Subject: [Patches] [ python-Patches-1103951 ] Add O_SHLOCK/O_EXLOCK to posix Message-ID: Patches item #1103951, was opened at 2005-01-17 09:20 Message generated for change (Comment added) made by montanaro You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1103951&group_id=5470 Category: Library (Lib) Group: Python 2.5 >Status: Closed >Resolution: Accepted Priority: 5 Submitted By: Skip Montanaro (montanaro) Assigned to: Skip Montanaro (montanaro) Summary: Add O_SHLOCK/O_EXLOCK to posix Initial Comment: Attached is a patch to add O_SHLOCK and O_EXLOCK to the posix module. This was motivated by a thread on c.l.py. I'm not sure the simple tests are sufficient, but hopefully so. Also, I'm not sure where, if at all, this should go for non-posix platforms like Windows. ---------------------------------------------------------------------- >Comment By: Skip Montanaro (montanaro) Date: 2005-05-15 21:43 Message: Logged In: YES user_id=44345 libos.tex 1.154 posixmodule.c 2.335 ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2005-01-18 15:10 Message: Logged In: YES user_id=21627 The code itself is fine, but it lacks a change to Doc/lib/libos.tex. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1103951&group_id=5470 From noreply at sourceforge.net Mon May 16 16:11:04 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 16 May 2005 07:11:04 -0700 Subject: [Patches] [ python-Patches-1101726 ] Patch for potential buffer overrun in tokenizer.c Message-ID: Patches item #1101726, was opened at 2005-01-13 16:45 Message generated for change (Comment added) made by doerwalter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1101726&group_id=5470 Category: Core (C code) Group: Python 2.4 Status: Open Resolution: None Priority: 7 Submitted By: Greg Chapman (glchapman) Assigned to: Martin v. L?wis (loewis) Summary: Patch for potential buffer overrun in tokenizer.c Initial Comment: The fp_readl function in tokenizer.c has a potential buffer overrun; see: www.python.org/sf/1089395 It is also triggered by trying to generate the pycom file for the Excel 11.0 typelib, which is where I ran into it. The attached patch allows successful generation of the Excel file; it also runs the fail.py script from the above report without an access violation. It also doesn't break any of the tests in the regression suite (probably something like fail.py should be added as a test). It is not as efficient as it might be; with a function for determining the number of unicode characters in a utf8 string, you could avoid some memory allocations. Perhaps such a function should be added to unicodeobject.c? And, of course, the patch definitely needs review. I'm especially concerned that my use of tok->decoding_buffer might be violating some kind of assumption that I missed. ---------------------------------------------------------------------- >Comment By: Walter D?rwald (doerwalter) Date: 2005-05-16 16:11 Message: Logged In: YES user_id=89016 Here is another version of the patch, this version doesn't pass any arguments to readline(), because it's no longer neccessary to limit the line length. What do you think? ---------------------------------------------------------------------- Comment By: Greg Chapman (glchapman) Date: 2005-03-21 14:47 Message: Logged In: YES user_id=86307 You're quite right, 2.4 AV's reliably using the new test_pep263. The copy of python24.dll I was testing against already had (the first version of) the patch applied. Anyway, I'm attaching a diff for test_pep263 (against the original 2.4 test_pep263) which incorporates your suggestions about not assuming the current directory. ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2005-03-14 22:43 Message: Logged In: YES user_id=89016 Maybe I've put the test files in the wrong spot, but what I'm getting is: > ./python Lib/test/test_pep263.py test_pep263 (__main__.PEP263Test) ... ok test_evilencoding (__main__.EvilEncodingTest) ... ok Segmentation fault You should probably put pep263_evilencoding.py and pep263_longline.py alongside test_pep263.py and then find then via os.path.join(__file__.rsplit(os.sep, 1)[0], "pep263_longline.py") ---------------------------------------------------------------------- Comment By: Greg Chapman (glchapman) Date: 2005-02-27 16:22 Message: Logged In: YES user_id=86307 After thinking about it some more, I realized that fp_readl doesn?t have to do any utf8 manipulation. If the string it copies into the buffer does not include a \n, the buffer is expanded and fp_readl is called again until a \n is returned (or the end of the file is reached). It doesn?t matter if, during this loop, the buffer contains temporarily broken utf8 characters. So I?m attaching another new patch. This copies as many characters as fit into the buffer and saves any overflow into a new string object (stored in tok >decoding_buffer). When it is called again by the loop, it uses this overflow string to copy characters into the buffer. I?m also attaching a zip file with a modified test_pep263.py and some ancillary files. To test fp_readl, python needs to read from a file. Perhaps it would be better to generate temporary files rather than include these extra files. Also, although the tests will trigger the assert using a debug build of the 2.4 source, I?m not getting an access violation running regrtest against a release build (of 2.4) ? perhaps different tests are in order? ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2005-02-23 20:48 Message: Logged In: YES user_id=89016 I think the patch looks good. Staring at it for a while I believe the reference counts are OK. Can you incorporate fail.py into the test suite? ---------------------------------------------------------------------- Comment By: Greg Chapman (glchapman) Date: 2005-01-23 15:26 Message: Logged In: YES user_id=86307 I'm attaching a new patch (tokenizer.c.2.diff), which should be better since it avoids some unnecessary allocations and decoding/encoding. Hopefully, I haven't made any unwarranted assumptions about UTF8. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1101726&group_id=5470 From noreply at sourceforge.net Mon May 16 09:52:07 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 16 May 2005 00:52:07 -0700 Subject: [Patches] [ python-Patches-1166780 ] Fix _tryorder in webbrowser.py Message-ID: Patches item #1166780, was opened at 2005-03-20 05:25 Message generated for change (Comment added) made by doerwalter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1166780&group_id=5470 Category: Library (Lib) Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: Rodrigo Dias Arruda Senra (rodsenra) Assigned to: Nobody/Anonymous (nobody) Summary: Fix _tryorder in webbrowser.py Initial Comment: At the present time (Py2.4): """ Under Unix, if the environment variable BROWSER exists, it is interpreted to override the platform default list of browsers,... """ (extract from Python-2.4/Doc/html/lib/module-webbrowser.html) But, when the environment variable BROWSER is messed up, there is no reason not to try the other detected browser alternatives. In this patch, if the BROWSER variable is Ok, than it is respected. Otherwise, the previously detected browsers are tryied out as if BROWSER variable never existed. This does not break backward compatibility and adds more chance for webbrowser.open() to succeed. This patch was made against CVS head 2005-03-20, and aims to 2.5, but can safely be apllied to any 2.4.x bug fix release. ---------------------------------------------------------------------- >Comment By: Walter D?rwald (doerwalter) Date: 2005-05-16 09:52 Message: Logged In: YES user_id=89016 If this patch is subsumed by 754022 can we close this one? ---------------------------------------------------------------------- Comment By: Rodrigo Dias Arruda Senra (rodsenra) Date: 2005-03-27 16:18 Message: Logged In: YES user_id=9057 Michiel de Hoon, this patch is obsolete after the latest revision of patch [ 754022 ] Enhanced webbrowser.py, that integrates this functionality and others in a single patch. Moreover, if a user sets BROWSER incorrectly, to see another browser opening will probably lead him to find that BROWSER was set incorrectly. IMO it is better to see a different browser opening than no browser at all. But thank you for revising this patch. ---------------------------------------------------------------------- Comment By: Michiel de Hoon (mdehoon) Date: 2005-03-27 10:03 Message: Logged In: YES user_id=488897 I agree that this patch will improve chances that webbrowser.open() will succeed. I'm a bit worried though that if a user sets BROWSER incorrectly, it may cause some confusion to see another browser opening. So we might some some bug reports saying "webbrowser.py ignores BROWSER variable" because a user set BROWSER incorrectly. One solution might be to print some warning message if the browser specified in BROWSER cannot be used. (I'm just a patch reviewer, not an official Python developer, so you don't need to take my comment to seriously :-)). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1166780&group_id=5470 From noreply at sourceforge.net Mon May 16 22:03:02 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 16 May 2005 13:03:02 -0700 Subject: [Patches] [ python-Patches-1203094 ] httplib mentions getreply instead of getresponse Message-ID: Patches item #1203094, was opened at 2005-05-16 20:03 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1203094&group_id=5470 Category: Documentation Group: None Status: Open Resolution: None Priority: 5 Submitted By: Robert Brewer (aminusfu) Assigned to: Nobody/Anonymous (nobody) Summary: httplib mentions getreply instead of getresponse Initial Comment: See Bug 1202475. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1203094&group_id=5470 From noreply at sourceforge.net Tue May 17 08:02:39 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 16 May 2005 23:02:39 -0700 Subject: [Patches] [ python-Patches-1203329 ] workaround deprecated ostat structure in Message-ID: Patches item #1203329, was opened at 2005-05-17 06:02 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=1203329&group_id=5470 Category: Macintosh Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: J. J. Snitow (supercusp) Assigned to: Jack Jansen (jackjansen) Summary: workaround deprecated ostat structure in Initial Comment: This is a patch to python/python/dist/src/Include/pyport.h, CVS revision 2.70. On Mac OS X 10.4 (Tiger), the file /usr/include/sys/stat.h contains the ostat structure, which the in-file comments call "XXX So deprecated, it would make your head spin". This structure is not used by the kernel and should not be used by user programs (so the comments say). An "#ifndef _POSIX_C_SOURCE" protects #includers of sys/stat.h from this horrible struct (which doesn't even compile). This patch to Include/pyport.h makes sure that _POSIX_C_SOURCE is always defined before including sys/stat.h. Notably, this patch enables the stock Darwinports port of PyOpenGL (py-opengl) to compile and run just fine on Tiger. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1203329&group_id=5470 From noreply at sourceforge.net Tue May 17 10:39:51 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 17 May 2005 01:39:51 -0700 Subject: [Patches] [ python-Patches-1203393 ] Patch for [ 1163563 ] Sub threads execute in restricted mode Message-ID: Patches item #1203393, was opened at 2005-05-17 10: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=1203393&group_id=5470 Category: Core (C code) Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: anothermax (yetanothermax) Assigned to: Nobody/Anonymous (nobody) Summary: Patch for [ 1163563 ] Sub threads execute in restricted mode Initial Comment: The thread module delivered with versions of python greater than 2.3.4 is not compatible with the use of sub interpreters, this causes problems with the jep product and seems also to be a problem for mod_python. This has been raised as a bug "[ 1163563 ] Sub threads execute in restricted mode" (http://sourceforge.net/tracker/index.php? func=detail&aid=1163563&group_id=5470&atid=105470) please see this bug report for further details. The problem seems to be the with use of PyGIL_StateXXX functions in the module. This patch replaces these calls with those used in pre- 2.3.5 threadmodule.c. A file called threadtest.c is attached to the bug report which demonstrates the problem. I'm using Python version 2.4.1 on Windows XP SP1 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1203393&group_id=5470 From noreply at sourceforge.net Tue May 17 15:47:10 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 17 May 2005 06:47:10 -0700 Subject: [Patches] [ python-Patches-1101726 ] Patch for potential buffer overrun in tokenizer.c Message-ID: Patches item #1101726, was opened at 2005-01-13 06:45 Message generated for change (Comment added) made by glchapman You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1101726&group_id=5470 Category: Core (C code) Group: Python 2.4 Status: Open Resolution: None Priority: 7 Submitted By: Greg Chapman (glchapman) Assigned to: Martin v. L?wis (loewis) Summary: Patch for potential buffer overrun in tokenizer.c Initial Comment: The fp_readl function in tokenizer.c has a potential buffer overrun; see: www.python.org/sf/1089395 It is also triggered by trying to generate the pycom file for the Excel 11.0 typelib, which is where I ran into it. The attached patch allows successful generation of the Excel file; it also runs the fail.py script from the above report without an access violation. It also doesn't break any of the tests in the regression suite (probably something like fail.py should be added as a test). It is not as efficient as it might be; with a function for determining the number of unicode characters in a utf8 string, you could avoid some memory allocations. Perhaps such a function should be added to unicodeobject.c? And, of course, the patch definitely needs review. I'm especially concerned that my use of tok->decoding_buffer might be violating some kind of assumption that I missed. ---------------------------------------------------------------------- >Comment By: Greg Chapman (glchapman) Date: 2005-05-17 05:47 Message: Logged In: YES user_id=86307 Looks good to me. ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2005-05-16 06:11 Message: Logged In: YES user_id=89016 Here is another version of the patch, this version doesn't pass any arguments to readline(), because it's no longer neccessary to limit the line length. What do you think? ---------------------------------------------------------------------- Comment By: Greg Chapman (glchapman) Date: 2005-03-21 04:47 Message: Logged In: YES user_id=86307 You're quite right, 2.4 AV's reliably using the new test_pep263. The copy of python24.dll I was testing against already had (the first version of) the patch applied. Anyway, I'm attaching a diff for test_pep263 (against the original 2.4 test_pep263) which incorporates your suggestions about not assuming the current directory. ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2005-03-14 12:43 Message: Logged In: YES user_id=89016 Maybe I've put the test files in the wrong spot, but what I'm getting is: > ./python Lib/test/test_pep263.py test_pep263 (__main__.PEP263Test) ... ok test_evilencoding (__main__.EvilEncodingTest) ... ok Segmentation fault You should probably put pep263_evilencoding.py and pep263_longline.py alongside test_pep263.py and then find then via os.path.join(__file__.rsplit(os.sep, 1)[0], "pep263_longline.py") ---------------------------------------------------------------------- Comment By: Greg Chapman (glchapman) Date: 2005-02-27 06:22 Message: Logged In: YES user_id=86307 After thinking about it some more, I realized that fp_readl doesn?t have to do any utf8 manipulation. If the string it copies into the buffer does not include a \n, the buffer is expanded and fp_readl is called again until a \n is returned (or the end of the file is reached). It doesn?t matter if, during this loop, the buffer contains temporarily broken utf8 characters. So I?m attaching another new patch. This copies as many characters as fit into the buffer and saves any overflow into a new string object (stored in tok >decoding_buffer). When it is called again by the loop, it uses this overflow string to copy characters into the buffer. I?m also attaching a zip file with a modified test_pep263.py and some ancillary files. To test fp_readl, python needs to read from a file. Perhaps it would be better to generate temporary files rather than include these extra files. Also, although the tests will trigger the assert using a debug build of the 2.4 source, I?m not getting an access violation running regrtest against a release build (of 2.4) ? perhaps different tests are in order? ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2005-02-23 10:48 Message: Logged In: YES user_id=89016 I think the patch looks good. Staring at it for a while I believe the reference counts are OK. Can you incorporate fail.py into the test suite? ---------------------------------------------------------------------- Comment By: Greg Chapman (glchapman) Date: 2005-01-23 05:26 Message: Logged In: YES user_id=86307 I'm attaching a new patch (tokenizer.c.2.diff), which should be better since it avoids some unnecessary allocations and decoding/encoding. Hopefully, I haven't made any unwarranted assumptions about UTF8. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1101726&group_id=5470 From noreply at sourceforge.net Tue May 17 17:03:28 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 17 May 2005 08:03:28 -0700 Subject: [Patches] [ python-Patches-1203650 ] Allow larger programs to be frozen under Win32 Message-ID: Patches item #1203650, was opened at 2005-05-17 15: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=1203650&group_id=5470 Category: Demos and tools Group: None Status: Open Resolution: None Priority: 5 Submitted By: Gottfried Gan?auge (ganssauge) Assigned to: Nobody/Anonymous (nobody) Summary: Allow larger programs to be frozen under Win32 Initial Comment: The makefile generated by freeze on Windows ist not suitable for Programs containing many imported modules. This patch generates a makefile using an inline linker response file. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1203650&group_id=5470 From noreply at sourceforge.net Wed May 18 00:29:04 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 17 May 2005 15:29:04 -0700 Subject: [Patches] [ python-Patches-1166780 ] Fix _tryorder in webbrowser.py Message-ID: Patches item #1166780, was opened at 2005-03-20 04:25 Message generated for change (Comment added) made by rodsenra You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1166780&group_id=5470 Category: Library (Lib) Group: Python 2.5 >Status: Closed Resolution: None Priority: 5 Submitted By: Rodrigo Dias Arruda Senra (rodsenra) Assigned to: Nobody/Anonymous (nobody) Summary: Fix _tryorder in webbrowser.py Initial Comment: At the present time (Py2.4): """ Under Unix, if the environment variable BROWSER exists, it is interpreted to override the platform default list of browsers,... """ (extract from Python-2.4/Doc/html/lib/module-webbrowser.html) But, when the environment variable BROWSER is messed up, there is no reason not to try the other detected browser alternatives. In this patch, if the BROWSER variable is Ok, than it is respected. Otherwise, the previously detected browsers are tryied out as if BROWSER variable never existed. This does not break backward compatibility and adds more chance for webbrowser.open() to succeed. This patch was made against CVS head 2005-03-20, and aims to 2.5, but can safely be apllied to any 2.4.x bug fix release. ---------------------------------------------------------------------- >Comment By: Rodrigo Dias Arruda Senra (rodsenra) Date: 2005-05-17 22:29 Message: Logged In: YES user_id=9057 Closed because it is subsumed by 754022 ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2005-05-16 07:52 Message: Logged In: YES user_id=89016 If this patch is subsumed by 754022 can we close this one? ---------------------------------------------------------------------- Comment By: Rodrigo Dias Arruda Senra (rodsenra) Date: 2005-03-27 14:18 Message: Logged In: YES user_id=9057 Michiel de Hoon, this patch is obsolete after the latest revision of patch [ 754022 ] Enhanced webbrowser.py, that integrates this functionality and others in a single patch. Moreover, if a user sets BROWSER incorrectly, to see another browser opening will probably lead him to find that BROWSER was set incorrectly. IMO it is better to see a different browser opening than no browser at all. But thank you for revising this patch. ---------------------------------------------------------------------- Comment By: Michiel de Hoon (mdehoon) Date: 2005-03-27 08:03 Message: Logged In: YES user_id=488897 I agree that this patch will improve chances that webbrowser.open() will succeed. I'm a bit worried though that if a user sets BROWSER incorrectly, it may cause some confusion to see another browser opening. So we might some some bug reports saying "webbrowser.py ignores BROWSER variable" because a user set BROWSER incorrectly. One solution might be to print some warning message if the browser specified in BROWSER cannot be used. (I'm just a patch reviewer, not an official Python developer, so you don't need to take my comment to seriously :-)). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1166780&group_id=5470 From noreply at sourceforge.net Wed May 18 06:37:36 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 17 May 2005 21:37:36 -0700 Subject: [Patches] [ python-Patches-1201569 ] allow running multiple instances of IDLE Message-ID: Patches item #1201569, was opened at 2005-05-13 13:03 Message generated for change (Comment added) made by kbk You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1201569&group_id=5470 Category: IDLE Group: None Status: Open >Resolution: Later >Priority: 3 Submitted By: Jeff Shute (jshute) >Assigned to: Kurt B. Kaiser (kbk) Summary: allow running multiple instances of IDLE Initial Comment: This patch will allow running multiple instances of IDLE in the default (mutli-process) mode by choosing the first available port from 8833-8893 instead of failing when another IDLE has already bound port 8833. (Not tested on windows.) ---------------------------------------------------------------------- >Comment By: Kurt B. Kaiser (kbk) Date: 2005-05-17 23:37 Message: Logged In: YES user_id=149084 Duplicate of IDLEfork 661363 Will not be considered until remaining problems with socket binding on Windows have been resolved. Note: You can start as many copies of IDLE as you want with the -n switch. What is your use case? Also note: # spawning first avoids passing a listening socket to the subprocess ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1201569&group_id=5470 From noreply at sourceforge.net Wed May 18 14:52:57 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 18 May 2005 05:52:57 -0700 Subject: [Patches] [ python-Patches-1201569 ] allow running multiple instances of IDLE Message-ID: Patches item #1201569, was opened at 2005-05-13 14:03 Message generated for change (Comment added) made by jshute You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1201569&group_id=5470 Category: IDLE Group: None Status: Open Resolution: Later Priority: 3 Submitted By: Jeff Shute (jshute) Assigned to: Kurt B. Kaiser (kbk) Summary: allow running multiple instances of IDLE Initial Comment: This patch will allow running multiple instances of IDLE in the default (mutli-process) mode by choosing the first available port from 8833-8893 instead of failing when another IDLE has already bound port 8833. (Not tested on windows.) ---------------------------------------------------------------------- >Comment By: Jeff Shute (jshute) Date: 2005-05-18 08:52 Message: Logged In: YES user_id=39615 My use case is just that I find it annoying that in the default mode, you can't run multiple instances, and I kept seeing the annoying dialog box and having to restart. I normally use -n mode partly because of this, but sometimes I forget. It seemed like a trivial fix. Regarding the note, I didn't understand the comment because it doesn't say why. I thought maybe it was done that way so that it could be made to fail so the error messages could be tested. It seemed like you avoid the sleep() and several race conditions by starting the listener first. ---------------------------------------------------------------------- Comment By: Kurt B. Kaiser (kbk) Date: 2005-05-18 00:37 Message: Logged In: YES user_id=149084 Duplicate of IDLEfork 661363 Will not be considered until remaining problems with socket binding on Windows have been resolved. Note: You can start as many copies of IDLE as you want with the -n switch. What is your use case? Also note: # spawning first avoids passing a listening socket to the subprocess ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1201569&group_id=5470 From noreply at sourceforge.net Wed May 18 17:11:20 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 18 May 2005 08:11:20 -0700 Subject: [Patches] [ python-Patches-1204347 ] optparse documentation bug fixes Message-ID: Patches item #1204347, was opened at 2005-05-18 11:11 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1204347&group_id=5470 Category: Documentation Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Barry A. Warsaw (bwarsaw) Assigned to: Greg Ward (gward) Summary: optparse documentation bug fixes Initial Comment: I would have checked these minor fixes to typos in the optparse documentation myself, but I vaguely recall that the docs in Python are derived from some upstream source. If that isn't the case, re-assign to me and I'll check the fixes in. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1204347&group_id=5470 From noreply at sourceforge.net Wed May 18 22:32:54 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 18 May 2005 13:32:54 -0700 Subject: [Patches] [ python-Patches-1000267 ] A BSD-style wait4 implementation Message-ID: Patches item #1000267, was opened at 2004-07-29 13:52 Message generated for change (Comment added) made by cjschr You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1000267&group_id=5470 Category: Modules Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: chads (cjschr) Assigned to: Nobody/Anonymous (nobody) Summary: A BSD-style wait4 implementation Initial Comment: A BSD-style wait4 implementation. Using existing code from the posixmodule.c and resource.c files, I threw together a patch that implements the wait4 function. This function is similar to waitpid, but it also returns usage information about the child process. wait4(pid, options) -> (pid, status, rusage) It works for me on RedHat Linux 9 and FreeBSD 4.5 boxes using Python-2.3.4. The patch may need some fine tuning. Thanks Chad ---------------------------------------------------------------------- >Comment By: chads (cjschr) Date: 2005-05-18 15:32 Message: Logged In: YES user_id=1093928 Finally took the time to implement os.wait4 based the comments from loewis. Added a resourcemodule.h header and modified resource.c and posixmodule.c appropriately. Take a gander and let me know what you think. Thanks. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2004-08-22 11:23 Message: Logged In: YES user_id=21627 struct rusage is already defined in Modules/resourcemodule.c. It would be good if there was only a single definition of the type object. To achieve this, resourcemodule.c should expose a C API (e.g. PyObject *PyResource_FromResource(struct rusage*) ). This should be put into a CObject, which should be published through the module; then posixmodule should import resource when wait4 is called for the first time. Alternative, wait4 could be added to resourcemodule.c entirely. Yet another alternative, on top of this approach, posixmodule and/or os.py could provide their own definition of wait4 which delegates to resource.wait4 on first usage. ---------------------------------------------------------------------- Comment By: chads (cjschr) Date: 2004-08-13 14:00 Message: Logged In: YES user_id=1093928 Added a test suite and an example of using wait4. Feedback is welcome. Thanks. ---------------------------------------------------------------------- Comment By: Jeff Epler (jepler) Date: 2004-08-04 16:53 Message: Logged In: YES user_id=2772 You should also add code to the test suite to test wait4 when it is available. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1000267&group_id=5470 From noreply at sourceforge.net Wed May 18 22:37:40 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 18 May 2005 13:37:40 -0700 Subject: [Patches] [ python-Patches-1000267 ] A BSD-style wait4 implementation Message-ID: Patches item #1000267, was opened at 2004-07-29 13:52 Message generated for change (Settings changed) made by cjschr You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1000267&group_id=5470 Category: Modules >Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: chads (cjschr) Assigned to: Nobody/Anonymous (nobody) Summary: A BSD-style wait4 implementation Initial Comment: A BSD-style wait4 implementation. Using existing code from the posixmodule.c and resource.c files, I threw together a patch that implements the wait4 function. This function is similar to waitpid, but it also returns usage information about the child process. wait4(pid, options) -> (pid, status, rusage) It works for me on RedHat Linux 9 and FreeBSD 4.5 boxes using Python-2.3.4. The patch may need some fine tuning. Thanks Chad ---------------------------------------------------------------------- Comment By: chads (cjschr) Date: 2005-05-18 15:32 Message: Logged In: YES user_id=1093928 Finally took the time to implement os.wait4 based the comments from loewis. Added a resourcemodule.h header and modified resource.c and posixmodule.c appropriately. Take a gander and let me know what you think. Thanks. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2004-08-22 11:23 Message: Logged In: YES user_id=21627 struct rusage is already defined in Modules/resourcemodule.c. It would be good if there was only a single definition of the type object. To achieve this, resourcemodule.c should expose a C API (e.g. PyObject *PyResource_FromResource(struct rusage*) ). This should be put into a CObject, which should be published through the module; then posixmodule should import resource when wait4 is called for the first time. Alternative, wait4 could be added to resourcemodule.c entirely. Yet another alternative, on top of this approach, posixmodule and/or os.py could provide their own definition of wait4 which delegates to resource.wait4 on first usage. ---------------------------------------------------------------------- Comment By: chads (cjschr) Date: 2004-08-13 14:00 Message: Logged In: YES user_id=1093928 Added a test suite and an example of using wait4. Feedback is welcome. Thanks. ---------------------------------------------------------------------- Comment By: Jeff Epler (jepler) Date: 2004-08-04 16:53 Message: Logged In: YES user_id=2772 You should also add code to the test suite to test wait4 when it is available. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1000267&group_id=5470 From noreply at sourceforge.net Thu May 19 04:14:41 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 18 May 2005 19:14:41 -0700 Subject: [Patches] [ python-Patches-1203329 ] workaround deprecated ostat structure in Message-ID: Patches item #1203329, was opened at 2005-05-17 06:02 Message generated for change (Comment added) made by supercusp You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1203329&group_id=5470 Category: Macintosh Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: J. J. Snitow (supercusp) Assigned to: Jack Jansen (jackjansen) Summary: workaround deprecated ostat structure in Initial Comment: This is a patch to python/python/dist/src/Include/pyport.h, CVS revision 2.70. On Mac OS X 10.4 (Tiger), the file /usr/include/sys/stat.h contains the ostat structure, which the in-file comments call "XXX So deprecated, it would make your head spin". This structure is not used by the kernel and should not be used by user programs (so the comments say). An "#ifndef _POSIX_C_SOURCE" protects #includers of sys/stat.h from this horrible struct (which doesn't even compile). This patch to Include/pyport.h makes sure that _POSIX_C_SOURCE is always defined before including sys/stat.h. Notably, this patch enables the stock Darwinports port of PyOpenGL (py-opengl) to compile and run just fine on Tiger. ---------------------------------------------------------------------- >Comment By: J. J. Snitow (supercusp) Date: 2005-05-19 02:14 Message: Logged In: YES user_id=14233 Looking at 1171767, http://sourceforge.net/tracker/index.php? func=detail&aid=1171767&group_id=5470&atid=305470 it appears that the _POSIX_C_SOURCE issue isn't so simple. Fortunately, my patch here is quite polite, in that it only defines _POSIX_C_SOURCE during the inclusion of , where it is sorely needed, then promptly gets rid of it if and only if it wasn't defined before. It seems to work nicely. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1203329&group_id=5470 From noreply at sourceforge.net Thu May 19 22:38:33 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 19 May 2005 13:38:33 -0700 Subject: [Patches] [ python-Patches-1053150 ] urllib2: better import ftplib and gopherlib etc late Message-ID: Patches item #1053150, was opened at 2004-10-24 12:50 Message generated for change (Comment added) made by jjlee You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1053150&group_id=5470 Please note that this 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: Robert Kiendl (kxroberto) Assigned to: Nobody/Anonymous (nobody) Summary: urllib2: better import ftplib and gopherlib etc late Initial Comment: importing those libs like (ftplib, gopherlib, ..) unconditionally on top of urllib2 slows down and hinders distributing small app packages (py2exe'd, mcm.installer, ...). simple patch in attachment ---------------------------------------------------------------------- Comment By: John J Lee (jjlee) Date: 2005-05-19 21:38 Message: Logged In: YES user_id=261020 Since Jeremy doesn't like the idea (see tracker item ref. below), this should probably be closed, but: Robert originally submitted this as bug 1046077. ---------------------------------------------------------------------- Comment By: John J Lee (jjlee) Date: 2005-02-04 23:10 Message: Logged In: YES user_id=261020 Looks good to me. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1053150&group_id=5470 From noreply at sourceforge.net Thu May 19 22:49:44 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 19 May 2005 13:49:44 -0700 Subject: [Patches] [ python-Patches-1045783 ] Remove unncessary NLST from ftp transfers Message-ID: Patches item #1045783, was opened at 2004-10-13 00:05 Message generated for change (Comment added) made by jjlee You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1045783&group_id=5470 Please note that this 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: Chris Cogdon (chriscog) Assigned to: Nobody/Anonymous (nobody) Summary: Remove unncessary NLST from ftp transfers Initial Comment: Using urllib (or urllib2) to open FTP URLs will attempt a 'nlst' (directory listing) before retrieving the file. Some FTP servers block directory listings, but allow 'getting' files just fine. Having urllib do a NLST before retriving files is totally unnecessary, and will fail given the FTP server mentioned above. If a file is not 'gettable', which is what the probable intention of NLST is, it will fail in the retrieve process. This patch removes the NLST from urllib. As a bonus, this makes FTP transfers faster. ---------------------------------------------------------------------- Comment By: John J Lee (jjlee) Date: 2005-05-19 21:49 Message: Logged In: YES user_id=261020 Looks reasonable to me. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1045783&group_id=5470 From noreply at sourceforge.net Thu May 19 22:53:16 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 19 May 2005 13:53:16 -0700 Subject: [Patches] [ python-Patches-972322 ] urllib2 handler naming convention collision Message-ID: Patches item #972322, was opened at 2004-06-14 00:16 Message generated for change (Comment added) made by jjlee You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=972322&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Library (Lib) Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: John J Lee (jjlee) Assigned to: Jeremy Hylton (jhylton) Summary: urllib2 handler naming convention collision Initial Comment: The method naming conventions of *_open and *_request in urllib2 are accidentally met by the following methods: AbstractHTTPHandler.do_open() ProxyHandler.proxy_open() AbstractHTTPHandler.redirect_request() So URLs like do://example.com/ are regarded as having a handler, and urllib2.urlopen("do://python.org/") causes a TypeError. I think *something* should be done about this, but I'm willing to provide a different patch if this one is frowned upon. The alternative would be to rename do_open and proxy_open, and leave the redirect_request case unchanged (see below for why). The first two methods are undocumented, so could in theory be renamed. However, people will likely be overriding them anyway, so perhaps it's better to apply this ugly patch than rename them. redirect_request is documented, so can't be renamed, but it will never be accidentally called unless somebody actually adds a handler with a method named "redirect_open". ---------------------------------------------------------------------- >Comment By: John J Lee (jjlee) Date: 2005-05-19 21:53 Message: Logged In: YES user_id=261020 Since nobody seems to mind the slightly uglified code required to fix these bugs in a backwards-compatible way, could somebody please apply this patch? ---------------------------------------------------------------------- Comment By: Michael Chermside (mcherm) Date: 2004-10-22 17:36 Message: Logged In: YES user_id=99874 I have reviewed this patch and I recomend applying it. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=972322&group_id=5470 From noreply at sourceforge.net Thu May 19 23:07:36 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 19 May 2005 14:07:36 -0700 Subject: [Patches] [ python-Patches-848870 ] Flakey urllib2.parse_http_list Message-ID: Patches item #848870, was opened at 2003-11-25 11:36 Message generated for change (Comment added) made by jjlee You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=848870&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Library (Lib) Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Stuart Bishop (zenzen) Assigned to: Nobody/Anonymous (nobody) Summary: Flakey urllib2.parse_http_list Initial Comment: Breaks with the following challenge: realm="localhost",nonce="764d66b5e8c907eb5873d5d4c2131 1a1ad62535c",qop=auth,charset=utf-8,algorithm=md5-sess''' 'realm="localhost",nonce="764d66b5e8c907eb5873d5d4c213 11a1ad62535c",qop=auth,charset=utf-8,algorithm=md5-sess Suggest changing the implementation to: import csv def parse_http_list(s): """Parse lists as described by RFC 2068 Section 2. In particular, parse comman-separated lists where the elements of the list may include quoted-strings. A quoted-string could contain a comma. """ return csv.reader([s]).next() ---------------------------------------------------------------------- Comment By: John J Lee (jjlee) Date: 2005-05-19 22:07 Message: Logged In: YES user_id=261020 This should be closed. Patch 901480 is better. (Stuart: I don't think it's wise to handle this RFC-documented protocol using a module designed for reading CSV files. Also, in future, please always use the file upload feature of the tracker to upload any code or patch, rather than pasting into the text area. Thanks for the report!) ---------------------------------------------------------------------- Comment By: Stuart Bishop (zenzen) Date: 2003-11-25 11:53 Message: Logged In: YES user_id=46639 I appear to be cut & paste challenged. The challenge is: realm="localhost",nonce="764d66b5e8c907eb5873d5d4c2131 1a1ad62535c",qop=auth,charset=utf-8,algorithm=md5-sess Might not be worth fixing on the 2.3 branch, since this isn't actually generated from a webserver (its from jabberd). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=848870&group_id=5470 From noreply at sourceforge.net Thu May 19 23:10:41 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 19 May 2005 14:10:41 -0700 Subject: [Patches] [ python-Patches-816787 ] urllib2.URLError don't calll IOError.__init__ Message-ID: Patches item #816787, was opened at 2003-10-02 21:16 Message generated for change (Comment added) made by jjlee You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=816787&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Library (Lib) Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Miki Tebeka (tebeka) Assigned to: Jeremy Hylton (jhylton) Summary: urllib2.URLError don't calll IOError.__init__ Initial Comment: The comments says it's not needed by in the case of: --------------- from urllib2 import URLError u = URLError(1) u[-1] Traceback (most recent call last): File "u.py", line 6, in ? u[-1] AttributeError: URLError instance has no attribute 'args' -------------- it's not what we excpect. Attaching a patch to call IOError.__init__ ---------------------------------------------------------------------- Comment By: John J Lee (jjlee) Date: 2005-05-19 22:10 Message: Logged In: YES user_id=261020 This should be closed: If anybody has any further bright ideas on making urllib2's exceptions more beautiful, they can always submit a new patch. ---------------------------------------------------------------------- Comment By: Jeremy Hylton (jhylton) Date: 2003-10-06 06:10 Message: Logged In: YES user_id=31392 I've changed URLError to call IOError.__init__(). That's an improvement, but it's still not great. The typical EnvironmentError has a two- or three-tuple where item 0 is the errno, item 1 is a string explaining the error, and item 3 is a filenumber. The change will creates args, but won't set errno or strerrror. Code expecting an errno in args[0] will be surprised. What do you think? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=816787&group_id=5470 From noreply at sourceforge.net Fri May 20 03:06:36 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 19 May 2005 18:06:36 -0700 Subject: [Patches] [ python-Patches-1197318 ] Cygwin case-sensitive import patch Message-ID: Patches item #1197318, was opened at 2005-05-07 07:56 Message generated for change (Comment added) made by jlt63 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1197318&group_id=5470 Please note that this 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: Jason Tishler (jlt63) Assigned to: Jason Tishler (jlt63) Summary: Cygwin case-sensitive import patch Initial Comment: A problem regarding importing symlinked modules was recently reported on the Cygwin mailing list: http://cygwin.com/ml/cygwin/2005-04/msg00257.html The following test case demonstrates the problem: $ ls -l total 1 lrwxrwxrwx 1 jt None 6 Apr 23 13:32 bar.py -> foo.py -rw-r--r-- 1 jt None 24 Apr 18 20:13 foo.py $ python -c 'import bar' Traceback (most recent call last): File "", line 1, in ? ImportError: No module named bar Since Cygwin's case_ok() uses a modified version of the Windows's version, the symlinked bar module actually resolves to file foo.py instead of bar.py. This obviously causes the matching code to fail (regardless of case). The attached patch fixes this problem. All that it does it make Cygwin use the Mac OS X case_ok() instead of a modified Window's version. Is this OK to apply? Or, would someone like to make sure I didn't break the Windows and Mac builds first? AFAICT, I didn't, but you never know... :,) Additionally, can I apply this patch to the 2.4 maintence branch? If so, is "release24-maint" the correct CVS tag to use? Thanks. ---------------------------------------------------------------------- >Comment By: Jason Tishler (jlt63) Date: 2005-05-19 17:06 Message: Logged In: YES user_id=86216 Commited onto HEAD as Python/import.c 2.241, so I'm in forgiveness mode for this change... :,) However, I won't commit onto the maintence branch without explicit permission, so I'm still in permission mode for this one... :,) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1197318&group_id=5470 From noreply at sourceforge.net Fri May 20 07:21:43 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 19 May 2005 22:21:43 -0700 Subject: [Patches] [ python-Patches-1205436 ] Bugfix for signal-handler on x64 Platform Message-ID: Patches item #1205436, was opened at 2005-05-20 05: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=1205436&group_id=5470 Please note that this 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: Andr? Fritzsche (computercrustie) Assigned to: Nobody/Anonymous (nobody) Summary: Bugfix for signal-handler on x64 Platform Initial Comment: On x64 Platform (i used Visual Studio 2005 and Windows XP x64) the python.exe hang up on registering signal handler for none used signals. I fixed this on my machine with a switch-case construct for filtering the unsupported signals. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1205436&group_id=5470 From noreply at sourceforge.net Fri May 20 13:09:18 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 20 May 2005 04:09:18 -0700 Subject: [Patches] [ python-Patches-1205436 ] Bugfix for signal-handler on x64 Platform Message-ID: Patches item #1205436, was opened at 2005-05-20 06:21 Message generated for change (Comment added) made by mwh You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1205436&group_id=5470 Please note that this 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: Andr? Fritzsche (computercrustie) Assigned to: Nobody/Anonymous (nobody) Summary: Bugfix for signal-handler on x64 Platform Initial Comment: On x64 Platform (i used Visual Studio 2005 and Windows XP x64) the python.exe hang up on registering signal handler for none used signals. I fixed this on my machine with a switch-case construct for filtering the unsupported signals. ---------------------------------------------------------------------- >Comment By: Michael Hudson (mwh) Date: 2005-05-20 12:09 Message: Logged In: YES user_id=6656 Point the first: please attach patches, not files. Point the second: we think this is a microsoft bug. Quoting C99 (about the signal function): If the request can be honored, the signal function returns the value of func for the most recent successful call to signal for the specified signal sig. Otherwise, a value of SIG_ERR is returned and a positive value is stored in errno. That doesn't seem to allow calling abort(). As I think VS 2005 is still in beta, there's still hope that this will get fixed. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1205436&group_id=5470 From noreply at sourceforge.net Fri May 20 23:09:29 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 20 May 2005 14:09:29 -0700 Subject: [Patches] [ python-Patches-1203329 ] workaround deprecated ostat structure in Message-ID: Patches item #1203329, was opened at 2005-05-17 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=1203329&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Macintosh Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: J. J. Snitow (supercusp) Assigned to: Jack Jansen (jackjansen) Summary: workaround deprecated ostat structure in Initial Comment: This is a patch to python/python/dist/src/Include/pyport.h, CVS revision 2.70. On Mac OS X 10.4 (Tiger), the file /usr/include/sys/stat.h contains the ostat structure, which the in-file comments call "XXX So deprecated, it would make your head spin". This structure is not used by the kernel and should not be used by user programs (so the comments say). An "#ifndef _POSIX_C_SOURCE" protects #includers of sys/stat.h from this horrible struct (which doesn't even compile). This patch to Include/pyport.h makes sure that _POSIX_C_SOURCE is always defined before including sys/stat.h. Notably, this patch enables the stock Darwinports port of PyOpenGL (py-opengl) to compile and run just fine on Tiger. ---------------------------------------------------------------------- >Comment By: Martin v. L?wis (loewis) Date: 2005-05-20 23:09 Message: Logged In: YES user_id=21627 I don't understand the purpose of the patch. So sys/stat.h defines struct ostat. Why is that a problem that Python needs somehow to deal with? Turning _POSIX_C_SOURCE on and off temporarily is a bad idea - this is either meant to be turned on for all translation units, or turned off for all of them. ---------------------------------------------------------------------- Comment By: J. J. Snitow (supercusp) Date: 2005-05-19 04:14 Message: Logged In: YES user_id=14233 Looking at 1171767, http://sourceforge.net/tracker/index.php? func=detail&aid=1171767&group_id=5470&atid=305470 it appears that the _POSIX_C_SOURCE issue isn't so simple. Fortunately, my patch here is quite polite, in that it only defines _POSIX_C_SOURCE during the inclusion of , where it is sorely needed, then promptly gets rid of it if and only if it wasn't defined before. It seems to work nicely. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1203329&group_id=5470 From noreply at sourceforge.net Sat May 21 06:57:31 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 20 May 2005 21:57:31 -0700 Subject: [Patches] [ python-Patches-1203329 ] workaround deprecated ostat structure in Message-ID: Patches item #1203329, was opened at 2005-05-17 06:02 Message generated for change (Comment added) made by supercusp You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1203329&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Macintosh Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: J. J. Snitow (supercusp) Assigned to: Jack Jansen (jackjansen) Summary: workaround deprecated ostat structure in Initial Comment: This is a patch to python/python/dist/src/Include/pyport.h, CVS revision 2.70. On Mac OS X 10.4 (Tiger), the file /usr/include/sys/stat.h contains the ostat structure, which the in-file comments call "XXX So deprecated, it would make your head spin". This structure is not used by the kernel and should not be used by user programs (so the comments say). An "#ifndef _POSIX_C_SOURCE" protects #includers of sys/stat.h from this horrible struct (which doesn't even compile). This patch to Include/pyport.h makes sure that _POSIX_C_SOURCE is always defined before including sys/stat.h. Notably, this patch enables the stock Darwinports port of PyOpenGL (py-opengl) to compile and run just fine on Tiger. ---------------------------------------------------------------------- >Comment By: J. J. Snitow (supercusp) Date: 2005-05-21 04:57 Message: Logged In: YES user_id=14233 Ack. loewis, you may be right. This patch may also be masking other bugs elsewhere. Notably, a dummy .c file with _POSIX_C_SOURCE undefined and included compiles without complaint. Time for more investigation on my part. For the moment, please consider this patch withdrawn. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2005-05-20 21:09 Message: Logged In: YES user_id=21627 I don't understand the purpose of the patch. So sys/stat.h defines struct ostat. Why is that a problem that Python needs somehow to deal with? Turning _POSIX_C_SOURCE on and off temporarily is a bad idea - this is either meant to be turned on for all translation units, or turned off for all of them. ---------------------------------------------------------------------- Comment By: J. J. Snitow (supercusp) Date: 2005-05-19 02:14 Message: Logged In: YES user_id=14233 Looking at 1171767, http://sourceforge.net/tracker/index.php? func=detail&aid=1171767&group_id=5470&atid=305470 it appears that the _POSIX_C_SOURCE issue isn't so simple. Fortunately, my patch here is quite polite, in that it only defines _POSIX_C_SOURCE during the inclusion of , where it is sorely needed, then promptly gets rid of it if and only if it wasn't defined before. It seems to work nicely. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1203329&group_id=5470 From noreply at sourceforge.net Sat May 21 11:23:48 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 21 May 2005 02:23:48 -0700 Subject: [Patches] [ python-Patches-1206077 ] updates for the compiler package Message-ID: Patches item #1206077, was opened at 2005-05-21 09:23 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1206077&group_id=5470 Please note that this 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: Stelios (sxanth) Assigned to: Nobody/Anonymous (nobody) Summary: updates for the compiler package Initial Comment: The compiler package produces lower quality bytecode since it does not do any of the peephole optimizations. I tried to fix that to make the package produce bytecode which is as good as the internal compiler. Yeah, probably wasted time but because python is so great it was much easier than I thought and now the package produces rather superior bytecode! The patch implements all the optimizations mentioned in compile.c and additionally: - constant folding (or however this is called). For example, it turns x = -(1<<2) to the constant -4. Also nested tuples of constants are converted to one big tuple constant. - The optimization which checks JUMPs that lead to other JUMPs is extended to re-run the optimization when something is modified. For example, the builtin optimizer can't do: if (a and b) and c where there is a JUMP_IF_FALSE which leads to a JUMP_IF_FALSE which leads to a third JUMP_IF_FALSE. While I was at it, I discovered several "bugs" which I couldn't resist attempting to fix. - Implemented LIST_APPEND for list comprehensions - The docstrings of functions where added in the co_consts of the module - All the names that appeared in a function where added to co_varnames. Not sure about the fix - Made co_filename and co_name interns - In generator expressions the outmost-iterable's names where considered freevars and therefore in: def bar(y): return foo (x for x in y) the generator expression was considered a closure I've used the new compiler for my own benchmark suite and all went well. I've also managed to just *compile* the standard library and with the new compiler it turns out 40167 bytes smaller (!). But really, somebody should run the regression tests with it (I can't due to inefficient hardware). IFF it passes the tests if *could* be used to re-compile the standard library for more efficient code. The patch is vs 2.4.1. However, the patch it's not 100% ready to be applied to mainline; but it's easier to review. The maintainer should tell me how to proceed :-) Further Questions: - generator expressions do not emit SETUP_LOOP/POP_BLOCK. Should they? - What is the status of the package? I discovered all those bugs in a couple of hours. Does this mean that there are many many others? How many new ones has my patch added? Is the package not suitable for serious development? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1206077&group_id=5470 From noreply at sourceforge.net Sat May 21 14:19:04 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 21 May 2005 05:19:04 -0700 Subject: [Patches] [ python-Patches-1206077 ] updates for the compiler package Message-ID: Patches item #1206077, was opened at 2005-05-21 10:23 Message generated for change (Comment added) made by mwh You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1206077&group_id=5470 Please note that this 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: Stelios (sxanth) Assigned to: Nobody/Anonymous (nobody) Summary: updates for the compiler package Initial Comment: The compiler package produces lower quality bytecode since it does not do any of the peephole optimizations. I tried to fix that to make the package produce bytecode which is as good as the internal compiler. Yeah, probably wasted time but because python is so great it was much easier than I thought and now the package produces rather superior bytecode! The patch implements all the optimizations mentioned in compile.c and additionally: - constant folding (or however this is called). For example, it turns x = -(1<<2) to the constant -4. Also nested tuples of constants are converted to one big tuple constant. - The optimization which checks JUMPs that lead to other JUMPs is extended to re-run the optimization when something is modified. For example, the builtin optimizer can't do: if (a and b) and c where there is a JUMP_IF_FALSE which leads to a JUMP_IF_FALSE which leads to a third JUMP_IF_FALSE. While I was at it, I discovered several "bugs" which I couldn't resist attempting to fix. - Implemented LIST_APPEND for list comprehensions - The docstrings of functions where added in the co_consts of the module - All the names that appeared in a function where added to co_varnames. Not sure about the fix - Made co_filename and co_name interns - In generator expressions the outmost-iterable's names where considered freevars and therefore in: def bar(y): return foo (x for x in y) the generator expression was considered a closure I've used the new compiler for my own benchmark suite and all went well. I've also managed to just *compile* the standard library and with the new compiler it turns out 40167 bytes smaller (!). But really, somebody should run the regression tests with it (I can't due to inefficient hardware). IFF it passes the tests if *could* be used to re-compile the standard library for more efficient code. The patch is vs 2.4.1. However, the patch it's not 100% ready to be applied to mainline; but it's easier to review. The maintainer should tell me how to proceed :-) Further Questions: - generator expressions do not emit SETUP_LOOP/POP_BLOCK. Should they? - What is the status of the package? I discovered all those bugs in a couple of hours. Does this mean that there are many many others? How many new ones has my patch added? Is the package not suitable for serious development? ---------------------------------------------------------------------- >Comment By: Michael Hudson (mwh) Date: 2005-05-21 13:19 Message: Logged In: YES user_id=6656 Why do you say this patch isn't ready to apply? Oh, I've read it now :) > What is the status of the package? Not as well looked after as it should be :-/ I'm not sure most of the changes you describe are really bugs, more inefficiencies (e.g. compiler generated list comps still work even if they don't emit LIST_APPEND). Running "./python Lib/test/regrtest.py test_compiler -uall" will compile the entire stdlib with Lib/compiler (this is probably an overnight job) then running just plain "./python Lib/test/regrtest.py" will run the test suite using the compiled copy. It probably makes sense to submit a number of patches, particularly for the optimization versus straight fix divide. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1206077&group_id=5470 From noreply at sourceforge.net Sat May 21 23:42:58 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 21 May 2005 14:42:58 -0700 Subject: [Patches] [ python-Patches-1203329 ] workaround deprecated ostat structure in Message-ID: Patches item #1203329, was opened at 2005-05-17 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=1203329&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Macintosh Group: Python 2.4 >Status: Closed >Resolution: Rejected Priority: 5 Submitted By: J. J. Snitow (supercusp) Assigned to: Jack Jansen (jackjansen) Summary: workaround deprecated ostat structure in Initial Comment: This is a patch to python/python/dist/src/Include/pyport.h, CVS revision 2.70. On Mac OS X 10.4 (Tiger), the file /usr/include/sys/stat.h contains the ostat structure, which the in-file comments call "XXX So deprecated, it would make your head spin". This structure is not used by the kernel and should not be used by user programs (so the comments say). An "#ifndef _POSIX_C_SOURCE" protects #includers of sys/stat.h from this horrible struct (which doesn't even compile). This patch to Include/pyport.h makes sure that _POSIX_C_SOURCE is always defined before including sys/stat.h. Notably, this patch enables the stock Darwinports port of PyOpenGL (py-opengl) to compile and run just fine on Tiger. ---------------------------------------------------------------------- >Comment By: Martin v. L?wis (loewis) Date: 2005-05-21 23:42 Message: Logged In: YES user_id=21627 Ok, rejecting it. Please submit a new patch with a new analysis if you think something needs to be done. ---------------------------------------------------------------------- Comment By: J. J. Snitow (supercusp) Date: 2005-05-21 06:57 Message: Logged In: YES user_id=14233 Ack. loewis, you may be right. This patch may also be masking other bugs elsewhere. Notably, a dummy .c file with _POSIX_C_SOURCE undefined and included compiles without complaint. Time for more investigation on my part. For the moment, please consider this patch withdrawn. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2005-05-20 23:09 Message: Logged In: YES user_id=21627 I don't understand the purpose of the patch. So sys/stat.h defines struct ostat. Why is that a problem that Python needs somehow to deal with? Turning _POSIX_C_SOURCE on and off temporarily is a bad idea - this is either meant to be turned on for all translation units, or turned off for all of them. ---------------------------------------------------------------------- Comment By: J. J. Snitow (supercusp) Date: 2005-05-19 04:14 Message: Logged In: YES user_id=14233 Looking at 1171767, http://sourceforge.net/tracker/index.php? func=detail&aid=1171767&group_id=5470&atid=305470 it appears that the _POSIX_C_SOURCE issue isn't so simple. Fortunately, my patch here is quite polite, in that it only defines _POSIX_C_SOURCE during the inclusion of , where it is sorely needed, then promptly gets rid of it if and only if it wasn't defined before. It seems to work nicely. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1203329&group_id=5470 From noreply at sourceforge.net Sun May 22 09:55:10 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 22 May 2005 00:55:10 -0700 Subject: [Patches] [ python-Patches-1206077 ] updates for the compiler package Message-ID: Patches item #1206077, was opened at 2005-05-21 09:23 Message generated for change (Comment added) made by sxanth You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1206077&group_id=5470 Please note that this 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: Stelios (sxanth) Assigned to: Nobody/Anonymous (nobody) Summary: updates for the compiler package Initial Comment: The compiler package produces lower quality bytecode since it does not do any of the peephole optimizations. I tried to fix that to make the package produce bytecode which is as good as the internal compiler. Yeah, probably wasted time but because python is so great it was much easier than I thought and now the package produces rather superior bytecode! The patch implements all the optimizations mentioned in compile.c and additionally: - constant folding (or however this is called). For example, it turns x = -(1<<2) to the constant -4. Also nested tuples of constants are converted to one big tuple constant. - The optimization which checks JUMPs that lead to other JUMPs is extended to re-run the optimization when something is modified. For example, the builtin optimizer can't do: if (a and b) and c where there is a JUMP_IF_FALSE which leads to a JUMP_IF_FALSE which leads to a third JUMP_IF_FALSE. While I was at it, I discovered several "bugs" which I couldn't resist attempting to fix. - Implemented LIST_APPEND for list comprehensions - The docstrings of functions where added in the co_consts of the module - All the names that appeared in a function where added to co_varnames. Not sure about the fix - Made co_filename and co_name interns - In generator expressions the outmost-iterable's names where considered freevars and therefore in: def bar(y): return foo (x for x in y) the generator expression was considered a closure I've used the new compiler for my own benchmark suite and all went well. I've also managed to just *compile* the standard library and with the new compiler it turns out 40167 bytes smaller (!). But really, somebody should run the regression tests with it (I can't due to inefficient hardware). IFF it passes the tests if *could* be used to re-compile the standard library for more efficient code. The patch is vs 2.4.1. However, the patch it's not 100% ready to be applied to mainline; but it's easier to review. The maintainer should tell me how to proceed :-) Further Questions: - generator expressions do not emit SETUP_LOOP/POP_BLOCK. Should they? - What is the status of the package? I discovered all those bugs in a couple of hours. Does this mean that there are many many others? How many new ones has my patch added? Is the package not suitable for serious development? ---------------------------------------------------------------------- >Comment By: Stelios (sxanth) Date: 2005-05-22 07:55 Message: Logged In: YES user_id=667962 Thanks for the instructions to regtest the compiler. I was hoping for a quick review by someone who knows well the compiler package to confirm that I'm doing the right thing in the places with XXX. It'll save me a lot of time. Hmmm. Since the patch is not ready to be applied, you can close this one if you want and we'll keep the link as a reference for future work. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2005-05-21 12:19 Message: Logged In: YES user_id=6656 Why do you say this patch isn't ready to apply? Oh, I've read it now :) > What is the status of the package? Not as well looked after as it should be :-/ I'm not sure most of the changes you describe are really bugs, more inefficiencies (e.g. compiler generated list comps still work even if they don't emit LIST_APPEND). Running "./python Lib/test/regrtest.py test_compiler -uall" will compile the entire stdlib with Lib/compiler (this is probably an overnight job) then running just plain "./python Lib/test/regrtest.py" will run the test suite using the compiled copy. It probably makes sense to submit a number of patches, particularly for the optimization versus straight fix divide. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1206077&group_id=5470 From noreply at sourceforge.net Tue May 24 19:12:05 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 24 May 2005 10:12:05 -0700 Subject: [Patches] [ python-Patches-1207985 ] An URL for UnicodeData File Format 3.2 has changed. Message-ID: Patches item #1207985, was opened at 2005-05-24 17:12 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1207985&group_id=5470 Please note that this 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: Darek Suchojad (dsuch) Assigned to: Nobody/Anonymous (nobody) Summary: An URL for UnicodeData File Format 3.2 has changed. Initial Comment: Hello, both Modules/unicodedata.c and Doc/lib/libunicodedata.tex mention an old URL for UnicodeData File Format 3.2.0. Attached is a patch to make them correct. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1207985&group_id=5470 From noreply at sourceforge.net Tue May 24 23:15:52 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 24 May 2005 14:15:52 -0700 Subject: [Patches] [ python-Patches-1000267 ] A BSD-style wait4 implementation Message-ID: Patches item #1000267, was opened at 2004-07-29 20:52 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1000267&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Modules Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: chads (cjschr) Assigned to: Nobody/Anonymous (nobody) Summary: A BSD-style wait4 implementation Initial Comment: A BSD-style wait4 implementation. Using existing code from the posixmodule.c and resource.c files, I threw together a patch that implements the wait4 function. This function is similar to waitpid, but it also returns usage information about the child process. wait4(pid, options) -> (pid, status, rusage) It works for me on RedHat Linux 9 and FreeBSD 4.5 boxes using Python-2.3.4. The patch may need some fine tuning. Thanks Chad ---------------------------------------------------------------------- >Comment By: Martin v. L?wis (loewis) Date: 2005-05-24 23:15 Message: Logged In: YES user_id=21627 The code looks fine. The only problem I have with it that it seems to assume that any POSIX system implements wait4. However, I don't see it in Single Unix V3, so I think there should be some configure test to determine whether the function is present. Also, it would be nice if the resource module was only imported if wait4 was actually called. I can't see documentation changes; please provide a patch for Doc/lib/libos.tex as well. If you resubmit the patch, it would be easiest if the patch was a single file, eg. generated with "cvs diff -u". There is no need to include configure changes; configure.in would be sufficient. ---------------------------------------------------------------------- Comment By: chads (cjschr) Date: 2005-05-18 22:32 Message: Logged In: YES user_id=1093928 Finally took the time to implement os.wait4 based the comments from loewis. Added a resourcemodule.h header and modified resource.c and posixmodule.c appropriately. Take a gander and let me know what you think. Thanks. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2004-08-22 18:23 Message: Logged In: YES user_id=21627 struct rusage is already defined in Modules/resourcemodule.c. It would be good if there was only a single definition of the type object. To achieve this, resourcemodule.c should expose a C API (e.g. PyObject *PyResource_FromResource(struct rusage*) ). This should be put into a CObject, which should be published through the module; then posixmodule should import resource when wait4 is called for the first time. Alternative, wait4 could be added to resourcemodule.c entirely. Yet another alternative, on top of this approach, posixmodule and/or os.py could provide their own definition of wait4 which delegates to resource.wait4 on first usage. ---------------------------------------------------------------------- Comment By: chads (cjschr) Date: 2004-08-13 21:00 Message: Logged In: YES user_id=1093928 Added a test suite and an example of using wait4. Feedback is welcome. Thanks. ---------------------------------------------------------------------- Comment By: Jeff Epler (jepler) Date: 2004-08-04 23:53 Message: Logged In: YES user_id=2772 You should also add code to the test suite to test wait4 when it is available. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1000267&group_id=5470 From RegenaQualls_2448 at johnschultz.com Wed May 25 16:43:01 2005 From: RegenaQualls_2448 at johnschultz.com (Regena Qualls) Date: Wed, 25 May 2005 09:43:01 -0500 Subject: [Patches] Like Being a Teeenager Again Message-ID: <20050525144240.D3E6B1E4002@bag.python.org> Hello, terrified woman, and another at Lord Julian's. They were given theOut of this, trouble followed quickly. Wolverstone coming ashoreof that. He has grown rich, I hear. He has translated, so it is"Damme if ever I met a man I liked better, or even a man I likedand a pirate, faith, ye may keep your gratitude for all the goodWhen he had done, Captain Blood, who until that moment had stoodIt was answered by a terrific broadside from the Arabella, which hadcomprehensive glimpse before his own decks were invaded by a wild,England where a man of your parts would be warmly welcomed. Therehe saw the white face of that child Mary Traill as she fled inemployed only as a last resource. Ye've said his lordship made agrim evidence was added to that of the sounds they had heard, andbeautifully damascened with golden arabesques. Over this, like aLord Julian Wade. But... but... aboard this ship...?" Theplantations in which his great wealth was being amassed with ansuave urbanity invited. He took his meals in the great cabin with -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.python.org/pipermail/patches/attachments/20050525/4933bd02/attachment.html From LarsoTyle at gabbertas.com Wed May 25 18:14:24 2005 From: LarsoTyle at gabbertas.com (Tyler Larson) Date: Wed, 25 May 2005 11:14:24 -0500 Subject: [Patches] I made the Moove Message-ID: <20050525161408.98AB41E4002@bag.python.org> Hello, then going on and about, he had put a second broadside into herin surprise and mistrust - a mistrust shared by Miss Bishop, who,His lordship was past amazement. She was not by any means the kindbells which was imminent.Blood bowed low. "Your lordship is very good. But...."when at last, as they drew closer to the doomed vessel, they madehim as if it were already a reality. And even when he conqueredhe ordered."The Captain was ever a modest man," he explained to Hagthorpe andmowing down the French soldiers who, unable to dislodge the irons,resolved itself into a series of skirmishes between groups. AndDispositions were to be made without delay against that which must"I pray Heaven they may sink all his infernal ships!" he cried inthe course. Of these was Wolverstone, who at once proclaimed histhe bearer of a folded scrap of paper for Captain Levasseur.he had considered nothing. But he made a quick recovery. "To my -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.python.org/pipermail/patches/attachments/20050525/5636b108/attachment.htm From JuanantilysisJ6dRn at toughguy.net Thu May 26 16:47:34 2005 From: JuanantilysisJ6dRn at toughguy.net (Brian G. Johnson, III) Date: Thu, 26 May 2005 08:47:34 -0600 Subject: [Patches] Download faster Message-ID: brown grape purple plum today i need to goto the store. Do you practice driving in London? red plumyellow mango -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.python.org/pipermail/patches/attachments/20050526/d284f38f/attachment.html From noreply at sourceforge.net Thu May 26 17:02:35 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 26 May 2005 08:02:35 -0700 Subject: [Patches] [ python-Patches-1206077 ] updates for the compiler package Message-ID: Patches item #1206077, was opened at 2005-05-21 05:23 Message generated for change (Comment added) made by tjreedy You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1206077&group_id=5470 Please note that this 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: Stelios (sxanth) Assigned to: Nobody/Anonymous (nobody) Summary: updates for the compiler package Initial Comment: The compiler package produces lower quality bytecode since it does not do any of the peephole optimizations. I tried to fix that to make the package produce bytecode which is as good as the internal compiler. Yeah, probably wasted time but because python is so great it was much easier than I thought and now the package produces rather superior bytecode! The patch implements all the optimizations mentioned in compile.c and additionally: - constant folding (or however this is called). For example, it turns x = -(1<<2) to the constant -4. Also nested tuples of constants are converted to one big tuple constant. - The optimization which checks JUMPs that lead to other JUMPs is extended to re-run the optimization when something is modified. For example, the builtin optimizer can't do: if (a and b) and c where there is a JUMP_IF_FALSE which leads to a JUMP_IF_FALSE which leads to a third JUMP_IF_FALSE. While I was at it, I discovered several "bugs" which I couldn't resist attempting to fix. - Implemented LIST_APPEND for list comprehensions - The docstrings of functions where added in the co_consts of the module - All the names that appeared in a function where added to co_varnames. Not sure about the fix - Made co_filename and co_name interns - In generator expressions the outmost-iterable's names where considered freevars and therefore in: def bar(y): return foo (x for x in y) the generator expression was considered a closure I've used the new compiler for my own benchmark suite and all went well. I've also managed to just *compile* the standard library and with the new compiler it turns out 40167 bytes smaller (!). But really, somebody should run the regression tests with it (I can't due to inefficient hardware). IFF it passes the tests if *could* be used to re-compile the standard library for more efficient code. The patch is vs 2.4.1. However, the patch it's not 100% ready to be applied to mainline; but it's easier to review. The maintainer should tell me how to proceed :-) Further Questions: - generator expressions do not emit SETUP_LOOP/POP_BLOCK. Should they? - What is the status of the package? I discovered all those bugs in a couple of hours. Does this mean that there are many many others? How many new ones has my patch added? Is the package not suitable for serious development? ---------------------------------------------------------------------- >Comment By: Terry J. Reedy (tjreedy) Date: 2005-05-26 11:02 Message: Logged In: YES user_id=593130 If you think you might split and resubmit within a few months, you could keep this open for further comments and then use it for the optimization upgrades (updates). Put bug fixes in Bug Fixers .... ---------------------------------------------------------------------- Comment By: Stelios (sxanth) Date: 2005-05-22 03:55 Message: Logged In: YES user_id=667962 Thanks for the instructions to regtest the compiler. I was hoping for a quick review by someone who knows well the compiler package to confirm that I'm doing the right thing in the places with XXX. It'll save me a lot of time. Hmmm. Since the patch is not ready to be applied, you can close this one if you want and we'll keep the link as a reference for future work. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2005-05-21 08:19 Message: Logged In: YES user_id=6656 Why do you say this patch isn't ready to apply? Oh, I've read it now :) > What is the status of the package? Not as well looked after as it should be :-/ I'm not sure most of the changes you describe are really bugs, more inefficiencies (e.g. compiler generated list comps still work even if they don't emit LIST_APPEND). Running "./python Lib/test/regrtest.py test_compiler -uall" will compile the entire stdlib with Lib/compiler (this is probably an overnight job) then running just plain "./python Lib/test/regrtest.py" will run the test suite using the compiled copy. It probably makes sense to submit a number of patches, particularly for the optimization versus straight fix divide. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1206077&group_id=5470 From noreply at sourceforge.net Thu May 26 17:04:45 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 26 May 2005 08:04:45 -0700 Subject: [Patches] [ python-Patches-1206077 ] updates for the compiler package Message-ID: Patches item #1206077, was opened at 2005-05-21 05:23 Message generated for change (Comment added) made by tjreedy You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1206077&group_id=5470 Please note that this 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: Stelios (sxanth) Assigned to: Nobody/Anonymous (nobody) Summary: updates for the compiler package Initial Comment: The compiler package produces lower quality bytecode since it does not do any of the peephole optimizations. I tried to fix that to make the package produce bytecode which is as good as the internal compiler. Yeah, probably wasted time but because python is so great it was much easier than I thought and now the package produces rather superior bytecode! The patch implements all the optimizations mentioned in compile.c and additionally: - constant folding (or however this is called). For example, it turns x = -(1<<2) to the constant -4. Also nested tuples of constants are converted to one big tuple constant. - The optimization which checks JUMPs that lead to other JUMPs is extended to re-run the optimization when something is modified. For example, the builtin optimizer can't do: if (a and b) and c where there is a JUMP_IF_FALSE which leads to a JUMP_IF_FALSE which leads to a third JUMP_IF_FALSE. While I was at it, I discovered several "bugs" which I couldn't resist attempting to fix. - Implemented LIST_APPEND for list comprehensions - The docstrings of functions where added in the co_consts of the module - All the names that appeared in a function where added to co_varnames. Not sure about the fix - Made co_filename and co_name interns - In generator expressions the outmost-iterable's names where considered freevars and therefore in: def bar(y): return foo (x for x in y) the generator expression was considered a closure I've used the new compiler for my own benchmark suite and all went well. I've also managed to just *compile* the standard library and with the new compiler it turns out 40167 bytes smaller (!). But really, somebody should run the regression tests with it (I can't due to inefficient hardware). IFF it passes the tests if *could* be used to re-compile the standard library for more efficient code. The patch is vs 2.4.1. However, the patch it's not 100% ready to be applied to mainline; but it's easier to review. The maintainer should tell me how to proceed :-) Further Questions: - generator expressions do not emit SETUP_LOOP/POP_BLOCK. Should they? - What is the status of the package? I discovered all those bugs in a couple of hours. Does this mean that there are many many others? How many new ones has my patch added? Is the package not suitable for serious development? ---------------------------------------------------------------------- >Comment By: Terry J. Reedy (tjreedy) Date: 2005-05-26 11:04 Message: Logged In: YES user_id=593130 If you think you might split and resubmit within a few months, you could keep this open for further comments and then use it for the optimization upgrades (updates). Put bug fixes in Bug Fixers .... ---------------------------------------------------------------------- Comment By: Terry J. Reedy (tjreedy) Date: 2005-05-26 11:02 Message: Logged In: YES user_id=593130 If you think you might split and resubmit within a few months, you could keep this open for further comments and then use it for the optimization upgrades (updates). Put bug fixes in Bug Fixers .... ---------------------------------------------------------------------- Comment By: Stelios (sxanth) Date: 2005-05-22 03:55 Message: Logged In: YES user_id=667962 Thanks for the instructions to regtest the compiler. I was hoping for a quick review by someone who knows well the compiler package to confirm that I'm doing the right thing in the places with XXX. It'll save me a lot of time. Hmmm. Since the patch is not ready to be applied, you can close this one if you want and we'll keep the link as a reference for future work. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2005-05-21 08:19 Message: Logged In: YES user_id=6656 Why do you say this patch isn't ready to apply? Oh, I've read it now :) > What is the status of the package? Not as well looked after as it should be :-/ I'm not sure most of the changes you describe are really bugs, more inefficiencies (e.g. compiler generated list comps still work even if they don't emit LIST_APPEND). Running "./python Lib/test/regrtest.py test_compiler -uall" will compile the entire stdlib with Lib/compiler (this is probably an overnight job) then running just plain "./python Lib/test/regrtest.py" will run the test suite using the compiled copy. It probably makes sense to submit a number of patches, particularly for the optimization versus straight fix divide. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1206077&group_id=5470 From noreply at sourceforge.net Fri May 27 01:09:52 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 26 May 2005 16:09:52 -0700 Subject: [Patches] [ python-Patches-1209527 ] Optimization for textwrap Message-ID: Patches item #1209527, was opened at 2005-05-26 23:09 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1209527&group_id=5470 Please note that this 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: Connelly (connelly) Assigned to: Nobody/Anonymous (nobody) Summary: Optimization for textwrap Initial Comment: This patch speeds up the textwrap module, so that it takes O(n) time to process n chunks rather than the O(n^2) time that textwrap previously took. This makes textwrap much faster for large texts (for example, the patched version runs textwrap.fill('foo' * 100000) 80 times faster than the unpatched version). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1209527&group_id=5470 From noreply at sourceforge.net Fri May 27 06:01:43 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 26 May 2005 21:01:43 -0700 Subject: [Patches] [ python-Patches-1209527 ] Optimization for textwrap Message-ID: Patches item #1209527, was opened at 2005-05-26 18:09 Message generated for change (Settings changed) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1209527&group_id=5470 Please note that this 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: Connelly (connelly) >Assigned to: Greg Ward (gward) Summary: Optimization for textwrap Initial Comment: This patch speeds up the textwrap module, so that it takes O(n) time to process n chunks rather than the O(n^2) time that textwrap previously took. This makes textwrap much faster for large texts (for example, the patched version runs textwrap.fill('foo' * 100000) 80 times faster than the unpatched version). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1209527&group_id=5470 From noreply at sourceforge.net Fri May 27 11:56:57 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 27 May 2005 02:56:57 -0700 Subject: [Patches] [ python-Patches-1206077 ] updates for the compiler package Message-ID: Patches item #1206077, was opened at 2005-05-21 09:23 Message generated for change (Comment added) made by sxanth You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1206077&group_id=5470 Please note that this 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: Stelios (sxanth) Assigned to: Nobody/Anonymous (nobody) Summary: updates for the compiler package Initial Comment: The compiler package produces lower quality bytecode since it does not do any of the peephole optimizations. I tried to fix that to make the package produce bytecode which is as good as the internal compiler. Yeah, probably wasted time but because python is so great it was much easier than I thought and now the package produces rather superior bytecode! The patch implements all the optimizations mentioned in compile.c and additionally: - constant folding (or however this is called). For example, it turns x = -(1<<2) to the constant -4. Also nested tuples of constants are converted to one big tuple constant. - The optimization which checks JUMPs that lead to other JUMPs is extended to re-run the optimization when something is modified. For example, the builtin optimizer can't do: if (a and b) and c where there is a JUMP_IF_FALSE which leads to a JUMP_IF_FALSE which leads to a third JUMP_IF_FALSE. While I was at it, I discovered several "bugs" which I couldn't resist attempting to fix. - Implemented LIST_APPEND for list comprehensions - The docstrings of functions where added in the co_consts of the module - All the names that appeared in a function where added to co_varnames. Not sure about the fix - Made co_filename and co_name interns - In generator expressions the outmost-iterable's names where considered freevars and therefore in: def bar(y): return foo (x for x in y) the generator expression was considered a closure I've used the new compiler for my own benchmark suite and all went well. I've also managed to just *compile* the standard library and with the new compiler it turns out 40167 bytes smaller (!). But really, somebody should run the regression tests with it (I can't due to inefficient hardware). IFF it passes the tests if *could* be used to re-compile the standard library for more efficient code. The patch is vs 2.4.1. However, the patch it's not 100% ready to be applied to mainline; but it's easier to review. The maintainer should tell me how to proceed :-) Further Questions: - generator expressions do not emit SETUP_LOOP/POP_BLOCK. Should they? - What is the status of the package? I discovered all those bugs in a couple of hours. Does this mean that there are many many others? How many new ones has my patch added? Is the package not suitable for serious development? ---------------------------------------------------------------------- >Comment By: Stelios (sxanth) Date: 2005-05-27 09:56 Message: Logged In: YES user_id=667962 I'm closing this one. Discovered many more things that can be improved and the patch will eventually get bigger than the entire package. I think it may be the best solution to submit an complete reimplementation of the package. ---------------------------------------------------------------------- Comment By: Terry J. Reedy (tjreedy) Date: 2005-05-26 15:04 Message: Logged In: YES user_id=593130 If you think you might split and resubmit within a few months, you could keep this open for further comments and then use it for the optimization upgrades (updates). Put bug fixes in Bug Fixers .... ---------------------------------------------------------------------- Comment By: Terry J. Reedy (tjreedy) Date: 2005-05-26 15:02 Message: Logged In: YES user_id=593130 If you think you might split and resubmit within a few months, you could keep this open for further comments and then use it for the optimization upgrades (updates). Put bug fixes in Bug Fixers .... ---------------------------------------------------------------------- Comment By: Stelios (sxanth) Date: 2005-05-22 07:55 Message: Logged In: YES user_id=667962 Thanks for the instructions to regtest the compiler. I was hoping for a quick review by someone who knows well the compiler package to confirm that I'm doing the right thing in the places with XXX. It'll save me a lot of time. Hmmm. Since the patch is not ready to be applied, you can close this one if you want and we'll keep the link as a reference for future work. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2005-05-21 12:19 Message: Logged In: YES user_id=6656 Why do you say this patch isn't ready to apply? Oh, I've read it now :) > What is the status of the package? Not as well looked after as it should be :-/ I'm not sure most of the changes you describe are really bugs, more inefficiencies (e.g. compiler generated list comps still work even if they don't emit LIST_APPEND). Running "./python Lib/test/regrtest.py test_compiler -uall" will compile the entire stdlib with Lib/compiler (this is probably an overnight job) then running just plain "./python Lib/test/regrtest.py" will run the test suite using the compiled copy. It probably makes sense to submit a number of patches, particularly for the optimization versus straight fix divide. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1206077&group_id=5470 From noreply at sourceforge.net Fri May 27 11:58:02 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 27 May 2005 02:58:02 -0700 Subject: [Patches] [ python-Patches-1206077 ] updates for the compiler package Message-ID: Patches item #1206077, was opened at 2005-05-21 09:23 Message generated for change (Settings changed) made by sxanth You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1206077&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Library (Lib) Group: Python 2.4 >Status: Closed Resolution: None Priority: 5 Submitted By: Stelios (sxanth) Assigned to: Nobody/Anonymous (nobody) Summary: updates for the compiler package Initial Comment: The compiler package produces lower quality bytecode since it does not do any of the peephole optimizations. I tried to fix that to make the package produce bytecode which is as good as the internal compiler. Yeah, probably wasted time but because python is so great it was much easier than I thought and now the package produces rather superior bytecode! The patch implements all the optimizations mentioned in compile.c and additionally: - constant folding (or however this is called). For example, it turns x = -(1<<2) to the constant -4. Also nested tuples of constants are converted to one big tuple constant. - The optimization which checks JUMPs that lead to other JUMPs is extended to re-run the optimization when something is modified. For example, the builtin optimizer can't do: if (a and b) and c where there is a JUMP_IF_FALSE which leads to a JUMP_IF_FALSE which leads to a third JUMP_IF_FALSE. While I was at it, I discovered several "bugs" which I couldn't resist attempting to fix. - Implemented LIST_APPEND for list comprehensions - The docstrings of functions where added in the co_consts of the module - All the names that appeared in a function where added to co_varnames. Not sure about the fix - Made co_filename and co_name interns - In generator expressions the outmost-iterable's names where considered freevars and therefore in: def bar(y): return foo (x for x in y) the generator expression was considered a closure I've used the new compiler for my own benchmark suite and all went well. I've also managed to just *compile* the standard library and with the new compiler it turns out 40167 bytes smaller (!). But really, somebody should run the regression tests with it (I can't due to inefficient hardware). IFF it passes the tests if *could* be used to re-compile the standard library for more efficient code. The patch is vs 2.4.1. However, the patch it's not 100% ready to be applied to mainline; but it's easier to review. The maintainer should tell me how to proceed :-) Further Questions: - generator expressions do not emit SETUP_LOOP/POP_BLOCK. Should they? - What is the status of the package? I discovered all those bugs in a couple of hours. Does this mean that there are many many others? How many new ones has my patch added? Is the package not suitable for serious development? ---------------------------------------------------------------------- Comment By: Stelios (sxanth) Date: 2005-05-27 09:56 Message: Logged In: YES user_id=667962 I'm closing this one. Discovered many more things that can be improved and the patch will eventually get bigger than the entire package. I think it may be the best solution to submit an complete reimplementation of the package. ---------------------------------------------------------------------- Comment By: Terry J. Reedy (tjreedy) Date: 2005-05-26 15:04 Message: Logged In: YES user_id=593130 If you think you might split and resubmit within a few months, you could keep this open for further comments and then use it for the optimization upgrades (updates). Put bug fixes in Bug Fixers .... ---------------------------------------------------------------------- Comment By: Terry J. Reedy (tjreedy) Date: 2005-05-26 15:02 Message: Logged In: YES user_id=593130 If you think you might split and resubmit within a few months, you could keep this open for further comments and then use it for the optimization upgrades (updates). Put bug fixes in Bug Fixers .... ---------------------------------------------------------------------- Comment By: Stelios (sxanth) Date: 2005-05-22 07:55 Message: Logged In: YES user_id=667962 Thanks for the instructions to regtest the compiler. I was hoping for a quick review by someone who knows well the compiler package to confirm that I'm doing the right thing in the places with XXX. It'll save me a lot of time. Hmmm. Since the patch is not ready to be applied, you can close this one if you want and we'll keep the link as a reference for future work. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2005-05-21 12:19 Message: Logged In: YES user_id=6656 Why do you say this patch isn't ready to apply? Oh, I've read it now :) > What is the status of the package? Not as well looked after as it should be :-/ I'm not sure most of the changes you describe are really bugs, more inefficiencies (e.g. compiler generated list comps still work even if they don't emit LIST_APPEND). Running "./python Lib/test/regrtest.py test_compiler -uall" will compile the entire stdlib with Lib/compiler (this is probably an overnight job) then running just plain "./python Lib/test/regrtest.py" will run the test suite using the compiled copy. It probably makes sense to submit a number of patches, particularly for the optimization versus straight fix divide. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1206077&group_id=5470 From noreply at sourceforge.net Fri May 27 13:53:37 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 27 May 2005 04:53:37 -0700 Subject: [Patches] [ python-Patches-1209781 ] Build Python2.4.1 on AIX5 using xlc v6 Message-ID: Patches item #1209781, was opened at 2005-05-27 11:53 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1209781&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Build Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Gangadhar NPK (npkg) Assigned to: Nobody/Anonymous (nobody) Summary: Build Python2.4.1 on AIX5 using xlc v6 Initial Comment: Using IBM's Visualage compiler to build Python on AIX, requires small changes to the code, to let it compile cleanly. OS version: AIX 5.2 xlc version: 6 The changes are: 1 AIX defines hz as a preprocessor symbol and it creates a conflict during preprocessing in the _codecs_cn.c. This symbol has been selectively undefined for AIX only 2.Trailing commas in an enum 3. Multiple defines of the _THREAD_SAFE symbol in python/thread.c. This has been selectively undefined. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1209781&group_id=5470 From noreply at sourceforge.net Fri May 27 17:24:51 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 27 May 2005 08:24:51 -0700 Subject: [Patches] [ python-Patches-1181301 ] make float packing copy bytes when they can Message-ID: Patches item #1181301, was opened at 2005-04-12 08:37 Message generated for change (Comment added) made by mwh You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1181301&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Core (C code) Group: Python 2.5 >Status: Closed >Resolution: Accepted Priority: 5 Submitted By: Michael Hudson (mwh) >Assigned to: Skip Montanaro (montanaro) Summary: make float packing copy bytes when they can Initial Comment: As discussed on python-dev, this makes the _PyFloat_{Pack,Unpack}{4,8} functions copy bytes around when peering at 1.5 has the right result. ---------------------------------------------------------------------- >Comment By: Michael Hudson (mwh) Date: 2005-05-27 16:24 Message: Logged In: YES user_id=6656 Checked in as: Lib/test/test_float.py revision 1.1 Include/floatobject.h revision 2.23 Include/pythonrun.h revision 2.66 Objects/floatobject.c revision 2.136 Python/pythonrun.c revision 2.214 ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2005-04-19 17:06 Message: Logged In: YES user_id=6656 Stop me if this is getting silly. This adds class methods __getformat__ and __setformat__ to the float type and uses them in a new test file, test_float (they have docstrings that warn people not to use them). I'd like to check this in soon. Any objections? ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2005-04-14 08:51 Message: Logged In: YES user_id=6656 This version attacks comments some more, uses more interesting probe values and, um, actually works on a little-endian platform (previous versions had a very stupid bug). ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2005-04-12 18:18 Message: Logged In: YES user_id=6656 New patch, which attacks comments in floatobject.h and implements Tim's idea of refusing to unpack an IEEE special on a non-IEEE platform. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1181301&group_id=5470 From noreply at sourceforge.net Fri May 27 17:27:40 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 27 May 2005 08:27:40 -0700 Subject: [Patches] [ python-Patches-1181301 ] make float packing copy bytes when they can Message-ID: Patches item #1181301, was opened at 2005-04-12 08:37 Message generated for change (Settings changed) made by mwh You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1181301&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Core (C code) Group: Python 2.5 Status: Closed Resolution: Accepted Priority: 5 Submitted By: Michael Hudson (mwh) >Assigned to: Michael Hudson (mwh) Summary: make float packing copy bytes when they can Initial Comment: As discussed on python-dev, this makes the _PyFloat_{Pack,Unpack}{4,8} functions copy bytes around when peering at 1.5 has the right result. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2005-05-27 16:24 Message: Logged In: YES user_id=6656 Checked in as: Lib/test/test_float.py revision 1.1 Include/floatobject.h revision 2.23 Include/pythonrun.h revision 2.66 Objects/floatobject.c revision 2.136 Python/pythonrun.c revision 2.214 ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2005-04-19 17:06 Message: Logged In: YES user_id=6656 Stop me if this is getting silly. This adds class methods __getformat__ and __setformat__ to the float type and uses them in a new test file, test_float (they have docstrings that warn people not to use them). I'd like to check this in soon. Any objections? ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2005-04-14 08:51 Message: Logged In: YES user_id=6656 This version attacks comments some more, uses more interesting probe values and, um, actually works on a little-endian platform (previous versions had a very stupid bug). ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2005-04-12 18:18 Message: Logged In: YES user_id=6656 New patch, which attacks comments in floatobject.h and implements Tim's idea of refusing to unpack an IEEE special on a non-IEEE platform. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1181301&group_id=5470 From noreply at sourceforge.net Fri May 27 18:37:07 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 27 May 2005 09:37:07 -0700 Subject: [Patches] [ python-Patches-1209527 ] Optimization for textwrap Message-ID: Patches item #1209527, was opened at 2005-05-26 23:09 Message generated for change (Comment added) made by connelly You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1209527&group_id=5470 Please note that this 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: Connelly (connelly) Assigned to: Greg Ward (gward) Summary: Optimization for textwrap Initial Comment: This patch speeds up the textwrap module, so that it takes O(n) time to process n chunks rather than the O(n^2) time that textwrap previously took. This makes textwrap much faster for large texts (for example, the patched version runs textwrap.fill('foo' * 100000) 80 times faster than the unpatched version). ---------------------------------------------------------------------- >Comment By: Connelly (connelly) Date: 2005-05-27 16:37 Message: Logged In: YES user_id=1039782 I assign the Copyright for this patch to the Python Software Foundation. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1209527&group_id=5470 From noreply at sourceforge.net Sun May 29 10:43:15 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 29 May 2005 01:43:15 -0700 Subject: [Patches] [ python-Patches-1210680 ] Split email headers near a space Message-ID: Patches item #1210680, was opened at 2005-05-29 11: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=1210680&group_id=5470 Please note that this 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: Nobody/Anonymous (nobody) Summary: Split email headers near a space Initial Comment: Hello, I recently used Python to automatically send messages to my gmail account. I was surprised to find out that some of the words in the subjects of messages were split by a space character which came from nowhere. It turns out that the international (Hebrew) subject was split into multiple lines by the email package, sometimes in the middle of words. Gmail treats these line breaks as spaces, so words gets cut into two. I've checked, and there are email clients which ignore the line breaks, so the subject looks ok. I added four lines to the _binsplit function of email.Header, so that if there is a space character in the string, it will be splitted there. This fixes the problem, and subjects look fine again. These four lines (plus a comment which I wrote) are: # Try to find a place in splittable[:i] which is near a space, # and split there, so that clients which interpret the line break # as a separator won't insert a space in the middle of a word. if splittable[i:i+1] != ' ': spacepos = splittable.rfind(' ', 0, i) if spacepos != -1: i = spacepos + 1 These lines should be added before the last three lines of _binsplit. Sorry about not attaching a diff file - I currently don't have diff at hand. Thank you, Noam Raphael ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1210680&group_id=5470 From noreply at sourceforge.net Sun May 29 13:16:20 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 29 May 2005 04:16:20 -0700 Subject: [Patches] [ python-Patches-1206077 ] updates for the compiler package Message-ID: Patches item #1206077, was opened at 2005-05-21 09:23 Message generated for change (Comment added) made by sxanth You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1206077&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Library (Lib) Group: Python 2.4 Status: Closed Resolution: None Priority: 5 Submitted By: Stelios (sxanth) Assigned to: Nobody/Anonymous (nobody) Summary: updates for the compiler package Initial Comment: The compiler package produces lower quality bytecode since it does not do any of the peephole optimizations. I tried to fix that to make the package produce bytecode which is as good as the internal compiler. Yeah, probably wasted time but because python is so great it was much easier than I thought and now the package produces rather superior bytecode! The patch implements all the optimizations mentioned in compile.c and additionally: - constant folding (or however this is called). For example, it turns x = -(1<<2) to the constant -4. Also nested tuples of constants are converted to one big tuple constant. - The optimization which checks JUMPs that lead to other JUMPs is extended to re-run the optimization when something is modified. For example, the builtin optimizer can't do: if (a and b) and c where there is a JUMP_IF_FALSE which leads to a JUMP_IF_FALSE which leads to a third JUMP_IF_FALSE. While I was at it, I discovered several "bugs" which I couldn't resist attempting to fix. - Implemented LIST_APPEND for list comprehensions - The docstrings of functions where added in the co_consts of the module - All the names that appeared in a function where added to co_varnames. Not sure about the fix - Made co_filename and co_name interns - In generator expressions the outmost-iterable's names where considered freevars and therefore in: def bar(y): return foo (x for x in y) the generator expression was considered a closure I've used the new compiler for my own benchmark suite and all went well. I've also managed to just *compile* the standard library and with the new compiler it turns out 40167 bytes smaller (!). But really, somebody should run the regression tests with it (I can't due to inefficient hardware). IFF it passes the tests if *could* be used to re-compile the standard library for more efficient code. The patch is vs 2.4.1. However, the patch it's not 100% ready to be applied to mainline; but it's easier to review. The maintainer should tell me how to proceed :-) Further Questions: - generator expressions do not emit SETUP_LOOP/POP_BLOCK. Should they? - What is the status of the package? I discovered all those bugs in a couple of hours. Does this mean that there are many many others? How many new ones has my patch added? Is the package not suitable for serious development? ---------------------------------------------------------------------- >Comment By: Stelios (sxanth) Date: 2005-05-29 11:16 Message: Logged In: YES user_id=667962 Some comments after regtesting: * The fix for generator expressions is *wrong* (grep the patch for the string 'genexp-1'). The right way to do this is to make the SymbolVisitor aware of the outmost iterable. * The FoldConst optimizer must be prepared to handle ZeroDivisionError. * It appears that the optimizer exposes some weird unicode bug. I can't find what's wrong so I suppose it's a python bug. Try to compile test_grammar to see it. ---------------------------------------------------------------------- Comment By: Stelios (sxanth) Date: 2005-05-27 09:56 Message: Logged In: YES user_id=667962 I'm closing this one. Discovered many more things that can be improved and the patch will eventually get bigger than the entire package. I think it may be the best solution to submit an complete reimplementation of the package. ---------------------------------------------------------------------- Comment By: Terry J. Reedy (tjreedy) Date: 2005-05-26 15:04 Message: Logged In: YES user_id=593130 If you think you might split and resubmit within a few months, you could keep this open for further comments and then use it for the optimization upgrades (updates). Put bug fixes in Bug Fixers .... ---------------------------------------------------------------------- Comment By: Terry J. Reedy (tjreedy) Date: 2005-05-26 15:02 Message: Logged In: YES user_id=593130 If you think you might split and resubmit within a few months, you could keep this open for further comments and then use it for the optimization upgrades (updates). Put bug fixes in Bug Fixers .... ---------------------------------------------------------------------- Comment By: Stelios (sxanth) Date: 2005-05-22 07:55 Message: Logged In: YES user_id=667962 Thanks for the instructions to regtest the compiler. I was hoping for a quick review by someone who knows well the compiler package to confirm that I'm doing the right thing in the places with XXX. It'll save me a lot of time. Hmmm. Since the patch is not ready to be applied, you can close this one if you want and we'll keep the link as a reference for future work. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2005-05-21 12:19 Message: Logged In: YES user_id=6656 Why do you say this patch isn't ready to apply? Oh, I've read it now :) > What is the status of the package? Not as well looked after as it should be :-/ I'm not sure most of the changes you describe are really bugs, more inefficiencies (e.g. compiler generated list comps still work even if they don't emit LIST_APPEND). Running "./python Lib/test/regrtest.py test_compiler -uall" will compile the entire stdlib with Lib/compiler (this is probably an overnight job) then running just plain "./python Lib/test/regrtest.py" will run the test suite using the compiled copy. It probably makes sense to submit a number of patches, particularly for the optimization versus straight fix divide. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1206077&group_id=5470 From noreply at sourceforge.net Sun May 29 14:11:25 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 29 May 2005 05:11:25 -0700 Subject: [Patches] [ python-Patches-1206077 ] updates for the compiler package Message-ID: Patches item #1206077, was opened at 2005-05-21 09:23 Message generated for change (Comment added) made by sxanth You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1206077&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Library (Lib) Group: Python 2.4 Status: Closed Resolution: None Priority: 5 Submitted By: Stelios (sxanth) Assigned to: Nobody/Anonymous (nobody) Summary: updates for the compiler package Initial Comment: The compiler package produces lower quality bytecode since it does not do any of the peephole optimizations. I tried to fix that to make the package produce bytecode which is as good as the internal compiler. Yeah, probably wasted time but because python is so great it was much easier than I thought and now the package produces rather superior bytecode! The patch implements all the optimizations mentioned in compile.c and additionally: - constant folding (or however this is called). For example, it turns x = -(1<<2) to the constant -4. Also nested tuples of constants are converted to one big tuple constant. - The optimization which checks JUMPs that lead to other JUMPs is extended to re-run the optimization when something is modified. For example, the builtin optimizer can't do: if (a and b) and c where there is a JUMP_IF_FALSE which leads to a JUMP_IF_FALSE which leads to a third JUMP_IF_FALSE. While I was at it, I discovered several "bugs" which I couldn't resist attempting to fix. - Implemented LIST_APPEND for list comprehensions - The docstrings of functions where added in the co_consts of the module - All the names that appeared in a function where added to co_varnames. Not sure about the fix - Made co_filename and co_name interns - In generator expressions the outmost-iterable's names where considered freevars and therefore in: def bar(y): return foo (x for x in y) the generator expression was considered a closure I've used the new compiler for my own benchmark suite and all went well. I've also managed to just *compile* the standard library and with the new compiler it turns out 40167 bytes smaller (!). But really, somebody should run the regression tests with it (I can't due to inefficient hardware). IFF it passes the tests if *could* be used to re-compile the standard library for more efficient code. The patch is vs 2.4.1. However, the patch it's not 100% ready to be applied to mainline; but it's easier to review. The maintainer should tell me how to proceed :-) Further Questions: - generator expressions do not emit SETUP_LOOP/POP_BLOCK. Should they? - What is the status of the package? I discovered all those bugs in a couple of hours. Does this mean that there are many many others? How many new ones has my patch added? Is the package not suitable for serious development? ---------------------------------------------------------------------- >Comment By: Stelios (sxanth) Date: 2005-05-29 12:11 Message: Logged In: YES user_id=667962 Correction: The bug is exposed by test_codecs, not test_grammar. ---------------------------------------------------------------------- Comment By: Stelios (sxanth) Date: 2005-05-29 11:16 Message: Logged In: YES user_id=667962 Some comments after regtesting: * The fix for generator expressions is *wrong* (grep the patch for the string 'genexp-1'). The right way to do this is to make the SymbolVisitor aware of the outmost iterable. * The FoldConst optimizer must be prepared to handle ZeroDivisionError. * It appears that the optimizer exposes some weird unicode bug. I can't find what's wrong so I suppose it's a python bug. Try to compile test_grammar to see it. ---------------------------------------------------------------------- Comment By: Stelios (sxanth) Date: 2005-05-27 09:56 Message: Logged In: YES user_id=667962 I'm closing this one. Discovered many more things that can be improved and the patch will eventually get bigger than the entire package. I think it may be the best solution to submit an complete reimplementation of the package. ---------------------------------------------------------------------- Comment By: Terry J. Reedy (tjreedy) Date: 2005-05-26 15:04 Message: Logged In: YES user_id=593130 If you think you might split and resubmit within a few months, you could keep this open for further comments and then use it for the optimization upgrades (updates). Put bug fixes in Bug Fixers .... ---------------------------------------------------------------------- Comment By: Terry J. Reedy (tjreedy) Date: 2005-05-26 15:02 Message: Logged In: YES user_id=593130 If you think you might split and resubmit within a few months, you could keep this open for further comments and then use it for the optimization upgrades (updates). Put bug fixes in Bug Fixers .... ---------------------------------------------------------------------- Comment By: Stelios (sxanth) Date: 2005-05-22 07:55 Message: Logged In: YES user_id=667962 Thanks for the instructions to regtest the compiler. I was hoping for a quick review by someone who knows well the compiler package to confirm that I'm doing the right thing in the places with XXX. It'll save me a lot of time. Hmmm. Since the patch is not ready to be applied, you can close this one if you want and we'll keep the link as a reference for future work. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2005-05-21 12:19 Message: Logged In: YES user_id=6656 Why do you say this patch isn't ready to apply? Oh, I've read it now :) > What is the status of the package? Not as well looked after as it should be :-/ I'm not sure most of the changes you describe are really bugs, more inefficiencies (e.g. compiler generated list comps still work even if they don't emit LIST_APPEND). Running "./python Lib/test/regrtest.py test_compiler -uall" will compile the entire stdlib with Lib/compiler (this is probably an overnight job) then running just plain "./python Lib/test/regrtest.py" will run the test suite using the compiled copy. It probably makes sense to submit a number of patches, particularly for the optimization versus straight fix divide. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1206077&group_id=5470 From noreply at sourceforge.net Sun May 29 23:59:52 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 29 May 2005 14:59:52 -0700 Subject: [Patches] [ python-Patches-1210680 ] Split email headers near a space Message-ID: Patches item #1210680, was opened at 2005-05-29 18:43 Message generated for change (Settings changed) made by ncoghlan You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1210680&group_id=5470 Please note that this 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: Barry A. Warsaw (bwarsaw) Summary: Split email headers near a space Initial Comment: Hello, I recently used Python to automatically send messages to my gmail account. I was surprised to find out that some of the words in the subjects of messages were split by a space character which came from nowhere. It turns out that the international (Hebrew) subject was split into multiple lines by the email package, sometimes in the middle of words. Gmail treats these line breaks as spaces, so words gets cut into two. I've checked, and there are email clients which ignore the line breaks, so the subject looks ok. I added four lines to the _binsplit function of email.Header, so that if there is a space character in the string, it will be splitted there. This fixes the problem, and subjects look fine again. These four lines (plus a comment which I wrote) are: # Try to find a place in splittable[:i] which is near a space, # and split there, so that clients which interpret the line break # as a separator won't insert a space in the middle of a word. if splittable[i:i+1] != ' ': spacepos = splittable.rfind(' ', 0, i) if spacepos != -1: i = spacepos + 1 These lines should be added before the last three lines of _binsplit. Sorry about not attaching a diff file - I currently don't have diff at hand. Thank you, Noam Raphael ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1210680&group_id=5470 From noreply at sourceforge.net Mon May 30 10:25:20 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 30 May 2005 01:25:20 -0700 Subject: [Patches] [ python-Patches-1209781 ] Build Python2.4.1 on AIX5 using xlc v6 Message-ID: Patches item #1209781, was opened at 2005-05-27 13:53 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1209781&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Build Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Gangadhar NPK (npkg) Assigned to: Nobody/Anonymous (nobody) Summary: Build Python2.4.1 on AIX5 using xlc v6 Initial Comment: Using IBM's Visualage compiler to build Python on AIX, requires small changes to the code, to let it compile cleanly. OS version: AIX 5.2 xlc version: 6 The changes are: 1 AIX defines hz as a preprocessor symbol and it creates a conflict during preprocessing in the _codecs_cn.c. This symbol has been selectively undefined for AIX only 2.Trailing commas in an enum 3. Multiple defines of the _THREAD_SAFE symbol in python/thread.c. This has been selectively undefined. ---------------------------------------------------------------------- >Comment By: Martin v. L?wis (loewis) Date: 2005-05-30 10:25 Message: Logged In: YES user_id=21627 These patches look fine except for the last chunk. I very much doubt that xlc cannot handle multiple defines; ISO C mandates that a redefine is allowed as long as the replacement lists of the macros are identical (6.10.3p2). So if xlc complains, it is likely that it has a different definition than the one it reports a conflict is. Also, it is unclear what precisely the conflict is: AFAICT, Python never defines _THREAD_SAFE itself. So the conflict must be between two AIX header files. Can you please investigate this aspect further? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1209781&group_id=5470 From noreply at sourceforge.net Mon May 30 10:26:31 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 30 May 2005 01:26:31 -0700 Subject: [Patches] [ python-Patches-1207985 ] An URL for UnicodeData File Format 3.2 has changed. Message-ID: Patches item #1207985, was opened at 2005-05-24 19:12 Message generated for change (Settings changed) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1207985&group_id=5470 Please note that this 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: 7 Submitted By: Darek Suchojad (dsuch) >Assigned to: Martin v. L?wis (loewis) Summary: An URL for UnicodeData File Format 3.2 has changed. Initial Comment: Hello, both Modules/unicodedata.c and Doc/lib/libunicodedata.tex mention an old URL for UnicodeData File Format 3.2.0. Attached is a patch to make them correct. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1207985&group_id=5470 From noreply at sourceforge.net Mon May 30 10:27:36 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 30 May 2005 01:27:36 -0700 Subject: [Patches] [ python-Patches-1203650 ] Allow larger programs to be frozen under Win32 Message-ID: Patches item #1203650, was opened at 2005-05-17 17:03 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1203650&group_id=5470 Please note that this 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: Gottfried Gan?auge (ganssauge) Assigned to: Nobody/Anonymous (nobody) Summary: Allow larger programs to be frozen under Win32 Initial Comment: The makefile generated by freeze on Windows ist not suitable for Programs containing many imported modules. This patch generates a makefile using an inline linker response file. ---------------------------------------------------------------------- >Comment By: Martin v. L?wis (loewis) Date: 2005-05-30 10:27 Message: Logged In: YES user_id=21627 Can you please explain what you mean by "not suitable"? Do you get some error? If so, what precisely is the error message? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1203650&group_id=5470 From noreply at sourceforge.net Tue May 31 04:56:30 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 30 May 2005 19:56:30 -0700 Subject: [Patches] [ python-Patches-1121142 ] ZipFile.open - read-only file-like obj for files in archive Message-ID: Patches item #1121142, was opened at 2005-02-11 19:08 Message generated for change (Comment added) made by alanmcintyre You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1121142&group_id=5470 Please note that this 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: Alan McIntyre (ESRG) (alanmcintyre) Assigned to: Nobody/Anonymous (nobody) Summary: ZipFile.open - read-only file-like obj for files in archive Initial Comment: I originally started working on updating patch 992750, but decided after a short while to just start from scratch, so I'm posting it as a new patch. Sorry if this isn't appropriate. This patch provides a new open() method on ZipFile; this method returns a file-like object for the requested item in the archive. This file-like object only provides a read() method. ZipFile.read was modified to use the new open method (this was suggested by loewis in reference to patch 992750). The patched zipfile.py passed the existing tests in the test_zipfile.py from CVS. New tests were added to verify the operation of the object returned by open(). These tests were modeled after existing tests for ZipFile.read(); two read fixed-size chunks from the file-like object, and two others read random-sized chunks. I have only run the tests on Windows XP, using Python2.4 from the official Windows installer. I will test the patch out on Linux over the weekend. If the patch is accepted I'll also generate and submit patches for the appropriate documentation as well. ---------------------------------------------------------------------- >Comment By: Alan McIntyre (ESRG) (alanmcintyre) Date: 2005-05-30 21:56 Message: Logged In: YES user_id=1115903 Revision 5 of this patch has been in constant use with Python 2.4.1 in an application at my job for about a month; it seems to be stable and useful in that regard. If anybody has time to review and accept (or reject) it I would appreciate it. ---------------------------------------------------------------------- Comment By: Alan McIntyre (ESRG) (alanmcintyre) Date: 2005-04-26 21:23 Message: Logged In: YES user_id=1115903 After testing on my large batch of large Zip files, I made one fix (version 4 of the patch didn't read all the content of large compressed archive items). The current set of changes is attached as zipfile_patch5.tgz. ---------------------------------------------------------------------- Comment By: Alan McIntyre (ESRG) (alanmcintyre) Date: 2005-04-13 11:34 Message: Logged In: YES user_id=1115903 I found a problem with my universal newline handling code in readline(); if the first byte of an '\r\n' pair was read from file but the second byte didn't come in on that same read, it resulted in the next line having an inappropriate '\n' prepended to it. zipfile_patch4.tgz has a fix for this included (with everything else, of course). I'm going to test the open() capability in a real application with some reasonably large zip files (containing files up to just short of 2GB) over the next few days, so if any bugs or performance problems show up I may have some more changes. ---------------------------------------------------------------------- Comment By: Alan McIntyre (ESRG) (alanmcintyre) Date: 2005-04-13 00:58 Message: Logged In: YES user_id=1115903 Uploaded the third revision of this patch; passes all regression tests against current CVS on WinXP. I think all the issues Martin brought up have been addressed except perhaps for the case of compression rate <1. I will have a look at that when I have time; just wanted to get an update here before the patch started to look abandoned. :) ---------------------------------------------------------------------- Comment By: Alan McIntyre (ESRG) (alanmcintyre) Date: 2005-03-14 09:37 Message: Logged In: YES user_id=1115903 Hmm...I could have sworn I did the diff in the correct order. I'll make sure next time. :) Here's my comments on your remarks (in order): - I'm adding support for universal newlines, and will reject all modes that aren't legal combinations of r, U, and b. - I'll see if I can make a Zip file store something with compression < 1, and if I can I'll add a test case for it. - I'll try work a .flush() in there on the compression object and come up with a test case if possible - .read(0) and .readline(0) will both return an empty string with no side-effects, since this seems to be what builtin files do. Right now ZipExtFile uses the ZipFile's file object, so you pretty much have to do whatever you're going to do with the ZipExtFile instance you get back from .open() before you use that ZipFile instance in a way that moves the file pointer around. I'm sure that somebody will eventually try to use the ZipFile in this way, so it appears my options are either to (1) give the ZipExtFile its own file object to use (when possible), or (2) make sure this limitation is documented. #1 feels (to me) to be the "right thing" to do, so that's what I'll try unless there's a good reason I shouldn't. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2005-03-01 02:59 Message: Logged In: YES user_id=21627 The patch is reversed: usually, diff is invoked as "-c old new". I think it is almost right, but I have a few remarks: - by tradition, open() should have a mode argument, defaulting to 'r'; it would be ok to raise exceptions if it is anything else. However, do consider implementing universal newlines; allowing 'b' as a no-op might also be reasonable. - I wonder what happens if the compression rate is < 1. It would appear that the code might use too few rawbytes. I suggest to recursively invoke read in this case. - I wonder whether it could ever happen that there is still data to uncompress in the zlib object, ie. whether it might be necessary to invoke .flush() after exhausting the rawbytes (and discard the zlib object afterwards) - it appears that atleast the builtin file object implements .read(0) as returning an empty string; the manual says that the entire file is meant only if size is omitted or negative. ---------------------------------------------------------------------- Comment By: Alan McIntyre (ESRG) (alanmcintyre) Date: 2005-02-27 01:28 Message: Logged In: YES user_id=1115903 zipfile_patch2.tgz: I updated the file-like object to support readline, readlines, __iter__ and next(). Added tests for those new methods. Also added a patch for the documentation. Passes regression tests on 2.5a0 built from CVS HEAD with MSVC .NET on Windows XP. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1121142&group_id=5470 From noreply at sourceforge.net Tue May 31 18:39:17 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 31 May 2005 09:39:17 -0700 Subject: [Patches] [ python-Patches-1212117 ] Add st_flags support to (l)stat function Message-ID: Patches item #1212117, was opened at 2005-05-31 18: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=1212117&group_id=5470 Please note that this 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: Diego Petten? (dgp85) Assigned to: Nobody/Anonymous (nobody) Summary: Add st_flags support to (l)stat function Initial Comment: The attached patch applied over Python 2.3.5 sources adds support for st_flags attribute of struct stat, which is used for example on FreeBSD for file's special flags. The same patch applies (with a bit of fuzzyness) over 2.4. The check is similar to the st_blocks and st_rdev in configure.in, and works in the same way. HTH, Diego Petten? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1212117&group_id=5470 From noreply at sourceforge.net Tue May 31 23:41:16 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 31 May 2005 14:41:16 -0700 Subject: [Patches] [ python-Patches-1212287 ] mode argument for fileinput class Message-ID: Patches item #1212287, was opened at 2005-05-31 23:41 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1212287&group_id=5470 Please note that this 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: Reinhold Birkenfeld (birkenfeld) Assigned to: Nobody/Anonymous (nobody) Summary: mode argument for fileinput class Initial Comment: This patch is in follow-up to bug #860515. It allows to specify a mode argument to the fileinput functions which can be r, rb, rU and U. Complete with test and doc. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1212287&group_id=5470