From noreply at sourceforge.net Mon Nov 1 01:16:51 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Nov 1 01:16:56 2004 Subject: [ python-Bugs-1052242 ] Attempt to run all atexit handlers Message-ID: Bugs item #1052242, was opened at 2004-10-22 09:31 Message generated for change (Comment added) made by montanaro You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1052242&group_id=5470 Category: Python Library Group: None Status: Open Resolution: None Priority: 5 Submitted By: Greg Chapman (glchapman) Assigned to: Skip Montanaro (montanaro) Summary: Attempt to run all atexit handlers Initial Comment: Currently, if an atexit handler raises an exception during _run_exitfuncs, none of the remaining handlers in the _exithandlers list gets run. I would prefer it if _run_exitfuncs did something like: while _exithandlers: func, targs, kargs = _exithandlers.pop() try: func(*targs, **kargs) except SystemExit: raise except: import sys, traceback print >> sys.stderr, "Error in sys.exitfunc:" traceback.print_exc() The SystemExit except clause is there because it looks like (given its special treatment in call_sys_exitfunc) SystemExit is envisioned as a way of intentionally breaking out of the exithandlers loop. ---------------------------------------------------------------------- >Comment By: Skip Montanaro (montanaro) Date: 2004-10-31 18:16 Message: Logged In: YES user_id=44345 Here's the next version of the patch. It includes the save-the-exception stuff and a rewrite of test_atexit.py using unittest. The only annoyance is that the traceback for the actually raised exception will be printed twice. One way around that might be to wrap the last raise in something like stdout = sys.stdout stderr = sys.stderr sys.stdout = sys.stderr = open(os.devnull, "w") try: raise ... finally: sys.stdout = stdout sys.stderr = stderr though I haven't tested the idea to see if it will actually work. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2004-10-28 14:21 Message: Logged In: YES user_id=80475 This should probably also be kicked around on python-dev so that we arrive at a clear expression of what it means to raise SystemExit and how that differs from os._exit(). One school of thought is that Greg's initial version is correct -- raising SystemExit means get out as fast as you can but not as abruptly as os._exit() so that buffers can be flushed, etc. ---------------------------------------------------------------------- Comment By: Greg Chapman (glchapman) Date: 2004-10-28 10:24 Message: Logged In: YES user_id=86307 > Should we defer it until the loop is complete and reraise it > then? +1 ---------------------------------------------------------------------- Comment By: Skip Montanaro (montanaro) Date: 2004-10-28 06:28 Message: Logged In: YES user_id=44345 Okay, Guido has pronounced. My idea for preserving compatibility is out. Now, I wonder about Greg's SystemExit behavior... Should we defer it until the loop is complete and reraise it then? ---------------------------------------------------------------------- Comment By: Skip Montanaro (montanaro) Date: 2004-10-27 09:44 Message: Logged In: YES user_id=44345 I agree with you in principle, but you'd change behavior and possibly break existing code that relies on the current implicit semantics, hence my suggestion to use a variable to control the behavior, with it set to preserve the current behavior by default. I'll post a request to python-dev soliciting input. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2004-10-27 00:46 Message: Logged In: YES user_id=80475 I prefer the original proposal that leaves the API untouched. Irrespective of ordering, my thought is that all exit handlers are probably expected to run (needed for important cleanup, resource freeing, etc) and may be independent of one another. So, all of them that can run, probably should. ---------------------------------------------------------------------- Comment By: Skip Montanaro (montanaro) Date: 2004-10-24 12:21 Message: Logged In: YES user_id=44345 OTOH, since the ordering of the exit handlers is not guaranteed, exiting after one exception is also reasonable behavior. Attached is a diff that does two things: adds a set_run_all function and converts the functionality into an ExitHandler class to keep from all the different bits of global state. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2004-10-23 19:56 Message: Logged In: YES user_id=80475 This could be considered a bug. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1052242&group_id=5470 From noreply at sourceforge.net Mon Nov 1 01:25:10 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Nov 1 01:25:23 2004 Subject: [ python-Bugs-1052242 ] Attempt to run all atexit handlers Message-ID: Bugs item #1052242, was opened at 2004-10-22 09:31 Message generated for change (Comment added) made by montanaro You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1052242&group_id=5470 Category: Python Library Group: None Status: Open Resolution: None Priority: 5 Submitted By: Greg Chapman (glchapman) Assigned to: Skip Montanaro (montanaro) Summary: Attempt to run all atexit handlers Initial Comment: Currently, if an atexit handler raises an exception during _run_exitfuncs, none of the remaining handlers in the _exithandlers list gets run. I would prefer it if _run_exitfuncs did something like: while _exithandlers: func, targs, kargs = _exithandlers.pop() try: func(*targs, **kargs) except SystemExit: raise except: import sys, traceback print >> sys.stderr, "Error in sys.exitfunc:" traceback.print_exc() The SystemExit except clause is there because it looks like (given its special treatment in call_sys_exitfunc) SystemExit is envisioned as a way of intentionally breaking out of the exithandlers loop. ---------------------------------------------------------------------- >Comment By: Skip Montanaro (montanaro) Date: 2004-10-31 18:25 Message: Logged In: YES user_id=44345 Whoops, forgot to attach. Just as well, I also have a small doc fix to include... ---------------------------------------------------------------------- Comment By: Skip Montanaro (montanaro) Date: 2004-10-31 18:16 Message: Logged In: YES user_id=44345 Here's the next version of the patch. It includes the save-the-exception stuff and a rewrite of test_atexit.py using unittest. The only annoyance is that the traceback for the actually raised exception will be printed twice. One way around that might be to wrap the last raise in something like stdout = sys.stdout stderr = sys.stderr sys.stdout = sys.stderr = open(os.devnull, "w") try: raise ... finally: sys.stdout = stdout sys.stderr = stderr though I haven't tested the idea to see if it will actually work. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2004-10-28 14:21 Message: Logged In: YES user_id=80475 This should probably also be kicked around on python-dev so that we arrive at a clear expression of what it means to raise SystemExit and how that differs from os._exit(). One school of thought is that Greg's initial version is correct -- raising SystemExit means get out as fast as you can but not as abruptly as os._exit() so that buffers can be flushed, etc. ---------------------------------------------------------------------- Comment By: Greg Chapman (glchapman) Date: 2004-10-28 10:24 Message: Logged In: YES user_id=86307 > Should we defer it until the loop is complete and reraise it > then? +1 ---------------------------------------------------------------------- Comment By: Skip Montanaro (montanaro) Date: 2004-10-28 06:28 Message: Logged In: YES user_id=44345 Okay, Guido has pronounced. My idea for preserving compatibility is out. Now, I wonder about Greg's SystemExit behavior... Should we defer it until the loop is complete and reraise it then? ---------------------------------------------------------------------- Comment By: Skip Montanaro (montanaro) Date: 2004-10-27 09:44 Message: Logged In: YES user_id=44345 I agree with you in principle, but you'd change behavior and possibly break existing code that relies on the current implicit semantics, hence my suggestion to use a variable to control the behavior, with it set to preserve the current behavior by default. I'll post a request to python-dev soliciting input. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2004-10-27 00:46 Message: Logged In: YES user_id=80475 I prefer the original proposal that leaves the API untouched. Irrespective of ordering, my thought is that all exit handlers are probably expected to run (needed for important cleanup, resource freeing, etc) and may be independent of one another. So, all of them that can run, probably should. ---------------------------------------------------------------------- Comment By: Skip Montanaro (montanaro) Date: 2004-10-24 12:21 Message: Logged In: YES user_id=44345 OTOH, since the ordering of the exit handlers is not guaranteed, exiting after one exception is also reasonable behavior. Attached is a diff that does two things: adds a set_run_all function and converts the functionality into an ExitHandler class to keep from all the different bits of global state. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2004-10-23 19:56 Message: Logged In: YES user_id=80475 This could be considered a bug. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1052242&group_id=5470 From noreply at sourceforge.net Mon Nov 1 04:59:41 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Nov 1 04:59:44 2004 Subject: [ python-Bugs-1030118 ] email.Utils not mentioned Message-ID: Bugs item #1030118, was opened at 2004-09-17 17:40 Message generated for change (Comment added) made by bwarsaw You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1030118&group_id=5470 Category: Documentation Group: None >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Jeff Blaine (jblaine) Assigned to: Barry A. Warsaw (bwarsaw) Summary: email.Utils not mentioned Initial Comment: I read the following and had to track down why 'email.make_msgid()' was failing. Turns out I need to import email.Utils of course, but the name of the module to import is not even mentioned in the docs. It states they come 'with the email package' only. ... 12.2.9 Miscellaneous utilities There are several useful utilities provided with the email package. quote(str) Return a new string with backslashes in str replaced by two backslashes, and double quotes replaced by backslash-double quote. .... ---------------------------------------------------------------------- >Comment By: Barry A. Warsaw (bwarsaw) Date: 2004-10-31 22:59 Message: Logged In: YES user_id=12800 Fixed in Py2.4 and Py2.3 documentation. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1030118&group_id=5470 From noreply at sourceforge.net Mon Nov 1 08:06:25 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Nov 1 08:06:28 2004 Subject: [ python-Bugs-1057992 ] os.utime() doesn't work on WinME Message-ID: Bugs item #1057992, was opened at 2004-11-01 02:06 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1057992&group_id=5470 Category: Extension Modules Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Raymond Hettinger (rhettinger) Assigned to: Nobody/Anonymous (nobody) Summary: os.utime() doesn't work on WinME Initial Comment: >>> from os import stat, utime >>> utime('fi.txt', (1099285201, 1099210995)) >>> stat('fi.txt').st_atime 1099285200 >>> stat('fi.txt').st_mtime 1099210996 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1057992&group_id=5470 From noreply at sourceforge.net Mon Nov 1 08:08:35 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Nov 1 08:08:38 2004 Subject: [ python-Bugs-1057993 ] test_traceback.py fails on WinME Message-ID: Bugs item #1057993, was opened at 2004-11-01 02:08 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1057993&group_id=5470 Category: Python Library Group: Python 2.4 Status: Open Resolution: None Priority: 7 Submitted By: Raymond Hettinger (rhettinger) Assigned to: Nobody/Anonymous (nobody) Summary: test_traceback.py fails on WinME Initial Comment: Traceback (most recent call last): File "test_traceback.py", line 79, in test_bug737473 test_bug737473.test() File "c:\windows\temp\tmpsj7w5a\test_bug737473.py", line 2, in test ValueError Does work if the sleep() option is forced. Recommend always using sleep(). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1057993&group_id=5470 From noreply at sourceforge.net Mon Nov 1 09:27:37 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Nov 1 09:27:56 2004 Subject: [ python-Bugs-1057993 ] test_traceback.py fails on WinME Message-ID: Bugs item #1057993, was opened at 2004-11-01 16:08 Message generated for change (Comment added) made by perky You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1057993&group_id=5470 Category: Python Library Group: Python 2.4 >Status: Closed >Resolution: Fixed Priority: 7 Submitted By: Raymond Hettinger (rhettinger) >Assigned to: Hye-Shik Chang (perky) Summary: test_traceback.py fails on WinME Initial Comment: Traceback (most recent call last): File "test_traceback.py", line 79, in test_bug737473 test_bug737473.test() File "c:\windows\temp\tmpsj7w5a\test_bug737473.py", line 2, in test ValueError Does work if the sleep() option is forced. Recommend always using sleep(). ---------------------------------------------------------------------- >Comment By: Hye-Shik Chang (perky) Date: 2004-11-01 17:27 Message: Logged In: YES user_id=55188 Fixed in CVS. Lib/test/test_traceback.py 1.13 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1057993&group_id=5470 From noreply at sourceforge.net Mon Nov 1 11:28:37 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Nov 1 11:28:43 2004 Subject: [ python-Bugs-1052242 ] Attempt to run all atexit handlers Message-ID: Bugs item #1052242, was opened at 2004-10-22 09:31 Message generated for change (Settings changed) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1052242&group_id=5470 Category: Python Library Group: None Status: Open >Resolution: Accepted Priority: 5 Submitted By: Greg Chapman (glchapman) Assigned to: Skip Montanaro (montanaro) Summary: Attempt to run all atexit handlers Initial Comment: Currently, if an atexit handler raises an exception during _run_exitfuncs, none of the remaining handlers in the _exithandlers list gets run. I would prefer it if _run_exitfuncs did something like: while _exithandlers: func, targs, kargs = _exithandlers.pop() try: func(*targs, **kargs) except SystemExit: raise except: import sys, traceback print >> sys.stderr, "Error in sys.exitfunc:" traceback.print_exc() The SystemExit except clause is there because it looks like (given its special treatment in call_sys_exitfunc) SystemExit is envisioned as a way of intentionally breaking out of the exithandlers loop. ---------------------------------------------------------------------- Comment By: Skip Montanaro (montanaro) Date: 2004-10-31 19:25 Message: Logged In: YES user_id=44345 Whoops, forgot to attach. Just as well, I also have a small doc fix to include... ---------------------------------------------------------------------- Comment By: Skip Montanaro (montanaro) Date: 2004-10-31 19:16 Message: Logged In: YES user_id=44345 Here's the next version of the patch. It includes the save-the-exception stuff and a rewrite of test_atexit.py using unittest. The only annoyance is that the traceback for the actually raised exception will be printed twice. One way around that might be to wrap the last raise in something like stdout = sys.stdout stderr = sys.stderr sys.stdout = sys.stderr = open(os.devnull, "w") try: raise ... finally: sys.stdout = stdout sys.stderr = stderr though I haven't tested the idea to see if it will actually work. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2004-10-28 14:21 Message: Logged In: YES user_id=80475 This should probably also be kicked around on python-dev so that we arrive at a clear expression of what it means to raise SystemExit and how that differs from os._exit(). One school of thought is that Greg's initial version is correct -- raising SystemExit means get out as fast as you can but not as abruptly as os._exit() so that buffers can be flushed, etc. ---------------------------------------------------------------------- Comment By: Greg Chapman (glchapman) Date: 2004-10-28 10:24 Message: Logged In: YES user_id=86307 > Should we defer it until the loop is complete and reraise it > then? +1 ---------------------------------------------------------------------- Comment By: Skip Montanaro (montanaro) Date: 2004-10-28 06:28 Message: Logged In: YES user_id=44345 Okay, Guido has pronounced. My idea for preserving compatibility is out. Now, I wonder about Greg's SystemExit behavior... Should we defer it until the loop is complete and reraise it then? ---------------------------------------------------------------------- Comment By: Skip Montanaro (montanaro) Date: 2004-10-27 09:44 Message: Logged In: YES user_id=44345 I agree with you in principle, but you'd change behavior and possibly break existing code that relies on the current implicit semantics, hence my suggestion to use a variable to control the behavior, with it set to preserve the current behavior by default. I'll post a request to python-dev soliciting input. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2004-10-27 00:46 Message: Logged In: YES user_id=80475 I prefer the original proposal that leaves the API untouched. Irrespective of ordering, my thought is that all exit handlers are probably expected to run (needed for important cleanup, resource freeing, etc) and may be independent of one another. So, all of them that can run, probably should. ---------------------------------------------------------------------- Comment By: Skip Montanaro (montanaro) Date: 2004-10-24 12:21 Message: Logged In: YES user_id=44345 OTOH, since the ordering of the exit handlers is not guaranteed, exiting after one exception is also reasonable behavior. Attached is a diff that does two things: adds a set_run_all function and converts the functionality into an ExitHandler class to keep from all the different bits of global state. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2004-10-23 19:56 Message: Logged In: YES user_id=80475 This could be considered a bug. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1052242&group_id=5470 From noreply at sourceforge.net Mon Nov 1 11:47:01 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Nov 1 11:47:04 2004 Subject: [ python-Bugs-1058059 ] Can't read some http URLs using neither urllib, nor urllib2 Message-ID: Bugs item #1058059, was opened at 2004-11-01 13:47 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1058059&group_id=5470 Category: Python Library Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Vsevolod Novikov (nnseva) Assigned to: Nobody/Anonymous (nobody) Summary: Can't read some http URLs using neither urllib, nor urllib2 Initial Comment: HTTP connection maden by urllib, as well as by urllib2, on some URL sleeps forever (until timeout happens) on reading from the socket. The popular Linux 'wget' utility behaviour is the same. The Mozilla browser, as well as Internet Explorer browser read this URL successfully, over proxy, as well as directly. The example URL is: http://nds.nokia.com/uaprof/N3510ir100.xml The example code is: import urllib2 u = urllib2.urlopen('http://nds.nokia.com/uaprof/N3510ir100.xml') print u.info() print '-------------' for l in u : print l The urllib library does the same. Info list was (on the moment when I tried it last time): Accept-Ranges: bytes Date: Mon, 01 Nov 2004 10:29:58 GMT Content-Length: 9710 Content-Type: text/plain Cache-Control: no-cache Server: Netscape-Enterprise/4.1 X-WR-FLAGS: CCHOMode=7200:0:force Etag: "acbd4f76-6-25ee-40910c98" Last-modified: Thu, 29 Apr 2004 14:09:28 GMT Via: 1.1 saec-nokp02ca (NetCache NetApp/5.3.1R2) I have no idea why it happens. May be, the HTTP server waits some additional headers? In any case, it is not a good behaviour of the library, I think. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1058059&group_id=5470 From noreply at sourceforge.net Mon Nov 1 12:41:55 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Nov 1 12:42:02 2004 Subject: [ python-Bugs-1057835 ] compiler.transformer, "from module import *" Message-ID: Bugs item #1057835, was opened at 2004-10-31 20:20 Message generated for change (Comment added) made by mwh You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1057835&group_id=5470 Category: Parser/Compiler Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Felix Wiemann (felixwiemann) Assigned to: Nobody/Anonymous (nobody) Summary: compiler.transformer, "from module import *" Initial Comment: import compiler.transformer compiler.transformer.parse('from module import *').getChildNodes()[0].getChildNodes()[0].lineno ... is 1 in Python 2.3 but None in Python 2.4b1. lineno is 1 in Python 2.4 too when passing 'from module import something' instead of 'from module import *'. ---------------------------------------------------------------------- >Comment By: Michael Hudson (mwh) Date: 2004-11-01 11:41 Message: Logged In: YES user_id=6656 I would guess that this is the result of the relatively recent changes to allow multiple line imports, but I don't really have time to play with this right now. Do you have time to work on a fix? If it does prove to be the multiple line import thing, you might want to pester Dima Dorfman -- I think that was his patch... ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1057835&group_id=5470 From noreply at sourceforge.net Mon Nov 1 14:03:14 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Nov 1 14:03:20 2004 Subject: [ python-Bugs-1057835 ] compiler.transformer, "from module import *" Message-ID: Bugs item #1057835, was opened at 2004-10-31 21:20 Message generated for change (Comment added) made by felixwiemann You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1057835&group_id=5470 Category: Parser/Compiler Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Felix Wiemann (felixwiemann) >Assigned to: Jeremy Hylton (jhylton) Summary: compiler.transformer, "from module import *" Initial Comment: import compiler.transformer compiler.transformer.parse('from module import *').getChildNodes()[0].getChildNodes()[0].lineno ... is 1 in Python 2.3 but None in Python 2.4b1. lineno is 1 in Python 2.4 too when passing 'from module import something' instead of 'from module import *'. ---------------------------------------------------------------------- >Comment By: Felix Wiemann (felixwiemann) Date: 2004-11-01 14:03 Message: Logged In: YES user_id=1014490 I neither have time nor knowledge to fix it, but it seems that the error was introduced in rev. 1.45 of transformer.py. The author of rev. 1.45 is jhylton, applying patch #1015989. Assigned this bug to him. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2004-11-01 12:41 Message: Logged In: YES user_id=6656 I would guess that this is the result of the relatively recent changes to allow multiple line imports, but I don't really have time to play with this right now. Do you have time to work on a fix? If it does prove to be the multiple line import thing, you might want to pester Dima Dorfman -- I think that was his patch... ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1057835&group_id=5470 From noreply at sourceforge.net Mon Nov 1 14:33:32 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Nov 1 14:33:41 2004 Subject: [ python-Bugs-1057835 ] compiler.transformer, "from module import *" Message-ID: Bugs item #1057835, was opened at 2004-10-31 20:20 Message generated for change (Comment added) made by mwh You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1057835&group_id=5470 Category: Parser/Compiler Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Felix Wiemann (felixwiemann) Assigned to: Jeremy Hylton (jhylton) Summary: compiler.transformer, "from module import *" Initial Comment: import compiler.transformer compiler.transformer.parse('from module import *').getChildNodes()[0].getChildNodes()[0].lineno ... is 1 in Python 2.3 but None in Python 2.4b1. lineno is 1 in Python 2.4 too when passing 'from module import something' instead of 'from module import *'. ---------------------------------------------------------------------- >Comment By: Michael Hudson (mwh) Date: 2004-11-01 13:33 Message: Logged In: YES user_id=6656 Hmm, consider the attached. It fixes the immediate issue, and doesn't seem to break test_compiler. I'd commit it, but it's so obvious that I'm wondering why Jeremy didn't do this in the first place: either I'm missing something a little subtle, or Jeremy missed something really obvious :) ---------------------------------------------------------------------- Comment By: Felix Wiemann (felixwiemann) Date: 2004-11-01 13:03 Message: Logged In: YES user_id=1014490 I neither have time nor knowledge to fix it, but it seems that the error was introduced in rev. 1.45 of transformer.py. The author of rev. 1.45 is jhylton, applying patch #1015989. Assigned this bug to him. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2004-11-01 11:41 Message: Logged In: YES user_id=6656 I would guess that this is the result of the relatively recent changes to allow multiple line imports, but I don't really have time to play with this right now. Do you have time to work on a fix? If it does prove to be the multiple line import thing, you might want to pester Dima Dorfman -- I think that was his patch... ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1057835&group_id=5470 From noreply at sourceforge.net Mon Nov 1 14:37:02 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Nov 1 14:37:12 2004 Subject: [ python-Bugs-1058059 ] Can't read some http URLs using neither urllib, nor urllib2 Message-ID: Bugs item #1058059, was opened at 2004-11-01 11:47 Message generated for change (Comment added) made by doerwalter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1058059&group_id=5470 Category: Python Library Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Vsevolod Novikov (nnseva) Assigned to: Nobody/Anonymous (nobody) Summary: Can't read some http URLs using neither urllib, nor urllib2 Initial Comment: HTTP connection maden by urllib, as well as by urllib2, on some URL sleeps forever (until timeout happens) on reading from the socket. The popular Linux 'wget' utility behaviour is the same. The Mozilla browser, as well as Internet Explorer browser read this URL successfully, over proxy, as well as directly. The example URL is: http://nds.nokia.com/uaprof/N3510ir100.xml The example code is: import urllib2 u = urllib2.urlopen('http://nds.nokia.com/uaprof/N3510ir100.xml') print u.info() print '-------------' for l in u : print l The urllib library does the same. Info list was (on the moment when I tried it last time): Accept-Ranges: bytes Date: Mon, 01 Nov 2004 10:29:58 GMT Content-Length: 9710 Content-Type: text/plain Cache-Control: no-cache Server: Netscape-Enterprise/4.1 X-WR-FLAGS: CCHOMode=7200:0:force Etag: "acbd4f76-6-25ee-40910c98" Last-modified: Thu, 29 Apr 2004 14:09:28 GMT Via: 1.1 saec-nokp02ca (NetCache NetApp/5.3.1R2) I have no idea why it happens. May be, the HTTP server waits some additional headers? In any case, it is not a good behaviour of the library, I think. ---------------------------------------------------------------------- >Comment By: Walter D?rwald (doerwalter) Date: 2004-11-01 14:37 Message: Logged In: YES user_id=89016 Work here without any problems: Python 2.3.4 (#2, Sep 29 2004, 18:56:11) [GCC 2.96 20000731 (Red Hat Linux 7.3 2.96-113)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> import urllib >>> d = urllib.urlopen ("http://nds.nokia.com/uaprof/N3510ir100.xml").read() >>> len(d) 9710 >>> d[:30] '\n goahead() identifies the next interesting part of the page as the inside the javascript. It's not seeing the comment. Should it? I changed interesting_cdata to lookup for Bugs item #1075934, was opened at 2004-11-30 11:47 Message generated for change (Comment added) made by whitingjr You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1075934&group_id=5470 Category: Build Group: Python 2.3 >Status: Closed >Resolution: Invalid Priority: 5 Submitted By: Jeremy Whiting (whitingjr) Assigned to: Nobody/Anonymous (nobody) Summary: Build Bug on Solaris. Initial Comment: Getting an error when running the configure script. ---------------------------------------------------------------------- >Comment By: Jeremy Whiting (whitingjr) Date: 2004-11-30 17:08 Message: Logged In: YES user_id=689952 This is not a bug. The root cause of the errors in the submitted log file were due to an incomplete extraction of the tar file. Tar directory checksum error. ---------------------------------------------------------------------- Comment By: Johannes Gijsbers (jlgijsbers) Date: 2004-11-30 12:10 Message: Logged In: YES user_id=469548 We're going to need some more information to reproduce this problem. What Python version is this with? If it's Python 2.3, can you reproduce it with Python 2.4? If you can reproduce this with 2.4, what exactly is the error you're seeing? Could you attach the config.log file to give us more information? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1075934&group_id=5470 From noreply at sourceforge.net Tue Nov 30 19:12:58 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Tue Nov 30 19:13:01 2004 Subject: [ python-Bugs-1073790 ] subprocess.py doc bug in 2.4c1 Message-ID: Bugs item #1073790, was opened at 2004-11-26 16:14 Message generated for change (Comment added) made by astrand You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1073790&group_id=5470 Category: Documentation Group: Python 2.4 >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Dan Christensen (jdc) Assigned to: Nobody/Anonymous (nobody) Summary: subprocess.py doc bug in 2.4c1 Initial Comment: This example from subprocess.py: Replacing shell pipe line ------------------------- output=`dmesg | grep hda` ==> p1 = Popen(["dmesg"], stdout=PIPE) p2 = Popen(["grep", "hda"], stdin=p1.stdout) output = p2.communicate()[0] needs to have stdout=PIPE added to the second Popen call. The same error occurs in PEP 324. Dan ---------------------------------------------------------------------- >Comment By: Peter ?strand (astrand) Date: 2004-11-30 19:12 Message: Logged In: YES user_id=344921 Fixed in trunk: libsubprocess.tex 1.3 subprocess.py 1.9 pep-0324.txt 1.7 Fixed in branch: libsubprocess.tex 1.2.2.1 subprocess.py 1.8.2.1 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1073790&group_id=5470 From noreply at sourceforge.net Tue Nov 30 20:53:22 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Tue Nov 30 20:53:26 2004 Subject: [ python-Bugs-1076233 ] distutils.core.setup() with unicode arguments broken Message-ID: Bugs item #1076233, was opened at 2004-11-30 20:53 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1076233&group_id=5470 Category: Distutils Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Walter D?rwald (doerwalter) Assigned to: Thomas Heller (theller) Summary: distutils.core.setup() with unicode arguments broken Initial Comment: When using unicode arguments for distutils.core.setup() running setup.py breaks with the following exception: Traceback (most recent call last): ... \Lib\distutils\command\sdist.py", line 430, in make_release_tree self.distribution.metadata.write_pkg_info(base_dir) File "C:\Programme\Python24\Lib\distutils\dist.py", line 1047, in write_pkg_info pkg_info.write('Author: %s\n' % self.get_contact() ) UnicodeEncodeError: 'ascii' codec can't encode character u'\xf6' in position 16: ordinal not in range(128) Changing the system default encoding to iso-8859-1 works around this problem. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1076233&group_id=5470 From noreply at sourceforge.net Tue Nov 30 21:13:26 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Tue Nov 30 21:13:32 2004 Subject: [ python-Bugs-1076233 ] distutils.core.setup() with unicode arguments broken Message-ID: Bugs item #1076233, was opened at 2004-11-30 20:53 Message generated for change (Comment added) made by theller You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1076233&group_id=5470 Category: Distutils Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Walter D?rwald (doerwalter) >Assigned to: A.M. Kuchling (akuchling) Summary: distutils.core.setup() with unicode arguments broken Initial Comment: When using unicode arguments for distutils.core.setup() running setup.py breaks with the following exception: Traceback (most recent call last): ... \Lib\distutils\command\sdist.py", line 430, in make_release_tree self.distribution.metadata.write_pkg_info(base_dir) File "C:\Programme\Python24\Lib\distutils\dist.py", line 1047, in write_pkg_info pkg_info.write('Author: %s\n' % self.get_contact() ) UnicodeEncodeError: 'ascii' codec can't encode character u'\xf6' in position 16: ordinal not in range(128) Changing the system default encoding to iso-8859-1 works around this problem. ---------------------------------------------------------------------- >Comment By: Thomas Heller (theller) Date: 2004-11-30 21:13 Message: Logged In: YES user_id=11105 I'm unusure about the allowed encoding in PKG-INFO, and I cannot find anything in PEP 241. Andrew, since you are listed as the author, can you comment? bdist_wininst does accept unicode strings, and that may be the reason that walter expects this to work for sdist also... ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1076233&group_id=5470 From noreply at sourceforge.net Tue Nov 30 23:21:50 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Tue Nov 30 23:21:54 2004 Subject: [ python-Bugs-1072623 ] FeedParser problem on end boundaries w/o newline Message-ID: Bugs item #1072623, was opened at 2004-11-24 12:27 Message generated for change (Comment added) made by bwarsaw You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1072623&group_id=5470 Category: Python Library Group: Python 2.4 Status: Closed Resolution: Wont Fix Priority: 5 Submitted By: Tessa Lau (tlau) Assigned to: Barry A. Warsaw (bwarsaw) Summary: FeedParser problem on end boundaries w/o newline Initial Comment: (Python 2.3.4, Linux Debian unstable) The email module's as_string() method generates messages that do not include a trailing CRLF on the last line. This causes problems when Python-created messages are piped to procmail and delivered to an mbox. The attached test script illustrates this behavior. You must have a working procmail configured to deliver mail to an mbox (the default configuration will work). If you then read the resulting mailbox with /bin/mail, it appears as if there is only one message in the mailbox, instead of two. The second is concatenated on to the end of the first. The mbox does not contain a blank line between the first message and the second. Pop servers require this blank line delimiter between messages. You could argue that this is procmail's responsibility, but as far as I can tell from reading RFC 2822, each line in an email message must terminate in CRLF, and Python's email module is violating that spec. ---------------------------------------------------------------------- >Comment By: Barry A. Warsaw (bwarsaw) Date: 2004-11-30 17:21 Message: Logged In: YES user_id=12800 Yep, it was someone else's posting, sorry about that. As for the trailing newline on non-MIME messages, you will need to make sure that your payload is terminated with a newline. Generator won't do that on the basis that maintaining idempotency (what goes in equals what goes out) is more important. ---------------------------------------------------------------------- Comment By: Tessa Lau (tlau) Date: 2004-11-29 08:23 Message: Logged In: YES user_id=112896 It must have been someone else on the email sig; I haven't posted there recently. Thanks for the workaround. However, it only fixes the problem for MIME messages, but not for non-MIME messages. The second message constructed in my test script still lacks a trailing newline. I can work around it after the message is generated by checking for a final newline on the string and adding it if it's missing, but that seems clunky. ---------------------------------------------------------------------- Comment By: Barry A. Warsaw (bwarsaw) Date: 2004-11-28 20:10 Message: Logged In: YES user_id=12800 I must have been thinking about the message you posted to the email sig, which uncovered the bug I commented on, and fixed. In the case of the original bug report, I don't believe this is fixable. There is, however a simple workaround for you. In your sample code, set the outer message's epilogue to the empty string, e.g.: msg1.epilogue = '' ... msg2.epilogue = '' This will cause the Generator to add a newline at the end of the outer message. We can't make that change in the Message class because doing so would break inner message flattening. However, if someone were to come up with a patch that fixes this problem yet doesn't break any of the 217 tests in the current test suite, I'd be happy to look at it. As it is, nothing will be changed for Python 2.4. final. ---------------------------------------------------------------------- Comment By: Tessa Lau (tlau) Date: 2004-11-27 19:45 Message: Logged In: YES user_id=112896 My original bugreport had to do with email generation, not parsing. Python seems to be generating email that is not compliant with the RFC spec. In my situation, parsing is done by 3rd party programs (procmail and /bin/mail) which also fail to deal gracefully with the lack of trailing newline. ---------------------------------------------------------------------- Comment By: Barry A. Warsaw (bwarsaw) Date: 2004-11-27 19:03 Message: Logged In: YES user_id=12800 Changing the summary of this issue to reflect the real problem. The attachment 1072623.py illustrates that if the end boundary of a string being parsed by the FeedParser does not have a trailing newline, the parser doesn't recognize this as an end boundary. It just so happens that your example produces a message string with that property (which isn't a bug). The fix is about as trivial as you can get: one character. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1072623&group_id=5470