From report at bugs.python.org Mon Oct 1 02:50:09 2007 From: report at bugs.python.org (Richie Ward) Date: Mon, 01 Oct 2007 00:50:09 -0000 Subject: [issue1223] httplib does not handle ssl end of file properly Message-ID: <1191199809.02.0.233978380017.issue1223@psf.upfronthosting.co.za> New submission from Richie Ward: I was using httplib to power my xml rpc script. I had problems when I wanted to use SSL and I got this error: File "/usr/lib/python2.5/httplib.py", line 1109, in recv return self._ssl.read(len) socket.sslerror: (8, 'EOF occurred in violation of protocol') I figured out this was because of poor error handling in python. May I suggest this as a fix to this bug: $ diff /usr/lib/python2.5/httplib.py /usr/lib/python2.5/httplib.py~ 1109,1112c1109 < try: < return self._ssl.read(len) < except socket.sslerror: < return --- > return self._ssl.read(len) Just a note. I am by no means a python expert, just good enough to get my work done. I use Ubuntu gutsy. ---------- components: Library (Lib) messages: 56203 nosy: Richie severity: major status: open title: httplib does not handle ssl end of file properly type: crash versions: Python 2.6 __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Oct 1 02:50:09 2007 From: report at bugs.python.org (Richie Ward) Date: Mon, 01 Oct 2007 00:50:09 -0000 Subject: [issue1223] httplib does not handle ssl end of file properly Message-ID: <1191199809.02.0.233978380017.issue1223@psf.upfronthosting.co.za> New submission from Richie Ward: I was using httplib to power my xml rpc script. I had problems when I wanted to use SSL and I got this error: File "/usr/lib/python2.5/httplib.py", line 1109, in recv return self._ssl.read(len) socket.sslerror: (8, 'EOF occurred in violation of protocol') I figured out this was because of poor error handling in python. May I suggest this as a fix to this bug: $ diff /usr/lib/python2.5/httplib.py /usr/lib/python2.5/httplib.py~ 1109,1112c1109 < try: < return self._ssl.read(len) < except socket.sslerror: < return --- > return self._ssl.read(len) Just a note. I am by no means a python expert, just good enough to get my work done. I use Ubuntu gutsy. ---------- components: Library (Lib) messages: 56203 nosy: Richie severity: major status: open title: httplib does not handle ssl end of file properly type: crash versions: Python 2.6 __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Oct 1 02:51:12 2007 From: report at bugs.python.org (Richie Ward) Date: Mon, 01 Oct 2007 00:51:12 -0000 Subject: [issue1223] httplib does not handle ssl end of file properly Message-ID: <1191199872.55.0.601544623139.issue1223@psf.upfronthosting.co.za> Changes by Richie Ward: ---------- versions: +Python 2.5 -Python 2.6 __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Oct 1 13:10:48 2007 From: report at bugs.python.org (philfr) Date: Mon, 01 Oct 2007 11:10:48 -0000 Subject: [issue1394565] SimpleHTTPServer doesn't understand query arguments Message-ID: <1191237048.36.0.810413937307.issue1394565@psf.upfronthosting.co.za> philfr added the comment: This fix introduces a nasty side-effect: "GET http://server//file" (with two /s) does not work anymore. It returns the directory index instead. This is because urlparse is not applied to an URL, but to its right-hand part starting at the path. urlparse.urlparse("http://server//foo")[2] correctly returns //foo, but urlparse.urlparse("//foo")[2] (as used in this library) returns an empty string. So the first proposed fix (msg27195) would be better. Or maybe this is an urlparse issue, so that it should be able to process such a partial url. ---------- nosy: +philfr _____________________________________ Tracker _____________________________________ From report at bugs.python.org Mon Oct 1 13:20:26 2007 From: report at bugs.python.org (philfr) Date: Mon, 01 Oct 2007 11:20:26 -0000 Subject: [issue1224] SimpleHTTPServer doesn't understand // at beginning of path anymore Message-ID: <1191237626.38.0.0266691685704.issue1224@psf.upfronthosting.co.za> New submission from philfr: The fix to issue 1394565 introduces a nasty side-effect: "GET http://server//file" (with two /s) does not work anymore. It returns the directory index instead. This is because urlparse is not applied to an URL, but to its right-hand part starting at the path. urlparse.urlparse("http://server//foo")[2] correctly returns //foo, but urlparse.urlparse("//foo")[2] (as used in this library) returns an empty string. ---------- components: Library (Lib) messages: 56205 nosy: philfr severity: normal status: open title: SimpleHTTPServer doesn't understand // at beginning of path anymore type: behavior versions: Python 2.4, Python 2.5 __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Oct 1 13:20:26 2007 From: report at bugs.python.org (philfr) Date: Mon, 01 Oct 2007 11:20:26 -0000 Subject: [issue1224] SimpleHTTPServer doesn't understand // at beginning of path anymore Message-ID: <1191237626.38.0.0266691685704.issue1224@psf.upfronthosting.co.za> New submission from philfr: The fix to issue 1394565 introduces a nasty side-effect: "GET http://server//file" (with two /s) does not work anymore. It returns the directory index instead. This is because urlparse is not applied to an URL, but to its right-hand part starting at the path. urlparse.urlparse("http://server//foo")[2] correctly returns //foo, but urlparse.urlparse("//foo")[2] (as used in this library) returns an empty string. ---------- components: Library (Lib) messages: 56205 nosy: philfr severity: normal status: open title: SimpleHTTPServer doesn't understand // at beginning of path anymore type: behavior versions: Python 2.4, Python 2.5 __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Oct 1 14:07:23 2007 From: report at bugs.python.org (philfr) Date: Mon, 01 Oct 2007 12:07:23 -0000 Subject: [issue1394565] SimpleHTTPServer doesn't understand query arguments Message-ID: <1191240443.29.0.0211601935182.issue1394565@psf.upfronthosting.co.za> philfr added the comment: I created the new issue 1224 for this. _____________________________________ Tracker _____________________________________ From report at bugs.python.org Mon Oct 1 14:15:24 2007 From: report at bugs.python.org (philfr) Date: Mon, 01 Oct 2007 12:15:24 -0000 Subject: [issue1224] SimpleHTTPServer doesn't understand // at beginning of path anymore Message-ID: <1191240923.92.0.130371208003.issue1224@psf.upfronthosting.co.za> philfr added the comment: May I suggest replacing the path = urlparse.urlparse(path)[2] line with the following two: path = path.split('?',1)[0] path = path.split('#',1)[0] thereby handling parameters as well as fragments. __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Oct 1 20:33:18 2007 From: report at bugs.python.org (Brett Cannon) Date: Mon, 01 Oct 2007 18:33:18 -0000 Subject: [issue1223] httplib does not handle ssl end of file properly Message-ID: <1191263598.64.0.283781467446.issue1223@psf.upfronthosting.co.za> Brett Cannon added the comment: Patch is inlined in the opening comment for the issue. ---------- keywords: +patch nosy: +brett.cannon type: crash -> behavior __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Oct 1 22:18:00 2007 From: report at bugs.python.org (Tal Einat) Date: Mon, 01 Oct 2007 20:18:00 -0000 Subject: [issue1225] IDLE - Fix: pressing Ctrl+C while printing exception -> stuck Message-ID: <1191269880.22.0.587814437498.issue1225@psf.upfronthosting.co.za> New submission from Tal Einat: Patch run.py, adding a global 'interruptable' flag which is set only when executing code. This avoids interrupting the main thread while it is printing an exception, which would cause IDLE to freeze up. Reworked patch from IDLE-Spoon. ---------- components: IDLE files: IDLE_Interrupt.071001.patch messages: 56209 nosy: kbk, taleinat severity: normal status: open title: IDLE - Fix: pressing Ctrl+C while printing exception -> stuck type: crash versions: Python 2.5, Python 2.6 __________________________________ Tracker __________________________________ -------------- next part -------------- A non-text attachment was scrubbed... Name: IDLE_Interrupt.071001.patch Type: application/octet-stream Size: 1348 bytes Desc: not available Url : http://mail.python.org/pipermail/python-bugs-list/attachments/20071001/5d319720/attachment.obj From report at bugs.python.org Mon Oct 1 22:18:00 2007 From: report at bugs.python.org (Tal Einat) Date: Mon, 01 Oct 2007 20:18:00 -0000 Subject: [issue1225] IDLE - Fix: pressing Ctrl+C while printing exception -> stuck Message-ID: <1191269880.22.0.587814437498.issue1225@psf.upfronthosting.co.za> New submission from Tal Einat: Patch run.py, adding a global 'interruptable' flag which is set only when executing code. This avoids interrupting the main thread while it is printing an exception, which would cause IDLE to freeze up. Reworked patch from IDLE-Spoon. ---------- components: IDLE files: IDLE_Interrupt.071001.patch messages: 56209 nosy: kbk, taleinat severity: normal status: open title: IDLE - Fix: pressing Ctrl+C while printing exception -> stuck type: crash versions: Python 2.5, Python 2.6 __________________________________ Tracker __________________________________ -------------- next part -------------- A non-text attachment was scrubbed... Name: IDLE_Interrupt.071001.patch Type: application/octet-stream Size: 1348 bytes Desc: not available Url : http://mail.python.org/pipermail/python-bugs-list/attachments/20071001/5d319720/attachment-0001.obj From report at bugs.python.org Tue Oct 2 00:12:59 2007 From: report at bugs.python.org (lorph) Date: Mon, 01 Oct 2007 22:12:59 -0000 Subject: [issue1226] lib/sched.py superfluous code for removal Message-ID: <1191276779.49.0.11926162245.issue1226@psf.upfronthosting.co.za> New submission from lorph: Line 114 of lib/sched.py: It has a superfluous variable assignment which I deleted. "void =" ---------- components: Library (Lib) files: sched.py messages: 56210 nosy: lorph severity: normal status: open title: lib/sched.py superfluous code for removal versions: Python 2.5 __________________________________ Tracker __________________________________ -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: sched.py Url: http://mail.python.org/pipermail/python-bugs-list/attachments/20071001/05cd9445/attachment-0001.txt From report at bugs.python.org Tue Oct 2 00:12:59 2007 From: report at bugs.python.org (lorph) Date: Mon, 01 Oct 2007 22:12:59 -0000 Subject: [issue1226] lib/sched.py superfluous code for removal Message-ID: <1191276779.49.0.11926162245.issue1226@psf.upfronthosting.co.za> New submission from lorph: Line 114 of lib/sched.py: It has a superfluous variable assignment which I deleted. "void =" ---------- components: Library (Lib) files: sched.py messages: 56210 nosy: lorph severity: normal status: open title: lib/sched.py superfluous code for removal versions: Python 2.5 __________________________________ Tracker __________________________________ -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: sched.py Url: http://mail.python.org/pipermail/python-bugs-list/attachments/20071001/05cd9445/attachment-0002.txt From report at bugs.python.org Tue Oct 2 00:16:47 2007 From: report at bugs.python.org (lorph) Date: Mon, 01 Oct 2007 22:16:47 -0000 Subject: [issue1226] lib/sched.py superfluous code for removal Message-ID: <1191277007.02.0.529177400108.issue1226@psf.upfronthosting.co.za> Changes by lorph: ---------- severity: normal -> minor type: -> resource usage __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Oct 2 06:00:57 2007 From: report at bugs.python.org (Dean Elzinga) Date: Tue, 02 Oct 2007 04:00:57 -0000 Subject: [issue1227] csv docs say 'excel_tab'; code says 'excel-tab' Message-ID: <1191297657.28.0.047850025382.issue1227@psf.upfronthosting.co.za> New submission from Dean Elzinga: I was trying out 'csv module' and noticed that it wouldn't accept a dialect of 'excel_tab' as documented. Then I noticed that csv.list_dialects() gave 'excel-tab' instead of 'excel_tab' as documented. I'm not sure which one it's supposed to be, but I guess when in doubt the docs are wrong. I leave these issues to the higher gods. Thanks for the work on this module. I'm enjoying it! ---------- components: Library (Lib) messages: 56211 nosy: dcelzinga severity: normal status: open title: csv docs say 'excel_tab'; code says 'excel-tab' type: behavior versions: Python 2.5 __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Oct 2 06:00:57 2007 From: report at bugs.python.org (Dean Elzinga) Date: Tue, 02 Oct 2007 04:00:57 -0000 Subject: [issue1227] csv docs say 'excel_tab'; code says 'excel-tab' Message-ID: <1191297657.28.0.047850025382.issue1227@psf.upfronthosting.co.za> New submission from Dean Elzinga: I was trying out 'csv module' and noticed that it wouldn't accept a dialect of 'excel_tab' as documented. Then I noticed that csv.list_dialects() gave 'excel-tab' instead of 'excel_tab' as documented. I'm not sure which one it's supposed to be, but I guess when in doubt the docs are wrong. I leave these issues to the higher gods. Thanks for the work on this module. I'm enjoying it! ---------- components: Library (Lib) messages: 56211 nosy: dcelzinga severity: normal status: open title: csv docs say 'excel_tab'; code says 'excel-tab' type: behavior versions: Python 2.5 __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Oct 2 13:06:01 2007 From: report at bugs.python.org (Peter Harris) Date: Tue, 02 Oct 2007 11:06:01 -0000 Subject: [issue1228] 3.0 tutorial/datastructures.rst patch Message-ID: <1191323161.32.0.788798026537.issue1228@psf.upfronthosting.co.za> New submission from Peter Harris: Describe 3.0 comparison behaviour (but not in much detail) ---------- components: Documentation files: datastructures.diff messages: 56212 nosy: scav severity: normal status: open title: 3.0 tutorial/datastructures.rst patch versions: Python 3.0 __________________________________ Tracker __________________________________ -------------- next part -------------- A non-text attachment was scrubbed... Name: datastructures.diff Type: application/octet-stream Size: 1157 bytes Desc: not available Url : http://mail.python.org/pipermail/python-bugs-list/attachments/20071002/3bc13b37/attachment.obj From report at bugs.python.org Tue Oct 2 13:06:01 2007 From: report at bugs.python.org (Peter Harris) Date: Tue, 02 Oct 2007 11:06:01 -0000 Subject: [issue1228] 3.0 tutorial/datastructures.rst patch Message-ID: <1191323161.32.0.788798026537.issue1228@psf.upfronthosting.co.za> New submission from Peter Harris: Describe 3.0 comparison behaviour (but not in much detail) ---------- components: Documentation files: datastructures.diff messages: 56212 nosy: scav severity: normal status: open title: 3.0 tutorial/datastructures.rst patch versions: Python 3.0 __________________________________ Tracker __________________________________ -------------- next part -------------- A non-text attachment was scrubbed... Name: datastructures.diff Type: application/octet-stream Size: 1157 bytes Desc: not available Url : http://mail.python.org/pipermail/python-bugs-list/attachments/20071002/3bc13b37/attachment-0001.obj From report at bugs.python.org Tue Oct 2 13:12:04 2007 From: report at bugs.python.org (Peter Harris) Date: Tue, 02 Oct 2007 11:12:04 -0000 Subject: [issue1229] 3.0 library/stdtypes.rst Message-ID: <1191323524.35.0.925963615426.issue1229@psf.upfronthosting.co.za> New submission from Peter Harris: line 221 'loating point' -> 'Floating point'. Also, maybe double-check that __cmp__ method still has special meaning in 3.0. My last patch took out mention of it because 3.0a1 seems not to support comparisons using __cmp__ method, but I could be missing something. ---------- components: Documentation messages: 56213 nosy: scav severity: minor status: open title: 3.0 library/stdtypes.rst versions: Python 3.0 __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Oct 2 13:12:04 2007 From: report at bugs.python.org (Peter Harris) Date: Tue, 02 Oct 2007 11:12:04 -0000 Subject: [issue1229] 3.0 library/stdtypes.rst Message-ID: <1191323524.35.0.925963615426.issue1229@psf.upfronthosting.co.za> New submission from Peter Harris: line 221 'loating point' -> 'Floating point'. Also, maybe double-check that __cmp__ method still has special meaning in 3.0. My last patch took out mention of it because 3.0a1 seems not to support comparisons using __cmp__ method, but I could be missing something. ---------- components: Documentation messages: 56213 nosy: scav severity: minor status: open title: 3.0 library/stdtypes.rst versions: Python 3.0 __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Oct 2 17:14:27 2007 From: report at bugs.python.org (Skip Montanaro) Date: Tue, 02 Oct 2007 15:14:27 -0000 Subject: [issue1227] csv docs say 'excel_tab'; code says 'excel-tab' Message-ID: <1191338067.83.0.817676070431.issue1227@psf.upfronthosting.co.za> Skip Montanaro added the comment: The string name of the dialect is "excel-tab". Hyphens are not valid characters in identifiers though, so the actual object is named "excel_tab". When you call csv.get_dialect("excel-tab") it instantiates the csv.excel_tab class and returns that: >>> csv.list_dialects() ['excel-tab', 'excel'] >>> csv.get_dialect("excel-tab") >>> csv.excel_tab >>> csv.get_dialect("excel-tab").__class__ == csv.excel_tab True ---------- assignee: -> skip.montanaro nosy: +skip.montanaro resolution: -> works for me status: open -> closed __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Oct 2 18:09:56 2007 From: report at bugs.python.org (Dean Elzinga) Date: Tue, 02 Oct 2007 16:09:56 -0000 Subject: [issue1227] csv docs say 'excel_tab'; code says 'excel-tab' In-Reply-To: <1191338067.83.0.817676070431.issue1227@psf.upfronthosting.co.za> Message-ID: <007f01c8050e$9f2f7e30$dd8e7a90$@com> Dean Elzinga added the comment: Ohh! Thanks for the clarification. Sorry for the misunderstanding. > -----Original Message----- > From: Skip Montanaro [mailto:report at bugs.python.org] > Sent: Tuesday, October 02, 2007 8:14 AM > To: dcelzinga at gmail.com > Subject: [issue1227] csv docs say 'excel_tab'; code says > 'excel-tab' > > > Skip Montanaro added the comment: > > The string name of the dialect is "excel-tab". Hyphens > are not > valid characters in identifiers though, so the actual > object > is named "excel_tab". When you call > csv.get_dialect("excel-tab") > it instantiates the csv.excel_tab class and returns that: > > >>> csv.list_dialects() > ['excel-tab', 'excel'] > >>> csv.get_dialect("excel-tab") > > >>> csv.excel_tab > > >>> csv.get_dialect("excel-tab").__class__ == > csv.excel_tab > True > > ---------- > assignee: -> skip.montanaro > nosy: +skip.montanaro > resolution: -> works for me > status: open -> closed > > __________________________________ > Tracker > > __________________________________ __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Oct 2 18:18:59 2007 From: report at bugs.python.org (Bill Janssen) Date: Tue, 02 Oct 2007 16:18:59 -0000 Subject: [issue1203] ctypes doesn't work on Mac with --disable-toolbox-glue In-Reply-To: <1190747772.87.0.458261693853.issue1203@psf.upfronthosting.co.za> Message-ID: <4b3e516a0710020918p2f80c573uaa7f54a2c062e5d8@mail.gmail.com> Bill Janssen added the comment: Yes, that works too. It seems to be another way of accessing the same information; it's not clear to me which is preferable. Bill On 9/25/07, Thomas Heller wrote: > > Thomas Heller added the comment: > > This patch looks better. However, the 'os.uname()' function seems to > return the information that we need; so I updated the patch to use this > instead. Can you please proofread it (osx.patch) ? > > __________________________________ > Tracker > > __________________________________ > __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Oct 2 21:29:02 2007 From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=) Date: Tue, 02 Oct 2007 19:29:02 -0000 Subject: [issue1228] 3.0 tutorial/datastructures.rst patch Message-ID: <1191353342.39.0.961352272695.issue1228@psf.upfronthosting.co.za> Changes by Martin v. L?wis: ---------- keywords: +patch __________________________________ Tracker __________________________________ From report at bugs.python.org Wed Oct 3 14:06:55 2007 From: report at bugs.python.org (Ron Longo) Date: Wed, 03 Oct 2007 12:06:55 -0000 Subject: [issue1230] Tix HList class missing method implementation for info_bbox Message-ID: <1191413215.63.0.728222035482.issue1230@psf.upfronthosting.co.za> Changes by Ron Longo: ---------- components: Tkinter severity: normal status: open title: Tix HList class missing method implementation for info_bbox type: behavior versions: Python 2.6 __________________________________ Tracker __________________________________ From report at bugs.python.org Wed Oct 3 16:47:32 2007 From: report at bugs.python.org (Raghuram Devarakonda) Date: Wed, 03 Oct 2007 14:47:32 -0000 Subject: [issue1231] PEPs 344 and 3134 contain incorrect hyperlinks. Message-ID: <1191422851.65.0.253135139161.issue1231@psf.upfronthosting.co.za> New submission from Raghuram Devarakonda: http://www.python.org/dev/peps/pep-0344/ http://www.python.org/dev/peps/pep-3134/ Check both the PEPs and grep for the first occurrence of "RFC 88" which is a link. The target of the link is http://www.faqs.org/rfcs/rfc88.html which is wrong. The correct value is indicated in footnote [9]. ---------- components: Documentation messages: 56217 nosy: draghuram severity: minor status: open title: PEPs 344 and 3134 contain incorrect hyperlinks. __________________________________ Tracker __________________________________ From report at bugs.python.org Wed Oct 3 16:47:31 2007 From: report at bugs.python.org (Raghuram Devarakonda) Date: Wed, 03 Oct 2007 14:47:31 -0000 Subject: [issue1231] PEPs 344 and 3134 contain incorrect hyperlinks. Message-ID: <1191422851.65.0.253135139161.issue1231@psf.upfronthosting.co.za> New submission from Raghuram Devarakonda: http://www.python.org/dev/peps/pep-0344/ http://www.python.org/dev/peps/pep-3134/ Check both the PEPs and grep for the first occurrence of "RFC 88" which is a link. The target of the link is http://www.faqs.org/rfcs/rfc88.html which is wrong. The correct value is indicated in footnote [9]. ---------- components: Documentation messages: 56217 nosy: draghuram severity: minor status: open title: PEPs 344 and 3134 contain incorrect hyperlinks. __________________________________ Tracker __________________________________ From report at bugs.python.org Wed Oct 3 18:36:04 2007 From: report at bugs.python.org (Kevin McKiou) Date: Wed, 03 Oct 2007 16:36:04 -0000 Subject: [issue1232] %f prints the wrong 6 decimal places Message-ID: <1191429364.71.0.660375750345.issue1232@psf.upfronthosting.co.za> New submission from Kevin McKiou: >>> print "price is: %f" % 5.1234567 price is: 5.123457 I was testing the statement about "prints to 6 decimal places". Sure enough, it printed only 6 decimal places, but it skipped over the 6th decimal place and printed the 7th. I am using Python version 2.5.1 and IDLE version 1.2.1 ---------- components: Interpreter Core messages: 56218 nosy: kmckiou severity: major status: open title: %f prints the wrong 6 decimal places type: behavior versions: Python 2.5 __________________________________ Tracker __________________________________ From report at bugs.python.org Wed Oct 3 18:36:05 2007 From: report at bugs.python.org (Kevin McKiou) Date: Wed, 03 Oct 2007 16:36:05 -0000 Subject: [issue1232] %f prints the wrong 6 decimal places Message-ID: <1191429364.71.0.660375750345.issue1232@psf.upfronthosting.co.za> New submission from Kevin McKiou: >>> print "price is: %f" % 5.1234567 price is: 5.123457 I was testing the statement about "prints to 6 decimal places". Sure enough, it printed only 6 decimal places, but it skipped over the 6th decimal place and printed the 7th. I am using Python version 2.5.1 and IDLE version 1.2.1 ---------- components: Interpreter Core messages: 56218 nosy: kmckiou severity: major status: open title: %f prints the wrong 6 decimal places type: behavior versions: Python 2.5 __________________________________ Tracker __________________________________ From report at bugs.python.org Wed Oct 3 18:45:22 2007 From: report at bugs.python.org (Steven Vereecken) Date: Wed, 03 Oct 2007 16:45:22 -0000 Subject: [issue1233] bsddb.dbshelve.DbShelf.append doesn't work Message-ID: <1191429921.84.0.632330951206.issue1233@psf.upfronthosting.co.za> New submission from Steven Vereecken: The check for DB_RECNO seems to do the opposite of what it's supposed to do: def append(self, value, txn=None): if self.get_type() != db.DB_RECNO: self.append = self.__append return self.append(value, txn=txn) raise db.DBError, "append() only supported when dbshelve opened with filetype=dbshelve.db.DB_RECNO" ---------- components: Library (Lib) messages: 56219 nosy: polaar severity: normal status: open title: bsddb.dbshelve.DbShelf.append doesn't work type: behavior versions: Python 2.5 __________________________________ Tracker __________________________________ From report at bugs.python.org Wed Oct 3 18:45:21 2007 From: report at bugs.python.org (Steven Vereecken) Date: Wed, 03 Oct 2007 16:45:21 -0000 Subject: [issue1233] bsddb.dbshelve.DbShelf.append doesn't work Message-ID: <1191429921.84.0.632330951206.issue1233@psf.upfronthosting.co.za> New submission from Steven Vereecken: The check for DB_RECNO seems to do the opposite of what it's supposed to do: def append(self, value, txn=None): if self.get_type() != db.DB_RECNO: self.append = self.__append return self.append(value, txn=txn) raise db.DBError, "append() only supported when dbshelve opened with filetype=dbshelve.db.DB_RECNO" ---------- components: Library (Lib) messages: 56219 nosy: polaar severity: normal status: open title: bsddb.dbshelve.DbShelf.append doesn't work type: behavior versions: Python 2.5 __________________________________ Tracker __________________________________ From report at bugs.python.org Wed Oct 3 18:53:02 2007 From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=) Date: Wed, 03 Oct 2007 16:53:02 -0000 Subject: [issue1232] %f prints the wrong 6 decimal places Message-ID: <1191430382.85.0.415907974668.issue1232@psf.upfronthosting.co.za> Martin v. L?wis added the comment: I think you are misinterpreting what you see. The last digit in the output (7) is *not* the last digit of the input, but is the output originating from the digit 6. As the last digit of output, it gets rounded. As the first digit not printed anymore (7) is greater than 5, it rounds up. Closing the report as invalid ---------- nosy: +loewis resolution: -> invalid status: open -> closed __________________________________ Tracker __________________________________ From report at bugs.python.org Wed Oct 3 19:06:36 2007 From: report at bugs.python.org (Kevin McKiou) Date: Wed, 03 Oct 2007 17:06:36 -0000 Subject: [issue1232] %f prints the wrong 6 decimal places In-Reply-To: <1191430382.85.0.415907974668.issue1232@psf.upfronthosting.co.za> Message-ID: Kevin McKiou added the comment: Martin, Oops. Sorry about that. Hey, I even tried it with more decimals. It never occurred to me it was rounding. I thought it was simply printing a certain number of decimals. Hmmm...looking at my C manual...by golly, printf does round. Thanks, - Kevin Kevin McKiou +1 630 979 2577 kmckiou at alcatel-lucent.com __________________________________ Tracker __________________________________ From report at bugs.python.org Thu Oct 4 04:54:08 2007 From: report at bugs.python.org (Kurt B. Kaiser) Date: Thu, 04 Oct 2007 02:54:08 -0000 Subject: [issue1718043] textView code cleanup Message-ID: <1191466448.63.0.677154194126.issue1718043@psf.upfronthosting.co.za> Kurt B. Kaiser added the comment: r58309. Thanks for the Patch! ---------- assignee: -> kbk nosy: +kbk resolution: -> accepted status: open -> closed _____________________________________ Tracker _____________________________________ From report at bugs.python.org Thu Oct 4 05:12:07 2007 From: report at bugs.python.org (Kurt B. Kaiser) Date: Thu, 04 Oct 2007 03:12:07 -0000 Subject: [issue1730217] IDLE - configDialog layout cleanup Message-ID: <1191467527.88.0.0620266956274.issue1730217@psf.upfronthosting.co.za> Kurt B. Kaiser added the comment: r58310. Thanks for the nice patch! Looks better! ---------- assignee: -> kbk nosy: +kbk resolution: -> accepted status: open -> closed _____________________________________ Tracker _____________________________________ From report at bugs.python.org Thu Oct 4 05:21:29 2007 From: report at bugs.python.org (Kurt B. Kaiser) Date: Thu, 04 Oct 2007 03:21:29 -0000 Subject: [issue1529018] Move firewall warning to "about" menu Message-ID: <1191468089.37.0.980819049008.issue1529018@psf.upfronthosting.co.za> Kurt B. Kaiser added the comment: I think it would be better if a dialog popped up (before trying to set up the subprocess!) with the warning. It should have a checkbox, "Don't show this again." And it should be something we can reuse in other situations. Store a tag in the user's .idlerc if he doesn't want to see it again.... ---------- resolution: -> rejected _____________________________________ Tracker _____________________________________ From report at bugs.python.org Thu Oct 4 08:52:26 2007 From: report at bugs.python.org (Georg Brandl) Date: Thu, 04 Oct 2007 06:52:26 -0000 Subject: [issue1529018] Move firewall warning to "about" menu Message-ID: <1191480746.88.0.0409886602004.issue1529018@psf.upfronthosting.co.za> Changes by Georg Brandl: ---------- status: open -> closed _____________________________________ Tracker _____________________________________ From report at bugs.python.org Thu Oct 4 08:57:55 2007 From: report at bugs.python.org (Georg Brandl) Date: Thu, 04 Oct 2007 06:57:55 -0000 Subject: [issue1231] PEPs 344 and 3134 contain incorrect hyperlinks. Message-ID: <1191481075.49.0.989918082373.issue1231@psf.upfronthosting.co.za> Georg Brandl added the comment: Fixed in r58312, by inserting "number" between RFC and 88. ---------- nosy: +georg.brandl resolution: -> fixed status: open -> closed __________________________________ Tracker __________________________________ From report at bugs.python.org Thu Oct 4 11:18:15 2007 From: report at bugs.python.org (=?utf-8?q?=0A=09=09=09=09=09S=C3=A9bastien_Sabl=C3=A9=0A=09=09=09=09?=) Date: Thu, 04 Oct 2007 09:18:15 -0000 Subject: [issue1234] semaphore errors on AIX 5.2 Message-ID: <1191489495.02.0.0992368584163.issue1234@psf.upfronthosting.co.za> New submission from S?bastien Sabl? : There used to be a bug open concerning this problem in the old bug tracker but I can't find it in the new bug tracker: http://mail.python.org/pipermail/python-bugs-list/2005-June/029290.html ---------- messages: 56226 nosy: sable severity: normal status: open title: semaphore errors on AIX 5.2 __________________________________ Tracker __________________________________ From report at bugs.python.org Thu Oct 4 11:18:15 2007 From: report at bugs.python.org (=?utf-8?q?=0A=09=09=09=09=09S=C3=A9bastien_Sabl=C3=A9=0A=09=09=09=09?=) Date: Thu, 04 Oct 2007 09:18:15 -0000 Subject: [issue1234] semaphore errors on AIX 5.2 Message-ID: <1191489495.02.0.0992368584163.issue1234@psf.upfronthosting.co.za> New submission from S?bastien Sabl? : There used to be a bug open concerning this problem in the old bug tracker but I can't find it in the new bug tracker: http://mail.python.org/pipermail/python-bugs-list/2005-June/029290.html ---------- messages: 56226 nosy: sable severity: normal status: open title: semaphore errors on AIX 5.2 __________________________________ Tracker __________________________________ From report at bugs.python.org Thu Oct 4 11:18:56 2007 From: report at bugs.python.org (=?utf-8?q?=0A=09=09=09=09=09S=C3=A9bastien_Sabl=C3=A9=0A=09=09=09=09?=) Date: Thu, 04 Oct 2007 09:18:56 -0000 Subject: [issue1234] semaphore errors on AIX 5.2 Message-ID: <1191489536.8.0.353415613583.issue1234@psf.upfronthosting.co.za> S?bastien Sabl? added the comment: Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: The Written Word (Albert Chin) (tww-china) Assigned to: Nobody/Anonymous (nobody) Summary: semaphore errors from Python 2.3.x on AIX 5.2 Initial Comment: Newer versions of the AIX 5.2 libc implement POSIX semaphores and thus define _POSIX_SEMAPHORES in . However, when building Python 2.3.x (and I'm sure any other version with sem_init()), a few semaphore errors are encountered: building 'pcre' extension ./Modules/ld_so_aix gcc -bI:Modules/python.exp -L/opt/TWWfsw/python232/lib/support -Wl,-brtl -Wl,-blibpath:/opt/TWWfsw/python232/lib/support:/usr/lib build/temp.aix-5.2-2.3/pcremodule.o build/temp.aix-5.2-2.3/pypcre.o -L/opt/TWWfsw/python232/lib -o build/lib.aix-5.2-2.3/pcre.so sem_trywait: Permission denied sem_wait: Permission denied sem_post: Permission denied I ran the Python process under truss and saw that the sem_init() from Python/thread_pthread.h worked successfully. fork() was then called and a sem_trywait() operation (probably from PyThread_acquire_lock()) was called. From the sem_init() man page (http://publib.boulder.ibm.com/infocenter/pseries/index.jsp?topic=/com.ibm.aix.doc/libs/basetrf2/sem_init.htm): If the pshared parameter has a nonzero value, the semaphore is shared between processes. In this case, any process that can access the sem parameter can use it for performing sem_wait, sem_trywait, sem_post, and sem_destroy operations. Only the sem parameter itself may be used for performing synchronization. If the pshared parameter is zero, the semaphore is shared between threads of the process. Any thread in this process can use the sem parameter for performing sem_wait, sem_trywait, sem_post, and sem_destroy operations. The use of the semaphore by threads other than those created in the same process returns an error. Setting the 2nd value of sem_init to 1 (was 0) solved the problem. However, I don't know if this is wise for security. Another solution is to set HAVE_BROKEN_POSIX_SEMAPHORES for "AIX/5" like for "SunOS/5.8". ---------------------------------------------------------------------- Comment By: Leanid (lim_1) Date: 2005-06-20 13:12 Message: Logged In: YES user_id=701470 I can confirm this problem. I am using scons to build my project on AIX. I could not run parallel builds (-j4) on AIX. Randomly, but very often xlC invocation would stuck and I have 4 xlCcode hanging and taking all CPUs. After adding HAVE_BROKEN_POSIX_SEMAPHORES for AIX and rebuilding Python parallel builds on AIX are fine. Trying first fix with changing 0 to 1 in sem_init also resolved this problem, but I started to get some other unexplained error from scons, so had to deactivate semaphores all together. Albert, thanks for this report, it helped a lot. ---------------------------------------------------------------------- __________________________________ Tracker __________________________________ From report at bugs.python.org Thu Oct 4 11:30:54 2007 From: report at bugs.python.org (=?utf-8?q?=0A=09=09=09=09=09S=C3=A9bastien_Sabl=C3=A9=0A=09=09=09=09?=) Date: Thu, 04 Oct 2007 09:30:54 -0000 Subject: [issue1234] semaphore errors on AIX 5.2 Message-ID: <1191490254.95.0.766535274513.issue1234@psf.upfronthosting.co.za> S?bastien Sabl? added the comment: I can confirm that this bug is still present in Python 2.4.1 (and probably later versions) on AIX 5.2 and 5.3. When HAVE_BROKEN_POSIX_SEMAPHORES is not defined at compile time, Python will spend a lot of time in sem_wait, usually when acessing files. The problem does not always happen as it seems to depend on the type of file system in use. In my programm running for 3m30s, Python would call about 400000 time sem_wait and spend about 2mins waiting. When Python is compiled with HAVE_BROKEN_POSIX_SEMAPHORES, the same programm will only take 1m30s. I attach a patch which solves the problem. __________________________________ Tracker __________________________________ -------------- next part -------------- A non-text attachment was scrubbed... Name: patch_aix_broken_semaphores.diff Type: text/x-patch Size: 523 bytes Desc: not available Url : http://mail.python.org/pipermail/python-bugs-list/attachments/20071004/3980a4bb/attachment.bin From report at bugs.python.org Thu Oct 4 11:43:07 2007 From: report at bugs.python.org (=?utf-8?q?=0A=09=09=09=09=09S=C3=A9bastien_Sabl=C3=A9=0A=09=09=09=09?=) Date: Thu, 04 Oct 2007 09:43:07 -0000 Subject: [issue1234] semaphore errors on AIX 5.2 Message-ID: <1191490987.67.0.336173130566.issue1234@psf.upfronthosting.co.za> Changes by S?bastien Sabl? : __________________________________ Tracker __________________________________ From report at bugs.python.org Thu Oct 4 12:13:02 2007 From: report at bugs.python.org (Andy Schumann) Date: Thu, 04 Oct 2007 10:13:02 -0000 Subject: [issue1235] CGIHTTPRequestHandler.run_cgi() does not run on Windows if sys.executable contains blanks Message-ID: <1191492781.93.0.606740316101.issue1235@psf.upfronthosting.co.za> New submission from Andy Schumann: On Windows a path can contain spaces (e.g. C:\Program Files\python22 \python.exe). If using popenx each component in a command line has therefore to be double quoted as well as the whole command string. The method run_cgi() of the class CGIHTTPRequestHandler in the module CGIHTTPServer does not do this. Therefore the line 236: cmdline = "%s -u %s" % (interp, cmdline) should be replaced by cmdline = '""%s" -u "%s""' % (interp, cmdline) ---------- components: Windows messages: 56229 nosy: schu severity: normal status: open title: CGIHTTPRequestHandler.run_cgi() does not run on Windows if sys.executable contains blanks versions: Python 2.3 __________________________________ Tracker __________________________________ From report at bugs.python.org Thu Oct 4 12:13:01 2007 From: report at bugs.python.org (Andy Schumann) Date: Thu, 04 Oct 2007 10:13:01 -0000 Subject: [issue1235] CGIHTTPRequestHandler.run_cgi() does not run on Windows if sys.executable contains blanks Message-ID: <1191492781.93.0.606740316101.issue1235@psf.upfronthosting.co.za> New submission from Andy Schumann: On Windows a path can contain spaces (e.g. C:\Program Files\python22 \python.exe). If using popenx each component in a command line has therefore to be double quoted as well as the whole command string. The method run_cgi() of the class CGIHTTPRequestHandler in the module CGIHTTPServer does not do this. Therefore the line 236: cmdline = "%s -u %s" % (interp, cmdline) should be replaced by cmdline = '""%s" -u "%s""' % (interp, cmdline) ---------- components: Windows messages: 56229 nosy: schu severity: normal status: open title: CGIHTTPRequestHandler.run_cgi() does not run on Windows if sys.executable contains blanks versions: Python 2.3 __________________________________ Tracker __________________________________ From report at bugs.python.org Thu Oct 4 23:31:58 2007 From: report at bugs.python.org (Kenneth Duda) Date: Thu, 04 Oct 2007 21:31:58 -0000 Subject: [issue1236] subprocess is not thread-safe Message-ID: <1191533517.74.0.548071476021.issue1236@psf.upfronthosting.co.za> New submission from Kenneth Duda: The following test program crashes: ======================================== import threading, sys, subprocess # subprocess._cleanup = lambda: None def doit(): for i in xrange(0, 1000): p = subprocess.Popen( "true" ) p.wait() t = threading.Thread( target=doit ) t.start() doit() ============================== It crashes because when one thread calls subprocess.Popen(), subprocess calls this _cleanup() function, which might reap the subprocess started in another thread ! The other thread might be inside subprocess.Popen.wait(), just about to call waitpid(), and kill itself. If you uncomment the commented line, then the program runs with no problems. I imagine the purpose of _cleanup is to protect users from themselves, i.e., protect a user who calls subprocess.Popen() a lot without ever calling wait(). I suggest either: (1) eliminating this _cleanup() mechanism completely; people who do not wait() deserve the zombies they get; (2) synchronizing _cleanup() with wait() through a lock; or, (3) having wait() simply retry if it gets ECHILD. On the retry, it will discover that returncode is set, and return normally. -Ken ---------- components: Library (Lib) messages: 56230 nosy: kjd at duda.org severity: normal status: open title: subprocess is not thread-safe type: crash versions: Python 2.5 __________________________________ Tracker __________________________________ From report at bugs.python.org Thu Oct 4 23:31:57 2007 From: report at bugs.python.org (Kenneth Duda) Date: Thu, 04 Oct 2007 21:31:57 -0000 Subject: [issue1236] subprocess is not thread-safe Message-ID: <1191533517.74.0.548071476021.issue1236@psf.upfronthosting.co.za> New submission from Kenneth Duda: The following test program crashes: ======================================== import threading, sys, subprocess # subprocess._cleanup = lambda: None def doit(): for i in xrange(0, 1000): p = subprocess.Popen( "true" ) p.wait() t = threading.Thread( target=doit ) t.start() doit() ============================== It crashes because when one thread calls subprocess.Popen(), subprocess calls this _cleanup() function, which might reap the subprocess started in another thread ! The other thread might be inside subprocess.Popen.wait(), just about to call waitpid(), and kill itself. If you uncomment the commented line, then the program runs with no problems. I imagine the purpose of _cleanup is to protect users from themselves, i.e., protect a user who calls subprocess.Popen() a lot without ever calling wait(). I suggest either: (1) eliminating this _cleanup() mechanism completely; people who do not wait() deserve the zombies they get; (2) synchronizing _cleanup() with wait() through a lock; or, (3) having wait() simply retry if it gets ECHILD. On the retry, it will discover that returncode is set, and return normally. -Ken ---------- components: Library (Lib) messages: 56230 nosy: kjd at duda.org severity: normal status: open title: subprocess is not thread-safe type: crash versions: Python 2.5 __________________________________ Tracker __________________________________ From report at bugs.python.org Fri Oct 5 02:00:41 2007 From: report at bugs.python.org (Adam Olsen) Date: Fri, 05 Oct 2007 00:00:41 -0000 Subject: [issue1237] type_new doesn't allocate space for sentinal slot Message-ID: <1191542441.83.0.652795661207.issue1237@psf.upfronthosting.co.za> New submission from Adam Olsen: type_new() allocates the exact number of slots it's going to use, but various other functions assume there's one more slot with a NULL name field serving as a sentinel. I'm unsure why it doesn't normally crash. ---------- components: Interpreter Core messages: 56231 nosy: rhamphoryncus severity: normal status: open title: type_new doesn't allocate space for sentinal slot __________________________________ Tracker __________________________________ From report at bugs.python.org Fri Oct 5 02:00:42 2007 From: report at bugs.python.org (Adam Olsen) Date: Fri, 05 Oct 2007 00:00:42 -0000 Subject: [issue1237] type_new doesn't allocate space for sentinal slot Message-ID: <1191542441.83.0.652795661207.issue1237@psf.upfronthosting.co.za> New submission from Adam Olsen: type_new() allocates the exact number of slots it's going to use, but various other functions assume there's one more slot with a NULL name field serving as a sentinel. I'm unsure why it doesn't normally crash. ---------- components: Interpreter Core messages: 56231 nosy: rhamphoryncus severity: normal status: open title: type_new doesn't allocate space for sentinal slot __________________________________ Tracker __________________________________ From report at bugs.python.org Fri Oct 5 05:15:16 2007 From: report at bugs.python.org (Fred L. Drake, Jr.) Date: Fri, 05 Oct 2007 03:15:16 -0000 Subject: [issue1053] bogus attributes reported in asyncore doc Message-ID: <1191554116.22.0.135610218104.issue1053@psf.upfronthosting.co.za> Fred L. Drake, Jr. added the comment: Fixed for the 2.5.2 (revision 58328) and 2.6 (revision 58327) releases. ---------- resolution: -> fixed status: open -> closed __________________________________ Tracker __________________________________ From report at bugs.python.org Fri Oct 5 08:04:31 2007 From: report at bugs.python.org (Benjamin Aranguren) Date: Fri, 05 Oct 2007 06:04:31 -0000 Subject: [issue1026] Backport ABC to 2.6 In-Reply-To: Message-ID: Benjamin Aranguren added the comment: Hi Guido, I just wanted to let you know that I have completed porting _abcoll.py but ran into other test failures after running testall. The following tests failed: test_class test_compile test_descr test_dict test_nis test_richcmp test_shelve test_userdict test_weakref Also since there are no bytes in 2.6, is it correct to replace bytes with str? This is in _abcoll.py. Thanks, Ben A. On 9/10/07, Benjamin Aranguren wrote: > > Benjamin Aranguren added the comment: > > Yes. I plan to work on it this weekend. I hope that's okay. > > On 9/10/07, Guido van Rossum wrote: > > > > Guido van Rossum added the comment: > > > > Committed revision 58099. > > (I had to backport test_typechecks.py myself, and fix one issue in abc.py.) > > > > Are you going to backport _abcoll.py and its tests? > > > > ---------- > > assignee: -> gvanrossum > > nosy: +gvanrossum > > resolution: -> accepted > > status: open -> closed > > > > __________________________________ > > Tracker > > > > __________________________________ > > > > __________________________________ > Tracker > > __________________________________ > __________________________________ Tracker __________________________________ From report at bugs.python.org Fri Oct 5 09:30:55 2007 From: report at bugs.python.org (Anthon van der Neut) Date: Fri, 05 Oct 2007 07:30:55 -0000 Subject: [issue1238] dictobject and dictentry not used consistently in dictobject.c Message-ID: <1191569454.84.0.732829758035.issue1238@psf.upfronthosting.co.za> New submission from Anthon van der Neut: In dictobject.c the structures from dictobject.h are typedeffed to: typedef PyDictEntry dictentry; typedef PyDictObject dictobject; However there are still a few locations in that file where the PyDictEntry and PyDictObject types are used directly. IMHO these should be replaced by dictentry resp. dictobject Attached is a patch for that. ---------- components: Interpreter Core files: dictobject.c.patch messages: 56234 nosy: anthon severity: minor status: open title: dictobject and dictentry not used consistently in dictobject.c versions: Python 2.5, Python 2.6 __________________________________ Tracker __________________________________ -------------- next part -------------- A non-text attachment was scrubbed... Name: dictobject.c.patch Type: text/x-patch Size: 1703 bytes Desc: not available Url : http://mail.python.org/pipermail/python-bugs-list/attachments/20071005/90ce3c40/attachment.bin From report at bugs.python.org Fri Oct 5 09:30:54 2007 From: report at bugs.python.org (Anthon van der Neut) Date: Fri, 05 Oct 2007 07:30:54 -0000 Subject: [issue1238] dictobject and dictentry not used consistently in dictobject.c Message-ID: <1191569454.84.0.732829758035.issue1238@psf.upfronthosting.co.za> New submission from Anthon van der Neut: In dictobject.c the structures from dictobject.h are typedeffed to: typedef PyDictEntry dictentry; typedef PyDictObject dictobject; However there are still a few locations in that file where the PyDictEntry and PyDictObject types are used directly. IMHO these should be replaced by dictentry resp. dictobject Attached is a patch for that. ---------- components: Interpreter Core files: dictobject.c.patch messages: 56234 nosy: anthon severity: minor status: open title: dictobject and dictentry not used consistently in dictobject.c versions: Python 2.5, Python 2.6 __________________________________ Tracker __________________________________ -------------- next part -------------- A non-text attachment was scrubbed... Name: dictobject.c.patch Type: text/x-patch Size: 1703 bytes Desc: not available Url : http://mail.python.org/pipermail/python-bugs-list/attachments/20071005/90ce3c40/attachment-0003.bin From report at bugs.python.org Fri Oct 5 10:10:34 2007 From: report at bugs.python.org (Matti Katila) Date: Fri, 05 Oct 2007 08:10:34 -0000 Subject: [issue1239] openpty does not give bidirectional pipe Message-ID: <1191571834.99.0.311414379194.issue1239@psf.upfronthosting.co.za> Changes by Matti Katila: ---------- components: None severity: normal status: open title: openpty does not give bidirectional pipe type: behavior versions: Python 2.5 __________________________________ Tracker __________________________________ From report at bugs.python.org Fri Oct 5 10:12:27 2007 From: report at bugs.python.org (Matti Katila) Date: Fri, 05 Oct 2007 08:12:27 -0000 Subject: [issue1239] openpty does not give bidirectional pipe Message-ID: <1191571947.24.0.64790674647.issue1239@psf.upfronthosting.co.za> New submission from Matti Katila: http://rafb.net/p/t8cqSt71.html ---------- nosy: +mudyc __________________________________ Tracker __________________________________ From report at bugs.python.org Fri Oct 5 10:50:58 2007 From: report at bugs.python.org (Matti Katila) Date: Fri, 05 Oct 2007 08:50:58 -0000 Subject: [issue1239] openpty does not give bidirectional pipe Message-ID: <1191574258.08.0.493037420806.issue1239@psf.upfronthosting.co.za> Matti Katila added the comment: Linux Programmer?s Manual for ptmx and pts - pseudo-terminal master and slave states: "Data written to the slave is presented on the master descriptor as input. Data written to the master is presented to the slave as input." The data can be read from slave to master but not from master to slave. The unit test does not test this issue either: http://coverage.livinglogic.de/Lib/test/test_openpty.py.html __________________________________ Tracker __________________________________ From report at bugs.python.org Fri Oct 5 15:20:23 2007 From: report at bugs.python.org (Tim Gordon) Date: Fri, 05 Oct 2007 13:20:23 -0000 Subject: [issue1240] str.split possible bug Message-ID: <1191590423.15.0.942254766334.issue1240@psf.upfronthosting.co.za> New submission from Tim Gordon: >From the docs for str.split: "If sep is not specified or is None... First, whitespace characters are stripped from both ends. Then, words are separated by arbitrary length strings of whitespace characters." However, ' a b c '.split(None, 1) returns ['a', 'b c '] indicating that the "stripped from both ends" isn't taking place, but that it's removing whitespace as it goes and never gets to the end as it stops parsing when it hits the first split. Note this is easily worked around by calling str.strip().split(None, 1), but it would be good not to have to. I've tested this on windows version 2.5, and 2.4.4 for Debian ---------- messages: 56237 nosy: QuantumTim severity: normal status: open title: str.split possible bug type: behavior versions: Python 2.4, Python 2.5 __________________________________ Tracker __________________________________ From report at bugs.python.org Fri Oct 5 15:20:23 2007 From: report at bugs.python.org (Tim Gordon) Date: Fri, 05 Oct 2007 13:20:23 -0000 Subject: [issue1240] str.split possible bug Message-ID: <1191590423.15.0.942254766334.issue1240@psf.upfronthosting.co.za> New submission from Tim Gordon: >From the docs for str.split: "If sep is not specified or is None... First, whitespace characters are stripped from both ends. Then, words are separated by arbitrary length strings of whitespace characters." However, ' a b c '.split(None, 1) returns ['a', 'b c '] indicating that the "stripped from both ends" isn't taking place, but that it's removing whitespace as it goes and never gets to the end as it stops parsing when it hits the first split. Note this is easily worked around by calling str.strip().split(None, 1), but it would be good not to have to. I've tested this on windows version 2.5, and 2.4.4 for Debian ---------- messages: 56237 nosy: QuantumTim severity: normal status: open title: str.split possible bug type: behavior versions: Python 2.4, Python 2.5 __________________________________ Tracker __________________________________ From report at bugs.python.org Fri Oct 5 15:21:11 2007 From: report at bugs.python.org (Tim Gordon) Date: Fri, 05 Oct 2007 13:21:11 -0000 Subject: [issue1240] str.split bug Message-ID: <1191590471.02.0.413551953107.issue1240@psf.upfronthosting.co.za> Changes by Tim Gordon: ---------- title: str.split possible bug -> str.split bug __________________________________ Tracker __________________________________ From report at bugs.python.org Fri Oct 5 15:22:01 2007 From: report at bugs.python.org (Tim Gordon) Date: Fri, 05 Oct 2007 13:22:01 -0000 Subject: [issue1240] str.split bug when using sep = None and maxsplit Message-ID: <1191590521.03.0.958780689219.issue1240@psf.upfronthosting.co.za> Changes by Tim Gordon: ---------- title: str.split bug -> str.split bug when using sep = None and maxsplit __________________________________ Tracker __________________________________ From report at bugs.python.org Fri Oct 5 17:05:53 2007 From: report at bugs.python.org (Guido van Rossum) Date: Fri, 05 Oct 2007 15:05:53 -0000 Subject: [issue1235] CGIHTTPRequestHandler.run_cgi() does not run on Windows if sys.executable contains blanks Message-ID: <1191596753.08.0.568052109853.issue1235@psf.upfronthosting.co.za> Guido van Rossum added the comment: Please submit a patch -- this was mostly intended as demo code, I didn't expect anyone to use it, let alone on Windows. :-) ---------- nosy: +gvanrossum __________________________________ Tracker __________________________________ From report at bugs.python.org Fri Oct 5 17:08:37 2007 From: report at bugs.python.org (Guido van Rossum) Date: Fri, 05 Oct 2007 15:08:37 -0000 Subject: [issue1237] type_new doesn't allocate space for sentinal slot Message-ID: <1191596917.93.0.635812521619.issue1237@psf.upfronthosting.co.za> Guido van Rossum added the comment: Can you be more specific as to on which line number the questionable allocation happens, and which functions are depending on there being one extra slot? ---------- nosy: +gvanrossum __________________________________ Tracker __________________________________ From report at bugs.python.org Fri Oct 5 17:11:03 2007 From: report at bugs.python.org (Guido van Rossum) Date: Fri, 05 Oct 2007 15:11:03 -0000 Subject: [issue1238] dictobject and dictentry not used consistently in dictobject.c Message-ID: <1191597063.05.0.9706354721.issue1238@psf.upfronthosting.co.za> Guido van Rossum added the comment: I think it would be better to get rid of the typedefs and use the public Py* names everywhere? ---------- nosy: +gvanrossum __________________________________ Tracker __________________________________ From report at bugs.python.org Fri Oct 5 19:18:01 2007 From: report at bugs.python.org (Adam Olsen) Date: Fri, 05 Oct 2007 17:18:01 -0000 Subject: [issue1237] type_new doesn't allocate space for sentinal slot Message-ID: <1191604681.49.0.616748526754.issue1237@psf.upfronthosting.co.za> Adam Olsen added the comment: typeobject.c:1842:type_new type = (PyTypeObject *)metatype->tp_alloc(metatype, nslots); nslots may be 0. typeobject.c:1966:type_new assigns this just-past-the-end address to tp_members type->tp_members = PyHeapType_GET_MEMBERS(et); type_new later calls PyType_Ready, which calls add_members. typeobject.c:3062:add_members for (; memb->name != NULL; memb++) { Interestingly, traverse_slots and clear_slots both use Py_Size rather than name != NULL (so I was wrong about the extent of the problem.) Both seem only to be used for heap types. add_members is used by both heap types and static C types, so it needs to handle both behaviours. One possible (if ugly) solution would be to switch iteration methods depending on if Py_Size() is 0 or not, making sure type_new sets tp_members to NULL if Py_Size() is 0. __________________________________ Tracker __________________________________ From report at bugs.python.org Fri Oct 5 19:21:58 2007 From: report at bugs.python.org (Brett Cannon) Date: Fri, 05 Oct 2007 17:21:58 -0000 Subject: [issue1240] str.split bug when using sep = None and maxsplit Message-ID: <1191604918.1.0.324688532154.issue1240@psf.upfronthosting.co.za> Brett Cannon added the comment: I know there is another filed bug on this topic, I just need to find it. ---------- nosy: +brett.cannon __________________________________ Tracker __________________________________ From report at bugs.python.org Fri Oct 5 20:07:51 2007 From: report at bugs.python.org (Guido van Rossum) Date: Fri, 05 Oct 2007 18:07:51 -0000 Subject: [issue1237] type_new doesn't allocate space for sentinal slot Message-ID: <1191607671.03.0.66336967497.issue1237@psf.upfronthosting.co.za> Guido van Rossum added the comment: Are you sure you're not missing the +1 on line 440 in PyType_GenericAlloc()? __________________________________ Tracker __________________________________ From report at bugs.python.org Fri Oct 5 20:25:12 2007 From: report at bugs.python.org (Adam Olsen) Date: Fri, 05 Oct 2007 18:25:12 -0000 Subject: [issue1237] type_new doesn't allocate space for sentinal slot Message-ID: <1191608712.89.0.564279661321.issue1237@psf.upfronthosting.co.za> Adam Olsen added the comment: Ugh, you're right. I refactored PyType_GenericAlloc out of my fork, which is why I got a crash. Sorry for wasting your time. __________________________________ Tracker __________________________________ From report at bugs.python.org Fri Oct 5 20:31:57 2007 From: report at bugs.python.org (Guido van Rossum) Date: Fri, 05 Oct 2007 18:31:57 -0000 Subject: [issue1731717] race condition in subprocess module Message-ID: <1191609117.87.0.725542170775.issue1731717@psf.upfronthosting.co.za> Guido van Rossum added the comment: See http://bugs.python.org/issue1236 for a good repeatable testcase. _____________________________________ Tracker _____________________________________ From report at bugs.python.org Fri Oct 5 20:32:05 2007 From: report at bugs.python.org (Guido van Rossum) Date: Fri, 05 Oct 2007 18:32:05 -0000 Subject: [issue1236] subprocess is not thread-safe Message-ID: <1191609125.62.0.585965417214.issue1236@psf.upfronthosting.co.za> Guido van Rossum added the comment: This is a duplicate of bug# 1731717. I asked Donovan Baarda, who told me: """ Last time I looked this had been fixed, admittedly in a bit of an ugly way, on the svn head. I offered to do a patch to make it a bit cleaner, but as it isn't really broken anymore it was a bit of a low priority and I haven't done it. This bug seems to have a good repeatable test-case that we can probably use in the unittests to show that it's now fixed... """ ---------- nosy: +gvanrossum resolution: -> duplicate status: open -> closed superseder: -> race condition in subprocess module __________________________________ Tracker __________________________________ From report at bugs.python.org Fri Oct 5 20:33:31 2007 From: report at bugs.python.org (Guido van Rossum) Date: Fri, 05 Oct 2007 18:33:31 -0000 Subject: [issue1237] type_new doesn't allocate space for sentinal slot Message-ID: <1191609211.78.0.403159730023.issue1237@psf.upfronthosting.co.za> Changes by Guido van Rossum: ---------- resolution: -> invalid status: open -> closed __________________________________ Tracker __________________________________ From report at bugs.python.org Fri Oct 5 22:09:30 2007 From: report at bugs.python.org (Jason Kim) Date: Fri, 05 Oct 2007 20:09:30 -0000 Subject: [issue1241] subprocess.py stdout of childprocess always buffered. Message-ID: <1191614970.62.0.0159920077283.issue1241@psf.upfronthosting.co.za> New submission from Jason Kim: Hi. I am currently using subprocess.py (2.4.4 and above) to try to have a portable way of running a sub task in linux and windows. I ran into a strange problem - a program runs and is "timed out" but the the subprocess's stdout and stderr are not fully "grabbed" So I've been trying various ways to force "flush" the stdout and stderr of the child process so that at least partial results can be saved. The "problem" app being spawned off is very simple: -------------------------------------- #include int main() { int i = 0; for (i = 0; i < 1000; ++i) { printf("STDOUT boo %d\n",i); fprintf(stdout,"STDOUT sleeping %d\n",i); fprintf(stderr,"STDERR sleeping %d\n",i); //fflush(stdout); //fflush(stderr); sleep(1); } } ----------------------------------------------- i.e. it just dumps its output to both stdout and stderr. The issue that I am seeing is that no matter what options I tried to place for subprocess(), the ONLY output I see from the executed process are "STDERR sleeping " lines, UNLESS I uncomment the fflush(stdout) line in the application. Executing the script with python -u doesn't seem to help either. Now, if the task completes normally, then I am able to grab the entire stdout and stderr produced by the subprocess. The issue is that I can't seem to grab the partial output for stdout, and there does not seem to be a way to make the file descriptors returned by pipe() to be unbuffered. So the question is: what is the preferred method of forcing the pipe() file descriptors created by subprocess.__init__() to be fully unbuffered? Second, is there a better way of doing this? i.e. a portable way to spawn off a task, with an optional timeout, grab any partial results from the task's stdout and stderr, and grab the return code from the child task? Any hints and advice will be greatly appreciated. Thank you. The relevant snippet of python code is: import threading from signal import * from subprocess import * import time import string import copy import re import sys import os from glob import glob from os import path import thread class task_wrapper(): def run(s): if s.timeout > 0: #print "starting timer for ",s.timeout s.task_timer = threading.Timer(s.timeout, task_wrapper.cleanup, [s]) s.task_timer.start() s.task_start_time = time.time() s.task_end_time = s.task_start_time s.subtask=Popen(s.cmd, bufsize=0, env=s.env, stdout=PIPE, stderr=PIPE) s.task_out, s.task_err = s.subtask.communicate() def kill(s, subtask): """ attempts a portable way to kill things First, flush the buffer """ print "killing", subtask.pid sys.stdout.flush() #s.subtask.stdin.flush() print "s.subtask.stdout.fileno()=",s.subtask.stdout.fileno() print "s.subtask.stderr.fileno()=",s.subtask.stderr.fileno() #os.fsync(s.subtask.stderr.fileno()) #os.fsync(s.subtask.stdout.fileno()) s.subtask.stdout.flush() s.subtask.stderr.flush() if os.name == "posix": os.kill(subtask.pid, SIGKILL) elif os.name == "nt": import win32api win32api.TerminateProcess(subtask._handle ,9) def cleanup(s, mode="TIMEOUT"): s.timer_lock.acquire() if s.task_result == None: if mode == "TIMEOUT": s.msg( """ Uhoh, subtask took too long""") s.kill(s.subtask) .... ---------- messages: 56247 nosy: jason.w.kim severity: normal status: open title: subprocess.py stdout of childprocess always buffered. type: behavior versions: Python 2.4, Python 2.5 __________________________________ Tracker __________________________________ From report at bugs.python.org Fri Oct 5 22:09:30 2007 From: report at bugs.python.org (Jason Kim) Date: Fri, 05 Oct 2007 20:09:30 -0000 Subject: [issue1241] subprocess.py stdout of childprocess always buffered. Message-ID: <1191614970.62.0.0159920077283.issue1241@psf.upfronthosting.co.za> New submission from Jason Kim: Hi. I am currently using subprocess.py (2.4.4 and above) to try to have a portable way of running a sub task in linux and windows. I ran into a strange problem - a program runs and is "timed out" but the the subprocess's stdout and stderr are not fully "grabbed" So I've been trying various ways to force "flush" the stdout and stderr of the child process so that at least partial results can be saved. The "problem" app being spawned off is very simple: -------------------------------------- #include int main() { int i = 0; for (i = 0; i < 1000; ++i) { printf("STDOUT boo %d\n",i); fprintf(stdout,"STDOUT sleeping %d\n",i); fprintf(stderr,"STDERR sleeping %d\n",i); //fflush(stdout); //fflush(stderr); sleep(1); } } ----------------------------------------------- i.e. it just dumps its output to both stdout and stderr. The issue that I am seeing is that no matter what options I tried to place for subprocess(), the ONLY output I see from the executed process are "STDERR sleeping " lines, UNLESS I uncomment the fflush(stdout) line in the application. Executing the script with python -u doesn't seem to help either. Now, if the task completes normally, then I am able to grab the entire stdout and stderr produced by the subprocess. The issue is that I can't seem to grab the partial output for stdout, and there does not seem to be a way to make the file descriptors returned by pipe() to be unbuffered. So the question is: what is the preferred method of forcing the pipe() file descriptors created by subprocess.__init__() to be fully unbuffered? Second, is there a better way of doing this? i.e. a portable way to spawn off a task, with an optional timeout, grab any partial results from the task's stdout and stderr, and grab the return code from the child task? Any hints and advice will be greatly appreciated. Thank you. The relevant snippet of python code is: import threading from signal import * from subprocess import * import time import string import copy import re import sys import os from glob import glob from os import path import thread class task_wrapper(): def run(s): if s.timeout > 0: #print "starting timer for ",s.timeout s.task_timer = threading.Timer(s.timeout, task_wrapper.cleanup, [s]) s.task_timer.start() s.task_start_time = time.time() s.task_end_time = s.task_start_time s.subtask=Popen(s.cmd, bufsize=0, env=s.env, stdout=PIPE, stderr=PIPE) s.task_out, s.task_err = s.subtask.communicate() def kill(s, subtask): """ attempts a portable way to kill things First, flush the buffer """ print "killing", subtask.pid sys.stdout.flush() #s.subtask.stdin.flush() print "s.subtask.stdout.fileno()=",s.subtask.stdout.fileno() print "s.subtask.stderr.fileno()=",s.subtask.stderr.fileno() #os.fsync(s.subtask.stderr.fileno()) #os.fsync(s.subtask.stdout.fileno()) s.subtask.stdout.flush() s.subtask.stderr.flush() if os.name == "posix": os.kill(subtask.pid, SIGKILL) elif os.name == "nt": import win32api win32api.TerminateProcess(subtask._handle ,9) def cleanup(s, mode="TIMEOUT"): s.timer_lock.acquire() if s.task_result == None: if mode == "TIMEOUT": s.msg( """ Uhoh, subtask took too long""") s.kill(s.subtask) .... ---------- messages: 56247 nosy: jason.w.kim severity: normal status: open title: subprocess.py stdout of childprocess always buffered. type: behavior versions: Python 2.4, Python 2.5 __________________________________ Tracker __________________________________ From report at bugs.python.org Fri Oct 5 22:52:15 2007 From: report at bugs.python.org (Matti Katila) Date: Fri, 05 Oct 2007 20:52:15 -0000 Subject: [issue1239] openpty does not give bidirectional pipe Message-ID: <1191617535.58.0.872594272542.issue1239@psf.upfronthosting.co.za> Matti Katila added the comment: Not a real issue - it's a standard behaviour of tty. Fix is to set -icanon: m,s = os.openpty() s = os.ttyname(s) os.system( 'stty cs8 -icanon -echo < %s' % s ) see, http://www.eulogika.net/download/eutalk_20040302/pymouse.html The issue can be closed and documentation can be updated with some helpful information. __________________________________ Tracker __________________________________ From report at bugs.python.org Sat Oct 6 07:24:51 2007 From: report at bugs.python.org (Gopinath) Date: Sat, 06 Oct 2007 05:24:51 -0000 Subject: [issue1242] test Message-ID: New submission from Gopinath: hi I have registerd recently and need notes on hacking disadvantages and advantages. ---------- files: unnamed messages: 56249 nosy: gopiyadav26 severity: normal status: open title: test __________________________________ Tracker __________________________________ -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: unnamed Url: http://mail.python.org/pipermail/python-bugs-list/attachments/20071006/1c70df43/attachment.txt From report at bugs.python.org Sat Oct 6 07:24:51 2007 From: report at bugs.python.org (Gopinath) Date: Sat, 06 Oct 2007 05:24:51 -0000 Subject: [issue1242] test Message-ID: New submission from Gopinath: hi I have registerd recently and need notes on hacking disadvantages and advantages. ---------- files: unnamed messages: 56249 nosy: gopiyadav26 severity: normal status: open title: test __________________________________ Tracker __________________________________ -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: unnamed Url: http://mail.python.org/pipermail/python-bugs-list/attachments/20071006/1c70df43/attachment-0001.txt From report at bugs.python.org Sat Oct 6 08:29:25 2007 From: report at bugs.python.org (Anthon van der Neut) Date: Sat, 06 Oct 2007 06:29:25 -0000 Subject: [issue1238] dictobject and dictentry not used consistently in dictobject.c Message-ID: <1191652165.15.0.30385765072.issue1238@psf.upfronthosting.co.za> Anthon van der Neut added the comment: Guido's suggestion to change all entries to PyDictEntry resp. PyDictObject would work as well and declutter the code in a better way. The only advantage of the typedefs that I see (and briefly used) it that it is easy to have structures local to dictobject.c that hold some more information, without having to touch dictobject.h (and trigger a more general recompile. For the few that need that, they can globaly replace PyDict{Entry,Object} when they do. __________________________________ Tracker __________________________________ From report at bugs.python.org Sat Oct 6 09:05:00 2007 From: report at bugs.python.org (=?utf-8?q?Peter_=C3=83=E2=80=A6strand?=) Date: Sat, 06 Oct 2007 07:05:00 -0000 Subject: [issue1241] subprocess.py stdout of childprocess always buffered. Message-ID: <1191654300.54.0.524352869774.issue1241@psf.upfronthosting.co.za> Peter ??strand added the comment: Most probably, this is not a problem with the Python side or the pipes, but the libc streams in the application. stderr is normally unbuffered, while stdout is buffered. You can see this by running the app with grep: $ ./a.out | grep STDOUT STDERR sleeping 0 STDERR sleeping 1 STDERR sleeping 2 STDERR sleeping 3 If you throw in a: setvbuf(stdout, NULL, _IONBF, 0); things will work the way you expect: $ ./a.out | grep STDOUT STDERR sleeping 0 STDOUT boo 0 STDOUT sleeping 0 STDERR sleeping 1 STDOUT boo 1 ---------- nosy: +astrand __________________________________ Tracker __________________________________ From report at bugs.python.org Sat Oct 6 18:03:12 2007 From: report at bugs.python.org (Chris Withers) Date: Sat, 06 Oct 2007 16:03:12 -0000 Subject: [issue1243] option.dest not set when callback called with optparse Message-ID: <1191686592.38.0.384749327692.issue1243@psf.upfronthosting.co.za> New submission from Chris Withers: The attached script demonstrates the bug. option.dest should be set, even if not explicitly supplied in the call to parser.add_option, by the time the callback is called. Unless dest='something' is specified in the call to add_option, you will get the following error when running "python test.py --myopt": File "test.py", line 4, in mycallback setattr(parser.values,option.dest,value) TypeError: attribute name must be string ...as options.dest is still None. I would expect options.dest to be computed as per the algorithm in optparse.Option._check_dest. ---------- components: Library (Lib) files: test.py messages: 56252 nosy: cjw296 severity: normal status: open title: option.dest not set when callback called with optparse versions: Python 2.3, Python 2.4, Python 2.5 __________________________________ Tracker __________________________________ -------------- next part -------------- A non-text attachment was scrubbed... Name: test.py Type: text/x-python Size: 276 bytes Desc: not available Url : http://mail.python.org/pipermail/python-bugs-list/attachments/20071006/0d9d745d/attachment.py From report at bugs.python.org Sat Oct 6 18:03:13 2007 From: report at bugs.python.org (Chris Withers) Date: Sat, 06 Oct 2007 16:03:13 -0000 Subject: [issue1243] option.dest not set when callback called with optparse Message-ID: <1191686592.38.0.384749327692.issue1243@psf.upfronthosting.co.za> New submission from Chris Withers: The attached script demonstrates the bug. option.dest should be set, even if not explicitly supplied in the call to parser.add_option, by the time the callback is called. Unless dest='something' is specified in the call to add_option, you will get the following error when running "python test.py --myopt": File "test.py", line 4, in mycallback setattr(parser.values,option.dest,value) TypeError: attribute name must be string ...as options.dest is still None. I would expect options.dest to be computed as per the algorithm in optparse.Option._check_dest. ---------- components: Library (Lib) files: test.py messages: 56252 nosy: cjw296 severity: normal status: open title: option.dest not set when callback called with optparse versions: Python 2.3, Python 2.4, Python 2.5 __________________________________ Tracker __________________________________ -------------- next part -------------- A non-text attachment was scrubbed... Name: test.py Type: text/x-python Size: 276 bytes Desc: not available Url : http://mail.python.org/pipermail/python-bugs-list/attachments/20071006/0d9d745d/attachment-0001.py From report at bugs.python.org Sat Oct 6 18:24:37 2007 From: report at bugs.python.org (Georg Brandl) Date: Sat, 06 Oct 2007 16:24:37 -0000 Subject: [issue1242] test Message-ID: <1191687877.39.0.69730566761.issue1242@psf.upfronthosting.co.za> Georg Brandl added the comment: This is a bug tracker, not a discussion forum. Please go to the comp.lang.python newsgroup. ---------- nosy: +georg.brandl resolution: -> invalid status: open -> closed __________________________________ Tracker __________________________________ From report at bugs.python.org Sun Oct 7 00:35:24 2007 From: report at bugs.python.org (Guido van Rossum) Date: Sat, 06 Oct 2007 22:35:24 -0000 Subject: [issue1240] str.split bug when using sep = None and maxsplit Message-ID: <1191710124.91.0.132759772129.issue1240@psf.upfronthosting.co.za> Guido van Rossum added the comment: It was deemed a documentation bug. ---------- nosy: +gvanrossum __________________________________ Tracker __________________________________ From report at bugs.python.org Sun Oct 7 00:36:54 2007 From: report at bugs.python.org (Guido van Rossum) Date: Sat, 06 Oct 2007 22:36:54 -0000 Subject: [issue1241] subprocess.py stdout of childprocess always buffered. Message-ID: <1191710214.61.0.348036298964.issue1241@psf.upfronthosting.co.za> Guido van Rossum added the comment: This is how C stdio works in the subprocess. Python's subprocess.py has nothing to do with it and can't do anything about it. ---------- nosy: +gvanrossum resolution: -> invalid status: open -> closed __________________________________ Tracker __________________________________ From report at bugs.python.org Sun Oct 7 15:55:51 2007 From: report at bugs.python.org (Aaron Swartz) Date: Sun, 07 Oct 2007 13:55:51 -0000 Subject: [issue1662581] the re module can perform poorly: O(2**n) versus O(n**2) Message-ID: <1191765351.92.0.868467569882.issue1662581@psf.upfronthosting.co.za> Aaron Swartz added the comment: Just a note for those who think this is a purely theoretical issue: We've been using the python-markdown module on our web app for a while, only to notice the app has been repeatedly going down. After tracking down the culprit, we found that a speech from Hamlet passed to one of the Markdown regular expressions caused this exponential behavior, freezing up the app. ---------- nosy: +aaronsw _____________________________________ Tracker _____________________________________ From report at bugs.python.org Sun Oct 7 18:29:34 2007 From: report at bugs.python.org (=?utf-8?q?=0A=09=09=09=09=09Gabriel_de_Perthuis=0A=09=09=09=09?=) Date: Sun, 07 Oct 2007 16:29:34 -0000 Subject: [issue1746656] IPv6 Interface naming/indexing functions Message-ID: <1191774574.79.0.817578512822.issue1746656@psf.upfronthosting.co.za> Changes by Gabriel de Perthuis : ---------- nosy: +onyxg7 type: -> rfe _____________________________________ Tracker _____________________________________ From report at bugs.python.org Sun Oct 7 22:05:30 2007 From: report at bugs.python.org (Brett Cannon) Date: Sun, 07 Oct 2007 20:05:30 -0000 Subject: [issue1123] split(None, maxsplit) does not strip whitespace correctly Message-ID: <1191787530.64.0.911524962183.issue1123@psf.upfronthosting.co.za> Brett Cannon added the comment: Re-opening as jafo was referring to the string module's function implementation which is deprecated. The real issue is that the built-in types docs are bad. ---------- assignee: fdrake -> resolution: invalid -> status: closed -> open versions: +Python 2.6 __________________________________ Tracker __________________________________ From report at bugs.python.org Sun Oct 7 22:05:53 2007 From: report at bugs.python.org (Brett Cannon) Date: Sun, 07 Oct 2007 20:05:53 -0000 Subject: [issue1240] str.split bug when using sep = None and maxsplit Message-ID: <1191787553.12.0.590909172034.issue1240@psf.upfronthosting.co.za> Brett Cannon added the comment: issue1123 was the issue I was thinking of. Setting that as a superceder as 1123 was closed prematurely. ---------- superseder: -> split(None, maxsplit) does not strip whitespace correctly __________________________________ Tracker __________________________________ From report at bugs.python.org Sun Oct 7 22:06:03 2007 From: report at bugs.python.org (Brett Cannon) Date: Sun, 07 Oct 2007 20:06:03 -0000 Subject: [issue1240] str.split bug when using sep = None and maxsplit Message-ID: <1191787563.04.0.863531098224.issue1240@psf.upfronthosting.co.za> Changes by Brett Cannon: ---------- resolution: -> duplicate status: open -> closed __________________________________ Tracker __________________________________ From report at bugs.python.org Sun Oct 7 23:07:45 2007 From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=) Date: Sun, 07 Oct 2007 21:07:45 -0000 Subject: [issue1238] dictobject and dictentry not used consistently in dictobject.c Message-ID: <1191791265.22.0.72216412648.issue1238@psf.upfronthosting.co.za> Changes by Martin v. L?wis: ---------- keywords: +patch __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Oct 8 01:13:10 2007 From: report at bugs.python.org (Brett Cannon) Date: Sun, 07 Oct 2007 23:13:10 -0000 Subject: [issue1229] 3.0 library/stdtypes.rst Message-ID: <1191798790.67.0.110065794538.issue1229@psf.upfronthosting.co.za> Brett Cannon added the comment: Fixed in revision 58353. ---------- assignee: -> brett.cannon keywords: +py3k nosy: +brett.cannon resolution: -> fixed status: open -> closed __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Oct 8 01:19:04 2007 From: report at bugs.python.org (Brett Cannon) Date: Sun, 07 Oct 2007 23:19:04 -0000 Subject: [issue467384] provide a documented serialization func Message-ID: <1191799144.78.0.279770833278.issue467384@psf.upfronthosting.co.za> Changes by Brett Cannon: ---------- nosy: -brett.cannon ____________________________________ Tracker ____________________________________ From report at bugs.python.org Mon Oct 8 01:20:37 2007 From: report at bugs.python.org (Brett Cannon) Date: Sun, 07 Oct 2007 23:20:37 -0000 Subject: [issue416670] MatchObjects not deepcopy()able Message-ID: <1191799237.17.0.240388791728.issue416670@psf.upfronthosting.co.za> Changes by Brett Cannon: ---------- nosy: -brett.cannon ____________________________________ Tracker ____________________________________ From report at bugs.python.org Mon Oct 8 01:23:02 2007 From: report at bugs.python.org (Brett Cannon) Date: Sun, 07 Oct 2007 23:23:02 -0000 Subject: [issue1035] bytes buffer API needs to support read locking and/or PyBUF_LOCKDATA Message-ID: <1191799382.02.0.988809091009.issue1035@psf.upfronthosting.co.za> Brett Cannon added the comment: All the tests pass for me, Gregory. Were the failures with some patch you had only locally? ---------- nosy: +brett.cannon priority: -> normal __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Oct 8 01:24:50 2007 From: report at bugs.python.org (Brett Cannon) Date: Sun, 07 Oct 2007 23:24:50 -0000 Subject: [issue1238] dictobject and dictentry not used consistently in dictobject.c Message-ID: <1191799490.09.0.0543374595349.issue1238@psf.upfronthosting.co.za> Changes by Brett Cannon: ---------- priority: -> low __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Oct 8 01:39:59 2007 From: report at bugs.python.org (Brett Cannon) Date: Sun, 07 Oct 2007 23:39:59 -0000 Subject: [issue1238] dictobject and dictentry not used consistently in dictobject.c Message-ID: <1191800399.67.0.45473849812.issue1238@psf.upfronthosting.co.za> Brett Cannon added the comment: While I understand the argument for faster recompiles, dictobject.(c|h) do not change that often, and thus faster recompiles are not critical. I am with Guido and would rather see the module moved over to public names. Setting the priority to low as this is not critical in any way, although I am all for making code more readable and thus will review any patch that Anthon comes up with that uses the public names. ---------- nosy: +brett.cannon __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Oct 8 01:40:32 2007 From: report at bugs.python.org (Brett Cannon) Date: Sun, 07 Oct 2007 23:40:32 -0000 Subject: [issue1160] Medium size regexp crashes python Message-ID: <1191800432.68.0.146306122594.issue1160@psf.upfronthosting.co.za> Changes by Brett Cannon: ---------- priority: -> normal __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Oct 8 01:46:46 2007 From: report at bugs.python.org (Guido van Rossum) Date: Sun, 07 Oct 2007 23:46:46 -0000 Subject: [issue1243] option.dest not set when callback called with optparse Message-ID: <1191800806.07.0.708813854965.issue1243@psf.upfronthosting.co.za> Guido van Rossum added the comment: Since you've done so much work debugging this, would you mind submitting a patch, including a unit test that confirms the desired behavior? ---------- nosy: +gvanrossum __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Oct 8 04:56:38 2007 From: report at bugs.python.org (Gregory P. Smith) Date: Mon, 08 Oct 2007 02:56:38 -0000 Subject: [issue1035] bytes buffer API needs to support read locking and/or PyBUF_LOCKDATA Message-ID: <1191812198.45.0.798982602603.issue1035@psf.upfronthosting.co.za> Gregory P. Smith added the comment: This bug will be taken care of by PEP 3137 http://python.org/dev/peps/pep-3137/ being implemented. Anyways, no the _bsddb.c changes that I checked in do not cause a problem because I checked them in using PyBUF_SIMPLE. Until PEP 3137 is implemented the possibility of hidden data corruption due to mutable bytes objects being modified while an IO library that releases the GIL is using them remains. Feel free to close this bug in favor of something that just tracks the PEP being implemented. __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Oct 8 05:46:41 2007 From: report at bugs.python.org (Brett Cannon) Date: Mon, 08 Oct 2007 03:46:41 -0000 Subject: [issue1035] bytes buffer API needs to support read locking and/or PyBUF_LOCKDATA In-Reply-To: <1191812198.45.0.798982602603.issue1035@psf.upfronthosting.co.za> Message-ID: Brett Cannon added the comment: On 10/7/07, Gregory P. Smith wrote: [SNIP] > Feel free to close this bug in favor of something that just tracks the > PEP being implemented. Eh, it can stay open as a reminder to double-check everything is fine once PEP 3137 goes in. It's really up to you since the bugs is assigned to you. =) __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Oct 8 07:49:28 2007 From: report at bugs.python.org (Alexander Shirokov) Date: Mon, 08 Oct 2007 05:49:28 -0000 Subject: [issue1244] Error on 'raise' does not show correct line number and Traceback message Message-ID: <1191822567.87.0.476542050297.issue1244@psf.upfronthosting.co.za> New submission from Alexander Shirokov: Please run debracket.py It halts immediately and the message explains the problem. Regards Alex ---------- files: debracket.py messages: 56265 nosy: alexander.shirokov severity: normal status: open title: Error on 'raise' does not show correct line number and Traceback message type: behavior versions: Python 2.5 __________________________________ Tracker __________________________________ -------------- next part -------------- A non-text attachment was scrubbed... Name: debracket.py Type: text/x-python Size: 3157 bytes Desc: not available Url : http://mail.python.org/pipermail/python-bugs-list/attachments/20071008/a66ffa2d/attachment.py From report at bugs.python.org Mon Oct 8 07:49:28 2007 From: report at bugs.python.org (Alexander Shirokov) Date: Mon, 08 Oct 2007 05:49:28 -0000 Subject: [issue1244] Error on 'raise' does not show correct line number and Traceback message Message-ID: <1191822567.87.0.476542050297.issue1244@psf.upfronthosting.co.za> New submission from Alexander Shirokov: Please run debracket.py It halts immediately and the message explains the problem. Regards Alex ---------- files: debracket.py messages: 56265 nosy: alexander.shirokov severity: normal status: open title: Error on 'raise' does not show correct line number and Traceback message type: behavior versions: Python 2.5 __________________________________ Tracker __________________________________ -------------- next part -------------- A non-text attachment was scrubbed... Name: debracket.py Type: text/x-python Size: 3157 bytes Desc: not available Url : http://mail.python.org/pipermail/python-bugs-list/attachments/20071008/a66ffa2d/attachment-0001.py From report at bugs.python.org Mon Oct 8 08:22:32 2007 From: report at bugs.python.org (Brett Cannon) Date: Mon, 08 Oct 2007 06:22:32 -0000 Subject: [issue1245] Document PySys_GetObject() Message-ID: <1191824552.71.0.744627118573.issue1245@psf.upfronthosting.co.za> New submission from Brett Cannon: PySys_GetObject() is not documented even though it is exposed as part of the public API. ---------- components: Documentation messages: 56266 nosy: brett.cannon priority: low severity: minor status: open title: Document PySys_GetObject() type: behavior versions: Python 2.6 __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Oct 8 08:22:33 2007 From: report at bugs.python.org (Brett Cannon) Date: Mon, 08 Oct 2007 06:22:33 -0000 Subject: [issue1245] Document PySys_GetObject() Message-ID: <1191824552.71.0.744627118573.issue1245@psf.upfronthosting.co.za> New submission from Brett Cannon: PySys_GetObject() is not documented even though it is exposed as part of the public API. ---------- components: Documentation messages: 56266 nosy: brett.cannon priority: low severity: minor status: open title: Document PySys_GetObject() type: behavior versions: Python 2.6 __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Oct 8 08:22:36 2007 From: report at bugs.python.org (Brett Cannon) Date: Mon, 08 Oct 2007 06:22:36 -0000 Subject: [issue1246] Document PySys_GetObject() Message-ID: <1191824556.45.0.43751222304.issue1246@psf.upfronthosting.co.za> New submission from Brett Cannon: PySys_GetObject() is not documented even though it is exposed as part of the public API. ---------- components: Documentation messages: 56267 nosy: brett.cannon priority: low severity: minor status: open title: Document PySys_GetObject() type: behavior versions: Python 2.6 __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Oct 8 08:22:36 2007 From: report at bugs.python.org (Brett Cannon) Date: Mon, 08 Oct 2007 06:22:36 -0000 Subject: [issue1246] Document PySys_GetObject() Message-ID: <1191824556.45.0.43751222304.issue1246@psf.upfronthosting.co.za> New submission from Brett Cannon: PySys_GetObject() is not documented even though it is exposed as part of the public API. ---------- components: Documentation messages: 56267 nosy: brett.cannon priority: low severity: minor status: open title: Document PySys_GetObject() type: behavior versions: Python 2.6 __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Oct 8 08:24:59 2007 From: report at bugs.python.org (Brett Cannon) Date: Mon, 08 Oct 2007 06:24:59 -0000 Subject: [issue1246] Document PySys_GetObject() Message-ID: <1191824699.21.0.401748508444.issue1246@psf.upfronthosting.co.za> Brett Cannon added the comment: Accidentally clicked the Submit button twice; exact dup of issue1245. ---------- resolution: -> duplicate status: open -> closed superseder: -> Document PySys_GetObject() __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Oct 8 09:08:11 2007 From: report at bugs.python.org (Georg Brandl) Date: Mon, 08 Oct 2007 07:08:11 -0000 Subject: [issue1244] Error on 'raise' does not show correct line number and Traceback message Message-ID: <1191827291.0.0.86273272349.issue1244@psf.upfronthosting.co.za> Georg Brandl added the comment: The raise statement without any arguments re-raises the last raised exception, complete with traceback, see http://docs.python.org/dev/reference/simple_stmts.html#the-raise-statement. Therefore your usage of the raise statement is incorrect; you should always use raise SomeException("some message") ---------- nosy: +georg.brandl resolution: -> invalid status: open -> closed __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Oct 8 09:22:32 2007 From: report at bugs.python.org (Alexander Shirokov) Date: Mon, 08 Oct 2007 07:22:32 -0000 Subject: [issue1244] Error on 'raise' does not show correct line number and Traceback message In-Reply-To: <1191827291.0.0.86273272349.issue1244@psf.upfronthosting.co.za> Message-ID: Alexander Shirokov added the comment: Dear Georg, Thank you for reply. Sorry, I thought it was a real bug. Best Regards, Alex On Mon, 8 Oct 2007, Georg Brandl wrote: > > Georg Brandl added the comment: > > The raise statement without any arguments re-raises the last raised > exception, complete with traceback, see > http://docs.python.org/dev/reference/simple_stmts.html#the-raise-statement. > > Therefore your usage of the raise statement is incorrect; you should > always use > > raise SomeException("some message") > > ---------- > nosy: +georg.brandl > resolution: -> invalid > status: open -> closed > > __________________________________ > Tracker > > __________________________________ > -- __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Oct 8 09:28:51 2007 From: report at bugs.python.org (Georg Brandl) Date: Mon, 08 Oct 2007 07:28:51 -0000 Subject: [issue1245] Document PySys_* API functions Message-ID: <1191828531.13.0.676803530009.issue1245@psf.upfronthosting.co.za> Georg Brandl added the comment: To generalize, almost all public PySys_* functions aren't documented yet. ---------- nosy: +georg.brandl title: Document PySys_GetObject() -> Document PySys_* API functions __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Oct 8 09:50:36 2007 From: report at bugs.python.org (Georg Brandl) Date: Mon, 08 Oct 2007 07:50:36 -0000 Subject: [issue1123] split(None, maxsplit) does not strip whitespace correctly Message-ID: <1191829836.29.0.168296475778.issue1123@psf.upfronthosting.co.za> Georg Brandl added the comment: This should now be fixed in r58368. ---------- nosy: +georg.brandl resolution: -> fixed status: open -> closed __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Oct 8 10:06:25 2007 From: report at bugs.python.org (Georg Brandl) Date: Mon, 08 Oct 2007 08:06:25 -0000 Subject: [issue1226] lib/sched.py superfluous code for removal Message-ID: <1191830785.51.0.0214928036804.issue1226@psf.upfronthosting.co.za> Georg Brandl added the comment: Done as part of r58369. ---------- nosy: +georg.brandl resolution: -> fixed status: open -> closed __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Oct 8 14:09:53 2007 From: report at bugs.python.org (Chris Withers) Date: Mon, 08 Oct 2007 12:09:53 -0000 Subject: [issue1243] option.dest not set when callback called with optparse Message-ID: <1191845393.86.0.406519190615.issue1243@psf.upfronthosting.co.za> Chris Withers added the comment: I'm not sure I fully understand where the fix should go but I'll put a note in to look into this. In the meantime, a good workaround is to supply an explicit destination: parser.add_option('--myopt',action='callback',callback=mycallback,dest='myopt') __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Oct 8 16:08:47 2007 From: report at bugs.python.org (Georg Brandl) Date: Mon, 08 Oct 2007 14:08:47 -0000 Subject: [issue1228] 3.0 tutorial/datastructures.rst patch Message-ID: <1191852527.32.0.0252607027804.issue1228@psf.upfronthosting.co.za> Georg Brandl added the comment: Applied in r58375, thanks! ---------- nosy: +georg.brandl resolution: -> accepted status: open -> closed __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Oct 8 16:13:01 2007 From: report at bugs.python.org (Georg Brandl) Date: Mon, 08 Oct 2007 14:13:01 -0000 Subject: [issue1199] Documentation for tp_as_number... version 2.6 Message-ID: <1191852781.41.0.418323069877.issue1199@psf.upfronthosting.co.za> Georg Brandl added the comment: Committed as r58376. ---------- resolution: -> accepted status: open -> closed __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Oct 8 16:30:43 2007 From: report at bugs.python.org (Raghuram Devarakonda) Date: Mon, 08 Oct 2007 14:30:43 -0000 Subject: [issue1243] option.dest not set when callback called with optparse Message-ID: <1191853843.43.0.0629450455073.issue1243@psf.upfronthosting.co.za> Raghuram Devarakonda added the comment: I have never used callbacks but went through the docs/code and I am not sure if there is a bug here. _check_dest() creates 'dest' only if 'type' is specified for the 'callback' option. With callbacks, it can not guess the type as there is no 'store' action. The document does say that without 'type', optparse does not know how many arguments to consume. I added 'type' to your example add_option() and all is well. Please correct me if I am missing some thing here. ---------- nosy: +draghuram __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Oct 8 16:32:34 2007 From: report at bugs.python.org (Chris Withers) Date: Mon, 08 Oct 2007 14:32:34 -0000 Subject: [issue1243] option.dest not set when callback called with optparse Message-ID: <1191853954.3.0.774470947607.issue1243@psf.upfronthosting.co.za> Chris Withers added the comment: But what type should I specify? I was using a callback to get a datetime object as an option... __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Oct 8 16:47:56 2007 From: report at bugs.python.org (Raghuram Devarakonda) Date: Mon, 08 Oct 2007 14:47:56 -0000 Subject: [issue1243] option.dest not set when callback called with optparse In-Reply-To: <1191853954.3.0.774470947607.issue1243@psf.upfronthosting.co.za> Message-ID: <2c51ecee0710080747q20e7b5l5ba67fef9d53da03@mail.gmail.com> Raghuram Devarakonda added the comment: > > But what type should I specify? > > I was using a callback to get a datetime object as an option... > If you are looking for a new type of option than what are already supported (string, int, long, choice, float and complex), you need to extend optparse (there is a section for that). I personally prefer a simple approach where the option value is taken as a string and any processing is done on the value to convert to what ever type of object one wants. For example, in this case, you can convert a string, say, 2007-10-8, internally to a datetime object. __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Oct 8 18:39:20 2007 From: report at bugs.python.org (=?utf-8?q?=0A=09=09=09=09=09Christian_Heimes=0A=09=09=09=09?=) Date: Mon, 08 Oct 2007 16:39:20 -0000 Subject: [issue1247] PEP 3137 patch (repr, names, parser) Message-ID: <1191861560.57.0.865268002143.issue1247@psf.upfronthosting.co.za> New submission from Christian Heimes : The patches changes: - change PyString's repr() to return "b'...'" - change PyBytes's repr() to return "buffer(b'...')" - change parser so that b"..." returns PyString, not PyBytes - rename bytes -> buffer, str8 -> bytes The patch breaks some unit test because some of the infrastructure like the new buffer() isn't in place yet. I'm not happy with bytes_repr() but the for loop with *p++ was the easiest way to implement it. Every other implementation I could think of was either too complicated or wouldn't work (like memcpy). ---------- components: Interpreter Core files: pep3137.patch messages: 56280 nosy: tiran severity: major status: open title: PEP 3137 patch (repr, names, parser) versions: Python 3.0 __________________________________ Tracker __________________________________ -------------- next part -------------- A non-text attachment was scrubbed... Name: pep3137.patch Type: text/x-diff Size: 8685 bytes Desc: not available Url : http://mail.python.org/pipermail/python-bugs-list/attachments/20071008/d5e76988/attachment-0002.patch From report at bugs.python.org Mon Oct 8 18:39:20 2007 From: report at bugs.python.org (=?utf-8?q?=0A=09=09=09=09=09Christian_Heimes=0A=09=09=09=09?=) Date: Mon, 08 Oct 2007 16:39:20 -0000 Subject: [issue1247] PEP 3137 patch (repr, names, parser) Message-ID: <1191861560.57.0.865268002143.issue1247@psf.upfronthosting.co.za> New submission from Christian Heimes : The patches changes: - change PyString's repr() to return "b'...'" - change PyBytes's repr() to return "buffer(b'...')" - change parser so that b"..." returns PyString, not PyBytes - rename bytes -> buffer, str8 -> bytes The patch breaks some unit test because some of the infrastructure like the new buffer() isn't in place yet. I'm not happy with bytes_repr() but the for loop with *p++ was the easiest way to implement it. Every other implementation I could think of was either too complicated or wouldn't work (like memcpy). ---------- components: Interpreter Core files: pep3137.patch messages: 56280 nosy: tiran severity: major status: open title: PEP 3137 patch (repr, names, parser) versions: Python 3.0 __________________________________ Tracker __________________________________ -------------- next part -------------- A non-text attachment was scrubbed... Name: pep3137.patch Type: text/x-diff Size: 8685 bytes Desc: not available Url : http://mail.python.org/pipermail/python-bugs-list/attachments/20071008/d5e76988/attachment-0003.patch From report at bugs.python.org Mon Oct 8 18:53:58 2007 From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=) Date: Mon, 08 Oct 2007 16:53:58 -0000 Subject: [issue1247] PEP 3137 patch (repr, names, parser) Message-ID: <1191862438.17.0.924179287081.issue1247@psf.upfronthosting.co.za> Changes by Martin v. L?wis: ---------- keywords: +patch __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Oct 8 22:12:04 2007 From: report at bugs.python.org (Brett Cannon) Date: Mon, 08 Oct 2007 20:12:04 -0000 Subject: [issue1248] ftplib needs a rewrite to use bytes/buffers Message-ID: <1191874324.3.0.017965594704.issue1248@psf.upfronthosting.co.za> New submission from Brett Cannon: For instance, ftplib.FTP reads from sockets using socket.makefile(), but in text mode. That's bad when the data could be in the format of ASCII or binary data. ---------- components: Library (Lib) keywords: py3k messages: 56281 nosy: brett.cannon priority: normal severity: major status: open title: ftplib needs a rewrite to use bytes/buffers versions: Python 3.0 __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Oct 8 22:12:04 2007 From: report at bugs.python.org (Brett Cannon) Date: Mon, 08 Oct 2007 20:12:04 -0000 Subject: [issue1248] ftplib needs a rewrite to use bytes/buffers Message-ID: <1191874324.3.0.017965594704.issue1248@psf.upfronthosting.co.za> New submission from Brett Cannon: For instance, ftplib.FTP reads from sockets using socket.makefile(), but in text mode. That's bad when the data could be in the format of ASCII or binary data. ---------- components: Library (Lib) keywords: py3k messages: 56281 nosy: brett.cannon priority: normal severity: major status: open title: ftplib needs a rewrite to use bytes/buffers versions: Python 3.0 __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Oct 9 05:28:29 2007 From: report at bugs.python.org (Alexandre Vassalotti) Date: Tue, 09 Oct 2007 03:28:29 -0000 Subject: [issue1247] PEP 3137 patch (repr, names, parser) Message-ID: <1191900509.0.0.757119949429.issue1247@psf.upfronthosting.co.za> Alexandre Vassalotti added the comment: I am not sure how the parser work, so I can't comment if your change to it is correct. It would probably a better idea to keep it for later, when the semantic differences between str8 and bytes objects will be resolved. I think changing b'' to buffer(b''), in the tests, is not a good idea. These tests will need to be changed again when bytes() will be changed to str8(). Your changes to PyString and PyBytes look good to me. As I said on the mailing list, I think the for-loops in bytes_repr() should be changed to: while (*quote_prefix) *p++ = *quote_prefix++; I attached updated patches with the above change. I also replaced bytes() for buffer() in PyBytes's docstrings. ---------- nosy: +alexandre.vassalotti __________________________________ Tracker __________________________________ -------------- next part -------------- A non-text attachment was scrubbed... Name: change_bytes_repr_for_buffer.patch Type: text/x-diff Size: 8943 bytes Desc: not available Url : http://mail.python.org/pipermail/python-bugs-list/attachments/20071009/86de2be8/attachment.patch From report at bugs.python.org Tue Oct 9 05:29:05 2007 From: report at bugs.python.org (Alexandre Vassalotti) Date: Tue, 09 Oct 2007 03:29:05 -0000 Subject: [issue1247] PEP 3137 patch (repr, names, parser) Message-ID: <1191900545.48.0.300666676824.issue1247@psf.upfronthosting.co.za> Changes by Alexandre Vassalotti: __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Oct 9 05:29:22 2007 From: report at bugs.python.org (Alexandre Vassalotti) Date: Tue, 09 Oct 2007 03:29:22 -0000 Subject: [issue1247] PEP 3137 patch (repr, names, parser) Message-ID: <1191900562.34.0.376812258392.issue1247@psf.upfronthosting.co.za> Changes by Alexandre Vassalotti: __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Oct 9 07:43:14 2007 From: report at bugs.python.org (Brett Cannon) Date: Tue, 09 Oct 2007 05:43:14 -0000 Subject: [issue1631171] implement warnings module in C Message-ID: <1191908594.32.0.178352276426.issue1631171@psf.upfronthosting.co.za> Brett Cannon added the comment: I have uploaded my touched up version of _warnings.c . I also have a new diff since the old one did not apply cleanly (test_warnings didn't get patched nor did PCbuild8). It also lacked the changes needed to Modules/config.c . It is still not complete, though. Some things are missing from _warnings.c and test_warnings is completely failing. But I figured I should get something uploaded so that other people can help if they want. _____________________________________ Tracker _____________________________________ -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: _warnings.c Url: http://mail.python.org/pipermail/python-bugs-list/attachments/20071009/3adfbc5e/attachment-0001.txt From report at bugs.python.org Tue Oct 9 07:43:48 2007 From: report at bugs.python.org (Brett Cannon) Date: Tue, 09 Oct 2007 05:43:48 -0000 Subject: [issue1631171] implement warnings module in C Message-ID: <1191908628.87.0.869410748432.issue1631171@psf.upfronthosting.co.za> Changes by Brett Cannon: _____________________________________ Tracker _____________________________________ From report at bugs.python.org Tue Oct 9 15:38:28 2007 From: report at bugs.python.org (Thomas Lee) Date: Tue, 09 Oct 2007 13:38:28 -0000 Subject: [issue1249] PEP 3137 patch: make PyBytes/PyUnicode ==/!= comparisons return False Message-ID: <1191937107.83.0.816091478678.issue1249@psf.upfronthosting.co.za> New submission from Thomas Lee: Initial patch attached. ---------- components: Interpreter Core files: bytes-unicode-return-false-r1.patch messages: 56284 nosy: thomas.lee severity: normal status: open title: PEP 3137 patch: make PyBytes/PyUnicode ==/!= comparisons return False type: rfe versions: Python 3.0 __________________________________ Tracker __________________________________ -------------- next part -------------- A non-text attachment was scrubbed... Name: bytes-unicode-return-false-r1.patch Type: text/x-patch Size: 1581 bytes Desc: not available Url : http://mail.python.org/pipermail/python-bugs-list/attachments/20071009/0faf8ac7/attachment.bin From report at bugs.python.org Tue Oct 9 15:38:27 2007 From: report at bugs.python.org (Thomas Lee) Date: Tue, 09 Oct 2007 13:38:27 -0000 Subject: [issue1249] PEP 3137 patch: make PyBytes/PyUnicode ==/!= comparisons return False Message-ID: <1191937107.83.0.816091478678.issue1249@psf.upfronthosting.co.za> New submission from Thomas Lee: Initial patch attached. ---------- components: Interpreter Core files: bytes-unicode-return-false-r1.patch messages: 56284 nosy: thomas.lee severity: normal status: open title: PEP 3137 patch: make PyBytes/PyUnicode ==/!= comparisons return False type: rfe versions: Python 3.0 __________________________________ Tracker __________________________________ -------------- next part -------------- A non-text attachment was scrubbed... Name: bytes-unicode-return-false-r1.patch Type: text/x-patch Size: 1581 bytes Desc: not available Url : http://mail.python.org/pipermail/python-bugs-list/attachments/20071009/0faf8ac7/attachment-0001.bin From report at bugs.python.org Tue Oct 9 18:05:42 2007 From: report at bugs.python.org (Thomas Lee) Date: Tue, 09 Oct 2007 16:05:42 -0000 Subject: [issue1249] PEP 3137 patch: PyBytes/PyUnicode comparisons Message-ID: <1191945942.24.0.514584630055.issue1249@psf.upfronthosting.co.za> Thomas Lee added the comment: Revised patch - originally misinterpreted what was required here. bytes() == str() now returns False, bytes() != str() now returns True. ---------- title: PEP 3137 patch: make PyBytes/PyUnicode ==/!= comparisons return False -> PEP 3137 patch: PyBytes/PyUnicode comparisons __________________________________ Tracker __________________________________ -------------- next part -------------- A non-text attachment was scrubbed... Name: bytes-unicode-eq-false-r2.patch Type: text/x-patch Size: 1886 bytes Desc: not available Url : http://mail.python.org/pipermail/python-bugs-list/attachments/20071009/51a84bfc/attachment.bin From report at bugs.python.org Tue Oct 9 19:03:55 2007 From: report at bugs.python.org (Guido van Rossum) Date: Tue, 09 Oct 2007 17:03:55 -0000 Subject: [issue1249] PEP 3137 patch: PyBytes/PyUnicode comparisons Message-ID: <1191949435.3.0.881312510263.issue1249@psf.upfronthosting.co.za> Changes by Guido van Rossum: ---------- assignee: -> gvanrossum nosy: +gvanrossum __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Oct 9 19:21:20 2007 From: report at bugs.python.org (Guido van Rossum) Date: Tue, 09 Oct 2007 17:21:20 -0000 Subject: [issue1249] PEP 3137 patch: PyBytes/PyUnicode comparisons Message-ID: <1191950480.91.0.476861069462.issue1249@psf.upfronthosting.co.za> Guido van Rossum added the comment: Thanks! This patch looks fine, except the PyClear() call is unnecessary. I suppose you copied it from the similar return clauses further down, but there they clear an exception set by the _getbuffer() call. But just calling PyObject_IsInstance() cannot set an exception. Committed revision 58390. ---------- resolution: -> accepted status: open -> closed __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Oct 9 19:22:44 2007 From: report at bugs.python.org (Guido van Rossum) Date: Tue, 09 Oct 2007 17:22:44 -0000 Subject: [issue1247] PEP 3137 patch (repr, names, parser) Message-ID: <1191950564.5.0.673953872746.issue1247@psf.upfronthosting.co.za> Guido van Rossum added the comment: GHave you two agreed yet as to which patch(es) I should look at? ---------- nosy: +gvanrossum __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Oct 9 19:55:15 2007 From: report at bugs.python.org (Brett Cannon) Date: Tue, 09 Oct 2007 17:55:15 -0000 Subject: [issue1631171] implement warnings module in C Message-ID: <1191952515.06.0.0459239939609.issue1631171@psf.upfronthosting.co.za> Brett Cannon added the comment: I just tried Neal's version of _warnings.c and it has the same failures, so they are not my fault. =) _____________________________________ Tracker _____________________________________ From report at bugs.python.org Tue Oct 9 20:19:06 2007 From: report at bugs.python.org (Christian Heimes) Date: Tue, 09 Oct 2007 18:19:06 -0000 Subject: [issue1247] PEP 3137 patch (repr, names, parser) In-Reply-To: <1191950564.5.0.673953872746.issue1247@psf.upfronthosting.co.za> Message-ID: <470BC615.3010003@cheimes.de> Christian Heimes added the comment: Guido van Rossum wrote: > Guido van Rossum added the comment: > > GHave you two agreed yet as to which patch(es) I should look at? Please commit Alexandres patch. His patch for bytesobject.c is based on my patch. It's more complete and a bit better than mine, too. I'm going to create a new patch for the other tasks later. __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Oct 9 21:32:28 2007 From: report at bugs.python.org (Kurt B. Kaiser) Date: Tue, 09 Oct 2007 19:32:28 -0000 Subject: [issue1225] IDLE - Fix: pressing Ctrl+C while printing exception -> stuck Message-ID: <1191958348.4.0.807746628371.issue1225@psf.upfronthosting.co.za> Kurt B. Kaiser added the comment: r58396 Thanks for the patch! ---------- assignee: -> kbk priority: -> normal resolution: -> accepted status: open -> closed __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Oct 9 21:53:18 2007 From: report at bugs.python.org (Brett Cannon) Date: Tue, 09 Oct 2007 19:53:18 -0000 Subject: [issue1631171] implement warnings module in C Message-ID: <1191959598.03.0.105570448043.issue1631171@psf.upfronthosting.co.za> Brett Cannon added the comment: I figured out why the tests are all failing; the C code does not call back into the Python 'warnings' wrapper. For instance, warn_explicit in the C code does not ever try to use a user-provided showwarning() function. This causes the tests to fail as they rely on this functionality. There is also the issue of the filters and once_registry also only be referenced in the C code and not in the Python code. So while the list and dict, respectively, are assigned in warnings.py from _warnings.c, the C code never checks to see if the attributes in the Python code were changed. This is an issue as a lot of times code does:: warnings.filter = [] ... code ... warnings.filter = original_filter That will not work with how it is implemented now as the C code only works off of the object it created and never one that a user may have provided. Could a descriptor be written so that when the Python code has the filter, once_registry, or showwarnings set it actually gets set in the C code? That way the C code can continue to be fully independent of the Python code and not have to import it unless a specific change was attempted upon 'warnings'? _____________________________________ Tracker _____________________________________ From report at bugs.python.org Tue Oct 9 21:58:03 2007 From: report at bugs.python.org (Raghuram Devarakonda) Date: Tue, 09 Oct 2007 19:58:03 -0000 Subject: [issue1713041] fix for 1712742: corrects pprint's handling of 'depth' Message-ID: <1191959883.46.0.282929614532.issue1713041@psf.upfronthosting.co.za> Raghuram Devarakonda added the comment: I was just searching for all my issues and found this one. Can some one please apply pprint.patch? Thanks. _____________________________________ Tracker _____________________________________ From report at bugs.python.org Tue Oct 9 23:10:52 2007 From: report at bugs.python.org (anilj) Date: Tue, 09 Oct 2007 21:10:52 -0000 Subject: [issue1250] Building external modules using Sun Studio 12 Message-ID: <1191964251.86.0.558465608726.issue1250@psf.upfronthosting.co.za> New submission from anilj: When compiling matplotlib, ditutils defaults to using /opt/SUNWspro/bin/cc but it needs to use /opt/SUNWspro/bin/CC for compiling c++ files. % python2.5 setup.py build building for GTK requires pygtk; you must be able to "import gtk" in your build/install environmentTKAgg requires TkInter running build running build_py copying lib/matplotlib/mpl-data/matplotlibrc -> build/lib.solaris-2.10-i86pc-2.5/matplotlib/mpl-data running build_ext building 'matplotlib._agg' extension /opt/SUNWspro/bin/cc -DNDEBUG -O -fast -xipo -xtarget=opteron -Kpic -Iagg23/include -Isrc -Iswig -I/usr/local/include/python2.5 -c src/agg.cxx -o build/temp.solaris-2.10-i86pc-2.5/src/agg.o cc: No input file specified, no output generated error: command '/opt/SUNWspro/bin/cc' failed with exit status 1 % python2.5 setup.py build --help-compiler building for GTK requires pygtk; you must be able to "import gtk" in your build/install environmentTKAgg requires TkInter List of available compilers: --compiler=bcpp Borland C++ Compiler --compiler=cygwin Cygwin port of GNU C Compiler for Win32 --compiler=emx EMX port of GNU C Compiler for OS/2 --compiler=mingw32 Mingw32 port of GNU C Compiler for Win32 --compiler=msvc Microsoft Visual C++ --compiler=mwerks MetroWerks CodeWarrior --compiler=unix standard UNIX-style compiler Doesn't look like I can override the default compiler using the above options. Thanks. ---------- components: Distutils messages: 56293 nosy: anilj severity: normal status: open title: Building external modules using Sun Studio 12 type: compile error versions: Python 2.5 __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Oct 9 23:10:51 2007 From: report at bugs.python.org (anilj) Date: Tue, 09 Oct 2007 21:10:51 -0000 Subject: [issue1250] Building external modules using Sun Studio 12 Message-ID: <1191964251.86.0.558465608726.issue1250@psf.upfronthosting.co.za> New submission from anilj: When compiling matplotlib, ditutils defaults to using /opt/SUNWspro/bin/cc but it needs to use /opt/SUNWspro/bin/CC for compiling c++ files. % python2.5 setup.py build building for GTK requires pygtk; you must be able to "import gtk" in your build/install environmentTKAgg requires TkInter running build running build_py copying lib/matplotlib/mpl-data/matplotlibrc -> build/lib.solaris-2.10-i86pc-2.5/matplotlib/mpl-data running build_ext building 'matplotlib._agg' extension /opt/SUNWspro/bin/cc -DNDEBUG -O -fast -xipo -xtarget=opteron -Kpic -Iagg23/include -Isrc -Iswig -I/usr/local/include/python2.5 -c src/agg.cxx -o build/temp.solaris-2.10-i86pc-2.5/src/agg.o cc: No input file specified, no output generated error: command '/opt/SUNWspro/bin/cc' failed with exit status 1 % python2.5 setup.py build --help-compiler building for GTK requires pygtk; you must be able to "import gtk" in your build/install environmentTKAgg requires TkInter List of available compilers: --compiler=bcpp Borland C++ Compiler --compiler=cygwin Cygwin port of GNU C Compiler for Win32 --compiler=emx EMX port of GNU C Compiler for OS/2 --compiler=mingw32 Mingw32 port of GNU C Compiler for Win32 --compiler=msvc Microsoft Visual C++ --compiler=mwerks MetroWerks CodeWarrior --compiler=unix standard UNIX-style compiler Doesn't look like I can override the default compiler using the above options. Thanks. ---------- components: Distutils messages: 56293 nosy: anilj severity: normal status: open title: Building external modules using Sun Studio 12 type: compile error versions: Python 2.5 __________________________________ Tracker __________________________________ From report at bugs.python.org Wed Oct 10 00:46:33 2007 From: report at bugs.python.org (Guido van Rossum) Date: Tue, 09 Oct 2007 22:46:33 -0000 Subject: [issue1247] PEP 3137 patch (repr, names, parser) Message-ID: <1191969993.07.0.592235138587.issue1247@psf.upfronthosting.co.za> Guido van Rossum added the comment: I don't think I can check these in yet; right now they are inconsistent. But I will check them in when they are ready. ---------- assignee: -> gvanrossum __________________________________ Tracker __________________________________ From report at bugs.python.org Wed Oct 10 00:48:18 2007 From: report at bugs.python.org (Chris Stawarz) Date: Tue, 09 Oct 2007 22:48:18 -0000 Subject: [issue1251] ssl module doesn't support non-blocking handshakes Message-ID: <1191970098.04.0.2942232647.issue1251@psf.upfronthosting.co.za> New submission from Chris Stawarz: The current version of the ssl module doesn't support non-blocking creation of SSLSocket objects. The reason for this is that the SSL handshaking (SSL_connect/SSL_accept) takes place during the construction of the SSLContext object (in newPySSLObject). This means that if the socket being wrapped is non-blocking, and the handshake fails with SSL_ERROR_WANT_READ/SSL_ERROR_WANT_WRITE, then the entire SSLContext is scrapped, and newPySSLObject must be run again in its entirety. Unfortunately, restarting from scratch on the same socket appears to confuse the remote host, and the new attempt fails. The attached patch fixes this problem by removing the handshaking code from newPySSLObject and adding a do_handshake method to SSLContext. It also adds a new parameter (do_handshake_on_connect) to the SSLSocket constructor and the wrap_socket function. The default value of the parameter is True, which preserves the current behavior of the module by immediately calling do_handshake after sslwrap. If do_handshake_on_connect is set to False, then the caller is responsible for calling do_handshake. This allows code that uses non-blocking sockets to first create the SSLSocket and then iteratively call do_handshake and select.select until the process completes (which is exactly how non-blocking reads and writes are handled). ---------- components: Documentation, Library (Lib), Tests files: ssl_nonblocking_handshake_patch.txt messages: 56295 nosy: chris.stawarz severity: normal status: open title: ssl module doesn't support non-blocking handshakes type: rfe versions: Python 2.6 __________________________________ Tracker __________________________________ -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: ssl_nonblocking_handshake_patch.txt Url: http://mail.python.org/pipermail/python-bugs-list/attachments/20071009/6af5321f/attachment-0002.txt From report at bugs.python.org Wed Oct 10 00:48:18 2007 From: report at bugs.python.org (Chris Stawarz) Date: Tue, 09 Oct 2007 22:48:18 -0000 Subject: [issue1251] ssl module doesn't support non-blocking handshakes Message-ID: <1191970098.04.0.2942232647.issue1251@psf.upfronthosting.co.za> New submission from Chris Stawarz: The current version of the ssl module doesn't support non-blocking creation of SSLSocket objects. The reason for this is that the SSL handshaking (SSL_connect/SSL_accept) takes place during the construction of the SSLContext object (in newPySSLObject). This means that if the socket being wrapped is non-blocking, and the handshake fails with SSL_ERROR_WANT_READ/SSL_ERROR_WANT_WRITE, then the entire SSLContext is scrapped, and newPySSLObject must be run again in its entirety. Unfortunately, restarting from scratch on the same socket appears to confuse the remote host, and the new attempt fails. The attached patch fixes this problem by removing the handshaking code from newPySSLObject and adding a do_handshake method to SSLContext. It also adds a new parameter (do_handshake_on_connect) to the SSLSocket constructor and the wrap_socket function. The default value of the parameter is True, which preserves the current behavior of the module by immediately calling do_handshake after sslwrap. If do_handshake_on_connect is set to False, then the caller is responsible for calling do_handshake. This allows code that uses non-blocking sockets to first create the SSLSocket and then iteratively call do_handshake and select.select until the process completes (which is exactly how non-blocking reads and writes are handled). ---------- components: Documentation, Library (Lib), Tests files: ssl_nonblocking_handshake_patch.txt messages: 56295 nosy: chris.stawarz severity: normal status: open title: ssl module doesn't support non-blocking handshakes type: rfe versions: Python 2.6 __________________________________ Tracker __________________________________ -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: ssl_nonblocking_handshake_patch.txt Url: http://mail.python.org/pipermail/python-bugs-list/attachments/20071009/6af5321f/attachment-0003.txt From report at bugs.python.org Wed Oct 10 01:13:37 2007 From: report at bugs.python.org (Kurt B. Kaiser) Date: Tue, 09 Oct 2007 23:13:37 -0000 Subject: [issue1130] Idle - Save (buffer) - closes IDLE and does not save file (Windows XP) Message-ID: <1191971617.67.0.763402500332.issue1130@psf.upfronthosting.co.za> Kurt B. Kaiser added the comment: r58398. Thanks for the report. Solution a little different than Tal Einat's. Please test. ---------- resolution: -> fixed status: open -> closed __________________________________ Tracker __________________________________ From report at bugs.python.org Wed Oct 10 01:27:03 2007 From: report at bugs.python.org (Brett Cannon) Date: Tue, 09 Oct 2007 23:27:03 -0000 Subject: [issue1238] dictobject and dictentry not used consistently in dictobject.c Message-ID: <1191972423.74.0.775232945164.issue1238@psf.upfronthosting.co.za> Brett Cannon added the comment: I went ahead and had Vim do a global search-and-replace on the names and ditched the typedefs; the patch is uploaded. I have not yet run the test suite, though, which is why I have not committed it. But if it passes I will just check it in. ---------- assignee: -> brett.cannon __________________________________ Tracker __________________________________ -------------- next part -------------- A non-text attachment was scrubbed... Name: dict_cleanup.diff Type: application/octet-stream Size: 18321 bytes Desc: not available Url : http://mail.python.org/pipermail/python-bugs-list/attachments/20071009/5314f940/attachment.obj From report at bugs.python.org Wed Oct 10 01:44:07 2007 From: report at bugs.python.org (Kurt B. Kaiser) Date: Tue, 09 Oct 2007 23:44:07 -0000 Subject: [issue1775388] Display CallTips for classes using metaclasses. Message-ID: <1191973447.11.0.880727141425.issue1775388@psf.upfronthosting.co.za> Kurt B. Kaiser added the comment: Appears this was fixed at r55818, though with a typo. Module heavily rewritten since then to use the inspect module. The example below now works without further changes. ---------- resolution: -> out of date status: open -> closed _____________________________________ Tracker _____________________________________ From report at bugs.python.org Wed Oct 10 01:48:07 2007 From: report at bugs.python.org (Kurt B. Kaiser) Date: Tue, 09 Oct 2007 23:48:07 -0000 Subject: [issue1713252] character set in Japanese on Ubuntu distribution Message-ID: <1191973687.92.0.495720655757.issue1713252@psf.upfronthosting.co.za> Kurt B. Kaiser added the comment: absent further response, closing as unreproducible. ---------- assignee: -> kbk keywords: +patch nosy: +kbk resolution: fixed -> works for me status: open -> closed _____________________________________ Tracker _____________________________________ From report at bugs.python.org Wed Oct 10 02:08:51 2007 From: report at bugs.python.org (Brett Cannon) Date: Wed, 10 Oct 2007 00:08:51 -0000 Subject: [issue1238] dictobject and dictentry not used consistently in dictobject.c Message-ID: <1191974931.58.0.272212914713.issue1238@psf.upfronthosting.co.za> Brett Cannon added the comment: Applied my patch in r58399. Thanks for noticing the inconsistency, anthon! ---------- resolution: -> fixed status: open -> closed __________________________________ Tracker __________________________________ From report at bugs.python.org Wed Oct 10 02:17:22 2007 From: report at bugs.python.org (Tal Einat) Date: Wed, 10 Oct 2007 00:17:22 -0000 Subject: [issue1130] Idle - Save (buffer) - closes IDLE and does not save file (Windows XP) Message-ID: <1191975442.49.0.548958443636.issue1130@psf.upfronthosting.co.za> Tal Einat added the comment: Your solution is better than my suggestion, but has two minor bugs: 1) eol_convention must be initialized somewhere. For instance, opening a new editor window (Ctrl+N) and saving it fails because self.eol_convention is not defined. I agree that is shouldn't be a class attribute, but it must be intialized in __init__. 2) You meant chars = self.encode(text), right? (otherwise the eol change is discraded...) __________________________________ Tracker __________________________________ From report at bugs.python.org Wed Oct 10 02:42:30 2007 From: report at bugs.python.org (Kurt B. Kaiser) Date: Wed, 10 Oct 2007 00:42:30 -0000 Subject: [issue1710718] Ctrl+Shift block marking by words Message-ID: <1191976950.36.0.81043051564.issue1710718@psf.upfronthosting.co.za> Kurt B. Kaiser added the comment: Ctrl- right does jump to the ends. Behaviour is slightly strange, but useful. Let Tk handle it. ---------- keywords: +patch resolution: -> works for me status: open -> closed _____________________________________ Tracker _____________________________________ From report at bugs.python.org Wed Oct 10 02:44:29 2007 From: report at bugs.python.org (Kurt B. Kaiser) Date: Wed, 10 Oct 2007 00:44:29 -0000 Subject: [issue1691411] Duplicate "preferences" menu item/Tk Aqua 8.4.14 Message-ID: <1191977069.95.0.681669932089.issue1691411@psf.upfronthosting.co.za> Changes by Kurt B. Kaiser: ---------- assignee: -> ronaldoussoren nosy: +ronaldoussoren _____________________________________ Tracker _____________________________________ From report at bugs.python.org Wed Oct 10 02:44:48 2007 From: report at bugs.python.org (Kurt B. Kaiser) Date: Wed, 10 Oct 2007 00:44:48 -0000 Subject: [issue1691411] Duplicate "preferences" menu item/Tk Aqua 8.4.14 Message-ID: <1191977088.29.0.619506983893.issue1691411@psf.upfronthosting.co.za> Changes by Kurt B. Kaiser: ---------- keywords: +patch _____________________________________ Tracker _____________________________________ From report at bugs.python.org Wed Oct 10 02:56:22 2007 From: report at bugs.python.org (Kurt B. Kaiser) Date: Wed, 10 Oct 2007 00:56:22 -0000 Subject: [issue1725576] IDLE - cursor color configuration bug Message-ID: <1191977782.4.0.0198768976687.issue1725576@psf.upfronthosting.co.za> Kurt B. Kaiser added the comment: r58403. Thanks for the patch! ---------- assignee: -> kbk nosy: +kbk resolution: -> accepted status: open -> closed _____________________________________ Tracker _____________________________________ From report at bugs.python.org Wed Oct 10 03:07:25 2007 From: report at bugs.python.org (Kurt B. Kaiser) Date: Wed, 10 Oct 2007 01:07:25 -0000 Subject: [issue1659326] Minor pasting patch Message-ID: <1191978445.49.0.961739284485.issue1659326@psf.upfronthosting.co.za> Kurt B. Kaiser added the comment: r58404. Thanks for the patch! ---------- assignee: -> kbk nosy: +kbk resolution: -> accepted status: open -> closed _____________________________________ Tracker _____________________________________ From report at bugs.python.org Wed Oct 10 04:06:52 2007 From: report at bugs.python.org (Tal Einat) Date: Wed, 10 Oct 2007 02:06:52 -0000 Subject: [issue1252] IDLE - patch Delegator to support callables Message-ID: <1191982010.97.0.724994014869.issue1252@psf.upfronthosting.co.za> New submission from Tal Einat: Add an __call__ magic method to Delegator so that it can delegate to callables. This will raise the required exception if the delegate isn't callable. The built-in callable() method will now return True for any Delegator. Before this patch it always returns False, which is wrong if the delegate is callable, so callable() doesn't really work on Delegator instances in both cases. I couldn't see how this could be harmful. Also make the Delegator class a new-style class. This patch is required for the Squeezer and ShellLogger IDLE extensions found on PyPI to be able to co-exist. ---------- components: IDLE files: IDLE_Delegator.071010.patch messages: 56305 nosy: kbk, taleinat severity: normal status: open title: IDLE - patch Delegator to support callables type: behavior versions: Python 2.5, Python 2.6 __________________________________ Tracker __________________________________ -------------- next part -------------- A non-text attachment was scrubbed... Name: IDLE_Delegator.071010.patch Type: application/octet-stream Size: 639 bytes Desc: not available Url : http://mail.python.org/pipermail/python-bugs-list/attachments/20071010/7af481a2/attachment.obj From report at bugs.python.org Wed Oct 10 04:06:51 2007 From: report at bugs.python.org (Tal Einat) Date: Wed, 10 Oct 2007 02:06:51 -0000 Subject: [issue1252] IDLE - patch Delegator to support callables Message-ID: <1191982010.97.0.724994014869.issue1252@psf.upfronthosting.co.za> New submission from Tal Einat: Add an __call__ magic method to Delegator so that it can delegate to callables. This will raise the required exception if the delegate isn't callable. The built-in callable() method will now return True for any Delegator. Before this patch it always returns False, which is wrong if the delegate is callable, so callable() doesn't really work on Delegator instances in both cases. I couldn't see how this could be harmful. Also make the Delegator class a new-style class. This patch is required for the Squeezer and ShellLogger IDLE extensions found on PyPI to be able to co-exist. ---------- components: IDLE files: IDLE_Delegator.071010.patch messages: 56305 nosy: kbk, taleinat severity: normal status: open title: IDLE - patch Delegator to support callables type: behavior versions: Python 2.5, Python 2.6 __________________________________ Tracker __________________________________ -------------- next part -------------- A non-text attachment was scrubbed... Name: IDLE_Delegator.071010.patch Type: application/octet-stream Size: 639 bytes Desc: not available Url : http://mail.python.org/pipermail/python-bugs-list/attachments/20071010/7af481a2/attachment-0001.obj From report at bugs.python.org Wed Oct 10 04:17:04 2007 From: report at bugs.python.org (Tal Einat) Date: Wed, 10 Oct 2007 02:17:04 -0000 Subject: [issue1253] IDLE - Percolator overhaul Message-ID: <1191982624.13.0.198270020748.issue1253@psf.upfronthosting.co.za> New submission from Tal Einat: The Percolator class has been very hard to figure out, and has been a source of confusion for users wanting to "hack" IDLE. This patch makes Percolator a generally useful class which inherits from Delegator. It also adds a new class, TkTextPercolator, which inherits from Percolator and does all of the Text widget specific stuff. The code has been refactored, cleaned up, and the in-code comments have been improved. UndoDelegator.py, ColorDelegator.py and EditorWindow.py have been updated as needed. Also, the code using ColorDelegator in EditorWindow.py has been slightly modified to work better with the Percolator. I've done some testing (only on WinXP but nothing here is platform specific) and this seems to work without a hitch. This patch is required for the Squeezer and ShellLogger IDLE extensions found on PyPI to be able to co-exist. ---------- components: IDLE files: IDLE_Percolator.071010.patch messages: 56306 nosy: kbk, taleinat severity: normal status: open title: IDLE - Percolator overhaul type: behavior versions: Python 2.5, Python 2.6 __________________________________ Tracker __________________________________ -------------- next part -------------- A non-text attachment was scrubbed... Name: IDLE_Percolator.071010.patch Type: application/octet-stream Size: 8896 bytes Desc: not available Url : http://mail.python.org/pipermail/python-bugs-list/attachments/20071010/c1395c12/attachment-0001.obj From report at bugs.python.org Wed Oct 10 04:17:04 2007 From: report at bugs.python.org (Tal Einat) Date: Wed, 10 Oct 2007 02:17:04 -0000 Subject: [issue1253] IDLE - Percolator overhaul Message-ID: <1191982624.13.0.198270020748.issue1253@psf.upfronthosting.co.za> New submission from Tal Einat: The Percolator class has been very hard to figure out, and has been a source of confusion for users wanting to "hack" IDLE. This patch makes Percolator a generally useful class which inherits from Delegator. It also adds a new class, TkTextPercolator, which inherits from Percolator and does all of the Text widget specific stuff. The code has been refactored, cleaned up, and the in-code comments have been improved. UndoDelegator.py, ColorDelegator.py and EditorWindow.py have been updated as needed. Also, the code using ColorDelegator in EditorWindow.py has been slightly modified to work better with the Percolator. I've done some testing (only on WinXP but nothing here is platform specific) and this seems to work without a hitch. This patch is required for the Squeezer and ShellLogger IDLE extensions found on PyPI to be able to co-exist. ---------- components: IDLE files: IDLE_Percolator.071010.patch messages: 56306 nosy: kbk, taleinat severity: normal status: open title: IDLE - Percolator overhaul type: behavior versions: Python 2.5, Python 2.6 __________________________________ Tracker __________________________________ -------------- next part -------------- A non-text attachment was scrubbed... Name: IDLE_Percolator.071010.patch Type: application/octet-stream Size: 8896 bytes Desc: not available Url : http://mail.python.org/pipermail/python-bugs-list/attachments/20071010/c1395c12/attachment-0002.obj From report at bugs.python.org Wed Oct 10 05:18:36 2007 From: report at bugs.python.org (Guido van Rossum) Date: Wed, 10 Oct 2007 03:18:36 -0000 Subject: [issue1251] ssl module doesn't support non-blocking handshakes Message-ID: <1191986316.92.0.784646408255.issue1251@psf.upfronthosting.co.za> Guido van Rossum added the comment: Assigning to Bill Janssen. ---------- assignee: -> janssen nosy: +gvanrossum, janssen __________________________________ Tracker __________________________________ From report at bugs.python.org Wed Oct 10 05:21:52 2007 From: report at bugs.python.org (Guido van Rossum) Date: Wed, 10 Oct 2007 03:21:52 -0000 Subject: [issue1253] IDLE - Percolator overhaul Message-ID: <1191986512.38.0.883627872312.issue1253@psf.upfronthosting.co.za> Guido van Rossum added the comment: It's been too long since I wrote this code to be able to review, but I'm glad that it still gets some love and attention. Here's to hoping that your patch gets applied. ---------- nosy: +gvanrossum __________________________________ Tracker __________________________________ From report at bugs.python.org Wed Oct 10 06:09:24 2007 From: report at bugs.python.org (Bill Janssen) Date: Wed, 10 Oct 2007 04:09:24 -0000 Subject: [issue1251] ssl module doesn't support non-blocking handshakes Message-ID: <1191989364.71.0.974571872838.issue1251@psf.upfronthosting.co.za> Bill Janssen added the comment: By a bit of synchronicity, I've been looking at non-blocking SSL issues all day. Thanks, Chris. I'll take a look and fold it in. There are a number of other issues here, too, such as changing the socket's blocking- ness after it's wrapped (which asyncore does). __________________________________ Tracker __________________________________ From report at bugs.python.org Wed Oct 10 08:03:02 2007 From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=) Date: Wed, 10 Oct 2007 06:03:02 -0000 Subject: [issue1252] IDLE - patch Delegator to support callables Message-ID: <1191996182.2.0.479016399954.issue1252@psf.upfronthosting.co.za> Changes by Martin v. L?wis: ---------- keywords: +patch __________________________________ Tracker __________________________________ From report at bugs.python.org Wed Oct 10 08:03:12 2007 From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=) Date: Wed, 10 Oct 2007 06:03:12 -0000 Subject: [issue1253] IDLE - Percolator overhaul Message-ID: <1191996192.96.0.570604959496.issue1253@psf.upfronthosting.co.za> Changes by Martin v. L?wis: ---------- keywords: +patch __________________________________ Tracker __________________________________ From report at bugs.python.org Wed Oct 10 08:12:47 2007 From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=) Date: Wed, 10 Oct 2007 06:12:47 -0000 Subject: [issue1541420] tools and demo missing from windows Message-ID: <1191996767.62.0.0206006261521.issue1541420@psf.upfronthosting.co.za> Martin v. L?wis added the comment: I'm closing it as "won't fix". If you have specific tools that you would like to see included, please submit that as a separate report, along with a rationale as to why you want to see them included. ---------- resolution: -> wont fix status: open -> closed _____________________________________ Tracker _____________________________________ From report at bugs.python.org Wed Oct 10 14:27:17 2007 From: report at bugs.python.org (Bill Janssen) Date: Wed, 10 Oct 2007 12:27:17 -0000 Subject: [issue1251] ssl module doesn't support non-blocking handshakes Message-ID: <1192019236.92.0.583332636267.issue1251@psf.upfronthosting.co.za> Bill Janssen added the comment: The larger problem here is that straightforward select() just doesn't work with SSL-wrapped sockets. If you depend on it for liveness, your program will eventually hang up. When packets in SSL arrive at a destination, they are pulled off the socket in chunks of sizes controlled by the encryption protocol being used, decrypted, and placed in SSL-internal buffers. The buffer content is then transferred to the application program through SSL_read(). If you've read only part of the decrypted data, there will still be pending input data on the SSL connection, but it won't show up on the underlying file descriptor via select(). Your code needs to call SSL_pending() explicitly to see if there is any pending data to be read. __________________________________ Tracker __________________________________ From report at bugs.python.org Wed Oct 10 16:02:30 2007 From: report at bugs.python.org (Romain JACQUET) Date: Wed, 10 Oct 2007 14:02:30 -0000 Subject: [issue1254] pdb fails to launch some script. Message-ID: <1192024950.07.0.645250068829.issue1254@psf.upfronthosting.co.za> New submission from Romain JACQUET: Pdb fails to launch any scripts that uses the __file__ builtin. This problem occurs because pdb does not set the global environnement correctly. It can be corrected by setting the global variable __file__ before pdb executes the file. Lib/pdb.py: Replace : globals_ = {"__name__" : "__main__"} by: globals_ = {"__name__" : "__main__", "__file__": filename} The problem happens also in python 2.5. ---------- components: Library (Lib) files: bug.py messages: 56312 nosy: romain_jacquet severity: normal status: open title: pdb fails to launch some script. type: behavior versions: Python 2.4 __________________________________ Tracker __________________________________ -------------- next part -------------- A non-text attachment was scrubbed... Name: bug.py Type: text/x-python Size: 753 bytes Desc: not available Url : http://mail.python.org/pipermail/python-bugs-list/attachments/20071010/a9e1a979/attachment.py From report at bugs.python.org Wed Oct 10 16:02:30 2007 From: report at bugs.python.org (Romain JACQUET) Date: Wed, 10 Oct 2007 14:02:30 -0000 Subject: [issue1254] pdb fails to launch some script. Message-ID: <1192024950.07.0.645250068829.issue1254@psf.upfronthosting.co.za> New submission from Romain JACQUET: Pdb fails to launch any scripts that uses the __file__ builtin. This problem occurs because pdb does not set the global environnement correctly. It can be corrected by setting the global variable __file__ before pdb executes the file. Lib/pdb.py: Replace : globals_ = {"__name__" : "__main__"} by: globals_ = {"__name__" : "__main__", "__file__": filename} The problem happens also in python 2.5. ---------- components: Library (Lib) files: bug.py messages: 56312 nosy: romain_jacquet severity: normal status: open title: pdb fails to launch some script. type: behavior versions: Python 2.4 __________________________________ Tracker __________________________________ -------------- next part -------------- A non-text attachment was scrubbed... Name: bug.py Type: text/x-python Size: 753 bytes Desc: not available Url : http://mail.python.org/pipermail/python-bugs-list/attachments/20071010/a9e1a979/attachment-0001.py From report at bugs.python.org Wed Oct 10 16:10:05 2007 From: report at bugs.python.org (Jiri Krivanek) Date: Wed, 10 Oct 2007 14:10:05 -0000 Subject: [issue1255] Strange Python hangup Message-ID: <1192025405.81.0.160567416704.issue1255@psf.upfronthosting.co.za> New submission from Jiri Krivanek: See please attached ZIP archive which contains the two simple example source codes. If you execute bb.py, let it running for a while and then press Ctrl+C then the Python will terminate safely and you will get the following output on your console: E:\KkWebrman\Instalace\Tmp>bb.py init parsing time... ...done started parsing time... ...done parsing time... ...done finishing done E:\KkWebrman\Instalace\Tmp> However, if you execute aa.py then it will not terminate by Ctrl+C and you will get the following output on your console: E:\KkWebrman\Instalace\Tmp>aa.py init parsing time... started finishing The aa.py simply imports bb. My OS is: MS Windows 2000. My Python version is: Python 2.4.4 (#71, Oct 18 2006, 08:34:43) [MSC v.1310 32 bit (Intel)] on win32 ---------- components: Interpreter Core, Library (Lib) files: Python24Error.zip messages: 56313 nosy: kakacek severity: urgent status: open title: Strange Python hangup type: behavior versions: Python 2.4 __________________________________ Tracker __________________________________ -------------- next part -------------- A non-text attachment was scrubbed... Name: Python24Error.zip Type: application/octet-stream Size: 498 bytes Desc: not available Url : http://mail.python.org/pipermail/python-bugs-list/attachments/20071010/ff3b1c97/attachment.obj From report at bugs.python.org Wed Oct 10 16:10:05 2007 From: report at bugs.python.org (Jiri Krivanek) Date: Wed, 10 Oct 2007 14:10:05 -0000 Subject: [issue1255] Strange Python hangup Message-ID: <1192025405.81.0.160567416704.issue1255@psf.upfronthosting.co.za> New submission from Jiri Krivanek: See please attached ZIP archive which contains the two simple example source codes. If you execute bb.py, let it running for a while and then press Ctrl+C then the Python will terminate safely and you will get the following output on your console: E:\KkWebrman\Instalace\Tmp>bb.py init parsing time... ...done started parsing time... ...done parsing time... ...done finishing done E:\KkWebrman\Instalace\Tmp> However, if you execute aa.py then it will not terminate by Ctrl+C and you will get the following output on your console: E:\KkWebrman\Instalace\Tmp>aa.py init parsing time... started finishing The aa.py simply imports bb. My OS is: MS Windows 2000. My Python version is: Python 2.4.4 (#71, Oct 18 2006, 08:34:43) [MSC v.1310 32 bit (Intel)] on win32 ---------- components: Interpreter Core, Library (Lib) files: Python24Error.zip messages: 56313 nosy: kakacek severity: urgent status: open title: Strange Python hangup type: behavior versions: Python 2.4 __________________________________ Tracker __________________________________ -------------- next part -------------- A non-text attachment was scrubbed... Name: Python24Error.zip Type: application/octet-stream Size: 498 bytes Desc: not available Url : http://mail.python.org/pipermail/python-bugs-list/attachments/20071010/ff3b1c97/attachment-0001.obj From report at bugs.python.org Wed Oct 10 16:50:00 2007 From: report at bugs.python.org (Chris Stawarz) Date: Wed, 10 Oct 2007 14:50:00 -0000 Subject: [issue1251] ssl module doesn't support non-blocking handshakes In-Reply-To: <1192019236.92.0.583332636267.issue1251@psf.upfronthosting.co.za> Message-ID: Chris Stawarz added the comment: Yeah, the pattern for doing non-blocking I/O with select() is different for SSL-wrapped sockets: You always have to try the potentially-blocking operation first, and then call select() and retry in response to SSL_ERROR_WANT_READ/WRITE. (You can also check SSL_pending(), but I don't think you really have to.) Also, unlike normal sockets, SSL-wrapped sockets *must* be set non-blocking. I can see how this pattern might not play nicely with asyncore. But I think this is a separate (though related) issue from the one I reported. As it's currently implemented, the ssl module provides no way of wrapping a socket without (potentially) blocking during the handshake, making it unusable by Twisted or any other package that requires all I/O to be non-blocking. Moving the handshaking into a separate method solves this problem. __________________________________ Tracker __________________________________ From report at bugs.python.org Wed Oct 10 17:51:58 2007 From: report at bugs.python.org (Tim Golden) Date: Wed, 10 Oct 2007 15:51:58 -0000 Subject: [issue1255] Strange Python hangup Message-ID: <1192031518.84.0.20923579565.issue1255@psf.upfronthosting.co.za> Tim Golden added the comment: Do you realise that the code at the bottom of bb.py is executed when you import it from aa.py? In other words, when you run aa.py, the whole of your significant code is running within an import statement. I don't know if it's the cause of the problem (although I remember past strictures on the messiness of threads and imports) but I doubt if it's a fantastic design choice. ---------- nosy: +tim.golden __________________________________ Tracker __________________________________ From report at bugs.python.org Wed Oct 10 18:39:58 2007 From: report at bugs.python.org (Guido van Rossum) Date: Wed, 10 Oct 2007 16:39:58 -0000 Subject: [issue1251] ssl module doesn't support non-blocking handshakes Message-ID: <1192034398.12.0.712533951428.issue1251@psf.upfronthosting.co.za> Changes by Guido van Rossum: ---------- nosy: -gvanrossum __________________________________ Tracker __________________________________ From report at bugs.python.org Wed Oct 10 19:16:53 2007 From: report at bugs.python.org (Bill Janssen) Date: Wed, 10 Oct 2007 17:16:53 -0000 Subject: [issue1251] ssl module doesn't support non-blocking handshakes Message-ID: <1192036613.14.0.33612242143.issue1251@psf.upfronthosting.co.za> Bill Janssen added the comment: "SSL-wrapped sockets *must* be set non-blocking." Can you say a bit more about why? __________________________________ Tracker __________________________________ From report at bugs.python.org Wed Oct 10 19:41:49 2007 From: report at bugs.python.org (superwesman) Date: Wed, 10 Oct 2007 17:41:49 -0000 Subject: [issue1256] subprocess Popen wait() function hangs when stdout is > 20480 Message-ID: <1192038109.59.0.704801934631.issue1256@psf.upfronthosting.co.za> New submission from superwesman: hi - I noticed some odd behaviour with subprocess when the output (stdout) is large - I did some sleuthing and found a reproduceable case - I tested this on solaris using python 2.4.2 (sparc) and using 2.5 (opteron) - I've attached a python script that details the problem - I created 2 files ("small_file" and "large_file") that are 20480 and 20481 bytes, respectively .... > ls -lrt ./tmp/*_file -rw-r--r-- 1 wtorres staff 20481 Oct 10 12:32 ./tmp/large_file -rw-r--r-- 1 wtorres staff 20480 Oct 10 12:32 ./tmp/small_file the script cats each file, thus generating an appropriately sized stdout - the workaround we came up with was to use our own file handle and use the parameter stdout=my_file_handle.fileno() instead of stdout=PIPE - you can see this in the attached example as well > python ./tmp/brent.py testing with a small file - these should both work using my own file handle .... ok using PIPE ... ok testing with a large file - the second one here should fail using my own file handle .... ok using PIPE ... Traceback (most recent call last): File "./tmp/brent.py", line 43, in ? test_popen_bug( large_file ) File "./tmp/brent.py", line 31, in test_popen_bug rc = my_popen.wait() File "/tools/python/2.4.2/solaris/lib/python2.4/subprocess.py", line 1007, in wait pid, sts = os.waitpid(self.pid, 0) KeyboardInterrupt based on all this, it seems that the PIPE file handle has some buffer or something that is filling up and not allowing us to continue... or something. Thoughts? -w ---------- components: None files: brent.py messages: 56317 nosy: superwesman severity: normal status: open title: subprocess Popen wait() function hangs when stdout is > 20480 type: behavior versions: Python 2.4 __________________________________ Tracker __________________________________ -------------- next part -------------- A non-text attachment was scrubbed... Name: brent.py Type: application/octet-stream Size: 1298 bytes Desc: not available Url : http://mail.python.org/pipermail/python-bugs-list/attachments/20071010/4d4cdade/attachment-0001.obj From report at bugs.python.org Wed Oct 10 19:41:49 2007 From: report at bugs.python.org (superwesman) Date: Wed, 10 Oct 2007 17:41:49 -0000 Subject: [issue1256] subprocess Popen wait() function hangs when stdout is > 20480 Message-ID: <1192038109.59.0.704801934631.issue1256@psf.upfronthosting.co.za> New submission from superwesman: hi - I noticed some odd behaviour with subprocess when the output (stdout) is large - I did some sleuthing and found a reproduceable case - I tested this on solaris using python 2.4.2 (sparc) and using 2.5 (opteron) - I've attached a python script that details the problem - I created 2 files ("small_file" and "large_file") that are 20480 and 20481 bytes, respectively .... > ls -lrt ./tmp/*_file -rw-r--r-- 1 wtorres staff 20481 Oct 10 12:32 ./tmp/large_file -rw-r--r-- 1 wtorres staff 20480 Oct 10 12:32 ./tmp/small_file the script cats each file, thus generating an appropriately sized stdout - the workaround we came up with was to use our own file handle and use the parameter stdout=my_file_handle.fileno() instead of stdout=PIPE - you can see this in the attached example as well > python ./tmp/brent.py testing with a small file - these should both work using my own file handle .... ok using PIPE ... ok testing with a large file - the second one here should fail using my own file handle .... ok using PIPE ... Traceback (most recent call last): File "./tmp/brent.py", line 43, in ? test_popen_bug( large_file ) File "./tmp/brent.py", line 31, in test_popen_bug rc = my_popen.wait() File "/tools/python/2.4.2/solaris/lib/python2.4/subprocess.py", line 1007, in wait pid, sts = os.waitpid(self.pid, 0) KeyboardInterrupt based on all this, it seems that the PIPE file handle has some buffer or something that is filling up and not allowing us to continue... or something. Thoughts? -w ---------- components: None files: brent.py messages: 56317 nosy: superwesman severity: normal status: open title: subprocess Popen wait() function hangs when stdout is > 20480 type: behavior versions: Python 2.4 __________________________________ Tracker __________________________________ -------------- next part -------------- A non-text attachment was scrubbed... Name: brent.py Type: application/octet-stream Size: 1298 bytes Desc: not available Url : http://mail.python.org/pipermail/python-bugs-list/attachments/20071010/4d4cdade/attachment-0002.obj From report at bugs.python.org Wed Oct 10 20:13:06 2007 From: report at bugs.python.org (Chris Stawarz) Date: Wed, 10 Oct 2007 18:13:06 -0000 Subject: [issue1251] ssl module doesn't support non-blocking handshakes In-Reply-To: <1192036613.14.0.33612242143.issue1251@psf.upfronthosting.co.za> Message-ID: <1E22425E-3DED-4A9D-B59D-DC9694E2EF53@csail.mit.edu> Chris Stawarz added the comment: I meant that SSL-wrapped sockets must be set non-blocking in the case where you want to do non-blocking I/O with them using select(). This is another difference between SSL-wrapped sockets and normal sockets. With a normal socket, as long as you use select() to know when a read or write won't block, it shouldn't matter whether you've called setblocking(False) on the socket (although there may be corner cases where it does). With an SSL-wrapped socket, you have to try the I/O operation first, and then call select() if it fails with SSL_ERROR_WANT_READ/WRITE. But that won't happen if the socket is in blocking mode. In that case, the OpenSSL call will just block until the operation completes (or an error or disconnection occurs). That's my understanding, anyway, based on the OpenSSL man pages and my own usage. __________________________________ Tracker __________________________________ From report at bugs.python.org Wed Oct 10 20:58:06 2007 From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=) Date: Wed, 10 Oct 2007 18:58:06 -0000 Subject: [issue1031213] Use correct encoding for printing SyntaxErrors Message-ID: <1192042686.2.0.0381969662003.issue1031213@psf.upfronthosting.co.za> Martin v. L?wis added the comment: ishimoto: in dec_utf8, there is a PyErr_Print call. What is the purpose of this call? _____________________________________ Tracker _____________________________________ From report at bugs.python.org Wed Oct 10 21:07:21 2007 From: report at bugs.python.org (Bill Janssen) Date: Wed, 10 Oct 2007 19:07:21 -0000 Subject: [issue1251] ssl module doesn't support non-blocking handshakes Message-ID: <1192043241.28.0.400234478266.issue1251@psf.upfronthosting.co.za> Bill Janssen added the comment: Yes, that's correct. I've reviewed your patch, and it looks OK to me. I'll fold it in in the next go-around, once I've made some progress on the asyncore issues. __________________________________ Tracker __________________________________ From report at bugs.python.org Wed Oct 10 21:32:22 2007 From: report at bugs.python.org (Jiri Krivanek) Date: Wed, 10 Oct 2007 19:32:22 -0000 Subject: [issue1255] Strange Python hangup Message-ID: <1192044742.67.0.878249256515.issue1255@psf.upfronthosting.co.za> Jiri Krivanek added the comment: The reason for it is pragmatic: The whole of my application is published as .pyc files. Except of the only one which must stay .py - that one which has to be executable (+x) on Linux and thus it starts with the line: # !/usr/bin/python and then it should only contain: import and is .pyc. So I did a simple change into my application. I start it via a very brief script whic only contains: # !/usr/bin/python import Wow! It stopped working at all! After 4 hours of isolating of the problem I developped an elementary code which demonstrates my problem (attached at the bug report). I expect that the import statement does not return the control until the code being executed by it finishes, does'n it? __________________________________ Tracker __________________________________ From report at bugs.python.org Wed Oct 10 21:42:50 2007 From: report at bugs.python.org (Jiri Krivanek) Date: Wed, 10 Oct 2007 19:42:50 -0000 Subject: [issue1255] Strange Python hangup Message-ID: <1192045370.0.0.506809956812.issue1255@psf.upfronthosting.co.za> Jiri Krivanek added the comment: One more hint: There is the coincidence of three facts: 1. It uses the thread (if I remove the thread then it works fine). 2. It is "double imported" (if I remove the outer import then it works fine). 3. There is the strptime() function being used (if I remove this function then it works fine). __________________________________ Tracker __________________________________ From report at bugs.python.org Wed Oct 10 21:56:26 2007 From: report at bugs.python.org (=?utf-8?q?=0A=09=09=09=09=09Robert_Brewer=0A=09=09=09=09?=) Date: Wed, 10 Oct 2007 19:56:26 -0000 Subject: [issue1257] atexit errors should result in nonzero exit code Message-ID: <1192046186.55.0.804669715206.issue1257@psf.upfronthosting.co.za> New submission from Robert Brewer : While debugging/fixing the logging module's atexit behavior (see http://www.cherrypy.org/ticket/646 -- it chokes atexit if stdout is closed), it became difficult to write an automated test that verified the bug occurred, since it happened at program exit. Returning a nonzero exit code when atexit errors occur would be preferable to just printing the error. Of course, if SystemExit is already raised, we should propagate that out, but other exceptions should print the traceback and then return some other code IMO. ---------- components: Interpreter Core messages: 56323 nosy: aminusfu severity: normal status: open title: atexit errors should result in nonzero exit code type: behavior versions: Python 2.4, Python 2.5, Python 2.6, Python 3.0 __________________________________ Tracker __________________________________ From report at bugs.python.org Wed Oct 10 21:56:26 2007 From: report at bugs.python.org (=?utf-8?q?=0A=09=09=09=09=09Robert_Brewer=0A=09=09=09=09?=) Date: Wed, 10 Oct 2007 19:56:26 -0000 Subject: [issue1257] atexit errors should result in nonzero exit code Message-ID: <1192046186.55.0.804669715206.issue1257@psf.upfronthosting.co.za> New submission from Robert Brewer : While debugging/fixing the logging module's atexit behavior (see http://www.cherrypy.org/ticket/646 -- it chokes atexit if stdout is closed), it became difficult to write an automated test that verified the bug occurred, since it happened at program exit. Returning a nonzero exit code when atexit errors occur would be preferable to just printing the error. Of course, if SystemExit is already raised, we should propagate that out, but other exceptions should print the traceback and then return some other code IMO. ---------- components: Interpreter Core messages: 56323 nosy: aminusfu severity: normal status: open title: atexit errors should result in nonzero exit code type: behavior versions: Python 2.4, Python 2.5, Python 2.6, Python 3.0 __________________________________ Tracker __________________________________ From report at bugs.python.org Wed Oct 10 22:03:54 2007 From: report at bugs.python.org (Lakin Wecker) Date: Wed, 10 Oct 2007 20:03:54 -0000 Subject: [issue1257] atexit errors should result in nonzero exit code Message-ID: <1192046634.55.0.213311009741.issue1257@psf.upfronthosting.co.za> Lakin Wecker added the comment: I am an agreeance with the original report. I just finished writing an automated test that did the following to work around this behavior: 46 # Sometimes an exception happens during exit, try to make sure we get 47 # a non_zero exit code. 48 old_exitfunc = sys.exitfunc 49 def exitfunc(): 50 try: 51 old_exitfunc() 52 except SystemExit: 53 raise 54 except: 55 raise SystemExit(1) ---------- nosy: +lakin.wecker __________________________________ Tracker __________________________________ From report at bugs.python.org Wed Oct 10 22:04:47 2007 From: report at bugs.python.org (Lakin Wecker) Date: Wed, 10 Oct 2007 20:04:47 -0000 Subject: [issue1257] atexit errors should result in nonzero exit code Message-ID: <1192046687.64.0.150972383697.issue1257@psf.upfronthosting.co.za> Lakin Wecker added the comment: sorry for the noise and duplication. The full code listing should have been: 46 # Sometimes an exception happens during exit, try to make sure we get 47 # a non_zero exit code. 48 old_exitfunc = sys.exitfunc 49 def exitfunc(): 50 try: 51 old_exitfunc() 52 except SystemExit: 53 raise 54 except: 55 raise SystemExit(1) 56 sys.exitfunc = exitfunc __________________________________ Tracker __________________________________ From report at bugs.python.org Wed Oct 10 23:39:28 2007 From: report at bugs.python.org (Guido van Rossum) Date: Wed, 10 Oct 2007 21:39:28 -0000 Subject: [issue1258] Removal of basestring type Message-ID: <1192052368.13.0.892143072041.issue1258@psf.upfronthosting.co.za> Guido van Rossum added the comment: Thanks, evaluating! ---------- nosy: +gvanrossum __________________________________ Tracker __________________________________ From report at bugs.python.org Wed Oct 10 23:54:50 2007 From: report at bugs.python.org (Guido van Rossum) Date: Wed, 10 Oct 2007 21:54:50 -0000 Subject: [issue1258] Removal of basestring type Message-ID: <1192053290.35.0.81048174857.issue1258@psf.upfronthosting.co.za> Guido van Rossum added the comment: I see 10 failing tests: test_ctypes test_email test_httplib test_inspect test_os test_re test_subprocess test_sys test_xml_etree test_xml_etree_c ---------- assignee: -> gvanrossum __________________________________ Tracker __________________________________ From report at bugs.python.org Thu Oct 11 00:34:00 2007 From: report at bugs.python.org (Christian Heimes) Date: Wed, 10 Oct 2007 22:34:00 -0000 Subject: [issue1258] Removal of basestring type In-Reply-To: <1192053290.35.0.81048174857.issue1258@psf.upfronthosting.co.za> Message-ID: <470D534E.6010302@cheimes.de> Christian Heimes added the comment: test_ctypes: works for me test_email: need some help from an email expoert test_httplib: __file__ has a wrong type str8. I'm looking into it. test_inspect: same issue as httplib test_os: same issue test_re: I had the failing test before my changes File "Lib/test/test_re.py", line 622, in test_empty_array ValueError: bad typecode (must be b, B, u, h, H, i, I, l, L, f or d) test_subprocess: I don't understand why it fails. The traceback is missing a line test_sys: related to __file__ test_xml_etree / test_xml_etree_c: a str8 / io error that may be related to __file__ __________________________________ Tracker __________________________________ From report at bugs.python.org Thu Oct 11 00:44:00 2007 From: report at bugs.python.org (Guido van Rossum) Date: Wed, 10 Oct 2007 22:44:00 -0000 Subject: [issue1258] Removal of basestring type In-Reply-To: <470D534E.6010302@cheimes.de> Message-ID: Guido van Rossum added the comment: On 10/10/07, Christian Heimes wrote: > > Christian Heimes added the comment: > > test_ctypes: works for me Did you svn up, make clean and rebuild? > test_email: need some help from an email expoert Which test is failing? > test_httplib: __file__ has a wrong type str8. I'm looking into it. Yes, __file__ always has that type. Fixing it is messy because it requires using the default filesystem encoding. Can you try that as a separate patch? > test_inspect: same issue as httplib > test_os: same issue > test_re: I had the failing test before my changes But it passes for me. > File "Lib/test/test_re.py", line 622, in test_empty_array > ValueError: bad typecode (must be b, B, u, h, H, i, I, l, L, f or d) Hm. It passes for me. > test_subprocess: I don't understand why it fails. The traceback is > missing a line > test_sys: related to __file__ > test_xml_etree / test_xml_etree_c: a str8 / io error that may be related > to __file__ Thanks for looking into these!! __________________________________ Tracker __________________________________ From report at bugs.python.org Thu Oct 11 01:16:38 2007 From: report at bugs.python.org (Christian Heimes) Date: Wed, 10 Oct 2007 23:16:38 -0000 Subject: [issue1258] Removal of basestring type In-Reply-To: Message-ID: <470D5D4B.3080604@cheimes.de> Christian Heimes added the comment: Guido van Rossum wrote: > Did you svn up, make clean and rebuild? The ctypes package didn't change since my last rebuild an hour ago. I'm on Linux (Ubuntu i386) > >> test_email: need some help from an email expoert > > Which test is failing? test_decoded_generator() The generator tries to print a str8 to a text file. > Yes, __file__ always has that type. Fixing it is messy because it > requires using the default filesystem encoding. Can you try that as a > separate patch? I'm already working on it. Can I introduce a new function _PyUnicode_AsDefaultFSEncodedString that encodes unicode using Py_FileSystemDefaultEncoding or UTF-8? >> File "Lib/test/test_re.py", line 622, in test_empty_array >> ValueError: bad typecode (must be b, B, u, h, H, i, I, l, L, f or d) > > Hm. It passes for me. I'm going to look into the issue later. __________________________________ Tracker __________________________________ From report at bugs.python.org Thu Oct 11 01:41:29 2007 From: report at bugs.python.org (=?utf-8?q?=0A=09=09=09=09=09Robert_Collins=0A=09=09=09=09?=) Date: Wed, 10 Oct 2007 23:41:29 -0000 Subject: [issue1259] string find and rfind methods give a TypeError that is misleading Message-ID: <1192059689.8.0.690640268578.issue1259@psf.upfronthosting.co.za> New submission from Robert Collins : Python 2.5.1 (r251:54863, May 2 2007, 16:56:35) [GCC 4.1.2 (Ubuntu 4.1.2-0ubuntu4)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> 'asd'.find('s', None, None) Traceback (most recent call last): File "", line 1, in TypeError: slice indices must be integers or None or have an __index__ method >>> 'asd'.rfind('s', None, None) Traceback (most recent call last): File "", line 1, in TypeError: slice indices must be integers or None or have an __index__ method >>> # Note that this works, at the price of a memory copy, >>> # and on large strings that is undesirable. >>> 'asd'[None:None].find('s') 1 >>> 'asd'[None:None].rfind('s') 1 >>> ---------- messages: 56332 nosy: rbcollins severity: normal status: open title: string find and rfind methods give a TypeError that is misleading versions: Python 2.5 __________________________________ Tracker __________________________________ From report at bugs.python.org Thu Oct 11 01:41:30 2007 From: report at bugs.python.org (=?utf-8?q?=0A=09=09=09=09=09Robert_Collins=0A=09=09=09=09?=) Date: Wed, 10 Oct 2007 23:41:30 -0000 Subject: [issue1259] string find and rfind methods give a TypeError that is misleading Message-ID: <1192059689.8.0.690640268578.issue1259@psf.upfronthosting.co.za> New submission from Robert Collins : Python 2.5.1 (r251:54863, May 2 2007, 16:56:35) [GCC 4.1.2 (Ubuntu 4.1.2-0ubuntu4)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> 'asd'.find('s', None, None) Traceback (most recent call last): File "", line 1, in TypeError: slice indices must be integers or None or have an __index__ method >>> 'asd'.rfind('s', None, None) Traceback (most recent call last): File "", line 1, in TypeError: slice indices must be integers or None or have an __index__ method >>> # Note that this works, at the price of a memory copy, >>> # and on large strings that is undesirable. >>> 'asd'[None:None].find('s') 1 >>> 'asd'[None:None].rfind('s') 1 >>> ---------- messages: 56332 nosy: rbcollins severity: normal status: open title: string find and rfind methods give a TypeError that is misleading versions: Python 2.5 __________________________________ Tracker __________________________________ From report at bugs.python.org Thu Oct 11 03:24:59 2007 From: report at bugs.python.org (Barry A. Warsaw) Date: Thu, 11 Oct 2007 01:24:59 -0000 Subject: [issue1259] string find and rfind methods give a TypeError that is misleading Message-ID: <1192065899.16.0.303804500993.issue1259@psf.upfronthosting.co.za> Barry A. Warsaw added the comment: I believe this is because string_find_internal() uses an O& with _PyEval_SliceIndex() to convert its start and end arguments, but the latter function does not accept None. To fix this, you'd have to change string_find_internal() to do its own argument checking for None before calling _PyEval_SliceIndex. ---------- nosy: +barry __________________________________ Tracker __________________________________ From report at bugs.python.org Thu Oct 11 03:54:49 2007 From: report at bugs.python.org (atsuo ishimoto) Date: Thu, 11 Oct 2007 01:54:49 -0000 Subject: [issue1031213] Use correct encoding for printing SyntaxErrors Message-ID: <1192067689.21.0.898260887055.issue1031213@psf.upfronthosting.co.za> atsuo ishimoto added the comment: PyErr_Print() is called to report exception raised by codec. If PyUnicode_DecodeUTF8() or PyUnicode_AsEncodedString() return NULL, PyErr_Print() is called. _____________________________________ Tracker _____________________________________ From report at bugs.python.org Thu Oct 11 04:20:08 2007 From: report at bugs.python.org (Guido van Rossum) Date: Thu, 11 Oct 2007 02:20:08 -0000 Subject: [issue1031213] Use correct encoding for printing SyntaxErrors In-Reply-To: <1192067689.21.0.898260887055.issue1031213@psf.upfronthosting.co.za> Message-ID: Guido van Rossum added the comment: > PyErr_Print() is called to report exception raised by codec. > If PyUnicode_DecodeUTF8() or PyUnicode_AsEncodedString() return NULL, > PyErr_Print() is called. This comment is not very helpful; it describes what happens, but not why, or whether that is a good idea. I believe that if this call is ever reached, two tracebacks will be printed, confusing the user. _____________________________________ Tracker _____________________________________ From report at bugs.python.org Thu Oct 11 05:00:26 2007 From: report at bugs.python.org (Alexandre Vassalotti) Date: Thu, 11 Oct 2007 03:00:26 -0000 Subject: [issue1260] PEP 3137: Remove the buffer API from PyUnicode Message-ID: <1192071626.91.0.943640538165.issue1260@psf.upfronthosting.co.za> New submission from Alexandre Vassalotti: This patch removes the buffer API from PyUnicode, as specified by PEP 3137. All the unit tests passes. However, I believe there is a few function calls to PyArg API that could become problematic if they are given a PyUnicode object: % egrep -R --include='*.c' 'PyArg.*Parse.*"[^;:]*[cwt].*"' py3k/ I haven't checked these function calls yet. So, it would probably be a good idea to wait I do so before committing this patch. ---------- files: unicode_rm_buf_api.patch messages: 56336 nosy: alexandre.vassalotti severity: normal status: open title: PEP 3137: Remove the buffer API from PyUnicode versions: Python 3.0 __________________________________ Tracker __________________________________ -------------- next part -------------- A non-text attachment was scrubbed... Name: unicode_rm_buf_api.patch Type: text/x-diff Size: 1890 bytes Desc: not available Url : http://mail.python.org/pipermail/python-bugs-list/attachments/20071011/2fd04a35/attachment-0001.patch From report at bugs.python.org Thu Oct 11 05:00:27 2007 From: report at bugs.python.org (Alexandre Vassalotti) Date: Thu, 11 Oct 2007 03:00:27 -0000 Subject: [issue1260] PEP 3137: Remove the buffer API from PyUnicode Message-ID: <1192071626.91.0.943640538165.issue1260@psf.upfronthosting.co.za> New submission from Alexandre Vassalotti: This patch removes the buffer API from PyUnicode, as specified by PEP 3137. All the unit tests passes. However, I believe there is a few function calls to PyArg API that could become problematic if they are given a PyUnicode object: % egrep -R --include='*.c' 'PyArg.*Parse.*"[^;:]*[cwt].*"' py3k/ I haven't checked these function calls yet. So, it would probably be a good idea to wait I do so before committing this patch. ---------- files: unicode_rm_buf_api.patch messages: 56336 nosy: alexandre.vassalotti severity: normal status: open title: PEP 3137: Remove the buffer API from PyUnicode versions: Python 3.0 __________________________________ Tracker __________________________________ -------------- next part -------------- A non-text attachment was scrubbed... Name: unicode_rm_buf_api.patch Type: text/x-diff Size: 1890 bytes Desc: not available Url : http://mail.python.org/pipermail/python-bugs-list/attachments/20071011/2fd04a35/attachment-0002.patch From report at bugs.python.org Thu Oct 11 05:17:24 2007 From: report at bugs.python.org (Guido van Rossum) Date: Thu, 11 Oct 2007 03:17:24 -0000 Subject: [issue1258] Removal of basestring type In-Reply-To: <470D5D4B.3080604@cheimes.de> Message-ID: Guido van Rossum added the comment: On 10/10/07, Christian Heimes wrote: > > Christian Heimes added the comment: > > Guido van Rossum wrote: > > Did you svn up, make clean and rebuild? > > The ctypes package didn't change since my last rebuild an hour ago. I'm > on Linux (Ubuntu i386) Odd. I'll investigate when I have more time. > >> test_email: need some help from an email expoert > > > > Which test is failing? > > test_decoded_generator() > The generator tries to print a str8 to a text file. Thought so. I have a tentative fix that I want approved by Barry Warsaw before checking; you can see if it works for you too: --- Lib/email/generator.py (revision 58412) +++ Lib/email/generator.py (working copy) @@ -288,7 +288,7 @@ for part in msg.walk(): maintype = part.get_content_maintype() if maintype == 'text': - print(part.get_payload(decode=True), file=self) + print(part.get_payload(decode=False), file=self) elif maintype == 'multipart': # Just skip this pass > > Yes, __file__ always has that type. Fixing it is messy because it > > requires using the default filesystem encoding. Can you try that as a > > separate patch? > > I'm already working on it. Can I introduce a new function > _PyUnicode_AsDefaultFSEncodedString that encodes unicode using > Py_FileSystemDefaultEncoding or UTF-8? That's a rather long name... I don't think it needs a leading underscore. How about PyUnicode_AsFSString()? __________________________________ Tracker __________________________________ From report at bugs.python.org Thu Oct 11 07:07:48 2007 From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=) Date: Thu, 11 Oct 2007 05:07:48 -0000 Subject: [issue1258] Removal of basestring type Message-ID: <1192079268.22.0.883867039575.issue1258@psf.upfronthosting.co.za> Changes by Martin v. L?wis: ---------- keywords: +patch __________________________________ Tracker __________________________________ From report at bugs.python.org Thu Oct 11 07:29:12 2007 From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=) Date: Thu, 11 Oct 2007 05:29:12 -0000 Subject: [issue1260] PEP 3137: Remove the buffer API from PyUnicode Message-ID: <1192080552.35.0.940013844994.issue1260@psf.upfronthosting.co.za> Changes by Martin v. L?wis: ---------- keywords: +patch __________________________________ Tracker __________________________________ From report at bugs.python.org Thu Oct 11 08:04:27 2007 From: report at bugs.python.org (atsuo ishimoto) Date: Thu, 11 Oct 2007 06:04:27 -0000 Subject: [issue1031213] Use correct encoding for printing SyntaxErrors Message-ID: <1192082667.16.0.92558818847.issue1031213@psf.upfronthosting.co.za> atsuo ishimoto added the comment: Sorry for insufficient comment. When a codec raised an exception, I think the exception should be reported. Otherwise, user cannot know why Python prints broken line of code. Should we silently clear the exception raised by codecs, or print a message such as "Codec raised an exception while processing compile error." ? _____________________________________ Tracker _____________________________________ From report at bugs.python.org Thu Oct 11 08:09:59 2007 From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=) Date: Thu, 11 Oct 2007 06:09:59 -0000 Subject: [issue1031213] Use correct encoding for printing SyntaxErrors In-Reply-To: <1192082667.16.0.92558818847.issue1031213@psf.upfronthosting.co.za> Message-ID: <470DBE35.7090800@v.loewis.de> Martin v. L?wis added the comment: > Should we silently clear the exception raised by codecs, or print a > message such as "Codec raised an exception while processing compile > error." ? Can you create a test case that triggers that specific problem? Regards, Martin _____________________________________ Tracker _____________________________________ From report at bugs.python.org Thu Oct 11 09:44:29 2007 From: report at bugs.python.org (atsuo ishimoto) Date: Thu, 11 Oct 2007 07:44:29 -0000 Subject: [issue1031213] Use correct encoding for printing SyntaxErrors Message-ID: <1192088669.94.0.457674661229.issue1031213@psf.upfronthosting.co.za> atsuo ishimoto added the comment: Codecs would hardly ever raises exception here. Usually, exception raised here would be a MemoryError. The unicode string we are trying to encode is just decoded by same codec. If codec raises exception other than MemoryError, the codec will likely have problem. I attached a script to print exception raised by codec. I wrote a "buggy" encoder, which never return string but raises an exception. _____________________________________ Tracker _____________________________________ -------------- next part -------------- A non-text attachment was scrubbed... Name: display_exception.py Type: text/x-python Size: 477 bytes Desc: not available Url : http://mail.python.org/pipermail/python-bugs-list/attachments/20071011/81390b85/attachment.py From report at bugs.python.org Thu Oct 11 10:45:44 2007 From: report at bugs.python.org (Gregory P. Smith) Date: Thu, 11 Oct 2007 08:45:44 -0000 Subject: [issue1261] PEP 3137: make bytesobject.c methods use PEP 3118 buffer API Message-ID: <1192092343.97.0.94438121325.issue1261@psf.upfronthosting.co.za> New submission from Gregory P. Smith: This makes all existing bytesobject.c methods use the buffer API rather than explicitly requiring bytes objects as input. It also fixes input to append() and remove() that was not strict enough and improves a few unit tests in that area. NOTE: this patch likely depends on http://bugs.python.org/issue1260 removing the buffer API from the unicode type in order for all unit tests to pass (i only tested it with that applied since thats where we're headed). ---------- files: bytes-methods-use-buffer-api-01.diff.txt keywords: patch, py3k messages: 56341 nosy: gregory.p.smith severity: normal status: open title: PEP 3137: make bytesobject.c methods use PEP 3118 buffer API versions: Python 3.0 __________________________________ Tracker __________________________________ -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: bytes-methods-use-buffer-api-01.diff.txt Url: http://mail.python.org/pipermail/python-bugs-list/attachments/20071011/6feed221/attachment-0001.txt From report at bugs.python.org Thu Oct 11 10:45:44 2007 From: report at bugs.python.org (Gregory P. Smith) Date: Thu, 11 Oct 2007 08:45:44 -0000 Subject: [issue1261] PEP 3137: make bytesobject.c methods use PEP 3118 buffer API Message-ID: <1192092343.97.0.94438121325.issue1261@psf.upfronthosting.co.za> New submission from Gregory P. Smith: This makes all existing bytesobject.c methods use the buffer API rather than explicitly requiring bytes objects as input. It also fixes input to append() and remove() that was not strict enough and improves a few unit tests in that area. NOTE: this patch likely depends on http://bugs.python.org/issue1260 removing the buffer API from the unicode type in order for all unit tests to pass (i only tested it with that applied since thats where we're headed). ---------- files: bytes-methods-use-buffer-api-01.diff.txt keywords: patch, py3k messages: 56341 nosy: gregory.p.smith severity: normal status: open title: PEP 3137: make bytesobject.c methods use PEP 3118 buffer API versions: Python 3.0 __________________________________ Tracker __________________________________ -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: bytes-methods-use-buffer-api-01.diff.txt Url: http://mail.python.org/pipermail/python-bugs-list/attachments/20071011/6feed221/attachment-0002.txt From report at bugs.python.org Thu Oct 11 13:30:38 2007 From: report at bugs.python.org (Reto Wehrli) Date: Thu, 11 Oct 2007 11:30:38 -0000 Subject: =?utf-8?q?[issue1262]_IDLE_does_not_start_if_windows_environment_variable_containing_'German_Umlaute:_=C3=A4=C3=B6=C3=BC'_exists?= Message-ID: <1192102237.9.0.369599220332.issue1262@psf.upfronthosting.co.za> New submission from Reto Wehrli: C:\devtools\Python30\Lib\idlelib>set ... eRoomOfflineFiles=Z:\Documents and Settings\tgdwere3\My Documents\eRoom Dateien f?r die Offline-Bearbeitung\ ... C:\devtools\Python30\Lib\idlelib>..\..\python.exe idle.pyw object : UnicodeDecodeError('utf8', b'Z:\\Documents and Settings\\tgdwere3\\My Documents\\eRoom Dateien f\xfcr die Offline-Bearbeitung\\', 63, 69, 'u nsupported Unicode code range') type : UnicodeDecodeError refcount: 4 address : 00B825B0 lost sys.stderr after removing the env variable idle starts ---------- components: IDLE messages: 56342 nosy: reto severity: normal status: open title: IDLE does not start if windows environment variable containing 'German Umlaute: ???' exists type: crash versions: Python 3.0 __________________________________ Tracker __________________________________ From report at bugs.python.org Thu Oct 11 13:30:37 2007 From: report at bugs.python.org (Reto Wehrli) Date: Thu, 11 Oct 2007 11:30:37 -0000 Subject: =?utf-8?q?[issue1262]_IDLE_does_not_start_if_windows_environment_variable_containing_'German_Umlaute:_=C3=A4=C3=B6=C3=BC'_exists?= Message-ID: <1192102237.9.0.369599220332.issue1262@psf.upfronthosting.co.za> New submission from Reto Wehrli: C:\devtools\Python30\Lib\idlelib>set ... eRoomOfflineFiles=Z:\Documents and Settings\tgdwere3\My Documents\eRoom Dateien f?r die Offline-Bearbeitung\ ... C:\devtools\Python30\Lib\idlelib>..\..\python.exe idle.pyw object : UnicodeDecodeError('utf8', b'Z:\\Documents and Settings\\tgdwere3\\My Documents\\eRoom Dateien f\xfcr die Offline-Bearbeitung\\', 63, 69, 'u nsupported Unicode code range') type : UnicodeDecodeError refcount: 4 address : 00B825B0 lost sys.stderr after removing the env variable idle starts ---------- components: IDLE messages: 56342 nosy: reto severity: normal status: open title: IDLE does not start if windows environment variable containing 'German Umlaute: ???' exists type: crash versions: Python 3.0 __________________________________ Tracker __________________________________ From report at bugs.python.org Thu Oct 11 14:20:47 2007 From: report at bugs.python.org (Thomas Lee) Date: Thu, 11 Oct 2007 12:20:47 -0000 Subject: [issue1263] PEP 3137 patch - str8/str comparison should return false Message-ID: <1192105247.69.0.759609123255.issue1263@psf.upfronthosting.co.za> New submission from Thomas Lee: The main patch - while exactly what is needed to make str8/str equality checks return False - breaks a bunch of tests due to PyString_* still being used elsewhere when it should be using PyUnicode. The second patch modifies structmember.c to use PyUnicode_* where it was previously using PyString_*, which fixes the first problem I stumbled across in trying to get test_unicode to run. Unfortunately, similar errors are present in Python/codecs.c and other places (maybe Python/modsupport.c too? not 100% sure yet) - these still need to be fixed! ---------- components: Interpreter Core files: unicode-string-eq-false-r2.patch messages: 56343 nosy: thomas.lee severity: normal status: open title: PEP 3137 patch - str8/str comparison should return false type: rfe versions: Python 3.0 __________________________________ Tracker __________________________________ -------------- next part -------------- A non-text attachment was scrubbed... Name: unicode-string-eq-false-r2.patch Type: text/x-patch Size: 1953 bytes Desc: not available Url : http://mail.python.org/pipermail/python-bugs-list/attachments/20071011/5547548e/attachment.bin From report at bugs.python.org Thu Oct 11 14:20:47 2007 From: report at bugs.python.org (Thomas Lee) Date: Thu, 11 Oct 2007 12:20:47 -0000 Subject: [issue1263] PEP 3137 patch - str8/str comparison should return false Message-ID: <1192105247.69.0.759609123255.issue1263@psf.upfronthosting.co.za> New submission from Thomas Lee: The main patch - while exactly what is needed to make str8/str equality checks return False - breaks a bunch of tests due to PyString_* still being used elsewhere when it should be using PyUnicode. The second patch modifies structmember.c to use PyUnicode_* where it was previously using PyString_*, which fixes the first problem I stumbled across in trying to get test_unicode to run. Unfortunately, similar errors are present in Python/codecs.c and other places (maybe Python/modsupport.c too? not 100% sure yet) - these still need to be fixed! ---------- components: Interpreter Core files: unicode-string-eq-false-r2.patch messages: 56343 nosy: thomas.lee severity: normal status: open title: PEP 3137 patch - str8/str comparison should return false type: rfe versions: Python 3.0 __________________________________ Tracker __________________________________ -------------- next part -------------- A non-text attachment was scrubbed... Name: unicode-string-eq-false-r2.patch Type: text/x-patch Size: 1953 bytes Desc: not available Url : http://mail.python.org/pipermail/python-bugs-list/attachments/20071011/5547548e/attachment-0001.bin From report at bugs.python.org Thu Oct 11 14:21:08 2007 From: report at bugs.python.org (Thomas Lee) Date: Thu, 11 Oct 2007 12:21:08 -0000 Subject: [issue1263] PEP 3137 patch - str8/str comparison should return false Message-ID: <1192105268.92.0.213390017186.issue1263@psf.upfronthosting.co.za> Changes by Thomas Lee: __________________________________ Tracker __________________________________ From report at bugs.python.org Thu Oct 11 14:28:23 2007 From: report at bugs.python.org (Thomas Lee) Date: Thu, 11 Oct 2007 12:28:23 -0000 Subject: [issue1263] PEP 3137 patch - str8/str comparison should return false Message-ID: <1192105703.8.0.125375701441.issue1263@psf.upfronthosting.co.za> Thomas Lee added the comment: Oops - use unicode-string-eq-false-r3.patch, not unicode-string-eq-false-r2.patch. __________________________________ Tracker __________________________________ -------------- next part -------------- A non-text attachment was scrubbed... Name: unicode-string-eq-false-r3.patch Type: text/x-patch Size: 1591 bytes Desc: not available Url : http://mail.python.org/pipermail/python-bugs-list/attachments/20071011/b25d4572/attachment.bin From report at bugs.python.org Thu Oct 11 17:49:25 2007 From: report at bugs.python.org (Christian Heimes) Date: Thu, 11 Oct 2007 15:49:25 -0000 Subject: [issue1264] __file__ and co_filename as unicode Message-ID: <1192117764.73.0.471656029437.issue1264@psf.upfronthosting.co.za> New submission from Christian Heimes: This is a *preliminary* patch for __file__ and co_filename which decodes char* / PyString using the FS default encoding. I'm still working on it. ---------- components: Interpreter Core files: py3k_file_fsenc.patch messages: 56345 nosy: tiran severity: normal status: open title: __file__ and co_filename as unicode versions: Python 3.0 __________________________________ Tracker __________________________________ -------------- next part -------------- A non-text attachment was scrubbed... Name: py3k_file_fsenc.patch Type: text/x-diff Size: 6323 bytes Desc: not available Url : http://mail.python.org/pipermail/python-bugs-list/attachments/20071011/0ed43947/attachment-0001.patch From report at bugs.python.org Thu Oct 11 17:49:24 2007 From: report at bugs.python.org (Christian Heimes) Date: Thu, 11 Oct 2007 15:49:24 -0000 Subject: [issue1264] __file__ and co_filename as unicode Message-ID: <1192117764.73.0.471656029437.issue1264@psf.upfronthosting.co.za> New submission from Christian Heimes: This is a *preliminary* patch for __file__ and co_filename which decodes char* / PyString using the FS default encoding. I'm still working on it. ---------- components: Interpreter Core files: py3k_file_fsenc.patch messages: 56345 nosy: tiran severity: normal status: open title: __file__ and co_filename as unicode versions: Python 3.0 __________________________________ Tracker __________________________________ -------------- next part -------------- A non-text attachment was scrubbed... Name: py3k_file_fsenc.patch Type: text/x-diff Size: 6323 bytes Desc: not available Url : http://mail.python.org/pipermail/python-bugs-list/attachments/20071011/0ed43947/attachment-0002.patch From report at bugs.python.org Thu Oct 11 18:00:52 2007 From: report at bugs.python.org (Christian Heimes) Date: Thu, 11 Oct 2007 16:00:52 -0000 Subject: [issue1265] pdb bug with "with" statement Message-ID: <1192118452.75.0.65576179893.issue1265@psf.upfronthosting.co.za> New submission from Christian Heimes: found a pretty annoying bug caused by with blocks. A with block terminates the debugging session and the program keeps running. It's not possible to go to the next line with 'n'. 's' steps into the open() call. # pdbtest.py import pdb pdb.set_trace() print("before with") with open("/etc/passwd") as fd: data = fd.read() print("after with") print("end of program") $ ./python pdbtest.py > /home/heimes/dev/python/py3k/pdbtest.py(3)() -> print("before with") (Pdb) n before with > /home/heimes/dev/python/py3k/pdbtest.py(4)() -> with open("/etc/passwd") as fd: (Pdb) n after with end of program ---------- components: Interpreter Core, Library (Lib) messages: 56346 nosy: tiran severity: normal status: open title: pdb bug with "with" statement versions: Python 3.0 __________________________________ Tracker __________________________________ From report at bugs.python.org Thu Oct 11 18:00:52 2007 From: report at bugs.python.org (Christian Heimes) Date: Thu, 11 Oct 2007 16:00:52 -0000 Subject: [issue1265] pdb bug with "with" statement Message-ID: <1192118452.75.0.65576179893.issue1265@psf.upfronthosting.co.za> New submission from Christian Heimes: found a pretty annoying bug caused by with blocks. A with block terminates the debugging session and the program keeps running. It's not possible to go to the next line with 'n'. 's' steps into the open() call. # pdbtest.py import pdb pdb.set_trace() print("before with") with open("/etc/passwd") as fd: data = fd.read() print("after with") print("end of program") $ ./python pdbtest.py > /home/heimes/dev/python/py3k/pdbtest.py(3)() -> print("before with") (Pdb) n before with > /home/heimes/dev/python/py3k/pdbtest.py(4)() -> with open("/etc/passwd") as fd: (Pdb) n after with end of program ---------- components: Interpreter Core, Library (Lib) messages: 56346 nosy: tiran severity: normal status: open title: pdb bug with "with" statement versions: Python 3.0 __________________________________ Tracker __________________________________ From report at bugs.python.org Thu Oct 11 18:51:51 2007 From: report at bugs.python.org (Guido van Rossum) Date: Thu, 11 Oct 2007 16:51:51 -0000 Subject: [issue1260] PEP 3137: Remove the buffer API from PyUnicode Message-ID: <1192121511.36.0.657887990172.issue1260@psf.upfronthosting.co.za> Changes by Guido van Rossum: ---------- assignee: -> gvanrossum nosy: +gvanrossum __________________________________ Tracker __________________________________ From report at bugs.python.org Thu Oct 11 18:52:28 2007 From: report at bugs.python.org (Guido van Rossum) Date: Thu, 11 Oct 2007 16:52:28 -0000 Subject: [issue1261] PEP 3137: make bytesobject.c methods use PEP 3118 buffer API Message-ID: <1192121548.38.0.985919356182.issue1261@psf.upfronthosting.co.za> Changes by Guido van Rossum: ---------- assignee: -> gvanrossum nosy: +gvanrossum __________________________________ Tracker __________________________________ From report at bugs.python.org Thu Oct 11 18:53:21 2007 From: report at bugs.python.org (Guido van Rossum) Date: Thu, 11 Oct 2007 16:53:21 -0000 Subject: [issue1263] PEP 3137 patch - str8/str comparison should return false Message-ID: <1192121601.98.0.366001450481.issue1263@psf.upfronthosting.co.za> Changes by Guido van Rossum: ---------- assignee: -> gvanrossum nosy: +gvanrossum __________________________________ Tracker __________________________________ From report at bugs.python.org Thu Oct 11 18:53:28 2007 From: report at bugs.python.org (Guido van Rossum) Date: Thu, 11 Oct 2007 16:53:28 -0000 Subject: [issue1031213] Use correct encoding for printing SyntaxErrors In-Reply-To: <1192088669.94.0.457674661229.issue1031213@psf.upfronthosting.co.za> Message-ID: Guido van Rossum added the comment: There are tons of situations where such an exception will be suppressed, ofr better or for worse. I don't think this one deserves such a radical approach. On 10/11/07, atsuo ishimoto wrote: > > atsuo ishimoto added the comment: > > Codecs would hardly ever raises exception here. > Usually, exception raised here would be a MemoryError. The unicode > string we are trying to encode is just decoded by same codec. If codec > raises exception other than MemoryError, the codec will likely have problem. > > I attached a script to print exception raised by codec. I wrote a "buggy" > encoder, which never return string but raises an exception. > > _____________________________________ > Tracker > > _____________________________________ > _____________________________________ Tracker _____________________________________ From report at bugs.python.org Thu Oct 11 19:40:46 2007 From: report at bugs.python.org (Guido van Rossum) Date: Thu, 11 Oct 2007 17:40:46 -0000 Subject: [issue1265] pdb bug with "with" statement Message-ID: <1192124446.53.0.689335791011.issue1265@psf.upfronthosting.co.za> Changes by Guido van Rossum: ---------- nosy: +gvanrossum __________________________________ Tracker __________________________________ From report at bugs.python.org Thu Oct 11 20:14:44 2007 From: report at bugs.python.org (Thorben) Date: Thu, 11 Oct 2007 18:14:44 -0000 Subject: [issue1266] segfault in curses when calling redrawwin() before refresh() Message-ID: <1192126484.51.0.25368750134.issue1266@psf.upfronthosting.co.za> New submission from Thorben: attached file makes python 2.5.1 segfault ---------- components: Library (Lib) files: curses-01.py messages: 56348 nosy: Thorben severity: critical status: open title: segfault in curses when calling redrawwin() before refresh() type: crash versions: Python 2.5 __________________________________ Tracker __________________________________ -------------- next part -------------- A non-text attachment was scrubbed... Name: curses-01.py Type: text/x-python Size: 157 bytes Desc: not available Url : http://mail.python.org/pipermail/python-bugs-list/attachments/20071011/497880bc/attachment-0001.py From report at bugs.python.org Thu Oct 11 20:14:44 2007 From: report at bugs.python.org (Thorben) Date: Thu, 11 Oct 2007 18:14:44 -0000 Subject: [issue1266] segfault in curses when calling redrawwin() before refresh() Message-ID: <1192126484.51.0.25368750134.issue1266@psf.upfronthosting.co.za> New submission from Thorben: attached file makes python 2.5.1 segfault ---------- components: Library (Lib) files: curses-01.py messages: 56348 nosy: Thorben severity: critical status: open title: segfault in curses when calling redrawwin() before refresh() type: crash versions: Python 2.5 __________________________________ Tracker __________________________________ -------------- next part -------------- A non-text attachment was scrubbed... Name: curses-01.py Type: text/x-python Size: 157 bytes Desc: not available Url : http://mail.python.org/pipermail/python-bugs-list/attachments/20071011/497880bc/attachment-0002.py From report at bugs.python.org Thu Oct 11 21:28:37 2007 From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=) Date: Thu, 11 Oct 2007 19:28:37 -0000 Subject: [issue1263] PEP 3137 patch - str8/str comparison should return false Message-ID: <1192130917.21.0.466293477677.issue1263@psf.upfronthosting.co.za> Changes by Martin v. L?wis: ---------- keywords: +patch __________________________________ Tracker __________________________________ From report at bugs.python.org Thu Oct 11 21:29:44 2007 From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=) Date: Thu, 11 Oct 2007 19:29:44 -0000 Subject: [issue1264] __file__ and co_filename as unicode Message-ID: <1192130984.31.0.306376325331.issue1264@psf.upfronthosting.co.za> Changes by Martin v. L?wis: ---------- keywords: +patch __________________________________ Tracker __________________________________ From report at bugs.python.org Thu Oct 11 21:52:06 2007 From: report at bugs.python.org (Thomas Heller) Date: Thu, 11 Oct 2007 19:52:06 -0000 Subject: [issue1203] ctypes doesn't work on Mac with --disable-toolbox-glue Message-ID: <1192132326.05.0.668503086618.issue1203@psf.upfronthosting.co.za> Thomas Heller added the comment: IMO os.uname() is preferable. Committed as SVN rev 58415 in trunk. Thanks. ---------- assignee: -> theller resolution: -> accepted status: open -> closed __________________________________ Tracker __________________________________ From report at bugs.python.org Fri Oct 12 00:58:18 2007 From: report at bugs.python.org (Brett Cannon) Date: Thu, 11 Oct 2007 22:58:18 -0000 Subject: [issue756576] Recursion limit too high for MacOSX Message-ID: <1192143498.96.0.515325555269.issue756576@psf.upfronthosting.co.za> Changes by Brett Cannon: ---------- status: open -> closed ____________________________________ Tracker ____________________________________ From report at bugs.python.org Fri Oct 12 01:02:39 2007 From: report at bugs.python.org (Brett Cannon) Date: Thu, 11 Oct 2007 23:02:39 -0000 Subject: [issue1267] Py3K cannot run as ``python -S`` Message-ID: <1192143759.73.0.716718415917.issue1267@psf.upfronthosting.co.za> New submission from Brett Cannon: If Py3K is executed without importing site, it fails horribly. This is because site.py sets __builtins__.open, sys.stdout, sys.stderr, and sys.stdin. The setting of sys.stderr is especially bad as exception printing requires sys.stderr, otherwise it reports that sys.stderr was lost. This prevents debugging any exceptions thrown when site.py isn't/can't be imported (e.g., trying to debug bootstrapping importlib). ---------- components: Interpreter Core keywords: py3k messages: 56350 nosy: brett.cannon severity: normal status: open title: Py3K cannot run as ``python -S`` versions: Python 3.0 __________________________________ Tracker __________________________________ From report at bugs.python.org Fri Oct 12 01:02:40 2007 From: report at bugs.python.org (Brett Cannon) Date: Thu, 11 Oct 2007 23:02:40 -0000 Subject: [issue1267] Py3K cannot run as ``python -S`` Message-ID: <1192143759.73.0.716718415917.issue1267@psf.upfronthosting.co.za> New submission from Brett Cannon: If Py3K is executed without importing site, it fails horribly. This is because site.py sets __builtins__.open, sys.stdout, sys.stderr, and sys.stdin. The setting of sys.stderr is especially bad as exception printing requires sys.stderr, otherwise it reports that sys.stderr was lost. This prevents debugging any exceptions thrown when site.py isn't/can't be imported (e.g., trying to debug bootstrapping importlib). ---------- components: Interpreter Core keywords: py3k messages: 56350 nosy: brett.cannon severity: normal status: open title: Py3K cannot run as ``python -S`` versions: Python 3.0 __________________________________ Tracker __________________________________ From report at bugs.python.org Fri Oct 12 02:57:05 2007 From: report at bugs.python.org (Gregory P. Smith) Date: Fri, 12 Oct 2007 00:57:05 -0000 Subject: [issue1261] PEP 3137: make bytesobject.c methods Message-ID: <1192150625.39.0.532167792852.issue1261@psf.upfronthosting.co.za> Changes by Gregory P. Smith: __________________________________ Tracker __________________________________ From report at bugs.python.org Fri Oct 12 04:42:33 2007 From: report at bugs.python.org (Guido van Rossum) Date: Fri, 12 Oct 2007 02:42:33 -0000 Subject: [issue1261] PEP 3137: make bytesobject.c methods In-Reply-To: <1192150615.15.0.333789718136.issue1261@psf.upfronthosting.co.za> Message-ID: Guido van Rossum added the comment: > Patch updated. It now implements the is*() methods for PyBytes. It > moves common code into a shared bytes_ctype.c and .h file so that > stringobject.c and bytesobject.c can share as much as possible. Did you move this into the stringlib subdirectory? That's more for sharing between PyString and PyUnicode, but I think there are more opportunities for sharing still, and PyString/PyBytes sharing makes sense separately. __________________________________ Tracker __________________________________ From report at bugs.python.org Fri Oct 12 05:10:48 2007 From: report at bugs.python.org (Christian Heimes) Date: Fri, 12 Oct 2007 03:10:48 -0000 Subject: [issue1268] array unittest problems with UCS4 build Message-ID: <1192158648.5.0.179668399301.issue1268@psf.upfronthosting.co.za> New submission from Christian Heimes: The array module is using a different typecode for unicode array depending on UCS2 or UCS4: #define Py_UNICODE_SIZE 4 #if Py_UNICODE_SIZE >= 4 #define Py_UNICODE_WIDE #endif #ifdef Py_UNICODE_WIDE #define PyArr_UNI 'w' #define PyArr_UNISTR "w" #else #define PyArr_UNI 'u' #define PyArr_UNISTR "u" #endif It's causing a bunch of unit test to fail which depend on 'u' as the type code for an unicode array. I don't see the benefit from specifying an alternative typecode for wide unicode arrays. It may be useful to have an additional typecode that fails for UCS-2 builds. My patch keeps 'u' in every build and adds 'w' as an alias for 'u' in UCS-4 builds only. It also introduces the new module variable typecodes which is a unicode string containing all valid typecodes. ---------- components: Extension Modules files: py3k_array_typecode.patch messages: 56353 nosy: tiran severity: normal status: open title: array unittest problems with UCS4 build versions: Python 3.0 __________________________________ Tracker __________________________________ -------------- next part -------------- A non-text attachment was scrubbed... Name: py3k_array_typecode.patch Type: text/x-diff Size: 8188 bytes Desc: not available Url : http://mail.python.org/pipermail/python-bugs-list/attachments/20071012/ea9165dd/attachment-0001.patch From report at bugs.python.org Fri Oct 12 05:10:49 2007 From: report at bugs.python.org (Christian Heimes) Date: Fri, 12 Oct 2007 03:10:49 -0000 Subject: [issue1268] array unittest problems with UCS4 build Message-ID: <1192158648.5.0.179668399301.issue1268@psf.upfronthosting.co.za> New submission from Christian Heimes: The array module is using a different typecode for unicode array depending on UCS2 or UCS4: #define Py_UNICODE_SIZE 4 #if Py_UNICODE_SIZE >= 4 #define Py_UNICODE_WIDE #endif #ifdef Py_UNICODE_WIDE #define PyArr_UNI 'w' #define PyArr_UNISTR "w" #else #define PyArr_UNI 'u' #define PyArr_UNISTR "u" #endif It's causing a bunch of unit test to fail which depend on 'u' as the type code for an unicode array. I don't see the benefit from specifying an alternative typecode for wide unicode arrays. It may be useful to have an additional typecode that fails for UCS-2 builds. My patch keeps 'u' in every build and adds 'w' as an alias for 'u' in UCS-4 builds only. It also introduces the new module variable typecodes which is a unicode string containing all valid typecodes. ---------- components: Extension Modules files: py3k_array_typecode.patch messages: 56353 nosy: tiran severity: normal status: open title: array unittest problems with UCS4 build versions: Python 3.0 __________________________________ Tracker __________________________________ -------------- next part -------------- A non-text attachment was scrubbed... Name: py3k_array_typecode.patch Type: text/x-diff Size: 8188 bytes Desc: not available Url : http://mail.python.org/pipermail/python-bugs-list/attachments/20071012/ea9165dd/attachment-0002.patch From report at bugs.python.org Fri Oct 12 05:20:59 2007 From: report at bugs.python.org (Gregory P. Smith) Date: Fri, 12 Oct 2007 03:20:59 -0000 Subject: [issue1261] PEP 3137: make bytesobject.c methods In-Reply-To: Message-ID: <52dc1c820710112020m1cf354fercbddcefecf4959de@mail.gmail.com> Gregory P. Smith added the comment: > > Patch updated. It now implements the is*() methods for PyBytes. It > > moves common code into a shared bytes_ctype.c and .h file so that > > stringobject.c and bytesobject.c can share as much as possible. > > Did you move this into the stringlib subdirectory? That's more for > sharing between PyString and PyUnicode, but I think there are more > opportunities for sharing still, and PyString/PyBytes sharing makes > sense separately. Good idea, I haven't done that yet. At the moment it lives in Include/bytes_ctype.h and Object/bytes_ctype.c directly. stringlib is a good place for it and is something I pondered but hadn't gotten to. I'll do that as I implement the remaining missing PyBytes_ methods to be in the next update to this patch. -gps ---------- nosy: +gps __________________________________ Tracker __________________________________ -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: unnamed Url: http://mail.python.org/pipermail/python-bugs-list/attachments/20071012/e373f7bd/attachment.txt From report at bugs.python.org Fri Oct 12 05:21:41 2007 From: report at bugs.python.org (Gregory P. Smith) Date: Fri, 12 Oct 2007 03:21:41 -0000 Subject: [issue1261] PEP 3137: make bytesobject.c methods Message-ID: <1192159301.11.0.555911381403.issue1261@psf.upfronthosting.co.za> Changes by Gregory P. Smith: __________________________________ Tracker __________________________________ From report at bugs.python.org Fri Oct 12 05:35:50 2007 From: report at bugs.python.org (Gregory P. Smith) Date: Fri, 12 Oct 2007 03:35:50 -0000 Subject: [issue1261] PEP 3137: make bytesobject.c methods Message-ID: <1192160150.9.0.853779316613.issue1261@psf.upfronthosting.co.za> Changes by Gregory P. Smith: ---------- nosy: -gps __________________________________ Tracker __________________________________ From report at bugs.python.org Fri Oct 12 07:22:26 2007 From: report at bugs.python.org (Neal Norwitz) Date: Fri, 12 Oct 2007 05:22:26 -0000 Subject: [issue1266] segfault in curses when calling redrawwin() before refresh() Message-ID: <1192166546.56.0.219755007952.issue1266@psf.upfronthosting.co.za> Neal Norwitz added the comment: What platform are you on? I can reproduce this with 2.5.1+ and trunk on Ubuntu. I can reproduce with a trivial C program that does the same thing. This could be a bug in the curses implementation. Or it could be misuse of the API. I don't know enough to suggest which is the case. The C program is: #include int main(int argc, char**argv) { WINDOW *win = initscr(); WINDOW *win2 = newwin(50, 50, 50, 50); redrawwin(win2); return 0; } Perhaps a bug should be filed against curses. ---------- components: +Extension Modules -Library (Lib) nosy: +nnorwitz __________________________________ Tracker __________________________________ From report at bugs.python.org Fri Oct 12 07:34:59 2007 From: report at bugs.python.org (Neal Norwitz) Date: Fri, 12 Oct 2007 05:34:59 -0000 Subject: [issue1233] bsddb.dbshelve.DbShelf.append doesn't work Message-ID: <1192167299.62.0.0513006292194.issue1233@psf.upfronthosting.co.za> Neal Norwitz added the comment: Gregory, could you take a look at this? ---------- assignee: -> gregory.p.smith components: +Extension Modules -Library (Lib) nosy: +gregory.p.smith, nnorwitz __________________________________ Tracker __________________________________ From report at bugs.python.org Fri Oct 12 07:47:03 2007 From: report at bugs.python.org (Neal Norwitz) Date: Fri, 12 Oct 2007 05:47:03 -0000 Subject: [issue1216] Python2.5.1 fails to compile under VC.NET2002 ( 7.0 ) Message-ID: <1192168023.6.0.83569407676.issue1216@psf.upfronthosting.co.za> Neal Norwitz added the comment: Martin, it looks like you made some changes in rev 46064. Can you suggest anything? ---------- assignee: -> loewis components: +Extension Modules nosy: +loewis, nnorwitz __________________________________ Tracker __________________________________ From report at bugs.python.org Fri Oct 12 09:06:27 2007 From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=) Date: Fri, 12 Oct 2007 07:06:27 -0000 Subject: [issue1268] array unittest problems with UCS4 build Message-ID: <1192172787.32.0.0890985430428.issue1268@psf.upfronthosting.co.za> Changes by Martin v. L?wis: ---------- keywords: +patch __________________________________ Tracker __________________________________ From report at bugs.python.org Fri Oct 12 09:14:22 2007 From: report at bugs.python.org (Andrew Stromnov) Date: Fri, 12 Oct 2007 07:14:22 -0000 Subject: [issue1269] Exception in pstats print_callers() Message-ID: <1192173262.83.0.27550877069.issue1269@psf.upfronthosting.co.za> New submission from Andrew Stromnov: Python 2.5.1 (r251:54863, Apr 18 2007, 08:51:08) [MSC v.1310 32 bit (Intel)] on win32 Type "help", "copyright", "credits" or "license" for more information. >>> import pstats >>> ps = pstats.Stats("profile.log") >>> ps.add("profile.log") >>> ps.print_callers() Random listing order was used {method 'append' of 'list' objects} <- Traceback (most recent call last): File "", line 1, in File "C:\Python25\lib\pstats.py", line 388, in print_callers self.print_call_line(width, func, callers, "<-") File "C:\Python25\lib\pstats.py", line 417, in print_call_line nc, cc, tt, ct = value ValueError: too many values to unpack ---------- components: Library (Lib) files: profile.log messages: 56358 nosy: stromnov severity: normal status: open title: Exception in pstats print_callers() type: crash versions: Python 2.5 __________________________________ Tracker __________________________________ -------------- next part -------------- A non-text attachment was scrubbed... Name: profile.log Type: application/octet-stream Size: 2733 bytes Desc: not available Url : http://mail.python.org/pipermail/python-bugs-list/attachments/20071012/57b7f71c/attachment.obj From report at bugs.python.org Fri Oct 12 09:14:23 2007 From: report at bugs.python.org (Andrew Stromnov) Date: Fri, 12 Oct 2007 07:14:23 -0000 Subject: [issue1269] Exception in pstats print_callers() Message-ID: <1192173262.83.0.27550877069.issue1269@psf.upfronthosting.co.za> New submission from Andrew Stromnov: Python 2.5.1 (r251:54863, Apr 18 2007, 08:51:08) [MSC v.1310 32 bit (Intel)] on win32 Type "help", "copyright", "credits" or "license" for more information. >>> import pstats >>> ps = pstats.Stats("profile.log") >>> ps.add("profile.log") >>> ps.print_callers() Random listing order was used {method 'append' of 'list' objects} <- Traceback (most recent call last): File "", line 1, in File "C:\Python25\lib\pstats.py", line 388, in print_callers self.print_call_line(width, func, callers, "<-") File "C:\Python25\lib\pstats.py", line 417, in print_call_line nc, cc, tt, ct = value ValueError: too many values to unpack ---------- components: Library (Lib) files: profile.log messages: 56358 nosy: stromnov severity: normal status: open title: Exception in pstats print_callers() type: crash versions: Python 2.5 __________________________________ Tracker __________________________________ -------------- next part -------------- A non-text attachment was scrubbed... Name: profile.log Type: application/octet-stream Size: 2733 bytes Desc: not available Url : http://mail.python.org/pipermail/python-bugs-list/attachments/20071012/57b7f71c/attachment-0001.obj From report at bugs.python.org Fri Oct 12 09:27:58 2007 From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=) Date: Fri, 12 Oct 2007 07:27:58 -0000 Subject: [issue1216] Python2.5.1 fails to compile under VC.NET2002 ( 7.0 ) Message-ID: <1192174078.16.0.826014036585.issue1216@psf.upfronthosting.co.za> Martin v. L?wis added the comment: The actual change that broke that was r41672, which added the ULL suffix. r46064 fixed it for VC6 and embedded VC. Raising the minimum _MSC_VER to above 1300 is fine (VC 7.1 is 1310). I personally can't test with VS 2002 anymore, so I have to trust that it doesn't support the suffix, and that it's value of _MSC_VER is 1300. __________________________________ Tracker __________________________________ From report at bugs.python.org Fri Oct 12 10:59:29 2007 From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=) Date: Fri, 12 Oct 2007 08:59:29 -0000 Subject: [issue1216] Python2.5.1 fails to compile under VC.NET2002 ( 7.0 ) Message-ID: <1192179569.45.0.246989006737.issue1216@psf.upfronthosting.co.za> Martin v. L?wis added the comment: Thanks for the report. This is now fixed in r58430 and r584301 __________________________________ Tracker __________________________________ From report at bugs.python.org Fri Oct 12 10:59:50 2007 From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=) Date: Fri, 12 Oct 2007 08:59:50 -0000 Subject: [issue1216] Python2.5.1 fails to compile under VC.NET2002 ( 7.0 ) Message-ID: <1192179590.07.0.821063789841.issue1216@psf.upfronthosting.co.za> Changes by Martin v. L?wis: ---------- resolution: -> fixed status: open -> closed __________________________________ Tracker __________________________________ From report at bugs.python.org Fri Oct 12 12:02:24 2007 From: report at bugs.python.org (Andre M. Descombes) Date: Fri, 12 Oct 2007 10:02:24 -0000 Subject: [issue1270] MemoryError when working on large dictionaries on Windows 2003 Server Message-ID: <1192183344.18.0.434949656884.issue1270@psf.upfronthosting.co.za> New submission from Andre M. Descombes: Hi everybody, I am using Python 2.5.1. I am creating a rather large dictionnary, with more than 8 million entries, memory usage should be about 1.5GB. If I run the program on Windows XP all runs fine, if I run the program on Windows Server 2003 I start getting MemoryError exceptions around the 1GB boundary. Is there a known issue with Windows 2003 Server? Thanks, Andr? M. Descombes ---------- components: Interpreter Core messages: 56361 nosy: amdescombes severity: critical status: open title: MemoryError when working on large dictionaries on Windows 2003 Server type: resource usage versions: Python 2.5 __________________________________ Tracker __________________________________ From report at bugs.python.org Fri Oct 12 12:02:24 2007 From: report at bugs.python.org (Andre M. Descombes) Date: Fri, 12 Oct 2007 10:02:24 -0000 Subject: [issue1270] MemoryError when working on large dictionaries on Windows 2003 Server Message-ID: <1192183344.18.0.434949656884.issue1270@psf.upfronthosting.co.za> New submission from Andre M. Descombes: Hi everybody, I am using Python 2.5.1. I am creating a rather large dictionnary, with more than 8 million entries, memory usage should be about 1.5GB. If I run the program on Windows XP all runs fine, if I run the program on Windows Server 2003 I start getting MemoryError exceptions around the 1GB boundary. Is there a known issue with Windows 2003 Server? Thanks, Andr? M. Descombes ---------- components: Interpreter Core messages: 56361 nosy: amdescombes severity: critical status: open title: MemoryError when working on large dictionaries on Windows 2003 Server type: resource usage versions: Python 2.5 __________________________________ Tracker __________________________________ From report at bugs.python.org Fri Oct 12 12:20:51 2007 From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=) Date: Fri, 12 Oct 2007 10:20:51 -0000 Subject: [issue1270] MemoryError when working on large dictionaries on Windows 2003 Server Message-ID: <1192184451.36.0.525480772214.issue1270@psf.upfronthosting.co.za> Martin v. L?wis added the comment: Please understand that the purpose of this bug tracker is to track bug reports and patches to Python, not a means of getting help in using Python. If you think you have found a bug, please submit a bug report that allows us to reproduce the bug. If you merely need help, please use some of the Python community channels, such as python-list at python.org. As for your question: I'm not aware of an issue with Windows 2003 server that could explain that behavior. Most likely, you get the MemoryError because you really ran out of memory. Try increasing the page file, and put more main memory into the machine. ---------- nosy: +loewis resolution: -> invalid __________________________________ Tracker __________________________________ From report at bugs.python.org Fri Oct 12 12:20:56 2007 From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=) Date: Fri, 12 Oct 2007 10:20:56 -0000 Subject: [issue1270] MemoryError when working on large dictionaries on Windows 2003 Server Message-ID: <1192184456.56.0.547123777638.issue1270@psf.upfronthosting.co.za> Changes by Martin v. L?wis: ---------- status: open -> closed __________________________________ Tracker __________________________________ From report at bugs.python.org Fri Oct 12 13:41:16 2007 From: report at bugs.python.org (Andre M. Descombes) Date: Fri, 12 Oct 2007 11:41:16 -0000 Subject: [issue1270] MemoryError when working on large dictionaries on Windows 2003 Server In-Reply-To: <1192184451.36.0.525480772214.issue1270@psf.upfronthosting.co.za> Message-ID: Andre M. Descombes added the comment: Martin, it is really a bug, as I have tried on a machine with Windows 2003 server and 4GBs of ram and it still doesn't run, and it does run on xp with only 1GB of ram. Does python.exe have then IMAGE_FILE_LARGE_ADDRESS_AWARE bit set, that could explain the behaviour it its not set. Thanks, Andre M. Descombes On 10/12/07, Martin v. L?wis wrote: > > > Martin v. L?wis added the comment: > > Please understand that the purpose of this bug tracker is to track bug > reports and patches to Python, not a means of getting help in using > Python. If you think you have found a bug, please submit a bug report > that allows us to reproduce the bug. If you merely need help, please use > some of the Python community channels, such as python-list at python.org. > > As for your question: I'm not aware of an issue with Windows 2003 server > that could explain that behavior. Most likely, you get the MemoryError > because you really ran out of memory. Try increasing the page file, and > put more main memory into the machine. > > ---------- > nosy: +loewis > resolution: -> invalid > > __________________________________ > Tracker > > __________________________________ > __________________________________ Tracker __________________________________ -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: unnamed Url: http://mail.python.org/pipermail/python-bugs-list/attachments/20071012/5530a822/attachment.txt From report at bugs.python.org Fri Oct 12 13:55:19 2007 From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=) Date: Fri, 12 Oct 2007 11:55:19 -0000 Subject: [issue1270] MemoryError when working on large dictionaries on Windows 2003 Server Message-ID: <1192190119.45.0.166447971512.issue1270@psf.upfronthosting.co.za> Martin v. L?wis added the comment: No, Python does not have IMAGE_FILE_LARGE_ADDRESS_AWARE set; that's not a bug, though. In any case, the lack of this flag cannot explain why your application works on Windows XP and not on Windows 2003. __________________________________ Tracker __________________________________ From report at bugs.python.org Fri Oct 12 13:59:32 2007 From: report at bugs.python.org (Andre M. Descombes) Date: Fri, 12 Oct 2007 11:59:32 -0000 Subject: [issue1270] MemoryError when working on large dictionaries on Windows 2003 Server In-Reply-To: <1192190119.45.0.166447971512.issue1270@psf.upfronthosting.co.za> Message-ID: Andre M. Descombes added the comment: Apparently, XP is more lax when it comes to checking this flag on the programs it runs then Windows 2003 Server. I am currently doing a test where I have manually added the flag to python to see if this makes the problem go away. I will post my results as soon as I have them. Andre M. Descombes __________________________________ Tracker __________________________________ -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: unnamed Url: http://mail.python.org/pipermail/python-bugs-list/attachments/20071012/df6f00ef/attachment.txt From report at bugs.python.org Fri Oct 12 14:23:13 2007 From: report at bugs.python.org (Andre M. Descombes) Date: Fri, 12 Oct 2007 12:23:13 -0000 Subject: [issue1270] MemoryError when working on large dictionaries on Windows 2003 Server In-Reply-To: <1192190119.45.0.166447971512.issue1270@psf.upfronthosting.co.za> Message-ID: Andre M. Descombes added the comment: I set the IMAGE_FILE_LARGE_ADDRESS_AWARE flag on python and I still get the memoryerror exceptions. When they start happening there is still more than 1GB of available memory! __________________________________ Tracker __________________________________ -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: unnamed Url: http://mail.python.org/pipermail/python-bugs-list/attachments/20071012/de032ea8/attachment.txt From report at bugs.python.org Fri Oct 12 14:36:56 2007 From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=) Date: Fri, 12 Oct 2007 12:36:56 -0000 Subject: [issue1270] MemoryError when working on large dictionaries on Windows 2003 Server In-Reply-To: Message-ID: <470F6A66.9000302@v.loewis.de> Martin v. L?wis added the comment: > I set the IMAGE_FILE_LARGE_ADDRESS_AWARE flag on python and I still get the > memoryerror exceptions. When they start happening there is still more than > 1GB of available memory! Just in case it isn't clear: I still don't see an indication of a bug in Python here. If Python reports MemoryError, it likely means that the system has refused to provide Python with more memory, whether or not it has memory available for other purposes. Martin __________________________________ Tracker __________________________________ From report at bugs.python.org Fri Oct 12 14:41:46 2007 From: report at bugs.python.org (Andre M. Descombes) Date: Fri, 12 Oct 2007 12:41:46 -0000 Subject: [issue1270] MemoryError when working on large dictionaries on Windows 2003 Server In-Reply-To: <470F6A66.9000302@v.loewis.de> Message-ID: Andre M. Descombes added the comment: Ok, so where would you recommend I move this discussion to? Andre On 10/12/07, Martin v. L?wis wrote: > > > Martin v. L?wis added the comment: > > > I set the IMAGE_FILE_LARGE_ADDRESS_AWARE flag on python and I still get > the > > memoryerror exceptions. When they start happening there is still more > than > > 1GB of available memory! > > Just in case it isn't clear: I still don't see an indication of a bug in > Python here. If Python reports MemoryError, it likely means that the > system has refused to provide Python with more memory, whether or not > it has memory available for other purposes. > > Martin > > __________________________________ > Tracker > > __________________________________ > __________________________________ Tracker __________________________________ -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: unnamed Url: http://mail.python.org/pipermail/python-bugs-list/attachments/20071012/7b93f558/attachment-0001.txt From report at bugs.python.org Fri Oct 12 14:49:00 2007 From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=) Date: Fri, 12 Oct 2007 12:49:00 -0000 Subject: [issue1270] MemoryError when working on large dictionaries on Windows 2003 Server Message-ID: <1192193340.04.0.377127546945.issue1270@psf.upfronthosting.co.za> Martin v. L?wis added the comment: I personally don't think this problem can be resolved by discussion. Instead, you have to use a debugger, debug your application, Python, and Windows, to find out the true cause of the problem. Only then discussion can be fruitful. If you cannot do these steps yourself, consider hiring somebody for you who can. If you still want to discuss, try python-list. __________________________________ Tracker __________________________________ From report at bugs.python.org Fri Oct 12 14:52:37 2007 From: report at bugs.python.org (Tim Gordon) Date: Fri, 12 Oct 2007 12:52:37 -0000 Subject: [issue1271] Raw string parsing fails with backslash as last character Message-ID: <1192193557.25.0.892687713719.issue1271@psf.upfronthosting.co.za> New submission from Tim Gordon: If you have a raw string with a backslash as the last character, the parser thinks the following quote, actually used to mark the end of the string, is being quoted by the backslash. For example, r'\' should be the string with one backslash, but... >>> print r'\' SyntaxError: EOL while scanning single-quoted string There seems to have been a fix added to python 3.0 (see issue 1720390), but it doesn't look like it's been backtracked into any earlier version. ---------- components: Interpreter Core messages: 56370 nosy: QuantumTim severity: normal status: open title: Raw string parsing fails with backslash as last character versions: Python 2.4, Python 2.5 __________________________________ Tracker __________________________________ From report at bugs.python.org Fri Oct 12 14:52:37 2007 From: report at bugs.python.org (Tim Gordon) Date: Fri, 12 Oct 2007 12:52:37 -0000 Subject: [issue1271] Raw string parsing fails with backslash as last character Message-ID: <1192193557.25.0.892687713719.issue1271@psf.upfronthosting.co.za> New submission from Tim Gordon: If you have a raw string with a backslash as the last character, the parser thinks the following quote, actually used to mark the end of the string, is being quoted by the backslash. For example, r'\' should be the string with one backslash, but... >>> print r'\' SyntaxError: EOL while scanning single-quoted string There seems to have been a fix added to python 3.0 (see issue 1720390), but it doesn't look like it's been backtracked into any earlier version. ---------- components: Interpreter Core messages: 56370 nosy: QuantumTim severity: normal status: open title: Raw string parsing fails with backslash as last character versions: Python 2.4, Python 2.5 __________________________________ Tracker __________________________________ From report at bugs.python.org Fri Oct 12 14:53:48 2007 From: report at bugs.python.org (Andre M. Descombes) Date: Fri, 12 Oct 2007 12:53:48 -0000 Subject: [issue1270] MemoryError when working on large dictionaries on Windows 2003 Server In-Reply-To: <1192193340.04.0.377127546945.issue1270@psf.upfronthosting.co.za> Message-ID: Andre M. Descombes added the comment: Thanks Martin, I think you are right, perhaps someone on the python-list will have seen and solved the problem before. Andre __________________________________ Tracker __________________________________ -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: unnamed Url: http://mail.python.org/pipermail/python-bugs-list/attachments/20071012/5c1f28e7/attachment.txt From report at bugs.python.org Fri Oct 12 14:57:58 2007 From: report at bugs.python.org (Facundo Batista) Date: Fri, 12 Oct 2007 12:57:58 -0000 Subject: [issue1271] Raw string parsing fails with backslash as last character Message-ID: <1192193878.03.0.824203665272.issue1271@psf.upfronthosting.co.za> Facundo Batista added the comment: As stated in the docs... http://docs.python.org/dev/reference/lexical_analysis.html#string-literals r"\" is not a valid string literal (even a raw string cannot end in an odd number of backslashes). Specifically, a raw string cannot end in a single backslash (since the backslash would escape the following quote character). ---------- nosy: +facundobatista resolution: -> invalid status: open -> closed __________________________________ Tracker __________________________________ From report at bugs.python.org Fri Oct 12 15:32:21 2007 From: report at bugs.python.org (Tim Gordon) Date: Fri, 12 Oct 2007 13:32:21 -0000 Subject: [issue1271] Raw string parsing fails with backslash as last character In-Reply-To: <1192193878.03.0.824203665272.issue1271@psf.upfronthosting.co.za> Message-ID: <470F7753.7040309@aleph17.co.uk> Tim Gordon added the comment: So basically raw strings are useless if you need to end a string with a backslash, as there is no way to quote the backslash to make it not do this... This surely can't be too hard to "fix" if one considers it a problem (which I do), and just because even the docs say it is the correct behaviour, doesn't mean it should be. Perhaps this has been debated before (and if so, where?), but it does seem rather odd behaviour. __________________________________ Tracker __________________________________ From report at bugs.python.org Fri Oct 12 15:41:38 2007 From: report at bugs.python.org (Christian Heimes) Date: Fri, 12 Oct 2007 13:41:38 -0000 Subject: [issue1272] Decode __file__ and co_filename to unicode using fs default Message-ID: <1192196498.75.0.195670929774.issue1272@psf.upfronthosting.co.za> New submission from Christian Heimes: I'm sending the patch in for review. ---------- components: Interpreter Core files: py3k_file_fsenc2.patch messages: 56374 nosy: tiran severity: normal status: open title: Decode __file__ and co_filename to unicode using fs default versions: Python 3.0 __________________________________ Tracker __________________________________ -------------- next part -------------- A non-text attachment was scrubbed... Name: py3k_file_fsenc2.patch Type: text/x-diff Size: 9342 bytes Desc: not available Url : http://mail.python.org/pipermail/python-bugs-list/attachments/20071012/32dd9344/attachment-0001.patch From report at bugs.python.org Fri Oct 12 15:41:38 2007 From: report at bugs.python.org (Christian Heimes) Date: Fri, 12 Oct 2007 13:41:38 -0000 Subject: [issue1272] Decode __file__ and co_filename to unicode using fs default Message-ID: <1192196498.75.0.195670929774.issue1272@psf.upfronthosting.co.za> New submission from Christian Heimes: I'm sending the patch in for review. ---------- components: Interpreter Core files: py3k_file_fsenc2.patch messages: 56374 nosy: tiran severity: normal status: open title: Decode __file__ and co_filename to unicode using fs default versions: Python 3.0 __________________________________ Tracker __________________________________ -------------- next part -------------- A non-text attachment was scrubbed... Name: py3k_file_fsenc2.patch Type: text/x-diff Size: 9342 bytes Desc: not available Url : http://mail.python.org/pipermail/python-bugs-list/attachments/20071012/32dd9344/attachment-0002.patch From report at bugs.python.org Fri Oct 12 16:09:43 2007 From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=) Date: Fri, 12 Oct 2007 14:09:43 -0000 Subject: [issue1272] Decode __file__ and co_filename to unicode using fs default Message-ID: <1192198183.29.0.729199035005.issue1272@psf.upfronthosting.co.za> Changes by Martin v. L?wis: ---------- keywords: +patch __________________________________ Tracker __________________________________ From report at bugs.python.org Fri Oct 12 17:43:59 2007 From: report at bugs.python.org (Christian Heimes) Date: Fri, 12 Oct 2007 15:43:59 -0000 Subject: [issue1268] array unittest problems with UCS4 build Message-ID: <1192203839.5.0.832196540185.issue1268@psf.upfronthosting.co.za> Christian Heimes added the comment: svn annotate shows that you implemented the 'w' typecode in revision 57181. What do you think about my patch and my proposal? ---------- nosy: +teoliphant __________________________________ Tracker __________________________________ From report at bugs.python.org Fri Oct 12 18:03:19 2007 From: report at bugs.python.org (Ed Vinyard) Date: Fri, 12 Oct 2007 16:03:19 -0000 Subject: [issue1273] email module example email-unpack.py error Message-ID: <1192204998.94.0.0490108270822.issue1273@psf.upfronthosting.co.za> New submission from Ed Vinyard: In the email module example, email-unpack.py (http://docs.python.org/lib/email-unpack.txt), line 56 throws an AttributeError. It is currently ext = mimetypes.guess_extension(part.get_type()) I think this line should be ext = mimetypes.guess_extension(part.get_content_type()) The Message documentation (http://docs.python.org/lib/module-email.message.html) mentions that "Changed in version 2.5: The previously deprecated methods get_type(), get_main_type(), and get_subtype() were removed." ---------- components: Documentation messages: 56376 nosy: esv severity: minor status: open title: email module example email-unpack.py error type: behavior versions: Python 2.5 __________________________________ Tracker __________________________________ From report at bugs.python.org Fri Oct 12 18:03:18 2007 From: report at bugs.python.org (Ed Vinyard) Date: Fri, 12 Oct 2007 16:03:18 -0000 Subject: [issue1273] email module example email-unpack.py error Message-ID: <1192204998.94.0.0490108270822.issue1273@psf.upfronthosting.co.za> New submission from Ed Vinyard: In the email module example, email-unpack.py (http://docs.python.org/lib/email-unpack.txt), line 56 throws an AttributeError. It is currently ext = mimetypes.guess_extension(part.get_type()) I think this line should be ext = mimetypes.guess_extension(part.get_content_type()) The Message documentation (http://docs.python.org/lib/module-email.message.html) mentions that "Changed in version 2.5: The previously deprecated methods get_type(), get_main_type(), and get_subtype() were removed." ---------- components: Documentation messages: 56376 nosy: esv severity: minor status: open title: email module example email-unpack.py error type: behavior versions: Python 2.5 __________________________________ Tracker __________________________________ From report at bugs.python.org Fri Oct 12 18:15:25 2007 From: report at bugs.python.org (Georg Brandl) Date: Fri, 12 Oct 2007 16:15:25 -0000 Subject: [issue1271] Raw string parsing fails with backslash as last character Message-ID: <1192205725.91.0.847312886676.issue1271@psf.upfronthosting.co.za> Georg Brandl added the comment: There's more to allowing \ at the end of a raw string: if you do that, the raw string will end at the first quote character which is the same as the opening one, so you can't put such a quote character into a raw string anymore. At the moment, you can, by escaping it with a backslash, though the backslash is left in the string. There are basically two main uses for raw strings: Windows path names and regular expressions. The current situation is optimal for the latter: you can put both quote characters in a raw string, and the backslash needed to quote the "string quote" being retained is not a problem. ---------- nosy: +georg.brandl __________________________________ Tracker __________________________________ From report at bugs.python.org Fri Oct 12 18:42:04 2007 From: report at bugs.python.org (Gregory P. Smith) Date: Fri, 12 Oct 2007 16:42:04 -0000 Subject: [issue1233] bsddb.dbshelve.DbShelf.append doesn't work Message-ID: <1192207324.82.0.53325985989.issue1233@psf.upfronthosting.co.za> Gregory P. Smith added the comment: heh yep that does look like a bug. Laughing at that one goes well with this comment currently in test_dbshelve.py: # TODO: Add test cases for a DBShelf in a RECNO DB. i'll fix it. :) __________________________________ Tracker __________________________________ From report at bugs.python.org Fri Oct 12 18:43:30 2007 From: report at bugs.python.org (Bill Janssen) Date: Fri, 12 Oct 2007 16:43:30 -0000 Subject: [issue1251] ssl module doesn't support non-blocking handshakes Message-ID: <1192207410.62.0.381288037694.issue1251@psf.upfronthosting.co.za> Bill Janssen added the comment: Chris, Looking at this a bit harder, I don't see that it accomplishes much. The loop in _ssl.c/do_handshake will never return WANT_READ or WANT_WRITE, so the loop in the test case, for instance, is unnecessary. The original code handled the non-blocking case just fine. I think this fix is unnecessary. __________________________________ Tracker __________________________________ From report at bugs.python.org Fri Oct 12 19:19:51 2007 From: report at bugs.python.org (Chris Stawarz) Date: Fri, 12 Oct 2007 17:19:51 -0000 Subject: [issue1251] ssl module doesn't support non-blocking handshakes In-Reply-To: <1192207410.62.0.381288037694.issue1251@psf.upfronthosting.co.za> Message-ID: <2A59C0D9-B831-40DD-8AF7-A7CB312A0631@csail.mit.edu> Chris Stawarz added the comment: > The loop in _ssl.c/do_handshake will never return WANT_READ or > WANT_WRITE, so the loop in the test case, for instance, is > unnecessary. I don't know why you think that, but it's easy enough to show that this statement is incorrect. I've attached two scripts (nonblocking_handshake.py and blocking_handshake.py). The first does basically the same thing as my test case, but connecting to a different server and with some print statements added. Here's the output I get when I run it using an up-to-date trunk checkout with my patch applied: $ ../build/bin/python2.6 nonblocking_handshake.py starting handshake need read need read need read handshake complete The second reproduces the situation that led me to file this bug report in the first place. Here's what happens when I run it with an *unpatched* trunk build: $ ../build/bin/python2.6 blocking_handshake.py starting handshake need read Traceback (most recent call last): File "blocking_handshake.py", line 14, in s = ssl.wrap_socket(s,cert_reqs=ssl.CERT_NONE) File "/Users/cstawarz/Documents/Code/Python/svn/build/lib/ python2.6/ssl.py", line 466, in wrap_socket ssl_version=ssl_version, ca_certs=ca_certs) File "/Users/cstawarz/Documents/Code/Python/svn/build/lib/ python2.6/ssl.py", line 103, in __init__ cert_reqs, ssl_version, ca_certs) ssl.SSLError: [Errno 1] _ssl.c:429: error:04077068:rsa routines:RSA_verify:bad signature As you see, in both cases the handshaking fails with SSL_ERROR_WANT_READ. But without the fixes introduced by my patch, there's no way to handle the error. __________________________________ Tracker __________________________________ -------------- next part -------------- A non-text attachment was scrubbed... Name: nonblocking_handshake.py Type: text/x-python-script Size: 685 bytes Desc: not available Url : http://mail.python.org/pipermail/python-bugs-list/attachments/20071012/a2b3e742/attachment.bin -------------- next part -------------- A non-text attachment was scrubbed... Name: blocking_handshake.py Type: text/x-python-script Size: 602 bytes Desc: not available Url : http://mail.python.org/pipermail/python-bugs-list/attachments/20071012/a2b3e742/attachment-0001.bin From report at bugs.python.org Fri Oct 12 20:29:49 2007 From: report at bugs.python.org (Mike Taylor) Date: Fri, 12 Oct 2007 18:29:49 -0000 Subject: [issue1274] doctest fails to run file based tests with 8bit paths Message-ID: <1192213789.99.0.676777667813.issue1274@psf.upfronthosting.co.za> Changes by Mike Taylor: ---------- components: Tests severity: major status: open title: doctest fails to run file based tests with 8bit paths type: behavior versions: Python 2.5 __________________________________ Tracker __________________________________ From report at bugs.python.org Fri Oct 12 20:31:59 2007 From: report at bugs.python.org (Mike Taylor) Date: Fri, 12 Oct 2007 18:31:59 -0000 Subject: [issue1274] doctest fails to run file based tests with 8bit paths Message-ID: <1192213919.32.0.843568182453.issue1274@psf.upfronthosting.co.za> New submission from Mike Taylor: In our builds the included patch fixes this issue. Patch by Brian Kirsch, tested at OSAF on Python 2.5.1 ---------- nosy: +bear __________________________________ Tracker __________________________________ -------------- next part -------------- A non-text attachment was scrubbed... Name: bug_3740_1.patch Type: application/octet-stream Size: 917 bytes Desc: not available Url : http://mail.python.org/pipermail/python-bugs-list/attachments/20071012/e2c115ef/attachment.obj From report at bugs.python.org Fri Oct 12 21:14:44 2007 From: report at bugs.python.org (Gregory P. Smith) Date: Fri, 12 Oct 2007 19:14:44 -0000 Subject: [issue1233] bsddb.dbshelve.DbShelf.append doesn't work Message-ID: <1192216484.95.0.528918985518.issue1233@psf.upfronthosting.co.za> Gregory P. Smith added the comment: Fixed in python trunk r58434, release25-maint r58435, py3k r58438 ---------- resolution: -> fixed status: open -> closed versions: +Python 2.6, Python 3.0 __________________________________ Tracker __________________________________ From report at bugs.python.org Fri Oct 12 21:20:02 2007 From: report at bugs.python.org (Gregory P. Smith) Date: Fri, 12 Oct 2007 19:20:02 -0000 Subject: [issue1275] bsddb closing a DB object before all DBCursors using it are closed crashes Message-ID: <1192216802.58.0.956972286502.issue1275@psf.upfronthosting.co.za> New submission from Gregory P. Smith: If a bsddb.db.DB object is closed before any DBCursor objects referencing it are closed, python will crash when the cursors are closed or deleted. Workaround: never close a database with open cursors. this is annoying in unittest code where a tearDown method closes the DB in the exception handling path on a test failure before the cursors have been closed or garbage collected. I've got a test in my sandbox, I'll check it in with the fix as its a crasher otherwise. ---------- assignee: gregory.p.smith components: Extension Modules messages: 56383 nosy: gregory.p.smith severity: normal status: open title: bsddb closing a DB object before all DBCursors using it are closed crashes type: crash __________________________________ Tracker __________________________________ From report at bugs.python.org Fri Oct 12 21:20:02 2007 From: report at bugs.python.org (Gregory P. Smith) Date: Fri, 12 Oct 2007 19:20:02 -0000 Subject: [issue1275] bsddb closing a DB object before all DBCursors using it are closed crashes Message-ID: <1192216802.58.0.956972286502.issue1275@psf.upfronthosting.co.za> New submission from Gregory P. Smith: If a bsddb.db.DB object is closed before any DBCursor objects referencing it are closed, python will crash when the cursors are closed or deleted. Workaround: never close a database with open cursors. this is annoying in unittest code where a tearDown method closes the DB in the exception handling path on a test failure before the cursors have been closed or garbage collected. I've got a test in my sandbox, I'll check it in with the fix as its a crasher otherwise. ---------- assignee: gregory.p.smith components: Extension Modules messages: 56383 nosy: gregory.p.smith severity: normal status: open title: bsddb closing a DB object before all DBCursors using it are closed crashes type: crash __________________________________ Tracker __________________________________ From report at bugs.python.org Sat Oct 13 00:07:14 2007 From: report at bugs.python.org (Brett Cannon) Date: Fri, 12 Oct 2007 22:07:14 -0000 Subject: [issue1274] doctest fails to run file based tests with 8bit paths Message-ID: <1192226834.79.0.0570650649144.issue1274@psf.upfronthosting.co.za> Changes by Brett Cannon: ---------- keywords: +patch __________________________________ Tracker __________________________________ From report at bugs.python.org Sat Oct 13 03:36:18 2007 From: report at bugs.python.org (Marcos Dione) Date: Sat, 13 Oct 2007 01:36:18 -0000 Subject: [issue1580738] httplib hangs reading too much data Message-ID: <1192239378.22.0.499424195584.issue1580738@psf.upfronthosting.co.za> Marcos Dione added the comment: with facundo we were tracking this bug down. mhammond is right about that read() should allow 0 size responses, but the bug is that the response is "not closed". HTTPResponse.read() says: if amt is None: # unbounded read if self.length is None: s = self.fp.read() else: s = self._safe_read(self.length) self.length = 0 self.close() # we read everything return s see that if self.close()s, which really closes the fp created with makefile() in the constructor. this does not closes the underlying socket, as you can see trying this short example: import httplib c= httplib.HTTPConnection ('www.python.org', 80) c.request ('GET', '/index.html') a1= c.getresponse () data1= a1.read() c.request ('GET', '/404.html') a2= c.getresponse () data2= a2.read() and run it under strace -e network,file. if the last part of read is changed to this, read(n) works just like read() does: # we do not use _safe_read() here because this may be a .will_close # connection, and the user is reading more bytes than will be provided # (for example, reading in 1k chunks) s = self.fp.read(amt) if self.length is not None: self.length -= len(s) if len(s)==0: self.close () return s ---------- nosy: +StyXman, facundobatista _____________________________________ Tracker _____________________________________ From report at bugs.python.org Sat Oct 13 04:09:36 2007 From: report at bugs.python.org (Facundo Batista) Date: Sat, 13 Oct 2007 02:09:36 -0000 Subject: [issue1580738] httplib hangs reading too much data Message-ID: <1192241376.85.0.602549446161.issue1580738@psf.upfronthosting.co.za> Facundo Batista added the comment: Mark is ok, zero length responses are ok. But that has nothing to do with self.length. self.lenght reaching zero means that everything that needed to be read is already read. If the read() method is called without an argument, it reads everything until it reaches self.lenght, and then it closes self. So, when is called with an argument, is ok to close self if after reading something self.length reaches zero (note that this actually means that something was read, and self.length was lowered down...) If self is closed also in this instance (see the patch), all tests pass ok, and how you use HTTPConnection reading small pieces and not the whole thing, is actually simplified... ---------- assignee: -> facundobatista keywords: +patch versions: +Python 2.5 -Python 2.4 _____________________________________ Tracker _____________________________________ -------------- next part -------------- A non-text attachment was scrubbed... Name: httplib.py.diff Type: text/x-diff Size: 409 bytes Desc: not available Url : http://mail.python.org/pipermail/python-bugs-list/attachments/20071013/fd3ad960/attachment-0001.diff From report at bugs.python.org Sat Oct 13 12:07:09 2007 From: report at bugs.python.org (=?utf-8?q?=0A=09=09=09=09=09jos=0A=09=09=09=09?=) Date: Sat, 13 Oct 2007 10:07:09 -0000 Subject: [issue1276] LookupError: unknown encoding: X-MAC-JAPANESE Message-ID: <1192270029.29.0.976742738273.issue1276@psf.upfronthosting.co.za> New submission from jos : When I compile Python-3.0a1 on Mac OS X with Japanese locale, I've got LookupError like below. ========================================== running build_scripts creating build/scripts-3.0 Traceback (most recent call last): File "./setup.py", line 1572, in main() File "./setup.py", line 1567, in main 'Lib/smtpd.py'] File "/private/tmp/Python-3.0a1/Lib/distutils/core.py", line 148, in setup dist.run_commands() File "/private/tmp/Python-3.0a1/Lib/distutils/dist.py", line 943, in run_commands self.run_command(cmd) File "/private/tmp/Python-3.0a1/Lib/distutils/dist.py", line 963, in run_command cmd_obj.run() File "/private/tmp/Python-3.0a1/Lib/distutils/command/build.py", line 106, in run self.run_command(cmd_name) File "/private/tmp/Python-3.0a1/Lib/distutils/cmd.py", line 317, in run_command self.distribution.run_command(command) File "/private/tmp/Python-3.0a1/Lib/distutils/dist.py", line 963, in run_command cmd_obj.run() File "/private/tmp/Python-3.0a1/Lib/distutils/command/build_scripts.py", line 51, in run self.copy_scripts() File "/private/tmp/Python-3.0a1/Lib/distutils/command/build_scripts.py", line 82, in copy_scripts first_line = f.readline() File "/private/tmp/Python-3.0a1/Lib/io.py", line 1259, in readline decoder = self._decoder or self._get_decoder() File "/private/tmp/Python-3.0a1/Lib/io.py", line 1111, in _get_decoder make_decoder = codecs.getincrementaldecoder(self._encoding) File "/private/tmp/Python-3.0a1/Lib/codecs.py", line 951, in getincrementaldecoder decoder = lookup(encoding).incrementaldecoder LookupError: unknown encoding: X-MAC-JAPANESE make: *** [sharedmods] Error 1 ========================================== This problem happens for lack of appropriate codec so also occurs in apps using getdefaultencoding. After patching Tools/unicode/Makefile and running make generates build/mac_japanese.py, mac-japanese codec. ---------- components: Build, Demos and Tools, Library (Lib), Macintosh, Unicode files: x_mac_japanese.diff messages: 56386 nosy: josm severity: normal status: open title: LookupError: unknown encoding: X-MAC-JAPANESE __________________________________ Tracker __________________________________ -------------- next part -------------- A non-text attachment was scrubbed... Name: x_mac_japanese.diff Type: application/octet-stream Size: 413 bytes Desc: not available Url : http://mail.python.org/pipermail/python-bugs-list/attachments/20071013/ce915c1f/attachment.obj From report at bugs.python.org Sat Oct 13 12:07:09 2007 From: report at bugs.python.org (=?utf-8?q?=0A=09=09=09=09=09jos=0A=09=09=09=09?=) Date: Sat, 13 Oct 2007 10:07:09 -0000 Subject: [issue1276] LookupError: unknown encoding: X-MAC-JAPANESE Message-ID: <1192270029.29.0.976742738273.issue1276@psf.upfronthosting.co.za> New submission from jos : When I compile Python-3.0a1 on Mac OS X with Japanese locale, I've got LookupError like below. ========================================== running build_scripts creating build/scripts-3.0 Traceback (most recent call last): File "./setup.py", line 1572, in main() File "./setup.py", line 1567, in main 'Lib/smtpd.py'] File "/private/tmp/Python-3.0a1/Lib/distutils/core.py", line 148, in setup dist.run_commands() File "/private/tmp/Python-3.0a1/Lib/distutils/dist.py", line 943, in run_commands self.run_command(cmd) File "/private/tmp/Python-3.0a1/Lib/distutils/dist.py", line 963, in run_command cmd_obj.run() File "/private/tmp/Python-3.0a1/Lib/distutils/command/build.py", line 106, in run self.run_command(cmd_name) File "/private/tmp/Python-3.0a1/Lib/distutils/cmd.py", line 317, in run_command self.distribution.run_command(command) File "/private/tmp/Python-3.0a1/Lib/distutils/dist.py", line 963, in run_command cmd_obj.run() File "/private/tmp/Python-3.0a1/Lib/distutils/command/build_scripts.py", line 51, in run self.copy_scripts() File "/private/tmp/Python-3.0a1/Lib/distutils/command/build_scripts.py", line 82, in copy_scripts first_line = f.readline() File "/private/tmp/Python-3.0a1/Lib/io.py", line 1259, in readline decoder = self._decoder or self._get_decoder() File "/private/tmp/Python-3.0a1/Lib/io.py", line 1111, in _get_decoder make_decoder = codecs.getincrementaldecoder(self._encoding) File "/private/tmp/Python-3.0a1/Lib/codecs.py", line 951, in getincrementaldecoder decoder = lookup(encoding).incrementaldecoder LookupError: unknown encoding: X-MAC-JAPANESE make: *** [sharedmods] Error 1 ========================================== This problem happens for lack of appropriate codec so also occurs in apps using getdefaultencoding. After patching Tools/unicode/Makefile and running make generates build/mac_japanese.py, mac-japanese codec. ---------- components: Build, Demos and Tools, Library (Lib), Macintosh, Unicode files: x_mac_japanese.diff messages: 56386 nosy: josm severity: normal status: open title: LookupError: unknown encoding: X-MAC-JAPANESE __________________________________ Tracker __________________________________ -------------- next part -------------- A non-text attachment was scrubbed... Name: x_mac_japanese.diff Type: application/octet-stream Size: 413 bytes Desc: not available Url : http://mail.python.org/pipermail/python-bugs-list/attachments/20071013/ce915c1f/attachment-0001.obj From report at bugs.python.org Sat Oct 13 18:52:01 2007 From: report at bugs.python.org (Bill Janssen) Date: Sat, 13 Oct 2007 16:52:01 -0000 Subject: [issue1251] ssl module doesn't support non-blocking handshakes In-Reply-To: <2A59C0D9-B831-40DD-8AF7-A7CB312A0631@csail.mit.edu> Message-ID: <4b3e516a0710130951w578af878g2117da3ef3ffb17@mail.gmail.com> Bill Janssen added the comment: It's my mistake; I was looking at too many patches at the same time. Thanks for the example. Bill __________________________________ Tracker __________________________________ From report at bugs.python.org Sat Oct 13 22:49:32 2007 From: report at bugs.python.org (Guido van Rossum) Date: Sat, 13 Oct 2007 20:49:32 -0000 Subject: [issue1272] Decode __file__ and co_filename to unicode using fs default Message-ID: <1192308572.13.0.74108363572.issue1272@psf.upfronthosting.co.za> Changes by Guido van Rossum: ---------- assignee: -> gvanrossum nosy: +gvanrossum __________________________________ Tracker __________________________________ From report at bugs.python.org Sat Oct 13 23:19:06 2007 From: report at bugs.python.org (Guido van Rossum) Date: Sat, 13 Oct 2007 21:19:06 -0000 Subject: [issue1272] Decode __file__ and co_filename to unicode using fs default Message-ID: <1192310346.63.0.723987066167.issue1272@psf.upfronthosting.co.za> Guido van Rossum added the comment: Couple of nits: - You added a removal of hotshot from setup.py to the patch; but that's been checked in in the mean time. - Why add an 'errors' argument to the function when it's a fatal error to use it? - Using 0 to autodetect the length is scary. Normally we have two APIs for that, one ..._FromString and one ...FromStringAndSize. If you really don't want that, please use -1, which is at least an illegal value. - Why is there code in codeobject.c::PyCode_New() that still accepts a PyString for the filename? - In that file (and possibly others, I didn't check) your code uses spaces to indent while the surrounding code uses tabs. Moreover, your space indent seems to assume there are 4 spaces to a tab, but all our code (Python and C) is formatted assuming tabs are 8 spaces. (The indent isn't always 8 spaces -- but ASCII TAB characters always are 8, for us.) - Why copy the default encoding before mangling it? With a little extra care you will only have to copy it once. Also, consider not mangling at all, but assuming the encoding comes in a canonical form -- several other functions assume that, e.g. PyUnicode_Decode() and PyUnicode_AsEncodedString(). - I haven't run the unit tests yet. Will be doing that next... __________________________________ Tracker __________________________________ From report at bugs.python.org Sun Oct 14 00:10:06 2007 From: report at bugs.python.org (Alexandre Vassalotti) Date: Sat, 13 Oct 2007 22:10:06 -0000 Subject: [issue1272] Decode __file__ and co_filename to unicode using fs default Message-ID: <1192313406.27.0.0583048162244.issue1272@psf.upfronthosting.co.za> Alexandre Vassalotti added the comment: I found a few problems in your patch. In PyCode_New() the type check for the filename argument is incorrect: --- Objects/codeobject.c (revision 58412) +++ Objects/codeobject.c (working copy) @@ -59,7 +59,7 @@ freevars == NULL || !PyTuple_Check(freevars) || cellvars == NULL || !PyTuple_Check(cellvars) || name == NULL || (!PyString_Check(name) && !PyUnicode_Check(name)) || - filename == NULL || !PyString_Check(filename) || + filename == NULL || (!PyString_Check(name) && !PyUnicode_Check(name)) || lnotab == NULL || !PyString_Check(lnotab) || !PyObject_CheckReadBuffer(code)) { PyErr_BadInternalCall(); @@ -260,6 +267,8 @@ ourcellvars = PyTuple_New(0); if (ourcellvars == NULL) goto cleanup; + filename = PyUnicode_DecodeFSDefault(PyString_AS_STRING(filename), + 0, NULL); The following is unnecessary and will cause a reference leak: @@ -260,6 +267,8 @@ ourcellvars = PyTuple_New(0); if (ourcellvars == NULL) goto cleanup; + filename = PyUnicode_DecodeFSDefault(PyString_AS_STRING(filename), + 0, NULL); co = (PyObject *)PyCode_New(argcount, kwonlyargcount, nlocals, stacksize, flags, I think the interface of PyUnicode_DecodeFSDefault() could be improved a bit. The function doesn't use the last argument 'errors', so why is there? I am not sure if it is useful to keep second argument, 'length', either. So, I believe the function prototype should be changed to: PyObject *PyUnicode_Decode_FSDefault(const char *s); Another thing that I am not sure about is whether it is correct to consider ISO-8859-15 the same thing as Latin-1. Overall, the patch looks good to me and doesn't cause any test to fail. I attached an updated patch with the above issues fixed. Thank you, Christian, for the patch. :) ---------- nosy: +alexandre.vassalotti __________________________________ Tracker __________________________________ From report at bugs.python.org Sun Oct 14 00:10:19 2007 From: report at bugs.python.org (Alexandre Vassalotti) Date: Sat, 13 Oct 2007 22:10:19 -0000 Subject: [issue1272] Decode __file__ and co_filename to unicode using fs default Message-ID: <1192313419.48.0.817052014226.issue1272@psf.upfronthosting.co.za> Changes by Alexandre Vassalotti: __________________________________ Tracker __________________________________ From report at bugs.python.org Sun Oct 14 00:20:02 2007 From: report at bugs.python.org (Alexandre Vassalotti) Date: Sat, 13 Oct 2007 22:20:02 -0000 Subject: [issue1272] Decode __file__ and co_filename to unicode using fs default Message-ID: <1192314002.4.0.467578290533.issue1272@psf.upfronthosting.co.za> Alexandre Vassalotti added the comment: Guido wrote: > Why copy the default encoding before mangling it? With a little > extra care you will only have to copy it once. Also, consider not > mangling at all, but assuming the encoding comes in a canonical form > -- several other functions assume that, e.g. PyUnicode_Decode() and > PyUnicode_AsEncodedString(). It is impossible guarantee that Py_FileSystemDefaultEncoding is normalized, since its value can be set using nl_langinfo(CODESET) during the bootstrapping process. PyUnicode_Decode() and other decoding/encoding functions use the codec module, which is not available during the early bootstrapping process, to normalize the encoding name. __________________________________ Tracker __________________________________ From report at bugs.python.org Sun Oct 14 00:43:19 2007 From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=) Date: Sat, 13 Oct 2007 22:43:19 -0000 Subject: [issue1276] LookupError: unknown encoding: X-MAC-JAPANESE Message-ID: <1192315399.52.0.0168338229506.issue1276@psf.upfronthosting.co.za> Changes by Martin v. L?wis: ---------- keywords: +patch __________________________________ Tracker __________________________________ From report at bugs.python.org Sun Oct 14 01:27:30 2007 From: report at bugs.python.org (Christian Heimes) Date: Sat, 13 Oct 2007 23:27:30 -0000 Subject: [issue1272] Decode __file__ and co_filename to unicode using fs default In-Reply-To: <1192310346.63.0.723987066167.issue1272@psf.upfronthosting.co.za> Message-ID: <4711545C.7080408@cheimes.de> Christian Heimes added the comment: Guido van Rossum wrote: > - You added a removal of hotshot from setup.py to the patch; but that's > been checked in in the mean time. Oh, the change shouldn't make it into the patch. I guess I forgot a svn revert on setup.py > - Why add an 'errors' argument to the function when it's a fatal error > to use it? I wanted the signature of the method be equal to the other methods PyUnicode_Decode*. I copied the FatalError from *_PyUnicode_AsDefaultEncodedString(). > - Using 0 to autodetect the length is scary. Normally we have two APIs > for that, one ..._FromString and one ...FromStringAndSize. If you > really don't want that, please use -1, which is at least an illegal value. Oh right, -1 is *much* better for autodetect than 0. What do you prefer, a second method or -1 as auto detect? > - Why is there code in codeobject.c::PyCode_New() that still accepts a > PyString for the filename? Because it's my fault that I've overseen it. :/ > - In that file (and possibly others, I didn't check) your code uses > spaces to indent while the surrounding code uses tabs. Moreover, your > space indent seems to assume there are 4 spaces to a tab, but all our > code (Python and C) is formatted assuming tabs are 8 spaces. (The > indent isn't always 8 spaces -- but ASCII TAB characters always are 8, > for us.) Some C files like unicodeobject.c are using 4 spaces while other files are using tabs for indention. My editor may got confused by the mix. I've manually fixed it in the patch but I may have overseen a line or two. > - Why copy the default encoding before mangling it? With a little extra > care you will only have to copy it once. Also, consider not mangling at > all, but assuming the encoding comes in a canonical form -- several > other functions assume that, e.g. PyUnicode_Decode() and > PyUnicode_AsEncodedString(). My C is a bit rusty and still need to learn news tricks. I'm trying to see if I can remove the extra copy without causing a problem. The other part of your question was already answered by Alexandre. The aliases map is defined in Python code. It's not available so early in the boot strapping process. We'd have to redesign the assignment of co_filename and __file__ completely if we want to use the aliases and other codecs. For example we could store a PyString at first and redo all names once the codecs are set up. Christian __________________________________ Tracker __________________________________ From report at bugs.python.org Sun Oct 14 01:46:02 2007 From: report at bugs.python.org (Alexandre Vassalotti) Date: Sat, 13 Oct 2007 23:46:02 -0000 Subject: [issue1260] PEP 3137: Remove the buffer API from PyUnicode Message-ID: <1192319162.52.0.691046775796.issue1260@psf.upfronthosting.co.za> Alexandre Vassalotti added the comment: There was a problem with one of the call of PyArg_ParseTuple in the OS/2 version of listdir() in the posix module. I also clarified the error message of the 't' format unit. __________________________________ Tracker __________________________________ -------------- next part -------------- A non-text attachment was scrubbed... Name: unicode_rm_buf_api_02.patch Type: text/x-patch Size: 2889 bytes Desc: not available Url : http://mail.python.org/pipermail/python-bugs-list/attachments/20071013/4f1cb327/attachment.bin From report at bugs.python.org Sun Oct 14 02:35:54 2007 From: report at bugs.python.org (Guido van Rossum) Date: Sun, 14 Oct 2007 00:35:54 -0000 Subject: [issue1272] Decode __file__ and co_filename to unicode using fs default In-Reply-To: <4711545C.7080408@cheimes.de> Message-ID: Guido van Rossum added the comment: On 10/13/07, Christian Heimes wrote: > Guido van Rossum wrote: > > - Why add an 'errors' argument to the function when it's a fatal error > > to use it? > > I wanted the signature of the method be equal to the other methods > PyUnicode_Decode*. I copied the FatalError from > *_PyUnicode_AsDefaultEncodedString(). But that function is a terrible example; it was done that way because an earlier version of the function *did* allow using the errors argument and I wanted to make sure to catch all calls that were still passing an errors value. This doesn't apply here, we're creating a brand new API. > > - Using 0 to autodetect the length is scary. Normally we have two APIs > > for that, one ..._FromString and one ...FromStringAndSize. If you > > really don't want that, please use -1, which is at least an illegal value. > > Oh right, -1 is *much* better for autodetect than 0. What do you prefer, > a second method or -1 as auto detect? Even better is Alexandre's version: always autodetect. I think we can assume that filenames are always available as 0-terminated byte arrays, since that's how all system calls need them. Anyway, let me know if you want to change something in Alexandre's version or if you want him to check it in. Oh. Hm. I still wish that PyCode_New() could just insist that the filename argument is a PyUnicode instance. Why can't it? Perhaps the caller should be fixed instead? __________________________________ Tracker __________________________________ From report at bugs.python.org Sun Oct 14 02:43:59 2007 From: report at bugs.python.org (Christian Heimes) Date: Sun, 14 Oct 2007 00:43:59 -0000 Subject: [issue1272] Decode __file__ and co_filename to unicode using fs default In-Reply-To: Message-ID: <4711664A.5070300@cheimes.de> Christian Heimes added the comment: Guido van Rossum wrote: > But that function is a terrible example; it was done that way because > an earlier version of the function *did* allow using the errors > argument and I wanted to make sure to catch all calls that were still > passing an errors value. This doesn't apply here, we're creating a > brand new API. Ahhh! I really didn't know it. I thought that the non functional arguments have a purpose. > Anyway, let me know if you want to change something in Alexandre's > version or if you want him to check it in. I'm going to create a new patch based on his fixes and your recommendations. > Oh. Hm. I still wish that PyCode_New() could just insist that the > filename argument is a PyUnicode instance. Why can't it? Perhaps the > caller should be fixed instead? I'll try. __________________________________ Tracker __________________________________ From report at bugs.python.org Sun Oct 14 02:51:49 2007 From: report at bugs.python.org (Guido van Rossum) Date: Sun, 14 Oct 2007 00:51:49 -0000 Subject: [issue1272] Decode __file__ and co_filename to unicode using fs default Message-ID: <1192323109.63.0.541678273577.issue1272@psf.upfronthosting.co.za> Guido van Rossum added the comment: > > Oh. Hm. I still wish that PyCode_New() could just insist that the > > filename argument is a PyUnicode instance. Why can't it? Perhaps the > > caller should be fixed instead? > I'll try. I figured out the problem -- it came from marshalled old code objects. If you throw away all .pyc files the problem goes away. You can also get rid of the similar checks for the 'name' argument -- this should just be a PyUnicode too. A systematic approach to invalidating all the .pyc files is updating the magic number in import.c. __________________________________ Tracker __________________________________ From report at bugs.python.org Sun Oct 14 02:57:17 2007 From: report at bugs.python.org (Christian Heimes) Date: Sun, 14 Oct 2007 00:57:17 -0000 Subject: [issue1272] Decode __file__ and co_filename to unicode using fs default In-Reply-To: <1192310346.63.0.723987066167.issue1272@psf.upfronthosting.co.za> Message-ID: <47116966.7040402@cheimes.de> Christian Heimes added the comment: Guido van Rossum wrote: > - Why copy the default encoding before mangling it? With a little extra > care you will only have to copy it once. Now I remember why I added the strncpy() call plus encoding[31] = '\0'. I wanted to make sure that the code doesn't break even if the encoding name is longer than 31 + 1 chars long. I'm aware that it's very unlikely but I didn't want to take chances. You are allowed to call me paranoid. *g* Christian __________________________________ Tracker __________________________________ From report at bugs.python.org Sun Oct 14 03:00:41 2007 From: report at bugs.python.org (Guido van Rossum) Date: Sun, 14 Oct 2007 01:00:41 -0000 Subject: [issue1272] Decode __file__ and co_filename to unicode using fs default In-Reply-To: <47116966.7040402@cheimes.de> Message-ID: Guido van Rossum added the comment: Well, you could ensure that by checking that you haven't reached the end of the mangling buffer. That will have the added advantage that when the input is something silly like 32 spaces followed by "utf-8" it will be still be mangled correctly. The slight extra cost of the check (could be a single pointer compare) is offset by saving a call to strncpy(). --Guido On 10/13/07, Christian Heimes wrote: > > Christian Heimes added the comment: > > Guido van Rossum wrote: > > - Why copy the default encoding before mangling it? With a little extra > > care you will only have to copy it once. > > Now I remember why I added the strncpy() call plus encoding[31] = '\0'. > I wanted to make sure that the code doesn't break even if the encoding > name is longer than 31 + 1 chars long. I'm aware that it's very unlikely > but I didn't want to take chances. You are allowed to call me paranoid. *g* > > Christian > > __________________________________ > Tracker > > __________________________________ > __________________________________ Tracker __________________________________ From report at bugs.python.org Sun Oct 14 03:02:25 2007 From: report at bugs.python.org (Guido van Rossum) Date: Sun, 14 Oct 2007 01:02:25 -0000 Subject: [issue1264] __file__ and co_filename as unicode Message-ID: <1192323745.16.0.604379354796.issue1264@psf.upfronthosting.co.za> Changes by Guido van Rossum: ---------- resolution: -> out of date status: open -> closed superseder: -> Decode __file__ and co_filename to unicode using fs default __________________________________ Tracker __________________________________ From report at bugs.python.org Sun Oct 14 03:03:18 2007 From: report at bugs.python.org (Guido van Rossum) Date: Sun, 14 Oct 2007 01:03:18 -0000 Subject: [issue1267] Py3K cannot run as ``python -S`` Message-ID: <1192323798.67.0.577586879488.issue1267@psf.upfronthosting.co.za> Changes by Guido van Rossum: ---------- nosy: +gvanrossum __________________________________ Tracker __________________________________ From report at bugs.python.org Sun Oct 14 03:04:13 2007 From: report at bugs.python.org (Guido van Rossum) Date: Sun, 14 Oct 2007 01:04:13 -0000 Subject: [issue1268] array unittest problems with UCS4 build Message-ID: <1192323853.8.0.720657585016.issue1268@psf.upfronthosting.co.za> Guido van Rossum added the comment: Can this be closed now that Travis reverted his patch? ---------- nosy: +gvanrossum __________________________________ Tracker __________________________________ From report at bugs.python.org Sun Oct 14 03:19:42 2007 From: report at bugs.python.org (Guido van Rossum) Date: Sun, 14 Oct 2007 01:19:42 -0000 Subject: [issue1260] PEP 3137: Remove the buffer API from PyUnicode Message-ID: <1192324782.79.0.180683372031.issue1260@psf.upfronthosting.co.za> Guido van Rossum added the comment: You can check this in. You do have checkin privs right? ---------- resolution: -> accepted __________________________________ Tracker __________________________________ From report at bugs.python.org Sun Oct 14 03:32:10 2007 From: report at bugs.python.org (Alexandre Vassalotti) Date: Sun, 14 Oct 2007 01:32:10 -0000 Subject: [issue1272] Decode __file__ and co_filename to unicode using fs default Message-ID: <1192325530.75.0.439779829904.issue1272@psf.upfronthosting.co.za> Alexandre Vassalotti added the comment: Guido wrote: > I figured out the problem -- it came from marshalled old code objects. > If you throw away all .pyc files the problem goes away. You can also > get rid of the similar checks for the 'name' argument -- this should > just be a PyUnicode too. A systematic approach to invalidating all the > .pyc files is updating the magic number in import.c. Done. I had to remove a few another PyString instances in pyexpat.c and _ctypes.c. So, here (hopefully) the final version of the patch. The changes from the last version are: - Correct a typo in of the comments in PyUnicode_DecodeFSDefault - Specified in the API doc of PyUnicode_DecodeFSDefault that the function take a null-terminated string. - Bumped the magic number in import.c - Fix PyCode_New calls in _ctypes and pyexpat module. - Remove the PyString type check on 'filename' and 'name' in PyCode_New. - Remove the unneeded string coercion code from PyCode_New. __________________________________ Tracker __________________________________ -------------- next part -------------- A non-text attachment was scrubbed... Name: updated_file_fsenc-2.patch Type: text/x-patch Size: 11018 bytes Desc: not available Url : http://mail.python.org/pipermail/python-bugs-list/attachments/20071014/b9acf7f1/attachment.bin From report at bugs.python.org Sun Oct 14 03:42:29 2007 From: report at bugs.python.org (Alexandre Vassalotti) Date: Sun, 14 Oct 2007 01:42:29 -0000 Subject: [issue1272] Decode __file__ and co_filename to unicode using fs default Message-ID: <1192326149.6.0.716040354276.issue1272@psf.upfronthosting.co.za> Alexandre Vassalotti added the comment: > Remove the PyString type check on 'filename' and 'name' in PyCode_New. Oops. I removed one of the ! the checks by mistake. __________________________________ Tracker __________________________________ -------------- next part -------------- A non-text attachment was scrubbed... Name: updated_file_fsenc-3.patch Type: text/x-patch Size: 11019 bytes Desc: not available Url : http://mail.python.org/pipermail/python-bugs-list/attachments/20071014/d05515cf/attachment-0001.bin From report at bugs.python.org Sun Oct 14 04:06:21 2007 From: report at bugs.python.org (Alexandre Vassalotti) Date: Sun, 14 Oct 2007 02:06:21 -0000 Subject: [issue1260] PEP 3137: Remove the buffer API from PyUnicode Message-ID: <1192327581.29.0.576914777355.issue1260@psf.upfronthosting.co.za> Alexandre Vassalotti added the comment: Committed in r58455. __________________________________ Tracker __________________________________ From report at bugs.python.org Sun Oct 14 04:09:05 2007 From: report at bugs.python.org (Guido van Rossum) Date: Sun, 14 Oct 2007 02:09:05 -0000 Subject: [issue1260] PEP 3137: Remove the buffer API from PyUnicode Message-ID: <1192327745.83.0.55614119433.issue1260@psf.upfronthosting.co.za> Changes by Guido van Rossum: ---------- status: open -> closed __________________________________ Tracker __________________________________ From report at bugs.python.org Sun Oct 14 04:15:19 2007 From: report at bugs.python.org (Guido van Rossum) Date: Sun, 14 Oct 2007 02:15:19 -0000 Subject: [issue1272] Decode __file__ and co_filename to unicode using fs default In-Reply-To: <1192325530.75.0.439779829904.issue1272@psf.upfronthosting.co.za> Message-ID: Guido van Rossum added the comment: Crys, is this OK with you? On 10/13/07, Alexandre Vassalotti wrote: > > Alexandre Vassalotti added the comment: > > Guido wrote: > > I figured out the problem -- it came from marshalled old code objects. > > If you throw away all .pyc files the problem goes away. You can also > > get rid of the similar checks for the 'name' argument -- this should > > just be a PyUnicode too. A systematic approach to invalidating all the > > .pyc files is updating the magic number in import.c. > > Done. > > I had to remove a few another PyString instances in pyexpat.c and > _ctypes.c. So, here (hopefully) the final version of the patch. > > The changes from the last version are: > > - Correct a typo in of the comments in PyUnicode_DecodeFSDefault > - Specified in the API doc of PyUnicode_DecodeFSDefault that the > function take a null-terminated string. > - Bumped the magic number in import.c > - Fix PyCode_New calls in _ctypes and pyexpat module. > - Remove the PyString type check on 'filename' and 'name' in PyCode_New. > - Remove the unneeded string coercion code from PyCode_New. > > __________________________________ > Tracker > > __________________________________ > __________________________________ Tracker __________________________________ From report at bugs.python.org Sun Oct 14 05:06:47 2007 From: report at bugs.python.org (Christian Heimes) Date: Sun, 14 Oct 2007 03:06:47 -0000 Subject: [issue1272] Decode __file__ and co_filename to unicode using fs default In-Reply-To: Message-ID: <471187B9.8050502@cheimes.de> Christian Heimes added the comment: Guido van Rossum wrote: > Guido van Rossum added the comment: > > Crys, is this OK with you? Alexandre's mangle loop doesn't do the same job as mine. Chars like _ and - aren't removed from the encoding name and the if clauses don't catch for example UTF-8 or ISO-8859-1 only UTF8 or ISO8859-1. Also he has overseen a PyString_Check in the code repr function. I'm working on a better mangler and I believe that I can make Py_FilesystemEncoding available much earlier in Py_InitializeEx(). *after some debugging* I fear that we are on the wrong path. Py_FileSystemEncoding is set *much* later in the boot strapping process unless its value is hard coded (Win32 and Apple only). Any attempt to get the right codec or even a normalized name without the codecs package is going to extremely hard. We have to get the codecs up and Py_FileSystemEncoding before we can decode the filenames. :( I think that the problem needs much more attention and a proper fix. Christian __________________________________ Tracker __________________________________ From report at bugs.python.org Sun Oct 14 05:35:23 2007 From: report at bugs.python.org (Guido van Rossum) Date: Sun, 14 Oct 2007 03:35:23 -0000 Subject: [issue1272] Decode __file__ and co_filename to unicode using fs default Message-ID: <1192332923.86.0.036439972638.issue1272@psf.upfronthosting.co.za> Guido van Rossum added the comment: OK, in the spirit of delegation I'll leave this for you and Alexandre to work out more. If you're stuck, post to the list so others can jump in. __________________________________ Tracker __________________________________ From report at bugs.python.org Sun Oct 14 05:56:18 2007 From: report at bugs.python.org (Travis Oliphant) Date: Sun, 14 Oct 2007 03:56:18 -0000 Subject: [issue1268] array unittest problems with UCS4 build Message-ID: <1192334178.53.0.823902454386.issue1268@psf.upfronthosting.co.za> Travis Oliphant added the comment: This issue may be closed. __________________________________ Tracker __________________________________ From report at bugs.python.org Sun Oct 14 06:17:43 2007 From: report at bugs.python.org (Guido van Rossum) Date: Sun, 14 Oct 2007 04:17:43 -0000 Subject: [issue1268] array unittest problems with UCS4 build Message-ID: <1192335463.04.0.388056452077.issue1268@psf.upfronthosting.co.za> Changes by Guido van Rossum: ---------- resolution: -> fixed status: open -> closed __________________________________ Tracker __________________________________ From report at bugs.python.org Sun Oct 14 06:35:07 2007 From: report at bugs.python.org (Alexandre Vassalotti) Date: Sun, 14 Oct 2007 04:35:07 -0000 Subject: [issue1272] Decode __file__ and co_filename to unicode using fs default Message-ID: <1192336506.88.0.448378594514.issue1272@psf.upfronthosting.co.za> Alexandre Vassalotti added the comment: Christian wrote: > Alexandre's mangle loop doesn't do the same job as mine. Chars like _ > and - aren't removed from the encoding name and the if clauses don't > catch for example UTF-8 or ISO-8859-1 only UTF8 or ISO8859-1. That isn't true. My mangler does exactly the same thing as your original one. However, I forgot to add Py_CHARMASK to the calls of tolower() and isalnum() which would cause problems on platforms with signed char. > Also he has overseen a PyString_Check in the code repr function. Fixed. > We have to get the codecs up and Py_FileSystemEncoding before we can > decode the filenames. :( I think that the problem needs much more > attention and a proper fix. Maybe adding a global variable, let's say _Py_Codecs_Ready, could be used to notify PyUnicode_DecodeFSDefault that it can use PyUnicode_Decode, instead of relying only on the built-in codecs. That would be much simpler than changing boostrapping process. Here yet another updated patch. The changes are the following: - Add Py_CHARMASK to tolower() and isalnum() calls in PyUnicode_DecodeFSDefault(). - Use PyUnicode_Check(), instead of PyString_Check(), in code_repr(). - Update comments for co_filename and co_name in PyCodeObject struct definition. - Fix a PyString_AS_STRING(co->co_name) instance in compile.c - Replace %S for %U in PyErr_Format() calls for substituting co_name. One more thing, frozen.c needs to be updated. The module data contains a code object with a PyString co_name. However, there is a bug in the imp module (it doesn't detect the encoding from modelines, which cause io.TextIOWrapper to crash) that prevents me from generating the data for frozen.c. __________________________________ Tracker __________________________________ -------------- next part -------------- A non-text attachment was scrubbed... Name: updated_file_fsenc-4.patch Type: text/x-patch Size: 14076 bytes Desc: not available Url : http://mail.python.org/pipermail/python-bugs-list/attachments/20071014/d0d2361a/attachment-0001.bin From report at bugs.python.org Sun Oct 14 06:55:59 2007 From: report at bugs.python.org (Brett Cannon) Date: Sun, 14 Oct 2007 04:55:59 -0000 Subject: [issue1631171] implement warnings module in C Message-ID: <1192337759.08.0.333891845477.issue1631171@psf.upfronthosting.co.za> Brett Cannon added the comment: So the descriptor idea didn't work. Another idea is to have the C code that relies on attributes on warnings that are allowed to change have an initial check for warnings, and if that fails to fall back on C code. That way the module can still be completely self-sufficient while still allowing users to change values from Python code. For instance, take warnings.filters. Initially it can be set to _warnings.filters. But in the C code, where access to the filters list is needed, a check is first done to see if the warnings module has been imported. If so, check for a filters attribute. If it exists, replace the internal list with that one and continue on. If the module is not there, however, use the list stored statically in the module without change. Same idea of the once registry and a similar idea for showwarnings(). _____________________________________ Tracker _____________________________________ From report at bugs.python.org Sun Oct 14 09:57:42 2007 From: report at bugs.python.org (Georg Brandl) Date: Sun, 14 Oct 2007 07:57:42 -0000 Subject: [issue1276] LookupError: unknown encoding: X-MAC-JAPANESE Message-ID: <1192348662.55.0.499106036973.issue1276@psf.upfronthosting.co.za> Changes by Georg Brandl: ---------- versions: +Python 3.0 __________________________________ Tracker __________________________________ From report at bugs.python.org Sun Oct 14 11:21:36 2007 From: report at bugs.python.org (vila) Date: Sun, 14 Oct 2007 09:21:36 -0000 Subject: [issue1114345] Add SSL certificate validation Message-ID: <1192353696.72.0.25905536404.issue1114345@psf.upfronthosting.co.za> vila added the comment: > I'm planning to do a package for 2.3... Any progress on that package ? I'd like to do the same for python 2.4 and 2.5 as I have a need for it for both versions. I don't know what you call a package though, but I'm willing to learn :) ---------- nosy: +vila _____________________________________ Tracker _____________________________________ From report at bugs.python.org Sun Oct 14 14:25:23 2007 From: report at bugs.python.org (Matthias Kievernagel) Date: Sun, 14 Oct 2007 12:25:23 -0000 Subject: [issue961805] Text.edit_modified() fails Message-ID: <1192364723.47.0.856098309729.issue961805@psf.upfronthosting.co.za> Matthias Kievernagel added the comment: Moved my patch from Issue1643641 to this Issue. (duplication was created when moving from SF bugs/patches) Patch to be applied with 'patch -p0' I have also attached a demo where you can test all Text.edit_* functions. Regards, Matthias Kievernagel ---------- nosy: +mkiever ____________________________________ Tracker ____________________________________ -------------- next part -------------- A non-text attachment was scrubbed... Name: editModified.py Type: application/octet-stream Size: 1538 bytes Desc: not available Url : http://mail.python.org/pipermail/python-bugs-list/attachments/20071014/dbce8acc/attachment-0001.obj From report at bugs.python.org Sun Oct 14 14:26:49 2007 From: report at bugs.python.org (Matthias Kievernagel) Date: Sun, 14 Oct 2007 12:26:49 -0000 Subject: [issue961805] Text.edit_modified() fails Message-ID: <1192364809.18.0.17689422221.issue961805@psf.upfronthosting.co.za> Changes by Matthias Kievernagel: ____________________________________ Tracker ____________________________________ From report at bugs.python.org Sun Oct 14 14:30:30 2007 From: report at bugs.python.org (Matthias Kievernagel) Date: Sun, 14 Oct 2007 12:30:30 -0000 Subject: [issue1643641] Fix Bug 1362475 Text.edit_modified() doesn't work Message-ID: <1192365030.07.0.515179426175.issue1643641@psf.upfronthosting.co.za> Matthias Kievernagel added the comment: Moved my patch to Issue961805. (duplication was created when moving from SF bugs/patches) This issue should be closed down. Regards, Matthias Kievernagel _____________________________________ Tracker _____________________________________ From report at bugs.python.org Sun Oct 14 15:13:53 2007 From: report at bugs.python.org (Matthias Kievernagel) Date: Sun, 14 Oct 2007 13:13:53 -0000 Subject: [issue1135] xview/yview of Tix.Grid is broken Message-ID: <1192367633.78.0.767341938147.issue1135@psf.upfronthosting.co.za> Matthias Kievernagel added the comment: Hint: There is also Issue1522587, which contains a large patch (by klappnase) for Tix.Grid addressing xview/yview and several other issues. I do not know if it fixes this issue exactly. Can you take a look at it, ocean-city? Regards, Matthias Kievernagel ---------- nosy: +mkiever __________________________________ Tracker __________________________________ From report at bugs.python.org Sun Oct 14 15:14:43 2007 From: report at bugs.python.org (Matthias Kievernagel) Date: Sun, 14 Oct 2007 13:14:43 -0000 Subject: [issue1522587] Tix.Grid patch Message-ID: <1192367684.0.0.831068749896.issue1522587@psf.upfronthosting.co.za> Changes by Matthias Kievernagel: ---------- nosy: +mkiever _____________________________________ Tracker _____________________________________ From report at bugs.python.org Sun Oct 14 17:05:27 2007 From: report at bugs.python.org (Christian Heimes) Date: Sun, 14 Oct 2007 15:05:27 -0000 Subject: [issue1272] Decode __file__ and co_filename to unicode using fs default In-Reply-To: <1192336506.88.0.448378594514.issue1272@psf.upfronthosting.co.za> Message-ID: <47123032.2050809@cheimes.de> Christian Heimes added the comment: Alexandre Vassalotti wrote: > That isn't true. My mangler does exactly the same thing as your > original one. > > However, I forgot to add Py_CHARMASK to the calls of tolower() and > isalnum() which would cause problems on platforms with signed char. I wasn't sure how tolower() reacts on numeric values. The addition of Py_CHARMASK is a good idea. It's a shame stringobject.c doesn't expose its non locale version of tolower() and isalnum(). > Maybe adding a global variable, let's say _Py_Codecs_Ready, could be > used to notify PyUnicode_DecodeFSDefault that it can use > PyUnicode_Decode, instead of relying only on the built-in codecs. That > would be much simpler than changing boostrapping process. It still f... up the file names of Python modules that were loaded before the codecs are ready to use. What do you think about this (pseudocode): #if defined(MS_WINDOWS) && defined(HAVE_USABLE_WCHAR_T) return PyUnicode_DecodeMBCS(string, "replace) #elif defined(__APPLE__) return PyUnicode_DecodeUTF8(string, "replace) #else * set __file__ and co_filename to a preliminary value with PyUnicode_DecodeUTF8(string, "replace") * Store a pointer and original string in a linked list struct Py_FixFileNames { struct Py_FixFileNames *next; char *string; PyObject *unicode; }; * After the codecs and Py_FileSystemDefaultEncoding are set up in Py_InitializeEx() check the value. If the fs default encoding isn't UTF-8 redo all encodings with the correct encoding. * Free the linked list * From now on use the codecs package, PyUnicode_Decode() and Py_FileSystemDefaultEncoding for every filename #endif Add comments to See Python/bltinmodule.c Py_FileSystemDefaultEncoding and Objects/unicodeobject.c unicode_default_encoding that PyUnicode_DecodeFSDefault depends on the values. It ain't beautiful and fast but we definitely get the right file names after boot strapping and fair file names during boot strapping. Christian __________________________________ Tracker __________________________________ From report at bugs.python.org Sun Oct 14 17:23:43 2007 From: report at bugs.python.org (Guido van Rossum) Date: Sun, 14 Oct 2007 15:23:43 -0000 Subject: [issue1272] Decode __file__ and co_filename to unicode using fs default In-Reply-To: <47123032.2050809@cheimes.de> Message-ID: Guido van Rossum added the comment: Only a few modules are involved in the bootstrap. The filename is mostly used to display in the traceback. There is already a fallback in the traceback-printing code that tries to look through sys.path for a file matching the module if it can't open the filename from the code object. So I suggest to do something much simpler -- if the default encoding isn't set yet, use ASCII + replace, and leave it at that -- don't bother fixing these things later. Another thought: when installed, the built-in modules are compiled to byte code by compileall.py, which runs late enough so that the filesystem encoding is known and everything can be done right. I have a question for Alexandre related to frozen.c -- why is there a mode line with an encoding involved in freezing hello.py? __________________________________ Tracker __________________________________ From report at bugs.python.org Sun Oct 14 17:26:16 2007 From: report at bugs.python.org (Christian Heimes) Date: Sun, 14 Oct 2007 15:26:16 -0000 Subject: [issue1268] array unittest problems with UCS4 build In-Reply-To: <1192323853.8.0.720657585016.issue1268@psf.upfronthosting.co.za> Message-ID: <47123514.7080007@cheimes.de> Christian Heimes added the comment: > Can this be closed now that Travis reverted his patch? Yes, it can be closed. By the way svn.python.org and the anon svn server are down the third time this week. Something is wrong with the server. Christian __________________________________ Tracker __________________________________ From report at bugs.python.org Sun Oct 14 18:00:22 2007 From: report at bugs.python.org (Alexandre Vassalotti) Date: Sun, 14 Oct 2007 16:00:22 -0000 Subject: [issue1272] Decode __file__ and co_filename to unicode using fs default Message-ID: <1192377622.87.0.989770474728.issue1272@psf.upfronthosting.co.za> Alexandre Vassalotti added the comment: > I have a question for Alexandre related to frozen.c -- why is there a > mode line with an encoding involved in freezing hello.py? For some reason which I don't know about, freeze.py tries to read all the modules accessible from sys.path: # collect all modules of the program dir = os.path.dirname(scriptfile) path[0] = dir mf = modulefinder.ModuleFinder(path, debug, exclude, replace_paths) The problem is the imp module, which modulefinder uses, does not detect the encoding of the files from the mode-line. This causes TextIOWrapper to crash when it tries to read modules using an encoding other than ASCII or UTF-8. Here an example: >>> import imp >>> imp.find_module('heapq')[0].read() Traceback (most recent call last): ... UnicodeDecodeError: 'utf8' codec can't decode bytes in position 1428-1430: invalid data I probably should open a seperate issue in the tracker for this, though. __________________________________ Tracker __________________________________ From report at bugs.python.org Sun Oct 14 18:02:43 2007 From: report at bugs.python.org (Bernd Wurst) Date: Sun, 14 Oct 2007 16:02:43 -0000 Subject: [issue1277] mailbox.Maildir: factory not used Message-ID: <1192377763.05.0.280093607923.issue1277@psf.upfronthosting.co.za> New submission from Bernd Wurst: The "factory"-argument to the constructorof mailbox.Maildir is not used as it should be. First, it's default is set to rfc822.Message instead of MaildirMessage and then, inside the module's code, MaildirMessage is hard-coded as a message constructor. If I need a derived class with custom attributes, I cannot use it. ---------- components: Extension Modules messages: 56418 nosy: bwurst severity: normal status: open title: mailbox.Maildir: factory not used type: resource usage versions: Python 2.5 __________________________________ Tracker __________________________________ From report at bugs.python.org Sun Oct 14 18:17:39 2007 From: report at bugs.python.org (Alexandre Vassalotti) Date: Sun, 14 Oct 2007 16:17:39 -0000 Subject: [issue1272] Decode __file__ and co_filename to unicode using fs default Message-ID: <1192378659.86.0.20481632454.issue1272@psf.upfronthosting.co.za> Alexandre Vassalotti added the comment: I thought of another way to implement PyUnicode_DecodeFSDefault. If Py_FileSystemDefaultEncoding is set, decode with the codecs module, otherwise use UTF-8 + replace. This works because when Py_FileSystemDefaultEncoding is initialized at the end of Py_InitializeEx(), the codecs module is ready to be used. Here's what it looks like: PyObject* PyUnicode_DecodeFSDefault(const char *s) { Py_ssize_t size = (Py_ssize_t)strlen(s); /* During the early bootstrapping process, Py_FileSystemDefaultEncoding can be undefined. If it is case, decode using UTF-8. The following assumes that Py_FileSystemDefaultEncoding is set to a built-in encoding during the bootstrapping process where the codecs aren't ready yet. */ if (Py_FileSystemDefaultEncoding) { return PyUnicode_Decode(s, size, Py_FileSystemDefaultEncoding, "replace"); } else { return PyUnicode_DecodeUTF8(s, size, "replace"); } } It is not perfect, since the extra function calls in the codecs module causes test_profile and test_doctest to fail. However, I think this is much simpler that the previous versions. __________________________________ Tracker __________________________________ -------------- next part -------------- A non-text attachment was scrubbed... Name: updated_file_fsenc-5.patch Type: text/x-patch Size: 13082 bytes Desc: not available Url : http://mail.python.org/pipermail/python-bugs-list/attachments/20071014/de0d1c29/attachment-0001.bin From report at bugs.python.org Sun Oct 14 18:22:53 2007 From: report at bugs.python.org (Christian Heimes) Date: Sun, 14 Oct 2007 16:22:53 -0000 Subject: [issue1272] Decode __file__ and co_filename to unicode using fs default In-Reply-To: <1192378659.86.0.20481632454.issue1272@psf.upfronthosting.co.za> Message-ID: <47124259.6080805@cheimes.de> Christian Heimes added the comment: Alexandre Vassalotti wrote: > Alexandre Vassalotti added the comment: > > I thought of another way to implement PyUnicode_DecodeFSDefault. If > Py_FileSystemDefaultEncoding is set, decode with the codecs module, > otherwise use UTF-8 + replace. This works because when > Py_FileSystemDefaultEncoding is initialized at the end of > Py_InitializeEx(), the codecs module is ready to be used. Here's what > it looks like: That's almost what I had in mind but with two exceptions for __APPLE__ and MS_WINDOWS. For both OS the value of Py_FileSystemDefaultEncoding is hard coded to UTF-8 / MBCS. In your code the method would use PyUnicode_Decode() too early but you can work around the problem with two #if defined. Christian __________________________________ Tracker __________________________________ From report at bugs.python.org Sun Oct 14 18:59:23 2007 From: report at bugs.python.org (Christian Heimes) Date: Sun, 14 Oct 2007 16:59:23 -0000 Subject: [issue1268] array unittest problems with UCS4 build In-Reply-To: <47123514.7080007@cheimes.de> Message-ID: <47124AE8.1070903@cheimes.de> Christian Heimes added the comment: Oh stop, the array module doesn't build for me (Ubuntu Linux, i386, UCS-4 build, rev58458): Modules/arraymodule.c: In function 'array_buffer_getbuf': Modules/arraymodule.c:1815: error: 'Py_buffer' has no member named 'formats' Please replace formats with format in line 1815: view->format = "w"; Christian __________________________________ Tracker __________________________________ From report at bugs.python.org Sun Oct 14 19:06:25 2007 From: report at bugs.python.org (Christian Heimes) Date: Sun, 14 Oct 2007 17:06:25 -0000 Subject: [issue1272] Decode __file__ and co_filename to unicode using fs default Message-ID: <1192381585.39.0.931452210332.issue1272@psf.upfronthosting.co.za> Christian Heimes added the comment: Changes since updated_file_fsenc-5.patch: * Fix for hard coded FS default encoding on Apple and Windows * Added two notes to unicode_default_encoding and Py_FileSystemDefaultEncoding __________________________________ Tracker __________________________________ -------------- next part -------------- A non-text attachment was scrubbed... Name: updated_file_fsenc-6.patch Type: text/x-diff Size: 14463 bytes Desc: not available Url : http://mail.python.org/pipermail/python-bugs-list/attachments/20071014/7dfb404c/attachment-0001.patch From report at bugs.python.org Sun Oct 14 22:07:31 2007 From: report at bugs.python.org (Bill Janssen) Date: Sun, 14 Oct 2007 20:07:31 -0000 Subject: [issue1114345] Add SSL certificate validation In-Reply-To: <1192353696.72.0.25905536404.issue1114345@psf.upfronthosting.co.za> Message-ID: <4b3e516a0710141307i4ffcf34che8ff2eda52304148@mail.gmail.com> Bill Janssen added the comment: See the SSL package on PyPI. Should work on 2.3, 2.4, and 2.5. Bill On 10/14/07, vila wrote: > > vila added the comment: > > > I'm planning to do a package for 2.3... > > Any progress on that package ? > > I'd like to do the same for python 2.4 and 2.5 as I have a need for it > for both versions. > > I don't know what you call a package though, but I'm willing to learn :) > > ---------- > nosy: +vila > > _____________________________________ > Tracker > > _____________________________________ > _____________________________________ Tracker _____________________________________ From report at bugs.python.org Sun Oct 14 22:46:51 2007 From: report at bugs.python.org (Guido van Rossum) Date: Sun, 14 Oct 2007 20:46:51 -0000 Subject: [issue1268] array unittest problems with UCS4 build In-Reply-To: <47124AE8.1070903@cheimes.de> Message-ID: Guido van Rossum added the comment: > Oh stop, the array module doesn't build for me (Ubuntu Linux, i386, > UCS-4 build, rev58458): > > Modules/arraymodule.c: In function 'array_buffer_getbuf': > Modules/arraymodule.c:1815: error: 'Py_buffer' has no member named 'formats' > > Please replace formats with format in line 1815: > > view->format = "w"; Done. __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Oct 15 02:13:33 2007 From: report at bugs.python.org (Guido van Rossum) Date: Mon, 15 Oct 2007 00:13:33 -0000 Subject: [issue1272] Decode __file__ and co_filename to unicode using fs default In-Reply-To: <1192381585.39.0.931452210332.issue1272@psf.upfronthosting.co.za> Message-ID: Guido van Rossum added the comment: This looks promising. I'm working on the freeze issue. Once I get that working I'll check this in. Thanks Alexandre and Christian for all your hard work!!! __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Oct 15 02:27:17 2007 From: report at bugs.python.org (Guido van Rossum) Date: Mon, 15 Oct 2007 00:27:17 -0000 Subject: [issue1272] Decode __file__ and co_filename to unicode using fs default In-Reply-To: <1192377622.87.0.989770474728.issue1272@psf.upfronthosting.co.za> Message-ID: Guido van Rossum added the comment: > The problem is the imp module, which modulefinder uses, does not > detect the encoding of the files from the mode-line. This causes > TextIOWrapper to crash when it tries to read modules using an encoding > other than ASCII or UTF-8. Here an example: > > >>> import imp > >>> imp.find_module('heapq')[0].read() > Traceback (most recent call last): > ... > UnicodeDecodeError: 'utf8' codec can't decode bytes in position > 1428-1430: invalid data I can't reproduce this. Can you open a separate issue? __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Oct 15 02:34:28 2007 From: report at bugs.python.org (Christian Heimes) Date: Mon, 15 Oct 2007 00:34:28 -0000 Subject: [issue1272] Decode __file__ and co_filename to unicode using fs default In-Reply-To: Message-ID: <4712B58B.5030904@cheimes.de> Christian Heimes added the comment: >> UnicodeDecodeError: 'utf8' codec can't decode bytes in position >> 1428-1430: invalid data > > I can't reproduce this. Can you open a separate issue? It breaks for me with the same error message on Ubuntu Linux, i386, UCS-4 build and locale de_DE.UTF-8. (, '/home/heimes/dev/python/py3k/Lib/heapq.py', ('.py', 'U', 1)) >>> imp.find_module('heapq')[0].read() Traceback (most recent call last): File "", line 1, in File "/home/heimes/dev/python/py3k/Lib/io.py", line 1224, in read res += decoder.decode(self.buffer.read(), True) File "/home/heimes/dev/python/py3k/Lib/codecs.py", line 291, in decode (result, consumed) = self._buffer_decode(data, self.errors, final) UnicodeDecodeError: 'utf8' codec can't decode bytes in position 1428-1430: invalid data >>> imp.find_module('heapq')[0].readline() '# -*- coding: Latin-1 -*-\n' >>> imp.find_module('heapq')[0].encoding 'UTF-8' __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Oct 15 02:36:23 2007 From: report at bugs.python.org (Christian Heimes) Date: Mon, 15 Oct 2007 00:36:23 -0000 Subject: [issue1272] Decode __file__ and co_filename to unicode using fs default In-Reply-To: Message-ID: <4712B5F4.4000901@cheimes.de> Christian Heimes added the comment: > This looks promising. I'm working on the freeze issue. Once I get that > working I'll check this in. Thanks Alexandre and Christian for all > your hard work!!! You're welcome. Does the patch qualify me for Misc/ACKS? :) I'm going to work on the basestring patch after you have committed the changes. Christian __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Oct 15 02:57:19 2007 From: report at bugs.python.org (Christian Heimes) Date: Mon, 15 Oct 2007 00:57:19 -0000 Subject: [issue1272] Decode __file__ and co_filename to unicode using fs default In-Reply-To: Message-ID: <4712BAE7.1040900@cheimes.de> Christian Heimes added the comment: I found two minor bugs in the fix. In Modules/posixmodule.c the tmpnam() and tempnam() methods return a PyString instance. Please change line 5373 and 5431 to use PyUnicode_DecodeFSDefault(). Index: Modules/posixmodule.c =================================================================== --- Modules/posixmodule.c (Revision 58461) +++ Modules/posixmodule.c (Arbeitskopie) @@ -5370,7 +5370,7 @@ #endif if (name == NULL) return PyErr_NoMemory(); - result = PyString_FromString(name); + result = PyUnicode_DecodeFSDefault(name); free(name); return result; } @@ -5428,7 +5428,7 @@ Py_XDECREF(err); return NULL; } - return PyString_FromString(buffer); + return PyUnicode_DecodeFSDefault(buffer); } #endif __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Oct 15 03:31:29 2007 From: report at bugs.python.org (Guido van Rossum) Date: Mon, 15 Oct 2007 01:31:29 -0000 Subject: [issue1272] Decode __file__ and co_filename to unicode using fs default In-Reply-To: <4712B5F4.4000901@cheimes.de> Message-ID: Guido van Rossum added the comment: > > This looks promising. I'm working on the freeze issue. Once I get that > > working I'll check this in. Thanks Alexandre and Christian for all > > your hard work!!! > > You're welcome. Does the patch qualify me for Misc/ACKS? :) Yes, and also Alexandre. :-) > I'm going to work on the basestring patch after you have committed the > changes. The commit may have to wait a bit; I'm finding some problems on OSX when the directory in which I'm building has a unicode character in it. (Now, svn has severe problems with this as well, and so far it looks like all the tests run; but still, it's disturbing.) __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Oct 15 03:34:29 2007 From: report at bugs.python.org (Christian Heimes) Date: Mon, 15 Oct 2007 01:34:29 -0000 Subject: [issue1278] imp.find_module() ignores -*- coding: Latin-1 -*- Message-ID: <1192412068.91.0.486789183864.issue1278@psf.upfronthosting.co.za> New submission from Christian Heimes: imp.find_module() returns an io.TextIOWrapper instance first value. The encoding of the TextIOWrapper isn't set from a -*- coding: Latin-1 -*- line. >>> import imp >>> imp.find_module("heapq") (, '/home/heimes/dev/python/py3k/Lib/heapq.py', ('.py', 'U', 1)) >>> imp.find_module("heapq")[0].read() Traceback (most recent call last): File "", line 1, in File "/home/heimes/dev/python/py3k/Lib/io.py", line 1224, in read res += decoder.decode(self.buffer.read(), True) File "/home/heimes/dev/python/py3k/Lib/codecs.py", line 291, in decode (result, consumed) = self._buffer_decode(data, self.errors, final) UnicodeDecodeError: 'utf8' codec can't decode bytes in position 1428-1430: invalid data >>> imp.find_module("heapq")[0].encoding 'UTF-8' >>> imp.find_module("heapq")[0].readline() '# -*- coding: Latin-1 -*-\n' ---------- components: Interpreter Core messages: 56431 nosy: tiran severity: normal status: open title: imp.find_module() ignores -*- coding: Latin-1 -*- type: behavior versions: Python 3.0 __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Oct 15 04:53:16 2007 From: report at bugs.python.org (Guido van Rossum) Date: Mon, 15 Oct 2007 02:53:16 -0000 Subject: [issue1272] Decode __file__ and co_filename to unicode using fs default Message-ID: <1192416796.6.0.663452524367.issue1272@psf.upfronthosting.co.za> Guido van Rossum added the comment: Committed revision 58466. Fingers crossed. ---------- resolution: -> accepted status: open -> closed __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Oct 15 05:19:28 2007 From: report at bugs.python.org (Kurt B. Kaiser) Date: Mon, 15 Oct 2007 03:19:28 -0000 Subject: [issue1130] Idle - Save (buffer) - closes IDLE and does not save file (Windows XP) Message-ID: <1192418368.25.0.921340632729.issue1130@psf.upfronthosting.co.za> Kurt B. Kaiser added the comment: I caught the first part, but not the second using GNU/Linux. I think that eol_convention can be a class variable, since os.linesep isn't going to change from file to file. Thanks for the report! r58465. __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Oct 15 06:08:20 2007 From: report at bugs.python.org (Georg Brandl) Date: Mon, 15 Oct 2007 04:08:20 -0000 Subject: [issue1643641] Fix Bug 1362475 Text.edit_modified() doesn't work Message-ID: <1192421300.69.0.493292133807.issue1643641@psf.upfronthosting.co.za> Changes by Georg Brandl: ---------- resolution: -> duplicate status: open -> closed superseder: -> Text.edit_modified() fails _____________________________________ Tracker _____________________________________ From report at bugs.python.org Mon Oct 15 06:15:40 2007 From: report at bugs.python.org (Zooko O'Whielacronx) Date: Mon, 15 Oct 2007 04:15:40 -0000 Subject: [issue1074462] Irregular behavior of datetime.__str__() Message-ID: <1192421740.18.0.527419575059.issue1074462@psf.upfronthosting.co.za> Zooko O'Whielacronx added the comment: Here is a note for the next person who comes to this ticket wondering why isoformat() exhibits this slightly un-Pythonic behavior. If you want to use isoformat() to produce, for example, timestamps for your logfiles, you'll need to do something like the following. (I do hope you noticed the documentation and didn't use isoformat() in the naive way, or your log files will very rarely have a different format than you expected.) d = datetime.datetime.utcfromtimestamp(when) if d.microsecond: return d.isoformat(" ")[:-3]+"Z" else: return d.isoformat(" ") + ".000Z" http://allmydata.org/trac/tahoe/browser/src/allmydata/node.py#L21 ---------- nosy: +zooko _____________________________________ Tracker _____________________________________ From report at bugs.python.org Mon Oct 15 10:13:01 2007 From: report at bugs.python.org (atsuo ishimoto) Date: Mon, 15 Oct 2007 08:13:01 -0000 Subject: [issue1031213] Use correct encoding for printing SyntaxErrors Message-ID: <1192435981.45.0.404001697393.issue1031213@psf.upfronthosting.co.za> atsuo ishimoto added the comment: That's fine with me. Please replace PyErr_Print() with PyErr_Clear(). _____________________________________ Tracker _____________________________________ From report at bugs.python.org Mon Oct 15 14:50:06 2007 From: report at bugs.python.org (Skip Montanaro) Date: Mon, 15 Oct 2007 12:50:06 -0000 Subject: [issue1074462] Irregular behavior of datetime.__str__() In-Reply-To: <1192421740.18.0.527419575059.issue1074462@psf.upfronthosting.co.za> Message-ID: <18195.25020.496808.44809@montanaro.dyndns.org> Skip Montanaro added the comment: Zooko> Here is a note for the next person who comes to this ticket Zooko> wondering why isoformat() exhibits this slightly un-Pythonic Zooko> behavior. What are you referring to, that it doesn't display any microseconds when the microsecond field happens to be 0 or that it doesn't truncate the fractions of a second to milliseconds? Skip _____________________________________ Tracker _____________________________________ From report at bugs.python.org Mon Oct 15 15:01:36 2007 From: report at bugs.python.org (Thomas Lee) Date: Mon, 15 Oct 2007 13:01:36 -0000 Subject: [issue1263] PEP 3137 patch - str8/str comparison should return false Message-ID: <1192453296.61.0.335767716616.issue1263@psf.upfronthosting.co.za> Thomas Lee added the comment: Hack to make Python/codecs.c use Unicode strings internally. I recognize the way I have fixed it here is probably not ideal (basically ripped out PyString_*, replaced with a PyMem_Malloc/PyMem_Free call) but it fixes 10-12 tests that were failing with my earlier changes. If anybody can recommend a "nice" way to fix this, I'm all ears. The following still fail for me with this patch applied: -- test_compile This is due to PyString_*/PyUnicode_*/PyBytes_* confusion in the assembler struct (specifically: a_lnotab and a_bytecode) in Python/compile.c - tried replacing PyString_* calls with PyBytes_* calls, but this raises a TypeError because PyBytes is not hashable ... not sure what exactly is causing this. -- test_ctypes Looks like a simple case of ctypes using str8 instead of str. Appears to be an easy fix. -- test_modulefinder Failing because str8 >= str is now an invalid operation -- test_set This test needs some love. -- test_sqlite Not sure what's going on here. -- test_str This one is a little tricky: str8/str with __str__/__unicode__ ... how is this test supposed to behave with the fix in this patch? -- test_struct "unpack/pack not transitive" - what does that mean? -- test_subprocess Like modulefinder, this is probably just due to the use of str8 over str internally in the subprocess module. Likely to be an easy fix. The following tests fail for me irrespective of whether or not I have r4 of my patch applied: -- test_doctest -- test_email -- test_nis -- test_pty If anybody can give this new patch a try and let me know the result it would be much appreciated. __________________________________ Tracker __________________________________ -------------- next part -------------- A non-text attachment was scrubbed... Name: unicode-string-eq-false-all-r4.patch Type: text/x-patch Size: 3876 bytes Desc: not available Url : http://mail.python.org/pipermail/python-bugs-list/attachments/20071015/b3f59768/attachment.bin From report at bugs.python.org Mon Oct 15 15:11:30 2007 From: report at bugs.python.org (Zooko O'Whielacronx) Date: Mon, 15 Oct 2007 13:11:30 -0000 Subject: [issue1074462] Irregular behavior of datetime.__str__() Message-ID: <1192453890.31.0.828450425872.issue1074462@psf.upfronthosting.co.za> Zooko O'Whielacronx added the comment: I meant that it special-cases .microseconds == 0. If I want to produce a custom output format using Python Standard Library, I expect to have to slice, add my own fields and so forth, but I don't expect to need an "if" to handle a special-case that is there for improving the appearance to human readers. That's something I had to do a lot more often when I worked in Perl. Even if the cost of changing the definition of isoformat() is too high at this point, I still wanted to post my code from http://allmydata.org as an example to other users so that they can use isoformat() safely. _____________________________________ Tracker _____________________________________ From report at bugs.python.org Mon Oct 15 15:12:56 2007 From: report at bugs.python.org (Stefan Sonnenberg-Carstens) Date: Mon, 15 Oct 2007 13:12:56 -0000 Subject: [issue1279] os.system() oddity under Windows XP SP2 Message-ID: <1192453976.49.0.177979344354.issue1279@psf.upfronthosting.co.za> New submission from Stefan Sonnenberg-Carstens: When doing such os.system("a command wich writes a outfile") f = open("the file the command before wrote") the file is empty. If I do this: os.popen("a command wich writes a outfile") f = open("the file the command before wrote") everything is fine ---------- components: Interpreter Core messages: 56439 nosy: pythonmeister severity: major status: open title: os.system() oddity under Windows XP SP2 type: behavior versions: Python 2.3 __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Oct 15 15:44:25 2007 From: report at bugs.python.org (Tim Golden) Date: Mon, 15 Oct 2007 13:44:25 -0000 Subject: [issue1279] os.system() oddity under Windows XP SP2 Message-ID: <1192455865.2.0.346303116454.issue1279@psf.upfronthosting.co.za> Tim Golden added the comment: Not, apparently, on my (XP SP2) box: Python 2.5.1 (r251:54863, Apr 18 2007, 08:51:08) [MSC v.1310 32 bit (Intel)] on win32 Type "help", "copyright", "credits" or "license" for more information. >>> import os >>> os.system ("""python -c "f=open ('temp.txt','w');f.write('hello');f.close ()"""); print open ("temp.txt").read () 0 hello >>> Perhaps you could provide a runnable piece of code which demonstrates the problem? ---------- nosy: +tim.golden __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Oct 15 15:47:39 2007 From: report at bugs.python.org (Skip Montanaro) Date: Mon, 15 Oct 2007 13:47:39 -0000 Subject: [issue1074462] Irregular behavior of datetime.__str__() In-Reply-To: <1192453890.31.0.828450425872.issue1074462@psf.upfronthosting.co.za> Message-ID: <18195.28531.607046.359408@montanaro.dyndns.org> Skip Montanaro added the comment: Zooko> I meant that it special-cases .microseconds == 0. Tim indicated in his comment that the behavior is both by design and documented and isn't going to change. In an earlier comment I showed how to achieve the result you ased for in one line. Here's another example using your desire for millisecond display resolution: >>> dt.replace(microsecond=0).strftime("%Y-%m-%dT%H:%M:%S") + ".%03dZ" % (dt.microsecond//1000) '2007-10-15T08:24:02.509Z' Also, I have a patch for py3k which adds a %f format specifier to strftime. I still have to make some other additions, but you're more than welcome to review what's there now: http://bugs.python.org/issue1158 Skip _____________________________________ Tracker _____________________________________ From report at bugs.python.org Mon Oct 15 16:27:18 2007 From: report at bugs.python.org (Alexandre Vassalotti) Date: Mon, 15 Oct 2007 14:27:18 -0000 Subject: [issue1280] PEP 3137: Make PyString's indexing and iteration return integers Message-ID: <1192458438.2.0.278920353598.issue1280@psf.upfronthosting.co.za> New submission from Alexandre Vassalotti: Here a preliminary patch to make PyString return integers on indexing and iteration. There is still quite a few XXX in the patch, that I would like to fix. However, the good thing is all tests passes. ---------- components: Interpreter Core files: string_iter_ret_ints.patch messages: 56442 nosy: alexandre.vassalotti severity: normal status: open title: PEP 3137: Make PyString's indexing and iteration return integers versions: Python 3.0 __________________________________ Tracker __________________________________ -------------- next part -------------- A non-text attachment was scrubbed... Name: string_iter_ret_ints.patch Type: text/x-diff Size: 12186 bytes Desc: not available Url : http://mail.python.org/pipermail/python-bugs-list/attachments/20071015/09fc34a4/attachment-0001.patch From report at bugs.python.org Mon Oct 15 17:20:32 2007 From: report at bugs.python.org (Zooko O'Whielacronx) Date: Mon, 15 Oct 2007 15:20:32 -0000 Subject: [issue1074462] Irregular behavior of datetime.__str__() Message-ID: <1192461632.85.0.869400123654.issue1074462@psf.upfronthosting.co.za> Zooko O'Whielacronx added the comment: Thank you for the one-liner. I was about to use it in the allmydata.org project, but I remembered that my programming partner would probably prefer the larger but more explicit if:else: over the clever one-liner. Perhaps it will be useful to someone else. I'll have a look at issue1158. _____________________________________ Tracker _____________________________________ From report at bugs.python.org Mon Oct 15 17:48:47 2007 From: report at bugs.python.org (Christian Heimes) Date: Mon, 15 Oct 2007 15:48:47 -0000 Subject: [issue1258] Removal of basestring type Message-ID: <1192463327.36.0.932603047838.issue1258@psf.upfronthosting.co.za> Christian Heimes added the comment: Here is an updated patch which applies cleanly and fixes some additional unit tests and removes one that doesn't make sense any more (re.compile doesn't accept bytes). The unit tests profile, cProfile and doctest fail w/ and w/o this patch. They seem to suffer from the latest changes of our previous patch and additional calls to utf_8_decode(). __________________________________ Tracker __________________________________ -------------- next part -------------- A non-text attachment was scrubbed... Name: py3k_basestring_removal2.patch Type: text/x-diff Size: 555 bytes Desc: not available Url : http://mail.python.org/pipermail/python-bugs-list/attachments/20071015/c234bd8c/attachment.patch From report at bugs.python.org Mon Oct 15 17:54:33 2007 From: report at bugs.python.org (Guido van Rossum) Date: Mon, 15 Oct 2007 15:54:33 -0000 Subject: [issue1031213] Use correct encoding for printing SyntaxErrors In-Reply-To: <1192435981.45.0.404001697393.issue1031213@psf.upfronthosting.co.za> Message-ID: Guido van Rossum added the comment: > atsuo ishimoto added the comment: > > That's fine with me. Please replace PyErr_Print() with PyErr_Clear(). Done. Committed revision 58471. _____________________________________ Tracker _____________________________________ From report at bugs.python.org Mon Oct 15 17:58:24 2007 From: report at bugs.python.org (Guido van Rossum) Date: Mon, 15 Oct 2007 15:58:24 -0000 Subject: [issue1258] Removal of basestring type In-Reply-To: <1192463327.36.0.932603047838.issue1258@psf.upfronthosting.co.za> Message-ID: Guido van Rossum added the comment: Hm? This is a one-word patch to email/generator.py. On 10/15/07, Christian Heimes wrote: > > Christian Heimes added the comment: > > Here is an updated patch which applies cleanly and fixes some additional > unit tests and removes one that doesn't make sense any more (re.compile > doesn't accept bytes). > > The unit tests profile, cProfile and doctest fail w/ and w/o this patch. > They seem to suffer from the latest changes of our previous patch and > additional calls to utf_8_decode(). __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Oct 15 18:25:32 2007 From: report at bugs.python.org (Kurt B. Kaiser) Date: Mon, 15 Oct 2007 16:25:32 -0000 Subject: [issue1253] IDLE - Percolator overhaul Message-ID: <1192465532.17.0.587070933345.issue1253@psf.upfronthosting.co.za> Kurt B. Kaiser added the comment: Thanks for the patch, it will definitely be applied once I finish reviewing it! Good job splitting off TkTextPercolator and inheriting from Delegator. ---------- assignee: -> kbk priority: -> normal __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Oct 15 18:49:12 2007 From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=) Date: Mon, 15 Oct 2007 16:49:12 -0000 Subject: [issue1280] PEP 3137: Make PyString's indexing and iteration return integers Message-ID: <1192466952.62.0.671733619635.issue1280@psf.upfronthosting.co.za> Changes by Martin v. L?wis: ---------- keywords: +patch __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Oct 15 19:27:30 2007 From: report at bugs.python.org (Guido van Rossum) Date: Mon, 15 Oct 2007 17:27:30 -0000 Subject: [issue1276] LookupError: unknown encoding: X-MAC-JAPANESE Message-ID: <1192469250.87.0.299374316912.issue1276@psf.upfronthosting.co.za> Guido van Rossum added the comment: Marc-Andre, do you understand this issue? Your name is in Tools/unicode/Makefile; the patch deletes the line $(RM) build/mac_japanese.* from the apple target, which seems rather arbitrary. ---------- assignee: -> lemburg nosy: +gvanrossum, lemburg __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Oct 15 19:28:07 2007 From: report at bugs.python.org (Guido van Rossum) Date: Mon, 15 Oct 2007 17:28:07 -0000 Subject: [issue1277] mailbox.Maildir: factory not used Message-ID: <1192469287.91.0.103168203366.issue1277@psf.upfronthosting.co.za> Guido van Rossum added the comment: Patch please? ---------- nosy: +gvanrossum __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Oct 15 19:29:19 2007 From: report at bugs.python.org (Guido van Rossum) Date: Mon, 15 Oct 2007 17:29:19 -0000 Subject: [issue1278] imp.find_module() ignores -*- coding: Latin-1 -*- Message-ID: <1192469359.16.0.404393465036.issue1278@psf.upfronthosting.co.za> Guido van Rossum added the comment: Can you suggest a patch? Adding Brett Cannon to the list, possibly his import-in-python would supersede this? ---------- nosy: +brett.cannon, gvanrossum __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Oct 15 19:31:28 2007 From: report at bugs.python.org (Guido van Rossum) Date: Mon, 15 Oct 2007 17:31:28 -0000 Subject: [issue1263] PEP 3137 patch - str8/str comparison should return false In-Reply-To: <1192453296.61.0.335767716616.issue1263@psf.upfronthosting.co.za> Message-ID: Guido van Rossum added the comment: I'll look at this at some point. One quick comment: the lnotab and bytecode should use PyString, which will be 'bytes' in 3.0a2. They must be immutable because code objects must be immutable (it must not be possible to modify an existing code object). On 10/15/07, Thomas Lee wrote: > > > Thomas Lee added the comment: > > Hack to make Python/codecs.c use Unicode strings internally. I recognize > the way I have fixed it here is probably not ideal (basically ripped out > PyString_*, replaced with a PyMem_Malloc/PyMem_Free call) but it fixes > 10-12 tests that were failing with my earlier changes. If anybody can > recommend a "nice" way to fix this, I'm all ears. > > The following still fail for me with this patch applied: > > -- test_compile > > This is due to PyString_*/PyUnicode_*/PyBytes_* confusion in the > assembler struct (specifically: a_lnotab and a_bytecode) in > Python/compile.c - tried replacing PyString_* calls with PyBytes_* > calls, but this raises a TypeError because PyBytes is not hashable ... > not sure what exactly is causing this. > > -- test_ctypes > Looks like a simple case of ctypes using str8 instead of str. Appears to > be an easy fix. > > -- test_modulefinder > Failing because str8 >= str is now an invalid operation > > -- test_set > This test needs some love. > > -- test_sqlite > Not sure what's going on here. > > -- test_str > > This one is a little tricky: str8/str with __str__/__unicode__ ... how > is this test supposed to behave with the fix in this patch? > > -- test_struct > "unpack/pack not transitive" - what does that mean? > > -- test_subprocess > Like modulefinder, this is probably just due to the use of str8 over str > internally in the subprocess module. Likely to be an easy fix. > > The following tests fail for me irrespective of whether or not I have r4 > of my patch applied: > > -- test_doctest > -- test_email > -- test_nis > -- test_pty > > If anybody can give this new patch a try and let me know the result it > would be much appreciated. > > __________________________________ > Tracker > > __________________________________ > __________________________________ Tracker __________________________________ -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: unnamed Url: http://mail.python.org/pipermail/python-bugs-list/attachments/20071015/29bf8825/attachment-0001.txt From report at bugs.python.org Mon Oct 15 19:47:13 2007 From: report at bugs.python.org (Christian Heimes) Date: Mon, 15 Oct 2007 17:47:13 -0000 Subject: [issue1278] imp.find_module() ignores -*- coding: Latin-1 -*- In-Reply-To: <1192469359.16.0.404393465036.issue1278@psf.upfronthosting.co.za> Message-ID: <4713A79A.9090605@cheimes.de> Christian Heimes added the comment: > Can you suggest a patch? > > Adding Brett Cannon to the list, possibly his import-in-python would > supersede this? No, I can't suggest a patch. I don't know how we could get the encoding from the tokenizer or AST. Brett is obviously the best man to fix the problem. :) Christian __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Oct 15 19:53:09 2007 From: report at bugs.python.org (Bill Janssen) Date: Mon, 15 Oct 2007 17:53:09 -0000 Subject: [issue1251] ssl module doesn't support non-blocking handshakes Message-ID: <1192470789.62.0.851906749518.issue1251@psf.upfronthosting.co.za> Bill Janssen added the comment: Perhaps we shouldn't expose this at the application level. We could check, in the C module's sslwrap, whether the socket is blocking or not, and do the right thing there, so that sslwrap would always succeed in one call. Since we are releasing the GIL whenever we do SSL_accept() or SSL_connect(), other threads get a chance to run, so doing it transparently shouldn't affect the Python program's liveness. And it would reduce the chances for application error. __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Oct 15 19:56:26 2007 From: report at bugs.python.org (Marc-Andre Lemburg) Date: Mon, 15 Oct 2007 17:56:26 -0000 Subject: [issue1276] LookupError: unknown encoding: X-MAC-JAPANESE Message-ID: <1192470986.25.0.888547240322.issue1276@psf.upfronthosting.co.za> Marc-Andre Lemburg added the comment: My name appears in that Makefile because I wrote it and used it to create the charmap codecs. The reason why the Mac Japanese codec was not created for 2.x was the size of the mapping table. Ideal would be to have the C version of the CJK codecs support the Mac Japanese encoding as well. Adding back the charmap based Mac Japanese codec would be a compromise. The absence of the Mac Japanese codec causes (obvious) problems for many Japanese Python users running Mac OS X. __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Oct 15 19:57:26 2007 From: report at bugs.python.org (Marc-Andre Lemburg) Date: Mon, 15 Oct 2007 17:57:26 -0000 Subject: [issue1276] LookupError: unknown encoding: X-MAC-JAPANESE Message-ID: <1192471046.38.0.489305985954.issue1276@psf.upfronthosting.co.za> Marc-Andre Lemburg added the comment: Adding Python 2.6 as version target. ---------- versions: +Python 2.6 __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Oct 15 20:02:59 2007 From: report at bugs.python.org (Guido van Rossum) Date: Mon, 15 Oct 2007 18:02:59 -0000 Subject: [issue1278] imp.find_module() ignores -*- coding: Latin-1 -*- In-Reply-To: <4713A79A.9090605@cheimes.de> Message-ID: Guido van Rossum added the comment: > No, I can't suggest a patch. I don't know how we could get the encoding > from the tokenizer or AST. Try harder. :-) Look at the code that accomplishes this feat in the regular parser... __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Oct 15 20:30:56 2007 From: report at bugs.python.org (Christian Heimes) Date: Mon, 15 Oct 2007 18:30:56 -0000 Subject: [issue1278] imp.find_module() ignores -*- coding: Latin-1 -*- In-Reply-To: Message-ID: <4713B1DD.6000503@cheimes.de> Christian Heimes added the comment: > Try harder. :-) Look at the code that accomplishes this feat in the > regular parser... I've already found the methods that find the encoding in Parser/tokenizer.c: check_coding_spec() and friends. But it seems like a waste of time to use PyTokenizer_FromFile() just to find the encoding. *reading* Mmh ... It's not a waste of time if I can stop the tokenizer. I think it may be possible to use the tokenizer to get the encoding efficiently. I could read until tok_state->read_coding_spec or tok_state->indent != 0. Do you know a better way to stop the tokenizer when the line isn't a special comment line "# -*-"? Christian __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Oct 15 21:26:02 2007 From: report at bugs.python.org (Ben Sherman) Date: Mon, 15 Oct 2007 19:26:02 -0000 Subject: [issue1281] type in docutmentatio section 14.3.3.4 Message-ID: <1192476362.59.0.198935696979.issue1281@psf.upfronthosting.co.za> New submission from Ben Sherman: """ If, a little later on, "-tracks=4" is seen, it does: options.tracks.append(int("4")) """ That should read --tracks=4, not -tracks=4 Found at http://docs.python.org/lib/optparse-standard-option-actions.html ---------- components: Documentation messages: 56460 nosy: bsherman severity: normal status: open title: type in docutmentatio section 14.3.3.4 versions: Python 2.5 __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Oct 15 21:30:23 2007 From: report at bugs.python.org (Guido van Rossum) Date: Mon, 15 Oct 2007 19:30:23 -0000 Subject: [issue1278] imp.find_module() ignores -*- coding: Latin-1 -*- In-Reply-To: <4713B1DD.6000503@cheimes.de> Message-ID: Guido van Rossum added the comment: Call PyTokenizer_Get until the line number is > 2? On 10/15/07, Christian Heimes wrote: > > Christian Heimes added the comment: > > > Try harder. :-) Look at the code that accomplishes this feat in the > > regular parser... > > I've already found the methods that find the encoding in > Parser/tokenizer.c: check_coding_spec() and friends. > > But it seems like a waste of time to use PyTokenizer_FromFile() just to > find the encoding. *reading* Mmh ... It's not a waste of time if I can > stop the tokenizer. I think it may be possible to use the tokenizer to > get the encoding efficiently. I could read until > tok_state->read_coding_spec or tok_state->indent != 0. > > Do you know a better way to stop the tokenizer when the line isn't a > special comment line "# -*-"? > > Christian > > __________________________________ > Tracker > > __________________________________ > __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Oct 15 21:34:55 2007 From: report at bugs.python.org (Brett Cannon) Date: Mon, 15 Oct 2007 19:34:55 -0000 Subject: [issue1278] imp.find_module() ignores -*- coding: Latin-1 -*- Message-ID: <1192476895.52.0.0663399212147.issue1278@psf.upfronthosting.co.za> Brett Cannon added the comment: No, my work has the exact same problem. Actually, this bug report has confirmed for me why heapq could not be imported when I accidentally forced all open text files to use UTF-8. I just have not gotten around to trying to solve this issue yet. But since importlib just uses open() directly it has the same problems. Since it looks like TextIOWrapper does not let one change the encoding after it has been set, some subclass might need to be written that reads Looks for the the stanza or else immediately stops and uses the expected encoding (UTF-8 in the case of Py3K or ASCII for 2.6). That or expose some C function that takes a file path or open file that returns a code object. But I have bigger fish to fry as my attempt to get around open() being defined in site.py is actually failing once I clobbered my .pyc files as codecs requires importing modules, even for ASCII encoding. __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Oct 15 21:36:01 2007 From: report at bugs.python.org (Christian Heimes) Date: Mon, 15 Oct 2007 19:36:01 -0000 Subject: [issue1278] imp.find_module() ignores -*- coding: Latin-1 -*- In-Reply-To: Message-ID: <4713C11F.5000509@cheimes.de> Christian Heimes added the comment: > Call PyTokenizer_Get until the line number is > 2? That's too easy :] I'm going to implement the fix tonight. Christian __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Oct 15 21:37:09 2007 From: report at bugs.python.org (Ben Sherman) Date: Mon, 15 Oct 2007 19:37:09 -0000 Subject: [issue1281] type in docutmentation - lib ref section 14.3.3.4 Message-ID: <1192477029.26.0.710569187337.issue1281@psf.upfronthosting.co.za> Ben Sherman added the comment: Typos corrected. ---------- title: type in docutmentatio section 14.3.3.4 -> type in docutmentation - lib ref section 14.3.3.4 __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Oct 15 22:28:51 2007 From: report at bugs.python.org (Christian Heimes) Date: Mon, 15 Oct 2007 20:28:51 -0000 Subject: [issue1267] Py3K cannot run as ``python -S`` Message-ID: <1192480131.59.0.0018284140008.issue1267@psf.upfronthosting.co.za> Christian Heimes added the comment: I've some code around which sets sys.stdin, out and err in C code. The code is far from perfect and I haven't checked it for reference leaks yet. I like to get your comment on the style and error catching. ---------- nosy: +tiran __________________________________ Tracker __________________________________ -------------- next part -------------- A non-text attachment was scrubbed... Name: py3k_initio.patch Type: text/x-diff Size: 4016 bytes Desc: not available Url : http://mail.python.org/pipermail/python-bugs-list/attachments/20071015/7c862602/attachment-0001.patch From report at bugs.python.org Mon Oct 15 22:31:54 2007 From: report at bugs.python.org (Brett Cannon) Date: Mon, 15 Oct 2007 20:31:54 -0000 Subject: [issue1267] Py3K cannot run as ``python -S`` Message-ID: <1192480314.56.0.901830323289.issue1267@psf.upfronthosting.co.za> Changes by Brett Cannon: ---------- assignee: -> brett.cannon keywords: +patch __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Oct 16 00:02:16 2007 From: report at bugs.python.org (Guido van Rossum) Date: Mon, 15 Oct 2007 22:02:16 -0000 Subject: [issue1261] PEP 3137: make bytesobject.c methods Message-ID: <1192485736.79.0.421775865397.issue1261@psf.upfronthosting.co.za> Guido van Rossum added the comment: Is it worth my time to review this yet? __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Oct 16 00:07:38 2007 From: report at bugs.python.org (Guido van Rossum) Date: Mon, 15 Oct 2007 22:07:38 -0000 Subject: [issue1258] Removal of basestring type Message-ID: <1192486058.97.0.84511553796.issue1258@psf.upfronthosting.co.za> Changes by Guido van Rossum: __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Oct 16 00:14:26 2007 From: report at bugs.python.org (Guido van Rossum) Date: Mon, 15 Oct 2007 22:14:26 -0000 Subject: [issue1258] Removal of basestring type Message-ID: <1192486466.29.0.378519209028.issue1258@psf.upfronthosting.co.za> Guido van Rossum added the comment: > The unit tests profile, cProfile and doctest fail w/ and w/o this patch. > They seem to suffer from the latest changes of our previous patch and > additional calls to utf_8_decode(). Any details on those? They don't fail for me. __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Oct 16 00:36:36 2007 From: report at bugs.python.org (Gregory P. Smith) Date: Mon, 15 Oct 2007 22:36:36 -0000 Subject: [issue1261] PEP 3137: make bytesobject.c methods Message-ID: <1192487796.8.0.189968801907.issue1261@psf.upfronthosting.co.za> Changes by Gregory P. Smith: __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Oct 16 00:57:55 2007 From: report at bugs.python.org (Guido van Rossum) Date: Mon, 15 Oct 2007 22:57:55 -0000 Subject: [issue1258] Removal of basestring type Message-ID: <1192489075.84.0.952393190719.issue1258@psf.upfronthosting.co.za> Guido van Rossum added the comment: I'll check this in as soon as there's agreement on the list about this. Not that I expect disagreement, but I just realized it was never brought up and it isn't in PEP 3137 (yet). __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Oct 16 01:11:45 2007 From: report at bugs.python.org (Christian Heimes) Date: Mon, 15 Oct 2007 23:11:45 -0000 Subject: [issue1258] Removal of basestring type In-Reply-To: <1192486466.29.0.378519209028.issue1258@psf.upfronthosting.co.za> Message-ID: <4713F3A2.6070801@cheimes.de> Christian Heimes added the comment: > Any details on those? They don't fail for me. Here you are. $ ./python Lib/test/test_cProfile.py 121 function calls (101 primitive calls) in 1.000 CPU seconds Ordered by: standard name ncalls tottime percall cumtime percall filename:lineno(function) 1 0.000 0.000 1.000 1.000 :1() 8 0.064 0.008 0.080 0.010 test_cProfile.py:103(subhelper) 28 0.028 0.001 0.028 0.001 test_cProfile.py:115(__getattr__) 1 0.270 0.270 1.000 1.000 test_cProfile.py:30(testfunc) 23/3 0.150 0.007 0.170 0.057 test_cProfile.py:40(factorial) 20 0.020 0.001 0.020 0.001 test_cProfile.py:53(mul) 2 0.040 0.020 0.600 0.300 test_cProfile.py:60(helper) 4 0.116 0.029 0.120 0.030 test_cProfile.py:78(helper1) 2 0.000 0.000 0.140 0.070 test_cProfile.py:89(helper2_indirect) 8 0.312 0.039 0.400 0.050 test_cProfile.py:93(helper2) 1 0.000 0.000 0.000 0.000 utf_8.py:15(decode) 1 0.000 0.000 0.000 0.000 {_codecs.utf_8_decode} 1 0.000 0.000 1.000 1.000 {exec} 12 0.000 0.000 0.012 0.001 {hasattr} 4 0.000 0.000 0.000 0.000 {method 'append' of 'list' objects} 1 0.000 0.000 0.000 0.000 {method 'disable' of '_lsprof.Profiler' objects} 4 0.000 0.000 0.000 0.000 {sys.exc_info} Ordered by: standard name Function called... ncalls tottime cumtime :1() -> 1 0.270 1.000 test_cProfile.py:30(testfunc) test_cProfile.py:103(subhelper) -> 16 0.016 0.016 test_cProfile.py:115(__getattr__) test_cProfile.py:115(__getattr__) -> test_cProfile.py:30(testfunc) -> 1 0.014 0.130 test_cProfile.py:40(factorial) 2 0.040 0.600 test_cProfile.py:60(helper) test_cProfile.py:40(factorial) -> 20/3 0.130 0.147 test_cProfile.py:40(factorial) 20 0.020 0.020 test_cProfile.py:53(mul) test_cProfile.py:53(mul) -> test_cProfile.py:60(helper) -> 4 0.116 0.120 test_cProfile.py:78(helper1) 2 0.000 0.140 test_cProfile.py:89(helper2_indirect) 6 0.234 0.300 test_cProfile.py:93(helper2) test_cProfile.py:78(helper1) -> 4 0.000 0.004 {hasattr} 4 0.000 0.000 {method 'append' of 'list' objects} 4 0.000 0.000 {sys.exc_info} test_cProfile.py:89(helper2_indirect) -> 2 0.006 0.040 test_cProfile.py:40(factorial) 2 0.078 0.100 test_cProfile.py:93(helper2) test_cProfile.py:93(helper2) -> 8 0.064 0.080 test_cProfile.py:103(subhelper) 8 0.000 0.008 {hasattr} utf_8.py:15(decode) -> 1 0.000 0.000 {_codecs.utf_8_decode} {_codecs.utf_8_decode} -> {exec} -> 1 0.000 1.000 :1() 1 0.000 0.000 utf_8.py:15(decode) {hasattr} -> 12 0.012 0.012 test_cProfile.py:115(__getattr__) {method 'append' of 'list' objects} -> {method 'disable' of '_lsprof.Profiler' objects} -> {sys.exc_info} -> Ordered by: standard name Function was called by... ncalls tottime cumtime :1() <- 1 0.000 1.000 {exec} test_cProfile.py:103(subhelper) <- 8 0.064 0.080 test_cProfile.py:93(helper2) test_cProfile.py:115(__getattr__) <- 16 0.016 0.016 test_cProfile.py:103(subhelper) 12 0.012 0.012 {hasattr} test_cProfile.py:30(testfunc) <- 1 0.270 1.000 :1() test_cProfile.py:40(factorial) <- 1 0.014 0.130 test_cProfile.py:30(testfunc) 20/3 0.130 0.147 test_cProfile.py:40(factorial) 2 0.006 0.040 test_cProfile.py:89(helper2_indirect) test_cProfile.py:53(mul) <- 20 0.020 0.020 test_cProfile.py:40(factorial) test_cProfile.py:60(helper) <- 2 0.040 0.600 test_cProfile.py:30(testfunc) test_cProfile.py:78(helper1) <- 4 0.116 0.120 test_cProfile.py:60(helper) test_cProfile.py:89(helper2_indirect) <- 2 0.000 0.140 test_cProfile.py:60(helper) test_cProfile.py:93(helper2) <- 6 0.234 0.300 test_cProfile.py:60(helper) 2 0.078 0.100 test_cProfile.py:89(helper2_indirect) utf_8.py:15(decode) <- 1 0.000 0.000 {exec} {_codecs.utf_8_decode} <- 1 0.000 0.000 utf_8.py:15(decode) {exec} <- {hasattr} <- 4 0.000 0.004 test_cProfile.py:78(helper1) 8 0.000 0.008 test_cProfile.py:93(helper2) {method 'append' of 'list' objects} <- 4 0.000 0.000 test_cProfile.py:78(helper1) {method 'disable' of '_lsprof.Profiler' objects} <- {sys.exc_info} <- 4 0.000 0.000 test_cProfile.py:78(helper1) #################################### $ ./python Lib/test/test_doctest.py doctest (doctest) ... 66 tests with zero failures ********************************************************************** File "/home/heimes/dev/python/py3k/Lib/test/test_doctest.py", line 1570, in test.test_doctest.test_debug Failed example: try: doctest.debug_src(s) finally: sys.stdin = real_stdin Expected: > (1)() (Pdb) next 12 --Return-- > (1)()->None (Pdb) print(x) 12 (Pdb) continue Got: > /home/heimes/dev/python/py3k/Lib/encodings/utf_8.py(16)decode() -> return codecs.utf_8_decode(input, errors, True) (Pdb) next --Return-- > /home/heimes/dev/python/py3k/Lib/encodings/utf_8.py(16)decode()->('', 8) -> return codecs.utf_8_decode(input, errors, True) (Pdb) print(x) *** NameError: NameError("name 'x' is not defined",) (Pdb) continue 12 ********************************************************************** 1 items had failures: 1 of 4 in test.test_doctest.test_debug ***Test Failed*** 1 failures. Traceback (most recent call last): File "Lib/test/test_doctest.py", line 2422, in test_main() File "Lib/test/test_doctest.py", line 2406, in test_main test_support.run_doctest(test_doctest, verbosity=True) File "/home/heimes/dev/python/py3k/Lib/test/test_support.py", line 569, in run_doctest raise TestFailed("%d of %d doctests failed" % (f, t)) test.test_support.TestFailed: 1 of 414 doctests failed #################################### $ ./python Lib/test/test_email.py Traceback (most recent call last): File "Lib/test/test_email.py", line 13, in test_main() File "Lib/test/test_email.py", line 10, in test_main test_support.run_unittest(suite()) File "/home/heimes/dev/python/py3k/Lib/test/test_support.py", line 541, in run_unittest _run_suite(suite) File "/home/heimes/dev/python/py3k/Lib/test/test_support.py", line 524, in _run_suite raise TestFailed(err) test.test_support.TestFailed: Traceback (most recent call last): File "/home/heimes/dev/python/py3k/Lib/email/test/test_email.py", line 1445, in test_same_boundary_inner_outer msg = self._msgobj('msg_15.txt') File "/home/heimes/dev/python/py3k/Lib/email/test/test_email.py", line 67, in _msgobj return email.message_from_file(fp) File "/home/heimes/dev/python/py3k/Lib/email/__init__.py", line 46, in message_from_file return Parser(*args, **kws).parse(fp) File "/home/heimes/dev/python/py3k/Lib/email/parser.py", line 68, in parse data = fp.read(8192) File "/home/heimes/dev/python/py3k/Lib/io.py", line 1240, in read readahead, pending = self._read_chunk() File "/home/heimes/dev/python/py3k/Lib/io.py", line 1136, in _read_chunk pending = self._decoder.decode(readahead, not readahead) File "/home/heimes/dev/python/py3k/Lib/codecs.py", line 291, in decode (result, consumed) = self._buffer_decode(data, self.errors, final) UnicodeDecodeError: 'utf8' codec can't decode byte 0xbe in position 86: unexpected code byte __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Oct 16 01:13:21 2007 From: report at bugs.python.org (Guido van Rossum) Date: Mon, 15 Oct 2007 23:13:21 -0000 Subject: [issue1258] Removal of basestring type Message-ID: <1192490001.06.0.130412485677.issue1258@psf.upfronthosting.co.za> Guido van Rossum added the comment: BTW we need a 2to3 fixer for this. Should be trivial -- just replace *all* occurrences of basestring with str. __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Oct 16 01:26:51 2007 From: report at bugs.python.org (Guido van Rossum) Date: Mon, 15 Oct 2007 23:26:51 -0000 Subject: [issue1282] re module needs to support bytes / memoryview well Message-ID: <1192490811.67.0.131142181278.issue1282@psf.upfronthosting.co.za> New submission from Guido van Rossum: Once PEP 3137 is fully implemented, the re module needs to be fixed so that the regex argument, the substitution argument, and the argument being searched/replaced are allowed to be arbitrary bytes arrays; where hashing is needed a copy in an immutable bytes object can be made. ---------- messages: 56472 nosy: gvanrossum severity: normal status: open title: re module needs to support bytes / memoryview well versions: Python 3.0 __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Oct 16 01:27:01 2007 From: report at bugs.python.org (Guido van Rossum) Date: Mon, 15 Oct 2007 23:27:01 -0000 Subject: [issue1258] Removal of basestring type Message-ID: <1192490821.77.0.116641656077.issue1258@psf.upfronthosting.co.za> Guido van Rossum added the comment: Even before this patch, the re module doesn't work very well on byte strings. IMO this should be fixed. I've filed a separate bug to remind us: bug 1282. __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Oct 16 01:52:41 2007 From: report at bugs.python.org (Christian Heimes) Date: Mon, 15 Oct 2007 23:52:41 -0000 Subject: [issue1258] Removal of basestring type In-Reply-To: <1192490001.06.0.130412485677.issue1258@psf.upfronthosting.co.za> Message-ID: <4713FD43.5090009@cheimes.de> Christian Heimes added the comment: Guido van Rossum wrote: > BTW we need a 2to3 fixer for this. Should be trivial -- just replace > *all* occurrences of basestring with str. I believe you that it's trivial for *you* but I've never dealt with the fixers or the grammar. Fortunately for me I was able to copy the fixer for standarderror. It toke just some minor tweaks :) Let's see if the mail interface can handle attachments. __________________________________ Tracker __________________________________ -------------- next part -------------- A non-text attachment was scrubbed... Name: fix_basestr.py Type: text/x-python Size: 368 bytes Desc: not available Url : http://mail.python.org/pipermail/python-bugs-list/attachments/20071015/a2badd18/attachment.py From report at bugs.python.org Tue Oct 16 02:11:31 2007 From: report at bugs.python.org (Chris Stawarz) Date: Tue, 16 Oct 2007 00:11:31 -0000 Subject: [issue1251] ssl module doesn't support non-blocking handshakes In-Reply-To: <1192470789.62.0.851906749518.issue1251@psf.upfronthosting.co.za> Message-ID: Chris Stawarz added the comment: Bill, You seem to be missing the whole point of doing non-blocking I/O, which is to handle multiple concurrent, I/O-bound tasks in a single OS thread. The application must be able to try the handshake, detect that it didn't complete because I/O needs to take place, and then retry it at a later time of its choosing (presumably when select() says it's OK to read from the socket). And between now and that later time, it can do other things, like read or write to other sockets. The point is that the *application* must have control over when it does I/O, when it waits for sockets to be ready for I/O, and what it does in between. There's just no way it can do this if the sslwrap() function doesn't return until the handshaking is complete. sslwrap() can't "do the right thing", because the right thing is to return control to the application until it's ready to try the handshake again. And this has nothing to do with the GIL or multiple threads. Like I said, the point of doing non-blocking I/O with select() is to *avoid* the need for multiple threads. __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Oct 16 02:19:34 2007 From: report at bugs.python.org (Guido van Rossum) Date: Tue, 16 Oct 2007 00:19:34 -0000 Subject: [issue1261] PEP 3137: make bytesobject.c methods Message-ID: <1192493974.38.0.289275810218.issue1261@psf.upfronthosting.co.za> Guido van Rossum added the comment: Very impressive! (Apologies if these lines are occasionally out of order.) +extern PyObject* _bytes_isspace(const char *cptr, const Py_ssize_t len); IMO all these functions should have names starting with _Py or _Py_, since they are visible to the linker. Also, why 'const Py_ssize_t'? It's a scalar! +/* these store their len sized answer in the given preallocated *result arg */ Mind using a Capital first letter? +extern const char isspace__doc__[]; This needs a _Py or _Py_ prefix too. +extern const unsigned int ctype_table[256]; Now this is no longer static, it also needs a _Py or _Py_ prefix. +extern const unsigned char ctype_tolower[256]; +extern const unsigned char ctype_toupper[256]; Ditto (the macros are fine though, since they are only visible to code that #includes this file, which is only a few files). +Return True if all characters in S are whitespace\n\ Shouldn't that be bytes instead of characters (and consistently throughout)? And probably use B for the variable name instead of S. +/* ------- GPS --------- */ What's this? Your initials? :-) I don't think it's needed. I'm guessing you /* The nullbytes are used by the stringlib during partition. * If partition is removed from bytes, nullbytes and its helper This comment block refers to something that ain't gonna happen (partition being removed). IMO the whole comment block can go, it's a red herring. + /* XXX: this depends on a signed integer overflow to < 0 */ + /* C compilers, including gcc, do -NOT- guarantee this. */ (And repeated twice more.) Wouldn't it be better to write this in a way that doesn't require this XXX comment? ISTR that we already had one area where we had to fight with gcc because it had proved to itself that something could never be negative, even though it could be due to overflow. The GCC authors won. :-( +/* TODO(gps): Don't you mean XXX(gps)? :-) + * These methods still need implementing (porting over from stringobject.c): + * + * IN PROGRESS: + * .capitalize(), .title(), .upper(), .lower(), .center(), .zfill(), + * .expandtabs(), .ljust(), .rjust(), .swapcase(), .splitlines(), + */ + Hmmm... Aren't these done now? + /* XXX(gps): the docstring above says any iterable int will do but the + * bytes_setslice code only accepts something supporting PEP 3118. + * Is a list or tuple of 0 <= ints <= 255 also supposed to work? */ Yes, it is, and it's a bug that it currently doesn't. __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Oct 16 02:31:50 2007 From: report at bugs.python.org (Gregory P. Smith) Date: Tue, 16 Oct 2007 00:31:50 -0000 Subject: [issue1283] PyBytes (buffer) .extend method needs to accept any iterable of ints Message-ID: <1192494710.42.0.243752942125.issue1283@psf.upfronthosting.co.za> New submission from Gregory P. Smith: The PyBytes (pep3137 buffer) .extend() method currently only accepts as input something supporting the pep3118 buffer API. It also needs to accept an iterable of ints in the 0..255 range. ---------- keywords: py3k messages: 56478 nosy: gregory.p.smith severity: normal status: open title: PyBytes (buffer) .extend method needs to accept any iterable of ints versions: Python 3.0 __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Oct 16 02:53:50 2007 From: report at bugs.python.org (Gregory P. Smith) Date: Tue, 16 Oct 2007 00:53:50 -0000 Subject: [issue1261] PEP 3137: make bytesobject.c methods Message-ID: <1192496030.11.0.908324877216.issue1261@psf.upfronthosting.co.za> Changes by Gregory P. Smith: __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Oct 16 02:53:53 2007 From: report at bugs.python.org (Gregory P. Smith) Date: Tue, 16 Oct 2007 00:53:53 -0000 Subject: [issue1261] PEP 3137: make bytesobject.c methods Message-ID: <1192496033.89.0.15669623452.issue1261@psf.upfronthosting.co.za> Changes by Gregory P. Smith: __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Oct 16 03:07:10 2007 From: report at bugs.python.org (Eric Wollesen) Date: Tue, 16 Oct 2007 01:07:10 -0000 Subject: [issue1284] typo in lib doc 7.3.2.1 MaildirMessage Message-ID: <1192496830.47.0.752456645031.issue1284@psf.upfronthosting.co.za> New submission from Eric Wollesen: get_subdir( ) Return either "new" (if the message should be stored in the new subdirectory) or "cur" (if the message should be stored in the cur subdirectory). Note: A message is typically moved from new to cur after its mailbox has been accessed, whether or not the message is has been read. A message msg has been read if "S" not in msg.get_flags() is True. ---- The last sentence above is incorrect. The "not" should be removed. It should read: A message msg has been read if "S" in msg.get_flags() is True. ---------- components: Documentation messages: 56481 nosy: encoded severity: minor status: open title: typo in lib doc 7.3.2.1 MaildirMessage type: rfe versions: Python 2.5 __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Oct 16 03:15:09 2007 From: report at bugs.python.org (Alexandre Vassalotti) Date: Tue, 16 Oct 2007 01:15:09 -0000 Subject: [issue1278] imp.find_module() ignores -*- coding: Latin-1 -*- Message-ID: <1192497309.96.0.479216433879.issue1278@psf.upfronthosting.co.za> Changes by Alexandre Vassalotti: ---------- nosy: +alexandre.vassalotti __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Oct 16 03:22:46 2007 From: report at bugs.python.org (Alexandre Vassalotti) Date: Tue, 16 Oct 2007 01:22:46 -0000 Subject: [issue1272] Decode __file__ and co_filename to unicode using fs default Message-ID: <1192497766.36.0.0800851672538.issue1272@psf.upfronthosting.co.za> Alexandre Vassalotti added the comment: I wrote in msg56419: > It is not perfect, since the extra function calls in the codecs module > causes test_profile and test_doctest to fail. How this was resolved? __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Oct 16 03:25:31 2007 From: report at bugs.python.org (Christian Heimes) Date: Tue, 16 Oct 2007 01:25:31 -0000 Subject: [issue1272] Decode __file__ and co_filename to unicode using fs default In-Reply-To: <1192497766.36.0.0800851672538.issue1272@psf.upfronthosting.co.za> Message-ID: <47141301.9090408@cheimes.de> Christian Heimes added the comment: >> It is not perfect, since the extra function calls in the codecs module >> causes test_profile and test_doctest to fail. > > How this was resolved? It's not resolved yet. __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Oct 16 04:11:25 2007 From: report at bugs.python.org (Christian Heimes) Date: Tue, 16 Oct 2007 02:11:25 -0000 Subject: [issue1267] Py3K cannot run as ``python -S`` Message-ID: <1192500685.39.0.29214068182.issue1267@psf.upfronthosting.co.za> Christian Heimes added the comment: I've carefully checked and tested the initstdio() method. I'm sure that I've catched every edged case. The unit tests pass w/o complains. I've also added a PyErr_Display() call to Py_FatalError(). It's still hard to understand an error in io.py but at least the dependency on site.py is removed. __________________________________ Tracker __________________________________ -------------- next part -------------- A non-text attachment was scrubbed... Name: py3k_initio2.patch Type: text/x-diff Size: 5339 bytes Desc: not available Url : http://mail.python.org/pipermail/python-bugs-list/attachments/20071016/b7c6ec12/attachment-0001.patch From report at bugs.python.org Tue Oct 16 04:27:14 2007 From: report at bugs.python.org (Facundo Batista) Date: Tue, 16 Oct 2007 02:27:14 -0000 Subject: [issue1259] string find and rfind methods give a TypeError that is misleading Message-ID: <1192501634.07.0.0876382697754.issue1259@psf.upfronthosting.co.za> Facundo Batista added the comment: Documentation for find(): str.find(sub[, start[, end]]) Return the lowest index in the string where substring sub is found, such that sub is contained in the range [start, end]. Optional arguments start and end are interpreted as in slice notation. Return -1 if sub is not found. I think that it shouldn't be possible to call it with None arguments. The error message is wrong: it's a TypeError, but the message should say something like... TypeError: slice indices must be integers or have an __index__ method If you're ok with this change, assign this bug to me and I'll fix it. Regards, ---------- nosy: +facundobatista __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Oct 16 04:29:33 2007 From: report at bugs.python.org (Bill Janssen) Date: Tue, 16 Oct 2007 02:29:33 -0000 Subject: [issue1251] ssl module doesn't support non-blocking handshakes In-Reply-To: Message-ID: <4b3e516a0710151929r6389b893o5dc16fe1a5d91ebd@mail.gmail.com> Bill Janssen added the comment: "You seem to be missing the whole point of doing non-blocking I/O," You know, I think that's right. I'm so used to using threads by now that the whole select-based approach seems very odd to me by now. OK, I've folded your patch into the PyPI version, ssl 1.8. It will meander into the trunk and 3K version as well. Thanks for the help! Bill On 10/15/07, Chris Stawarz wrote: > > Chris Stawarz added the comment: > > Bill, > > You seem to be missing the whole point of doing non-blocking I/O, > which is to handle multiple concurrent, I/O-bound tasks in a single > OS thread. The application must be able to try the handshake, detect > that it didn't complete because I/O needs to take place, and then > retry it at a later time of its choosing (presumably when select() > says it's OK to read from the socket). And between now and that > later time, it can do other things, like read or write to other sockets. > > The point is that the *application* must have control over when it > does I/O, when it waits for sockets to be ready for I/O, and what it > does in between. There's just no way it can do this if the sslwrap() > function doesn't return until the handshaking is complete. sslwrap() > can't "do the right thing", because the right thing is to return > control to the application until it's ready to try the handshake again. > > And this has nothing to do with the GIL or multiple threads. Like I > said, the point of doing non-blocking I/O with select() is to *avoid* > the need for multiple threads. > > __________________________________ > Tracker > > __________________________________ > __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Oct 16 05:27:03 2007 From: report at bugs.python.org (Guido van Rossum) Date: Tue, 16 Oct 2007 03:27:03 -0000 Subject: [issue1261] PEP 3137: make bytesobject.c methods In-Reply-To: <1192496707.32.0.492154756367.issue1261@psf.upfronthosting.co.za> Message-ID: Guido van Rossum added the comment: Good! Check it in before I change my mind. :-) The words can be tweaked later. > 04b is the same as 04, i just fixed the docstrings that i had missed in > stringlib/transmogrify.h to use 'B' instead of 'S' and say they return a > "modified copy of B" instead of a "string" > > wording could probably be improved further if anyone has any ideas. __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Oct 16 05:47:59 2007 From: report at bugs.python.org (Guido van Rossum) Date: Tue, 16 Oct 2007 03:47:59 -0000 Subject: [issue1267] Py3K cannot run as ``python -S`` In-Reply-To: <1192500685.39.0.29214068182.issue1267@psf.upfronthosting.co.za> Message-ID: Guido van Rossum added the comment: > I've carefully checked and tested the initstdio() method. I'm sure that > I've catched every edged case. The unit tests pass w/o complains. > > I've also added a PyErr_Display() call to Py_FatalError(). It's still > hard to understand an error in io.py but at least the dependency on > site.py is removed. Very cool! Some final suggestions: + Py_FatalError("Py_Initialize: can't initialize sys standard" + "streams"); Break this differently: Py_FatalError( "Py_........"); Don't call open() with keyword arg for newline="\r"; open() takes positional args too. This is done specifically to simplify life for C code calling it. :-) Perhaps one of the PyFunction_Call(..) variants makes it easier to call it without having to explicitly construct the tuple for the argument list. (All this because you're leaking the value of PyString_FromString("\n"). :-) I would change the error handling to avoid the 'finally' label, like this: if (0) { error: status = -1; Py_XDECREF(args); } I would add a comment "see initstdio() in pythonrun.c" to the OpenWrapper class, which otherwise looks a bit mysterious (as it's not used anywhere in the Python code). Thanks for doing this!!! __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Oct 16 05:59:13 2007 From: report at bugs.python.org (Robert Collins) Date: Tue, 16 Oct 2007 03:59:13 -0000 Subject: [issue1259] string find and rfind methods give a TypeError that is misleading Message-ID: <1192507153.75.0.598829968885.issue1259@psf.upfronthosting.co.za> Robert Collins added the comment: > The error message is wrong: it's a TypeError, but the message should say > something like... > > TypeError: slice indices must be integers or have an __index__ method This would be a false message, as, as my report demonstrated, slice indices *can* be None. And there is a very good reason for accepting None in the second parameter in slice notation as there is no value for '-0' to represent the end of the region being sliced, and None meaning 'default' fills that need most effectively. Surely the right fix is as Barry noted, to handle None correctly within this function? __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Oct 16 06:05:37 2007 From: report at bugs.python.org (Mike Klaas) Date: Tue, 16 Oct 2007 04:05:37 -0000 Subject: [issue1663329] subprocess/popen close_fds perform poor if SC_OPEN_MAX is hi Message-ID: <1192507537.66.0.367321336905.issue1663329@psf.upfronthosting.co.za> Mike Klaas added the comment: This problem has also afflicted us. Attached is a patch which adds closerange(fd_low, fd_high) to the posix (and consequently os) module, and modifies subprocess to use it. Patch is against trunk but should work for 2.5maint. I don't really think that this is useful enough to add to the public api, but it results in a huge performance benefit for subprocess: [python-trunk]$ ./python -m timeit -s 'import python_close' 'python_close.go(100000)' 10 loops, best of 3: 358 msec per loop [python-trunk]$ ./python -m timeit -s 'import os' 'os.closerange(4, 100000)' 10 loops, best of 3: 20.7 msec per loop [python-trunk]$ ./python -m timeit -s 'import python_close' 'python_close.go(300000)' 10 loops, best of 3: 1.05 sec per loop [python-trunk]$ ./python -m timeit -s 'import os' 'os.closerange(4, 300000)'10 loops, best of 3: 63 msec per loop [python-trunk]$ cat python_close.py import os, sys def go(N): for i in xrange(4, N): try: os.close(i) except: pass ---------- nosy: +klaas _____________________________________ Tracker _____________________________________ -------------- next part -------------- A non-text attachment was scrubbed... Name: posix_closerange.patch Type: application/octet-stream Size: 1915 bytes Desc: not available Url : http://mail.python.org/pipermail/python-bugs-list/attachments/20071016/e59cde84/attachment.obj From report at bugs.python.org Tue Oct 16 07:04:17 2007 From: report at bugs.python.org (Mike Klaas) Date: Tue, 16 Oct 2007 05:04:17 -0000 Subject: [issue1663329] subprocess/popen close_fds perform poor if SC_OPEN_MAX is hi Message-ID: <1192511057.42.0.788094169822.issue1663329@psf.upfronthosting.co.za> Mike Klaas added the comment: I see that some spaces crept in to the patch. I can fix that (and perhaps rename the function to start with an underscore) if desired. _____________________________________ Tracker _____________________________________ From report at bugs.python.org Tue Oct 16 07:12:40 2007 From: report at bugs.python.org (Mike Klaas) Date: Tue, 16 Oct 2007 05:12:40 -0000 Subject: [issue1663329] subprocess/popen close_fds perform poor if SC_OPEN_MAX is hi Message-ID: <1192511560.73.0.883248354399.issue1663329@psf.upfronthosting.co.za> Mike Klaas added the comment: Finally, I did not include any platform-specific optimizations, as I don't have AIX or solaris boxes on which to test them (and they can easily be added later). An order-mag speedup on all *nix platforms is a good start. _____________________________________ Tracker _____________________________________ From report at bugs.python.org Tue Oct 16 07:19:31 2007 From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=) Date: Tue, 16 Oct 2007 05:19:31 -0000 Subject: [issue1663329] subprocess/popen close_fds perform poor if SC_OPEN_MAX is hi Message-ID: <1192511971.38.0.631989336943.issue1663329@psf.upfronthosting.co.za> Changes by Martin v. L?wis: ---------- keywords: +patch _____________________________________ Tracker _____________________________________ From report at bugs.python.org Tue Oct 16 07:27:02 2007 From: report at bugs.python.org (Christian Heimes) Date: Tue, 16 Oct 2007 05:27:02 -0000 Subject: [issue1267] Py3K cannot run as ``python -S`` In-Reply-To: Message-ID: <47144BA0.90702@cheimes.de> Christian Heimes added the comment: Guido van Rossum wrote: > Don't call open() with keyword arg for newline="\r"; open() takes > positional args too. This is done specifically to simplify life for C > code calling it. :-) Perhaps one of the PyFunction_Call(..) variants > makes it easier to call it without having to explicitly construct the > tuple for the argument list. (All this because you're leaking the > value of PyString_FromString("\n"). :-) I need a way to open a file with a specific encoding for imp.find_module(), too. I found PyFile_FromFile(). It uses io.open but it doesn't accept the additional arguments. I like to add another function PyFile_FromFileEx() to the API. PyObject * PyFile_FromFileEx(FILE *fp, char *name, char *mode, int (*close)(FILE *), int buffering, char *encoding, char *newline) Some people may also miss the PyFile_FromString() function but that's a different story. With the my new function I can create sys.stdin with: PyFile_FromFileEx(stdin, "", "r", fclose, -1, NULL, "\n") I kinda like it :) > I would change the error handling to avoid the 'finally' label, like this: > > if (0) { > error: > status = -1; > Py_XDECREF(args); > } Wow, that's tricky. :) > I would add a comment "see initstdio() in pythonrun.c" to the > OpenWrapper class, which otherwise looks a bit mysterious (as it's not > used anywhere in the Python code). That sounds like a good idea! The code for const char *PyTokenizer_FindEncoding(FILE *fp) and imp.find_module() is also finished and works. Christian __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Oct 16 07:40:39 2007 From: report at bugs.python.org (Christian Heimes) Date: Tue, 16 Oct 2007 05:40:39 -0000 Subject: [issue1267] Py3K cannot run as ``python -S`` Message-ID: <1192513239.44.0.0415869004695.issue1267@psf.upfronthosting.co.za> Christian Heimes added the comment: The patch is a combined patch for the imp.find_module() problem and initstdio. Both patches depend on the new PyFile_FromFileEx() function. I hope you don't mind. __________________________________ Tracker __________________________________ -------------- next part -------------- A non-text attachment was scrubbed... Name: py3k_initstdio_impfindmodule.patch Type: text/x-diff Size: 11452 bytes Desc: not available Url : http://mail.python.org/pipermail/python-bugs-list/attachments/20071016/d233b4aa/attachment.patch From report at bugs.python.org Tue Oct 16 08:33:22 2007 From: report at bugs.python.org (Gregory P. Smith) Date: Tue, 16 Oct 2007 06:33:22 -0000 Subject: [issue1261] PEP 3137: make bytesobject.c methods Message-ID: <1192516402.31.0.899100878596.issue1261@psf.upfronthosting.co.za> Gregory P. Smith added the comment: Committed revision 58493 ---------- resolution: -> accepted status: open -> closed __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Oct 16 08:33:39 2007 From: report at bugs.python.org (Gregory P. Smith) Date: Tue, 16 Oct 2007 06:33:39 -0000 Subject: [issue1261] PEP 3137: make bytesobject.c methods Message-ID: <1192516419.44.0.63803545592.issue1261@psf.upfronthosting.co.za> Changes by Gregory P. Smith: __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Oct 16 09:29:10 2007 From: report at bugs.python.org (Ulrich Weber) Date: Tue, 16 Oct 2007 07:29:10 -0000 Subject: [issue1285] setp.py error "The process cannot access the file ..." Message-ID: <1192519749.91.0.34801949524.issue1285@psf.upfronthosting.co.za> New submission from Ulrich Weber: When creating a windows installer using setup.py an error message is displayed: "error: c:\docume~1\uweber\loca1s~1\temp\tmppnj1gz .zip: The process cannot access the file because it is being used by another process". The installer is created nevertheless and seems to work fine. I am using Python 2.5.1 on WinXP SP2. ---------- components: Distutils messages: 56496 nosy: uweber4711 severity: normal status: open title: setp.py error "The process cannot access the file ..." type: behavior __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Oct 16 13:59:57 2007 From: report at bugs.python.org (Yitz Gale) Date: Tue, 16 Oct 2007 11:59:57 -0000 Subject: [issue1286] fileinput, StringIO, and cStringIO do not support the with protocol Message-ID: <1192535997.09.0.645609216663.issue1286@psf.upfronthosting.co.za> Changes by Yitz Gale: ---------- components: Extension Modules nosy: ygale severity: normal status: open title: fileinput, StringIO, and cStringIO do not support the with protocol type: behavior versions: Python 2.5, Python 2.6, Python 3.0 __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Oct 16 14:42:36 2007 From: report at bugs.python.org (Yitz Gale) Date: Tue, 16 Oct 2007 12:42:36 -0000 Subject: [issue1286] fileinput, StringIO, and cStringIO do not support the with protocol Message-ID: <1192538556.96.0.72107595061.issue1286@psf.upfronthosting.co.za> New submission from Yitz Gale: The standard idiom for opening a file is now with open... So I think it should be a goal that this should work with any built-in file-like object that needs to be closed, without having to explicitly wrap it in closing(). It certainly should work for fileinput and StringIO - since these really are files, in some sense. __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Oct 16 14:45:03 2007 From: report at bugs.python.org (Wummel) Date: Tue, 16 Oct 2007 12:45:03 -0000 Subject: [issue1259] string find and rfind methods give a TypeError that is misleading Message-ID: <1192538703.2.0.314199224104.issue1259@psf.upfronthosting.co.za> Wummel added the comment: I also hit this bug. The .index() methods have the same issue, as well as the methods in the string and strop modules: >>> "123".index("2", None) Traceback (most recent call last): File "", line 1, in ? TypeError: slice indices must be integers or None >> import strop, string >>> strop.rfind("123", "2", None) Traceback (most recent call last): File "", line 1, in ? TypeError: an integer is required >>> string.rfind("123", "2", None) Traceback (most recent call last): File "", line 1, in ? File "/usr/lib/python2.4/string.py", line 374, in rfind return s.rfind(*args) TypeError: slice indices must be integers or None >>> ---------- nosy: +calvin __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Oct 16 19:55:23 2007 From: report at bugs.python.org (Christian Heimes) Date: Tue, 16 Oct 2007 17:55:23 -0000 Subject: [issue1267] Py3K cannot run as ``python -S`` Message-ID: <1192557323.74.0.226441796675.issue1267@psf.upfronthosting.co.za> Christian Heimes added the comment: Changes since last patch: * removed unused import of open in initstdio() * fixed infinite loop in PyTokenizer_FindEncoding() by checking tok-done == E_OK __________________________________ Tracker __________________________________ -------------- next part -------------- A non-text attachment was scrubbed... Name: py3k_initstdio_impfindmodule2.patch Type: text/x-diff Size: 11394 bytes Desc: not available Url : http://mail.python.org/pipermail/python-bugs-list/attachments/20071016/44230e2b/attachment.patch From report at bugs.python.org Tue Oct 16 19:55:49 2007 From: report at bugs.python.org (Gustavo Niemeyer) Date: Tue, 16 Oct 2007 17:55:49 -0000 Subject: [issue1287] os.environ.pop doesn't work Message-ID: <1192557349.01.0.0540058950355.issue1287@psf.upfronthosting.co.za> New submission from Gustavo Niemeyer: >>> import os >>> os.system("echo $ASD") 0 >>> os.environ["ASD"] = "asd" >>> os.system("echo $ASD") asd 0 >>> os.environ.pop("ASD") 'asd' >>> os.system("echo $ASD") asd 0 __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Oct 16 20:13:58 2007 From: report at bugs.python.org (Guido van Rossum) Date: Tue, 16 Oct 2007 18:13:58 -0000 Subject: [issue1258] Removal of basestring type Message-ID: <1192558438.14.0.736604303352.issue1258@psf.upfronthosting.co.za> Guido van Rossum added the comment: Committed revision 58495. Thanks Christian!!! ---------- resolution: -> accepted status: open -> closed __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Oct 16 19:55:11 2007 From: report at bugs.python.org (Gustavo Niemeyer) Date: Tue, 16 Oct 2007 17:55:11 -0000 Subject: [issue1287] os.environ.pop doesn't work Message-ID: <1192557310.97.0.899369581443.issue1287@psf.upfronthosting.co.za> Changes by Gustavo Niemeyer: ---------- nosy: niemeyer severity: normal status: open title: os.environ.pop doesn't work versions: Python 2.1.1, Python 2.1.2, Python 2.2, Python 2.2.1, Python 2.2.2, Python 2.2.3, Python 2.3, Python 2.4, Python 2.5, Python 2.6, Python 3.0 __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Oct 16 20:33:21 2007 From: report at bugs.python.org (Christian Heimes) Date: Tue, 16 Oct 2007 18:33:21 -0000 Subject: [issue1267] Py3K cannot run as ``python -S`` In-Reply-To: <1192557323.74.0.226441796675.issue1267@psf.upfronthosting.co.za> Message-ID: <471503ED.7010305@cheimes.de> Christian Heimes added the comment: Christian Heimes wrote: > * removed unused import of open in initstdio() > * fixed infinite loop in PyTokenizer_FindEncoding() by checking > tok-done == E_OK I found another bug in Python/import.c:call_find_method. The function mustn't set an encoding of ftp->mode contains 'b' for binary. if (strchr(fdp->mode, 'b') == NULL) { /* Python text file, get encoding from tokenizer */ encoding = PyTokenizer_FindEncoding(fp); encoding = (encoding != NULL) ? encoding : PyUnicode_GetDefaultEncoding(); } Christian __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Oct 16 20:43:27 2007 From: report at bugs.python.org (Guido van Rossum) Date: Tue, 16 Oct 2007 18:43:27 -0000 Subject: [issue1267] Py3K cannot run as ``python -S`` In-Reply-To: <471503ED.7010305@cheimes.de> Message-ID: Guido van Rossum added the comment: Does this mean I should hold off reviewing the patch? On 10/16/07, Christian Heimes wrote: > > Christian Heimes added the comment: > > Christian Heimes wrote: > > * removed unused import of open in initstdio() > > * fixed infinite loop in PyTokenizer_FindEncoding() by checking > > tok-done == E_OK > > I found another bug in Python/import.c:call_find_method. The function > mustn't set an encoding of ftp->mode contains 'b' for binary. > > if (strchr(fdp->mode, 'b') == NULL) { > /* Python text file, get encoding from tokenizer */ > encoding = PyTokenizer_FindEncoding(fp); > encoding = (encoding != NULL) ? encoding : > PyUnicode_GetDefaultEncoding(); > } > > Christian > > __________________________________ > Tracker > > __________________________________ > __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Oct 16 20:51:19 2007 From: report at bugs.python.org (Christian Heimes) Date: Tue, 16 Oct 2007 18:51:19 -0000 Subject: [issue1267] Py3K cannot run as ``python -S`` Message-ID: <1192560679.01.0.595682792599.issue1267@psf.upfronthosting.co.za> Christian Heimes added the comment: Update since last patch * removed unnecessary const from const char* PyTokenizer_FindEncoding(FILE *fp) * Fixed bug in find_module whith binary files Please review the patch. __________________________________ Tracker __________________________________ -------------- next part -------------- A non-text attachment was scrubbed... Name: py3k_initstdio_impfindmodule3.patch Type: text/x-diff Size: 11468 bytes Desc: not available Url : http://mail.python.org/pipermail/python-bugs-list/attachments/20071016/fbaa9f78/attachment.patch From report at bugs.python.org Tue Oct 16 21:07:05 2007 From: report at bugs.python.org (Raghuram Devarakonda) Date: Tue, 16 Oct 2007 19:07:05 -0000 Subject: [issue1287] os.environ.pop doesn't work Message-ID: <1192561625.69.0.341116279226.issue1287@psf.upfronthosting.co.za> Raghuram Devarakonda added the comment: The following patch solves the problem (with the latest from trunk). I only tested on Linux. I couldn't reproduce the problem with latest py3k (again, on Linux). =================================================================== --- Lib/os.py (revision 58221) +++ Lib/os.py (working copy) @@ -446,6 +446,9 @@ def __delitem__(self, key): unsetenv(key) del self.data[key.upper()] + def pop(self, key): + unsetenv(key) + return UserDict.IterableUserDict.pop(self, key) def clear(self): for key in self.data.keys(): unsetenv(key) @@ -513,6 +516,9 @@ del self.data[key] def copy(self): return dict(self) + def pop(self, key): + unsetenv(key) + return UserDict.IterableUserDict.pop(self, key) environ = _Environ(environ) ---------- nosy: +draghuram __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Oct 16 21:11:29 2007 From: report at bugs.python.org (Michael Torrie) Date: Tue, 16 Oct 2007 19:11:29 -0000 Subject: [issue1205] urllib fail to read URL contents, urllib2 crash Python Message-ID: <1192561889.42.0.423078900274.issue1205@psf.upfronthosting.co.za> Michael Torrie added the comment: I had a situation where I was talking to a Sharp MFD printer. Their web server apparently does not serve chunked data properly. However the patch posted here put it in an infinite loop. Somewhere around line 525 in the python 2.4 version of httplib.py, I had to make it look like this: while True: line = self.fp.readline() if line == '\r\n' or not line: break I added "or not line" to the if statement. The blank line in the chunked http was confusing the _last_chunk thing, but even when it was set to zero, since there was no more data, this loop to eat up crlfs was never ending. Is this really a proper fix? I'm in favor of changing urllib2 to be less strict because, despite the RFCs, we're stuck talking to all kinds of web servers (embedded ones in particular) that simply can't easily be changed. ---------- nosy: +torriem __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Oct 16 22:27:31 2007 From: report at bugs.python.org (Adam Doherty) Date: Tue, 16 Oct 2007 20:27:31 -0000 Subject: [issue1288] dict.fromkeys - Odd logic when passing second dict.fromkeys as value Message-ID: <1192566451.3.0.9845024568.issue1288@psf.upfronthosting.co.za> New submission from Adam Doherty: Hello: I'm am trying to conduct some tests on a list of data that checks for the position of values in list elements using the bisect module. To store the results of these tests for output to a template I have build a dictionary with 47 keys the values of which are dictionaries themselves. These inner dictionaries contain 7 keys that initially are valued at zero. Looping through the data in my list I check for values from 1 to 47 and if I find the value I am looking for I lookup it's position in the row using the bisect module. Using the current value I am looking for and the position returned from bisect I increase the value in the matching dictionary key value position by 1. Now for speed I have built the dictionary using d = dict.fromkeys(xrange(1,48),dict.fromkeys(xrange(1,8),0)) as this gives the desired result. Unfortunately when I run my test for values each value in the dictionary is listed as the total number of rows in the data list. This is not the desired result which is correctly achieved using: d = {} for x in xrange(1,48): d[x] = dict.fromkeys(xrange(1,8),0) I have included output from IDLE to demonstrate the problem. ---------- components: Interpreter Core files: problem-report.txt messages: 56507 nosy: dohertywa severity: normal status: open title: dict.fromkeys - Odd logic when passing second dict.fromkeys as value type: behavior versions: Python 2.3, Python 2.4, Python 2.5 __________________________________ Tracker __________________________________ -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: problem-report.txt Url: http://mail.python.org/pipermail/python-bugs-list/attachments/20071016/bdd5f55a/attachment.txt From report at bugs.python.org Wed Oct 17 00:35:47 2007 From: report at bugs.python.org (Raymond Hettinger) Date: Tue, 16 Oct 2007 22:35:47 -0000 Subject: [issue1288] dict.fromkeys - Odd logic when passing second dict.fromkeys as value Message-ID: <1192574147.66.0.461025822352.issue1288@psf.upfronthosting.co.za> Raymond Hettinger added the comment: This isn't a bug. Writing "dict.fromkeys(xrange(1,48),dict.fromkeys(xrange(1,8),0))" results in the inner expression being evaluated just once and then passed to the outer function call as a fully evaluated argument. As a result, the *same* dictionary is being used over and over again. People commonly encounter similar issue when they try to create initialized list-of-lists with something like s=[[0]*10] which repeats ten of the *same* lists. Instead they should write something like: s=[[0] for i in range(10)] which creates *distinct* inner lists. For you application, consider using a defaultdict which can call a function as needed to create new, distinct values: d = defaultdict(lambda: dict.fromkeys(xrange(1,8), 0)) ---------- nosy: +rhettinger resolution: -> invalid status: open -> closed __________________________________ Tracker __________________________________ From report at bugs.python.org Wed Oct 17 02:35:28 2007 From: report at bugs.python.org (Brett Cannon) Date: Wed, 17 Oct 2007 00:35:28 -0000 Subject: [issue1631171] implement warnings module in C Message-ID: <1192581328.79.0.174866242166.issue1631171@psf.upfronthosting.co.za> Brett Cannon added the comment: Attached is a new version of _warnings.c that checks to see if 'warnings' has been imported, and if so, uses the attributes from that module for onceregistry and 'filters'. I did it in such a way so that 'warnings' is in no way required nor imported through checking. If Neal does a code review and OKs the approach then it can also be implemented for showwarning() which should make testing test_warnings possible. =) Then we can start testing that changes to the module attributes actually affect things properly. ---------- assignee: brett.cannon -> nnorwitz _____________________________________ Tracker _____________________________________ -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: _warnings.c Url: http://mail.python.org/pipermail/python-bugs-list/attachments/20071017/e4874763/attachment-0001.txt From report at bugs.python.org Thu Oct 18 03:06:05 2007 From: report at bugs.python.org (Nathan Haines) Date: Thu, 18 Oct 2007 01:06:05 -0000 Subject: [issue1289] Typo in Context Manager Types Message-ID: <1192669565.11.0.542171346949.issue1289@psf.upfronthosting.co.za> New submission from Nathan Haines: In the first sentence in the ContextManager.__exit__() section, "exception" is spelled "expection". ---------- components: Documentation messages: 56510 nosy: nhaines severity: normal status: open title: Typo in Context Manager Types type: rfe versions: Python 2.5, Python 2.6, Python 3.0 __________________________________ Tracker __________________________________ From report at bugs.python.org Thu Oct 18 03:58:16 2007 From: report at bugs.python.org (Sharmila Sivakumar) Date: Thu, 18 Oct 2007 01:58:16 -0000 Subject: [issue1290] xml.dom.minidom not able to handle utf-8 data Message-ID: <1192672695.43.0.309092072224.issue1290@psf.upfronthosting.co.za> New submission from Sharmila Sivakumar: I try to load the data in the testdata.txt file into a dom. I tried import xml.dom.minidom as dom data = open('testdata.txt','r').read() mydom = dom.parseString(data) I get the following error >>> mydom.firstChild.childNodes Traceback (most recent call last): File "", line 1, in UnicodeEncodeError: 'ascii' codec can't encode character u'\u2022' in position 18: ordinal not in range(128) So I tried decoding the data and using it but it failed again. >>> mydom2 = dom.parseString(data.decode('utf-8')) Traceback (most recent call last): File "", line 1, in File "/usr/lib/python2.5/site-packages/_xmlplus/dom/minidom.py", line 1925, in parseString return expatbuilder.parseString(string) File "/usr/lib/python2.5/site-packages/_xmlplus/dom/expatbuilder.py", line 942, in parseString return builder.parseString(string) File "/usr/lib/python2.5/site-packages/_xmlplus/dom/expatbuilder.py", line 223, in parseString parser.Parse(string, True) UnicodeEncodeError: 'ascii' codec can't encode character u'\u014d' in position 173: ordinal not in range(128) I am willing to fix this myself if I'm given the permission. ---------- components: Interpreter Core, Unicode, XML files: testdata.txt messages: 56511 nosy: sharmila severity: normal status: open title: xml.dom.minidom not able to handle utf-8 data type: compile error versions: Python 2.5 Added file: http://bugs.python.org/file8558/testdata.txt __________________________________ Tracker __________________________________ -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: testdata.txt Url: http://mail.python.org/pipermail/python-bugs-list/attachments/20071018/dc3ca282/attachment.txt From report at bugs.python.org Thu Oct 18 05:17:02 2007 From: report at bugs.python.org (Facundo Batista) Date: Thu, 18 Oct 2007 03:17:02 -0000 Subject: [issue1580738] httplib hangs reading too much data Message-ID: <1192677422.4.0.88466323872.issue1580738@psf.upfronthosting.co.za> Facundo Batista added the comment: Fixed in rev 58530 (also added a test case) ---------- resolution: -> fixed status: open -> closed _____________________________________ Tracker _____________________________________ From report at bugs.python.org Thu Oct 18 05:27:59 2007 From: report at bugs.python.org (Facundo Batista) Date: Thu, 18 Oct 2007 03:27:59 -0000 Subject: [issue1289] Typo in Context Manager Types Message-ID: <1192678079.42.0.879687146842.issue1289@psf.upfronthosting.co.za> Facundo Batista added the comment: Where this happens? In the documentation? In the PEP? Do you have the URL where you found this? ---------- nosy: +facundobatista __________________________________ Tracker __________________________________ From report at bugs.python.org Thu Oct 18 05:36:31 2007 From: report at bugs.python.org (Facundo Batista) Date: Thu, 18 Oct 2007 03:36:31 -0000 Subject: [issue1290] xml.dom.minidom not able to handle utf-8 data Message-ID: <1192678591.15.0.210411295055.issue1290@psf.upfronthosting.co.za> Facundo Batista added the comment: Downloaded the testdata.txt file, and yes, it's UTF-8: facundo at pomcat:~/devel$ file testdata.txt testdata.txt: UTF-8 Unicode text But I opened it perfectly! Python 2.5.1 (r251:54863, May 2 2007, 16:56:35) [GCC 4.1.2 (Ubuntu 4.1.2-0ubuntu4)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> import xml.dom.minidom as dom >>> data = open('testdata.txt','r').read() >>> mydom = dom.parseString(data) >>> mydom >>> In which platform you're working? And yes, you have absolute permission to fix it, patchs are always welcomed! ---------- nosy: +facundobatista resolution: -> works for me status: open -> closed __________________________________ Tracker __________________________________ From report at bugs.python.org Thu Oct 18 05:37:08 2007 From: report at bugs.python.org (Nathan Haines) Date: Thu, 18 Oct 2007 03:37:08 -0000 Subject: [issue1289] Typo in Context Manager Types Message-ID: <1192678628.54.0.0473246605015.issue1289@psf.upfronthosting.co.za> Nathan Haines added the comment: This typo is in the Python Library Reference manual, section 3.10, for versions 2.5, 2.6, and 3.0. __________________________________ Tracker __________________________________ From report at bugs.python.org Thu Oct 18 05:45:33 2007 From: report at bugs.python.org (Facundo Batista) Date: Thu, 18 Oct 2007 03:45:33 -0000 Subject: [issue1289] Typo in Context Manager Types Message-ID: <1192679133.21.0.572127084855.issue1289@psf.upfronthosting.co.za> Facundo Batista added the comment: Fixed in rev 58531. ---------- resolution: -> fixed status: open -> closed __________________________________ Tracker __________________________________ From report at bugs.python.org Thu Oct 18 05:53:34 2007 From: report at bugs.python.org (Neal Norwitz) Date: Thu, 18 Oct 2007 03:53:34 -0000 Subject: [issue1631171] implement warnings module in C In-Reply-To: <1192581328.79.0.174866242166.issue1631171@psf.upfronthosting.co.za> Message-ID: Neal Norwitz added the comment: I think this is good enough for now. The approach will probably stand even if the details change. Go for it! _____________________________________ Tracker _____________________________________ From report at bugs.python.org Thu Oct 18 05:54:02 2007 From: report at bugs.python.org (Neal Norwitz) Date: Thu, 18 Oct 2007 03:54:02 -0000 Subject: [issue1631171] implement warnings module in C Message-ID: <1192679642.7.0.391365352872.issue1631171@psf.upfronthosting.co.za> Changes by Neal Norwitz: ---------- assignee: nnorwitz -> brett.cannon _____________________________________ Tracker _____________________________________ From report at bugs.python.org Thu Oct 18 06:41:15 2007 From: report at bugs.python.org (Sharmila Sivakumar) Date: Thu, 18 Oct 2007 04:41:15 -0000 Subject: [issue1290] xml.dom.minidom not able to handle utf-8 data In-Reply-To: <1192678591.15.0.210411295055.issue1290@psf.upfronthosting.co.za> Message-ID: <23205fa00710172141n709133cs12fa051c335978f5@mail.gmail.com> Sharmila Sivakumar added the comment: Thanks for your quick response Facundo. I'm working on Ubuntu 7.04, python 2.5.1 Python 2.5.1 (r251:54863, May 2 2007, 16:56:35) [GCC 4.1.2 (Ubuntu 4.1.2-0ubuntu4)] on linux2 This error occurs when the default encoding is 'ascii'. When I change the default encoding to 'utf-8' it works for me too. Is, by any chance, your default encoding 'utf-8'? On 10/18/07, Facundo Batista wrote: > > > Facundo Batista added the comment: > > Downloaded the testdata.txt file, and yes, it's UTF-8: > > facundo at pomcat:~/devel$ file testdata.txt > testdata.txt: UTF-8 Unicode text > > But I opened it perfectly! > > Python 2.5.1 (r251:54863, May 2 2007, 16:56:35) > [GCC 4.1.2 (Ubuntu 4.1.2-0ubuntu4)] on linux2 > Type "help", "copyright", "credits" or "license" for more information. > >>> import xml.dom.minidom as dom > >>> data = open('testdata.txt','r').read() > >>> mydom = dom.parseString(data) > >>> mydom > > >>> > > In which platform you're working? > > And yes, you have absolute permission to fix it, patchs are always > welcomed! > > ---------- > nosy: +facundobatista > resolution: -> works for me > status: open -> closed > > __________________________________ > Tracker > > __________________________________ > Added file: http://bugs.python.org/file8559/unnamed __________________________________ Tracker __________________________________ -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: unnamed Url: http://mail.python.org/pipermail/python-bugs-list/attachments/20071018/06bfbbb1/attachment.txt From report at bugs.python.org Thu Oct 18 06:45:14 2007 From: report at bugs.python.org (Sharmila Sivakumar) Date: Thu, 18 Oct 2007 04:45:14 -0000 Subject: [issue1290] xml.dom.minidom not able to handle utf-8 data In-Reply-To: <23205fa00710172141n709133cs12fa051c335978f5@mail.gmail.com> Message-ID: <23205fa00710172145p202e1614t9d9a816aa402975@mail.gmail.com> Sharmila Sivakumar added the comment: Oops Facundo, that will work. It actually fails * after the dom construction* when you do mydom.firstChild.childNodes I request you to try it again. The prob is there is some encoding and decoding done within the parser, and it uses the default encoding 'ascii'. This fails for utf-8 data. On 10/18/07, Sharmila Sivakumar wrote: > > > Sharmila Sivakumar added the comment: > > Thanks for your quick response Facundo. > > I'm working on Ubuntu 7.04, python 2.5.1 > Python 2.5.1 (r251:54863, May 2 2007, 16:56:35) > [GCC 4.1.2 (Ubuntu 4.1.2-0ubuntu4)] on linux2 > > This error occurs when the default encoding is 'ascii'. When I change the > default encoding to 'utf-8' it works for me too. Is, by any chance, your > default encoding 'utf-8'? > > On 10/18/07, Facundo Batista wrote: > > > > > > Facundo Batista added the comment: > > > > Downloaded the testdata.txt file, and yes, it's UTF-8: > > > > facundo at pomcat:~/devel$ file testdata.txt > > testdata.txt: UTF-8 Unicode text > > > > But I opened it perfectly! > > > > Python 2.5.1 (r251:54863, May 2 2007, 16:56:35) > > [GCC 4.1.2 (Ubuntu 4.1.2-0ubuntu4)] on linux2 > > Type "help", "copyright", "credits" or "license" for more information. > > >>> import xml.dom.minidom as dom > > >>> data = open('testdata.txt','r').read() > > >>> mydom = dom.parseString(data) > > >>> mydom > > > > >>> > > > > In which platform you're working? > > > > And yes, you have absolute permission to fix it, patchs are always > > welcomed! > > > > ---------- > > nosy: +facundobatista > > resolution: -> works for me > > status: open -> closed > > > > __________________________________ > > Tracker > > > > __________________________________ > > > > Added file: http://bugs.python.org/file8559/unnamed > > __________________________________ > Tracker > > __________________________________ > Added file: http://bugs.python.org/file8560/unnamed __________________________________ Tracker __________________________________ -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: unnamed Url: http://mail.python.org/pipermail/python-bugs-list/attachments/20071018/ba96f051/attachment-0001.txt From report at bugs.python.org Thu Oct 18 11:13:43 2007 From: report at bugs.python.org (Matthias Klose) Date: Thu, 18 Oct 2007 09:13:43 -0000 Subject: [issue1291] test_resource fails on recent linux systems ( Message-ID: <1192698822.84.0.082608978163.issue1291@psf.upfronthosting.co.za> New submission from Matthias Klose: The test_resource test fails at least on all non x86 linux systems; the test case notes: # Now check to see what happens when the RLIMIT_FSIZE is small. Some # versions of Python were terminated by an uncaught SIGXFSZ, but # pythonrun.c has been fixed to ignore that exception. If so, the # write() should return EFBIG when the limit is exceeded. however instead of EFBIG errno is set to ESPIPE, causing an IOException. and letting the test fail. ---------- components: Extension Modules files: tst.c messages: 56520 nosy: doko severity: normal status: open title: test_resource fails on recent linux systems ( type: behavior versions: Python 2.5 Added file: http://bugs.python.org/file8561/tst.c __________________________________ Tracker __________________________________ -------------- next part -------------- A non-text attachment was scrubbed... Name: tst.c Type: text/x-csrc Size: 958 bytes Desc: not available Url : http://mail.python.org/pipermail/python-bugs-list/attachments/20071018/0f415ca4/attachment.c From report at bugs.python.org Thu Oct 18 11:15:03 2007 From: report at bugs.python.org (Matthias Klose) Date: Thu, 18 Oct 2007 09:15:03 -0000 Subject: [issue1291] test_resource fails on recent linux systems ( Message-ID: <1192698903.93.0.335395092221.issue1291@psf.upfronthosting.co.za> Matthias Klose added the comment: $ python Lib/test/test_resource.py True Traceback (most recent call last): File "Lib/test/test_resource.py", line 42, in f.close() IOError: [Errno 27] File too large __________________________________ Tracker __________________________________ From report at bugs.python.org Thu Oct 18 11:23:06 2007 From: report at bugs.python.org (Matthias Klose) Date: Thu, 18 Oct 2007 09:23:06 -0000 Subject: [issue1292] libffi needs an update to support mips64, arm and armeabi on linux Message-ID: <1192699386.49.0.555660775493.issue1292@psf.upfronthosting.co.za> New submission from Matthias Klose: libffi needs an update to support mips64, arm and armeabi on linux; the current bits are all available in GCC trunk. as an alternative, those systems should be default to --with-system-ffi, unless this is xplicitely disabled. ---------- assignee: theller components: Extension Modules messages: 56522 nosy: doko, theller severity: normal status: open title: libffi needs an update to support mips64, arm and armeabi on linux type: compile error versions: Python 2.6 __________________________________ Tracker __________________________________ From report at bugs.python.org Thu Oct 18 14:47:42 2007 From: report at bugs.python.org (Guillaume Girard) Date: Thu, 18 Oct 2007 12:47:42 -0000 Subject: [issue1293] Trailing slash in sys.path cause import failure Message-ID: <1192711662.66.0.399172727466.issue1293@psf.upfronthosting.co.za> New submission from Guillaume Girard: On win32, the following code: import sys sys.path.append('../bar/') import bar where the file bar.py is present in ../bar/ will return an import error "No module named bar". Remove the trailing slash and the bar.py is imported correctly. The problem is identical with backslash. This code works in Python 2.4. Not a very serious bug, but it breaks programs working with Python 2.4. ---------- components: Interpreter Core messages: 56523 nosy: guillaumegirard severity: minor status: open title: Trailing slash in sys.path cause import failure type: behavior versions: Python 2.5 __________________________________ Tracker __________________________________ From report at bugs.python.org Thu Oct 18 14:51:56 2007 From: report at bugs.python.org (BULOT) Date: Thu, 18 Oct 2007 12:51:56 -0000 Subject: [issue1294] Management of KeyboardInterrupt in cmd.py Message-ID: <1192711916.5.0.235687394478.issue1294@psf.upfronthosting.co.za> New submission from BULOT: According to me, the Ctrl-C is not managed correctly in cmd.py. Ctrl-C generates a a KeyboardInterrupt exceptions, and only EOFError is managed. I propose to manage KeyboardInterrupt on line 130: print 'are you sure you want to exit? y/n' answer ='' while (answer != 'y') & (answer != 'n'): answer = raw_input() if answer == 'y': exit(0) Here is attached my new cmd.py Hope ti will help. ---------- components: None files: cmd.py messages: 56524 nosy: stephbul severity: normal status: open title: Management of KeyboardInterrupt in cmd.py type: behavior versions: Python 2.5 Added file: http://bugs.python.org/file8562/cmd.py __________________________________ Tracker __________________________________ -------------- next part -------------- A non-text attachment was scrubbed... Name: cmd.py Type: text/x-python Size: 15153 bytes Desc: not available Url : http://mail.python.org/pipermail/python-bugs-list/attachments/20071018/70d5c0e5/attachment.py From report at bugs.python.org Thu Oct 18 17:30:36 2007 From: report at bugs.python.org (Thomas Heller) Date: Thu, 18 Oct 2007 15:30:36 -0000 Subject: [issue1295] logging records cache the result of formatException() Message-ID: <1192721436.77.0.0263561863659.issue1295@psf.upfronthosting.co.za> New submission from Thomas Heller: I needed two logging handlers in my application, one notifiying the user of errors, the other writing errors to a logfile. So I created a custom subclass of logging.Formatter and redefined the formatException() method that returned a summary of the exception like 'ZeroDivisionError' instead of the full traceback. Unfortunately the logging record caches the result of the handler.formatException() call in the exc_text variable, and the formatException() method of the second handler isn't called at all. The attached patch removes the caching and fixes the problem. ---------- components: Library (Lib) files: logging.patch keywords: patch messages: 56525 nosy: theller severity: normal status: open title: logging records cache the result of formatException() type: behavior versions: Python 2.4, Python 2.5, Python 2.6, Python 3.0 Added file: http://bugs.python.org/file8563/logging.patch __________________________________ Tracker __________________________________ -------------- next part -------------- A non-text attachment was scrubbed... Name: logging.patch Type: text/x-patch Size: 1109 bytes Desc: not available Url : http://mail.python.org/pipermail/python-bugs-list/attachments/20071018/78cc6184/attachment-0001.bin From report at bugs.python.org Thu Oct 18 17:46:31 2007 From: report at bugs.python.org (Paul Melis) Date: Thu, 18 Oct 2007 15:46:31 -0000 Subject: [issue1296] optparse's OptionGroup not described Message-ID: <1192722391.31.0.57718526952.issue1296@psf.upfronthosting.co.za> New submission from Paul Melis: The current 2.5 documentation does not seem to describe the OptionGroup feature of the optparse module. In 2003 there was a patch submitted that added a section on OptionGroup ( http://bugs.python.org/issue697941). The issue entry mentions it was accepted, but the current docs do not seem to contain that section. ---------- components: Documentation messages: 56526 nosy: paulmelis severity: normal status: open title: optparse's OptionGroup not described versions: Python 2.5 __________________________________ Tracker __________________________________ From report at bugs.python.org Thu Oct 18 17:52:34 2007 From: report at bugs.python.org (Paul Melis) Date: Thu, 18 Oct 2007 15:52:34 -0000 Subject: [issue1296] optparse's OptionGroup not described Message-ID: <1192722754.08.0.0169407421198.issue1296@psf.upfronthosting.co.za> Paul Melis added the comment: It seems it got edited out when the documentation was overhauled for optik 1.5, in r37468 __________________________________ Tracker __________________________________ From report at bugs.python.org Thu Oct 18 18:54:16 2007 From: report at bugs.python.org (Guido van Rossum) Date: Thu, 18 Oct 2007 16:54:16 -0000 Subject: [issue1291] test_resource fails on recent linux systems ( Message-ID: <1192726456.71.0.88795081119.issue1291@psf.upfronthosting.co.za> Guido van Rossum added the comment: Patch please? ---------- nosy: +gvanrossum __________________________________ Tracker __________________________________ From report at bugs.python.org Thu Oct 18 18:55:53 2007 From: report at bugs.python.org (Guido van Rossum) Date: Thu, 18 Oct 2007 16:55:53 -0000 Subject: [issue1294] Management of KeyboardInterrupt in cmd.py Message-ID: <1192726553.11.0.351781868185.issue1294@psf.upfronthosting.co.za> Guido van Rossum added the comment: Would you mind submitting a patch instead of a whole new file? ---------- nosy: +gvanrossum __________________________________ Tracker __________________________________ From report at bugs.python.org Thu Oct 18 19:01:37 2007 From: report at bugs.python.org (Guido van Rossum) Date: Thu, 18 Oct 2007 17:01:37 -0000 Subject: [issue1295] logging records cache the result of formatException() Message-ID: <1192726897.32.0.660320436746.issue1295@psf.upfronthosting.co.za> Guido van Rossum added the comment: This is tough. On the one hand you are right that different classes that have different formatException() methods aren't treated correctly; on the other hand I think the caching is important for other cases where there are multiple loggers all using the default formatException(). I recommend that instead of getting rid of the cache, you fix your class by overriding format() to reset record.ex c_text and then calling the base class format() method. ---------- nosy: +gvanrossum __________________________________ Tracker __________________________________ From report at bugs.python.org Thu Oct 18 19:06:17 2007 From: report at bugs.python.org (Nick) Date: Thu, 18 Oct 2007 17:06:17 -0000 Subject: [issue1297] pyconfig.h not compatible with MS VC++ Express Edition Message-ID: <1192727177.86.0.467865548072.issue1297@psf.upfronthosting.co.za> New submission from Nick: pyconfig.h checks for _MSC_VER and based on its value decides to include . MS VC++ Express reports _MSC_VER to be 1400 but does _NOT_ have the file basetsd.h. So when including Python.h with the Microsoft VC Express compiler, pyconfig.h will try to include the non existing basetsd.h and compiling fails. ---------- components: Build messages: 56531 nosy: weegreenblobbie severity: normal status: open title: pyconfig.h not compatible with MS VC++ Express Edition type: compile error versions: Python 2.5 __________________________________ Tracker __________________________________ From report at bugs.python.org Thu Oct 18 19:16:50 2007 From: report at bugs.python.org (Nick) Date: Thu, 18 Oct 2007 17:16:50 -0000 Subject: [issue1299] distutils.sysconfig is not cross-platform compatible Message-ID: <1192727810.38.0.522851261061.issue1299@psf.upfronthosting.co.za> New submission from Nick: I'm using scons (www.scons.org) and Python's distutils.sysconfig to determine the correct compiler flags automatically to embed Python into my C++ application. I discovered that distuils.sysconfig is not fully implemented on Windows. Using distutils.sysconfg.get_config_var() or get_config_vars() does not work on the Windows distribution. The above calls will return values for INCLUDEPY LIBDIR LIB on Ubuntu Linux, however, on Windows, these variables are not all declared. These variables should be declared on all platforms so one can automatically get the correct compiler flags needed to embed python in one's C/C++ project. ---------- components: Build messages: 56533 nosy: weegreenblobbie severity: normal status: open title: distutils.sysconfig is not cross-platform compatible type: compile error versions: Python 2.5 __________________________________ Tracker __________________________________ From report at bugs.python.org Thu Oct 18 19:40:55 2007 From: report at bugs.python.org (Andrew Moise) Date: Thu, 18 Oct 2007 17:40:55 -0000 Subject: [issue1300] subprocess.list2cmdline doesn't do pipe symbols Message-ID: <1192729254.96.0.285794085895.issue1300@psf.upfronthosting.co.za> New submission from Andrew Moise: I expected subprocess.list2cmdline() to convert my list of arguments into a command line which results in behavior equivalent to the Unix exec() functions -- that is, that I can safely pass arbitrary characters to it and it'll make it such that those characters are escaped. It looks to me, though, like it doesn't handle the pipe symbol, so that if I call list2cmdline(['echo', 'foo|bar']), I get the command line 'echo foo|bar' instead of 'echo "foo|bar"' as I would expect. If this is actually a result of my misunderstanding (or if it's fixed in a more recent version), please accept my apologies. ---------- components: Windows messages: 56534 nosy: chops at demiurgestudios.com severity: normal status: open title: subprocess.list2cmdline doesn't do pipe symbols type: behavior versions: Python 2.5 __________________________________ Tracker __________________________________ From report at bugs.python.org Thu Oct 18 19:41:54 2007 From: report at bugs.python.org (Guido van Rossum) Date: Thu, 18 Oct 2007 17:41:54 -0000 Subject: [issue1298] Support for z/OS and EBCDIC. Message-ID: <1192729314.77.0.804292823115.issue1298@psf.upfronthosting.co.za> Guido van Rossum added the comment: How important is z/OS? I'm very skeptical of the viability of any OS that uses an encoding that is not a superset of ASCII. ---------- nosy: +gvanrossum __________________________________ Tracker __________________________________ From report at bugs.python.org Thu Oct 18 19:49:35 2007 From: report at bugs.python.org (Thomas Heller) Date: Thu, 18 Oct 2007 17:49:35 -0000 Subject: [issue1295] logging records cache the result of formatException() In-Reply-To: <1192726897.32.0.660320436746.issue1295@psf.upfronthosting.co.za> Message-ID: <47179CAB.7050701@ctypes.org> Thomas Heller added the comment: > > This is tough. On the one hand you are right that different classes that > > have different formatException() methods aren't treated correctly; on > > the other hand I think the caching is important for other cases where > > there are multiple loggers all using the default formatException(). > > > > I recommend that instead of getting rid of the cache, you fix your class > > by overriding format() to reset record.ex c_text and then calling the > > base class format() method. That is what I have been doing although I think that I have to reset record.exc_text also AFTER the call to format() for the following handlers, if any. So, should this issue be closed as 'wont fix' ? __________________________________ Tracker __________________________________ From report at bugs.python.org Thu Oct 18 19:53:25 2007 From: report at bugs.python.org (Guido van Rossum) Date: Thu, 18 Oct 2007 17:53:25 -0000 Subject: [issue1295] logging records cache the result of formatException() In-Reply-To: <47179CAB.7050701@ctypes.org> Message-ID: Guido van Rossum added the comment: I think so. On 10/18/07, Thomas Heller wrote: > > Thomas Heller added the comment: > > > > This is tough. On the one hand you are right that different classes that > > > have different formatException() methods aren't treated correctly; on > > > the other hand I think the caching is important for other cases where > > > there are multiple loggers all using the default formatException(). > > > > > > I recommend that instead of getting rid of the cache, you fix your class > > > by overriding format() to reset record.ex c_text and then calling the > > > base class format() method. > > That is what I have been doing although I think that I have to reset > record.exc_text also AFTER the call to format() for the following > handlers, if any. > > So, should this issue be closed as 'wont fix' ? > > __________________________________ > Tracker > > __________________________________ > __________________________________ Tracker __________________________________ From report at bugs.python.org Thu Oct 18 20:03:20 2007 From: report at bugs.python.org (Thomas Heller) Date: Thu, 18 Oct 2007 18:03:20 -0000 Subject: [issue1295] logging records cache the result of formatException() Message-ID: <1192730600.23.0.983845807365.issue1295@psf.upfronthosting.co.za> Thomas Heller added the comment: I think that a warning or an example in the docs would be nice, but I have no time to make a patch for that. ---------- resolution: -> wont fix status: open -> closed __________________________________ Tracker __________________________________ From report at bugs.python.org Thu Oct 18 20:54:13 2007 From: report at bugs.python.org (Ben Sherman) Date: Thu, 18 Oct 2007 18:54:13 -0000 Subject: [issue1281] typo in documentation - lib ref section 14.3.3.4 Message-ID: <1192733653.8.0.956935095375.issue1281@psf.upfronthosting.co.za> Ben Sherman added the comment: There were typos in my original bug report - the typo in the documentation is still a bug. Ugh, someone must have brewed decaf. ---------- title: type in docutmentation - lib ref section 14.3.3.4 -> typo in documentation - lib ref section 14.3.3.4 __________________________________ Tracker __________________________________ From report at bugs.python.org Thu Oct 18 21:46:37 2007 From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=) Date: Thu, 18 Oct 2007 19:46:37 -0000 Subject: [issue1297] pyconfig.h not compatible with MS VC++ Express Edition Message-ID: <1192736797.4.0.461390085559.issue1297@psf.upfronthosting.co.za> Martin v. L?wis added the comment: What version of VC++ Express are you specifically referring to? ---------- nosy: +loewis __________________________________ Tracker __________________________________ From report at bugs.python.org Thu Oct 18 21:47:58 2007 From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=) Date: Thu, 18 Oct 2007 19:47:58 -0000 Subject: [issue1299] distutils.sysconfig is not cross-platform compatible Message-ID: <1192736878.98.0.368615959791.issue1299@psf.upfronthosting.co.za> Martin v. L?wis added the comment: Would you like to work on a patch? ---------- nosy: +loewis __________________________________ Tracker __________________________________ From report at bugs.python.org Thu Oct 18 22:43:20 2007 From: report at bugs.python.org (Raghuram Devarakonda) Date: Thu, 18 Oct 2007 20:43:20 -0000 Subject: [issue1290] xml.dom.minidom not able to handle utf-8 data Message-ID: <1192740200.57.0.746600647606.issue1290@psf.upfronthosting.co.za> Raghuram Devarakonda added the comment: When I run the code in a script, I don't get the error. *************** marvin:cpython$ python Python 2.5 (r25:51908, Jan 24 2007, 12:48:15) [GCC 4.1.0 (SUSE Linux)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> import xml.dom.minidom as dom >>> data = open('testdata.txt','r').read() >>> mydom = dom.parseString(data) >>> mydom.firstChild.childNodes Traceback (most recent call last): File "", line 1, in UnicodeEncodeError: 'ascii' codec can't encode character u'\u2022' in position 18: ordinal not in range(128) >>> import sys >>> sys.getdefaultencoding() 'ascii' marvin:cpython$ python dom.py marvin:cpython$ *************** Can you try and see if you can run it from the script too? ---------- nosy: +draghuram __________________________________ Tracker __________________________________ From report at bugs.python.org Thu Oct 18 22:44:24 2007 From: report at bugs.python.org (Raghuram Devarakonda) Date: Thu, 18 Oct 2007 20:44:24 -0000 Subject: [issue1290] xml.dom.minidom not able to handle utf-8 data Message-ID: <1192740264.87.0.601301751126.issue1290@psf.upfronthosting.co.za> Raghuram Devarakonda added the comment: I forgot to show dom.py source. marvin:cpython$ cat dom.py import xml.dom.minidom as dom data = open('testdata.txt','r').read() mydom = dom.parseString(data) mydom.firstChild.childNodes __________________________________ Tracker __________________________________ From report at bugs.python.org Thu Oct 18 23:16:19 2007 From: report at bugs.python.org (Georg Brandl) Date: Thu, 18 Oct 2007 21:16:19 -0000 Subject: [issue1281] typo in documentation - lib ref section 14.3.3.4 Message-ID: <1192742179.93.0.183843498384.issue1281@psf.upfronthosting.co.za> Georg Brandl added the comment: In fact, the error is not a typo, but a glitch in latex2html's handling of "--". It's already corrected in the 2.5 branch and needs no correction in later branches. ---------- nosy: +georg.brandl resolution: -> out of date status: open -> closed __________________________________ Tracker __________________________________ From report at bugs.python.org Thu Oct 18 23:41:27 2007 From: report at bugs.python.org (Brett Cannon) Date: Thu, 18 Oct 2007 21:41:27 -0000 Subject: [issue1631171] implement warnings module in C Message-ID: <1192743687.46.0.873467665064.issue1631171@psf.upfronthosting.co.za> Brett Cannon added the comment: Regression test suite now passes. =) Had to add the support for when warnings.showwarning() is set and a bug in PyErr_WarnExplicit() where a NULL value for the module name was not being allowed. Couple things still left to implement. One is the second output line in show_warning(). Don't notice this in unit tests as it imports warnings and thus uses the Python implementation that works properly. Also need to implement warn_explicit(). Lastly, -W arguments need to be handled. In terms of differing semantics, file paths are different. Old way did absolute paths. It also handled what the file path should be when executing a warning from the interpreter differently. In terms of testing, some _warnings-specific tests are needed. As mentioned above, the differences between _warnings.show_warning() and warnings.showwarning() are not being picked up. This shows how tests for setting of 'filters', 'onceregistry', and 'showwarning' needs to be tested. Assigning to Neal to see if there is anything I missed in terms of todos and see if he wants to take any of them on. =) ---------- assignee: brett.cannon -> nnorwitz Added file: http://bugs.python.org/file8565/_warnings.c _____________________________________ Tracker _____________________________________ -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: _warnings.c Url: http://mail.python.org/pipermail/python-bugs-list/attachments/20071018/ea43b902/attachment-0001.txt From report at bugs.python.org Fri Oct 19 01:26:25 2007 From: report at bugs.python.org (Stephen P. Schaefer) Date: Thu, 18 Oct 2007 23:26:25 -0000 Subject: [issue1301] Bad assertion in _tkinter.c Message-ID: <1192749985.07.0.719728900575.issue1301@psf.upfronthosting.co.za> New submission from Stephen P. Schaefer: The following fails with python 2.5 as built by Fedora 7: t2.py: import sys, Tkinter Tkinter.Button(text=u"").pack( ) Tkinter.mainloop( ) $ python t2.py python: ./Modules/_tkinter.c:941: AsObj: Assertion `size < size * sizeof(Tcl_UniChar)' failed. Aborted The following patch corrects the problem: --- Python-2.5-fc7/Modules/_tkinter.c 2006-08-11 22:33:36.000000000 -0400 +++ Python-2.5/Modules/_tkinter.c 2007-10-18 18:44:40.000000000 -0400 @@ -938,7 +938,7 @@ #if defined(Py_UNICODE_WIDE) && TCL_UTF_MAX == 3 Tcl_UniChar *outbuf; Py_ssize_t i; - assert(size < size * sizeof(Tcl_UniChar)); + assert(size == 0 || size < size * sizeof(Tcl_UniChar)); outbuf = (Tcl_UniChar*)ckalloc(size * sizeof(Tcl_UniChar)); if (!outbuf) { PyErr_NoMemory(); ---------- components: Tkinter messages: 56546 nosy: thyrsus severity: normal status: open title: Bad assertion in _tkinter.c versions: Python 2.5 __________________________________ Tracker __________________________________ From report at bugs.python.org Fri Oct 19 02:56:00 2007 From: report at bugs.python.org (Brett Cannon) Date: Fri, 19 Oct 2007 00:56:00 -0000 Subject: [issue1301] Bad assertion in _tkinter.c Message-ID: <1192755360.0.0.612896425335.issue1301@psf.upfronthosting.co.za> Brett Cannon added the comment: Patch is inlined in a comment. ---------- keywords: +patch nosy: +brett.cannon __________________________________ Tracker __________________________________ From report at bugs.python.org Fri Oct 19 09:10:51 2007 From: report at bugs.python.org (Lauri Alanko) Date: Fri, 19 Oct 2007 07:10:51 -0000 Subject: [issue1298] Support for z/OS and EBCDIC. Message-ID: <1192777851.9.0.939002998986.issue1298@psf.upfronthosting.co.za> Lauri Alanko added the comment: The character set of EBCDIC is a superset of the character set of ASCII. In fact CP1047, the variant used on z/OS, has the same character set as Latin-1. Only the encoding is completely different. As a non-ASCII platform, z/OS is certainly challenging for people used to modern conventions, and that is exactly why a familiar and easy-to-use tool like Python is so valuable there. As for viability, there are some obvious difficulties with Python's handling of source encodings, but as long as you restrict yourself to the ASCII _character set_ in your source code, the vast majority of things seem to work fine with my patch. There are more details in my mail to python-dev, which doesn't seem to have appeared yet. I'm not a subscriber, so it's probably pending moderation somewhere. (I hope "The list address accepts e-mail from non-members" is still correct information.) __________________________________ Tracker __________________________________ From report at bugs.python.org Fri Oct 19 09:12:24 2007 From: report at bugs.python.org (Lauri Alanko) Date: Fri, 19 Oct 2007 07:12:24 -0000 Subject: [issue1298] Support for z/OS and EBCDIC. Message-ID: <1192777944.71.0.85840043677.issue1298@psf.upfronthosting.co.za> Lauri Alanko added the comment: How do you measure importance? Z/OS is not important to many people in the world, but to those to whom it is important, it is _very_ important, in a very tangible way. It was certainly important enough for someone to port Python to it. :) __________________________________ Tracker __________________________________ From report at bugs.python.org Fri Oct 19 12:01:02 2007 From: report at bugs.python.org (Tom Tanner) Date: Fri, 19 Oct 2007 10:01:02 -0000 Subject: [issue602345] option for not writing .py[co] files Message-ID: <1192788062.04.0.773243632085.issue602345@psf.upfronthosting.co.za> Tom Tanner added the comment: Is there likely to be any action on this. We can get issues with the creation of .pyc files due to our build setup. We can get situations where we run builds in parallel on 2 different architectures. Our build is set up so that anything generated by compilers end up in individual architecture specific directories, but we cannot do this with python. We are also using clearmae, which has its own build avoidance features, which get thoroughly confused by the generation of these files) End result is one of 1) We get corrupt .pyc files 2) The build breaks 3) We rebuild things we don't need to. We'd be very grateful for a way of suppressing the generation of .pyc files completely. ---------- nosy: +thosrtanner ____________________________________ Tracker ____________________________________ From report at bugs.python.org Fri Oct 19 14:27:53 2007 From: report at bugs.python.org (BULOT) Date: Fri, 19 Oct 2007 12:27:53 -0000 Subject: [issue1294] Management of KeyboardInterrupt in cmd.py Message-ID: <1192796873.16.0.919305558464.issue1294@psf.upfronthosting.co.za> BULOT added the comment: Hello, Here is my patch for cmd.py Regards stephbul Added file: http://bugs.python.org/file8566/cmd.py.keyboardinterrupt.patch __________________________________ Tracker __________________________________ -------------- next part -------------- A non-text attachment was scrubbed... Name: cmd.py.keyboardinterrupt.patch Type: text/x-patch Size: 794 bytes Desc: not available Url : http://mail.python.org/pipermail/python-bugs-list/attachments/20071019/fcfd8142/attachment.bin From report at bugs.python.org Fri Oct 19 14:41:22 2007 From: report at bugs.python.org (Georg Brandl) Date: Fri, 19 Oct 2007 12:41:22 -0000 Subject: [issue602345] option for not writing .py[co] files Message-ID: <1192797682.6.0.957173131742.issue602345@psf.upfronthosting.co.za> Georg Brandl added the comment: Since the PEP is now withdrawn, I updated Neal's patch to the trunk and added the env variable as well as the sys module value, including documentation. ---------- priority: low -> normal Added file: http://bugs.python.org/file8567/no-pyc-flag.diff ____________________________________ Tracker ____________________________________ -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: no-pyc-flag.diff Url: http://mail.python.org/pipermail/python-bugs-list/attachments/20071019/a2dac7bf/attachment.txt From report at bugs.python.org Fri Oct 19 16:02:25 2007 From: report at bugs.python.org (Guido van Rossum) Date: Fri, 19 Oct 2007 14:02:25 -0000 Subject: [issue1298] Support for z/OS and EBCDIC. In-Reply-To: <1192777944.71.0.85840043677.issue1298@psf.upfronthosting.co.za> Message-ID: Guido van Rossum added the comment: > How do you measure importance? Z/OS is not important to many > people in the world, but to those to whom it is important, it is > _very_ important, in a very tangible way. It was certainly > important enough for someone to port Python to it. :) But is it important enough to cause a lot of work for the maintainers of Python, not just once (reviewing your mega-patch) but also in the future (making sure that the Z/OS support doesn't break)? We have accepted mega-patches for minority OS'es in the past, and our experience has unfortunately been that the contributors of such patches inevitable lose interest and the Python core developers are stuck with maintaining the patch -- or ripping it out, which is just as much work but at least promises that there will be no more work related to this issue in the future. I strongly recommend an alternative: the Z/OS community should maintain the patch set themselves. That way the burden of keeping it working is to those who benefit. It also makes it possible to decide not to upgrade to a newer version of Python because there aren't enough benefits. This is done for example by Nokia for its port to S60. > The character set of EBCDIC is a superset of the character set of > ASCII. In fact CP1047, the variant used on z/OS, has the same > character set as Latin-1. Only the encoding is completely > different. And there's the crux -- too much code (not just in the core but also in the library and in 3rd party code) assumes that the ASCII *encoding* is used in 8-bit strings. Breaking this will break tons of stuff. Glancing at your code it seems that you haven't tried the socket module or the higher-level internet modules to contact web servers on the internet... __________________________________ Tracker __________________________________ From report at bugs.python.org Fri Oct 19 16:52:09 2007 From: report at bugs.python.org (Nick) Date: Fri, 19 Oct 2007 14:52:09 -0000 Subject: [issue1297] pyconfig.h not compatible with MS VC++ Express Edition Message-ID: <1192805529.06.0.753498975891.issue1297@psf.upfronthosting.co.za> Nick added the comment: MS VC++ 2005 Express Edition __________________________________ Tracker __________________________________ From report at bugs.python.org Fri Oct 19 16:52:58 2007 From: report at bugs.python.org (Nick) Date: Fri, 19 Oct 2007 14:52:58 -0000 Subject: [issue1299] distutils.sysconfig is not cross-platform compatible Message-ID: <1192805578.55.0.109220209197.issue1299@psf.upfronthosting.co.za> Nick added the comment: I'll look into it this weekend. __________________________________ Tracker __________________________________ From report at bugs.python.org Fri Oct 19 16:56:11 2007 From: report at bugs.python.org (Raghuram Devarakonda) Date: Fri, 19 Oct 2007 14:56:11 -0000 Subject: [issue1290] xml.dom.minidom not able to handle utf-8 data Message-ID: <1192805771.28.0.858973783616.issue1290@psf.upfronthosting.co.za> Raghuram Devarakonda added the comment: The fact that the problem occurs only from the command line and not when run from a script indicates that the real issue is in trying to print the object. Sure enough, if you modify the script to do repr(mydom.firstChild.childNodes), it gets the same problem. So the issue may have some thing to do with how the object is constructed in repr(). I don't have time right now to dig deeper but the parser itself may not have any encoding/decoding issues (apart of ability to print these high level objects). __________________________________ Tracker __________________________________ From report at bugs.python.org Fri Oct 19 19:34:29 2007 From: report at bugs.python.org (Guido van Rossum) Date: Fri, 19 Oct 2007 17:34:29 -0000 Subject: [issue1294] Management of KeyboardInterrupt in cmd.py Message-ID: <1192815269.84.0.891380547821.issue1294@psf.upfronthosting.co.za> Guido van Rossum added the comment: Hmm... I don't think this is the right thing to do. The code is broken in several ways. I recommend you find someone to help you come up with a better patch in comp.lang.python. ---------- keywords: +patch __________________________________ Tracker __________________________________ From report at bugs.python.org Fri Oct 19 19:39:32 2007 From: report at bugs.python.org (Georg Brandl) Date: Fri, 19 Oct 2007 17:39:32 -0000 Subject: [issue1284] typo in lib doc 7.3.2.1 MaildirMessage Message-ID: <1192815572.74.0.839272958516.issue1284@psf.upfronthosting.co.za> Georg Brandl added the comment: Thanks, fixed in r58545, r58546 (2.5). ---------- nosy: +georg.brandl resolution: -> fixed status: open -> closed __________________________________ Tracker __________________________________ From report at bugs.python.org Fri Oct 19 20:15:50 2007 From: report at bugs.python.org (Eduardo Padoan) Date: Fri, 19 Oct 2007 18:15:50 -0000 Subject: [issue1161] Garbled chars in offending line of SyntaxError traceback Message-ID: <1192817750.1.0.711542369228.issue1161@psf.upfronthosting.co.za> Eduardo Padoan added the comment: Can't reproduce this error anymore with revision 58472. __________________________________ Tracker __________________________________ From report at bugs.python.org Fri Oct 19 20:15:52 2007 From: report at bugs.python.org (Eduardo Padoan) Date: Fri, 19 Oct 2007 18:15:52 -0000 Subject: [issue1151] "TypeError: expected string, bytes found" instead of KeyboardInterrupt Message-ID: <1192817752.4.0.200932202678.issue1151@psf.upfronthosting.co.za> Eduardo Padoan added the comment: Can't reproduce this error anymore with revision 58472. __________________________________ Tracker __________________________________ From report at bugs.python.org Fri Oct 19 21:43:57 2007 From: report at bugs.python.org (Raghuram Devarakonda) Date: Fri, 19 Oct 2007 19:43:57 -0000 Subject: [issue1294] Management of KeyboardInterrupt in cmd.py Message-ID: <1192823037.94.0.722989568365.issue1294@psf.upfronthosting.co.za> Raghuram Devarakonda added the comment: I tested cmd.py on Linux and two things (including the one reported by OP) looked odd to me. 1) CTRL-D produces a message "*** Unknown syntax: EOF". 2) CTRL-C produces a KeyboardInterrupt exception and the session terminates. I am attaching a patch that changes the behaviour to a more typical one (at least, in IMHO). It terminates the session on CTRL-D and it just ignores CTRL-C. Both of these can be overridden, if required. If the patch is accepted, a doc change would be required in addition to the change in doc string. I tested the patch on Linux and Windows. ---------- nosy: +draghuram Added file: http://bugs.python.org/file8568/cmd.diff __________________________________ Tracker __________________________________ -------------- next part -------------- A non-text attachment was scrubbed... Name: cmd.diff Type: text/x-patch Size: 1016 bytes Desc: not available Url : http://mail.python.org/pipermail/python-bugs-list/attachments/20071019/c32e7dee/attachment.bin From report at bugs.python.org Fri Oct 19 22:53:48 2007 From: report at bugs.python.org (Guido van Rossum) Date: Fri, 19 Oct 2007 20:53:48 -0000 Subject: [issue1151] "TypeError: expected string, bytes found" instead of KeyboardInterrupt Message-ID: <1192827228.7.0.708380638131.issue1151@psf.upfronthosting.co.za> Guido van Rossum added the comment: There were some seriously broken things with exception reporting, most of which I seem to have fixed. ---------- resolution: -> fixed status: open -> closed __________________________________ Tracker __________________________________ From report at bugs.python.org Fri Oct 19 22:54:17 2007 From: report at bugs.python.org (Guido van Rossum) Date: Fri, 19 Oct 2007 20:54:17 -0000 Subject: [issue1161] Garbled chars in offending line of SyntaxError traceback Message-ID: <1192827256.98.0.398866104194.issue1161@psf.upfronthosting.co.za> Guido van Rossum added the comment: There were some seriously broken things with exception reporting, most of which I seem to have fixed. ---------- resolution: -> fixed status: open -> closed __________________________________ Tracker __________________________________ From report at bugs.python.org Fri Oct 19 23:02:20 2007 From: report at bugs.python.org (Guido van Rossum) Date: Fri, 19 Oct 2007 21:02:20 -0000 Subject: [issue1267] Py3K cannot run as ``python -S`` Message-ID: <1192827740.77.0.669758080678.issue1267@psf.upfronthosting.co.za> Guido van Rossum added the comment: I will take this. ---------- assignee: brett.cannon -> gvanrossum __________________________________ Tracker __________________________________ From report at bugs.python.org Fri Oct 19 23:14:20 2007 From: report at bugs.python.org (Brett Cannon) Date: Fri, 19 Oct 2007 21:14:20 -0000 Subject: [issue1267] Py3K cannot run as ``python -S`` Message-ID: <1192828460.86.0.0621160009535.issue1267@psf.upfronthosting.co.za> Brett Cannon added the comment: Thanks, Guido. __________________________________ Tracker __________________________________ From report at bugs.python.org Fri Oct 19 23:35:32 2007 From: report at bugs.python.org (Guido van Rossum) Date: Fri, 19 Oct 2007 21:35:32 -0000 Subject: [issue1280] PEP 3137: Make PyString's indexing and iteration return integers Message-ID: <1192829732.32.0.370317693086.issue1280@psf.upfronthosting.co.za> Changes by Guido van Rossum: ---------- assignee: -> gvanrossum nosy: +gvanrossum __________________________________ Tracker __________________________________ From report at bugs.python.org Fri Oct 19 23:49:42 2007 From: report at bugs.python.org (Guido van Rossum) Date: Fri, 19 Oct 2007 21:49:42 -0000 Subject: [issue1263] PEP 3137 patch - str8/str comparison should return false Message-ID: <1192830582.66.0.336370135768.issue1263@psf.upfronthosting.co.za> Guido van Rossum added the comment: I've committed the half of this patch that doesn't break any tests: the changes to codecs.c and structmember.c. Committed revision 58551. I'm seeking help getting the remaining unit tests to pass. (Thanks Thomas for the enumeration of the test failures!) __________________________________ Tracker __________________________________ From report at bugs.python.org Sat Oct 20 00:07:07 2007 From: report at bugs.python.org (Guido van Rossum) Date: Fri, 19 Oct 2007 22:07:07 -0000 Subject: [issue1280] PEP 3137: Make PyString's indexing and iteration return integers Message-ID: <1192831627.27.0.620044649418.issue1280@psf.upfronthosting.co.za> Guido van Rossum added the comment: Checked in. I addressed some of your XXX'es, left others in (sre needs a serious checkup for compatibility with bytes). Committed revision 58552. ---------- resolution: -> accepted status: open -> closed __________________________________ Tracker __________________________________ From report at bugs.python.org Sat Oct 20 00:13:18 2007 From: report at bugs.python.org (Amaury Forgeot d'Arc) Date: Fri, 19 Oct 2007 22:13:18 -0000 Subject: [issue1297] pyconfig.h not compatible with MS VC++ Express Edition Message-ID: <1192831998.79.0.377365074227.issue1297@psf.upfronthosting.co.za> Amaury Forgeot d'Arc added the comment: I found that BaseTsd.h is part of the Windows SDK, which is not included in the Express Edition. It can be installed separately. OTOH, the python core still compiles without the #include (using VC++ 2005 Express Edition). What about other compilers? What is this file needed for? ---------- nosy: +amaury.forgeotdarc __________________________________ Tracker __________________________________ From report at bugs.python.org Sat Oct 20 00:18:02 2007 From: report at bugs.python.org (Christian Heimes) Date: Fri, 19 Oct 2007 22:18:02 -0000 Subject: [issue1302] Fixes for profile/cprofile Message-ID: <1192832282.86.0.0922652821698.issue1302@psf.upfronthosting.co.za> New submission from Christian Heimes: The patch fixes the output for profile and cProfile. Another patch from Alexandre and me added additional calls to the UTF-8 codec. ---------- components: Library (Lib) messages: 56569 nosy: gvanrossum, tiran severity: normal status: open title: Fixes for profile/cprofile versions: Python 3.0 __________________________________ Tracker __________________________________ From report at bugs.python.org Sat Oct 20 00:29:48 2007 From: report at bugs.python.org (Brett Cannon) Date: Fri, 19 Oct 2007 22:29:48 -0000 Subject: [issue1302] Fixes for profile/cprofile Message-ID: <1192832988.33.0.64241208736.issue1302@psf.upfronthosting.co.za> Brett Cannon added the comment: There is no patch. =) ---------- assignee: -> gvanrossum keywords: +py3k nosy: +brett.cannon __________________________________ Tracker __________________________________ From report at bugs.python.org Sat Oct 20 00:31:03 2007 From: report at bugs.python.org (Christian Heimes) Date: Fri, 19 Oct 2007 22:31:03 -0000 Subject: [issue1302] Fixes for profile/cprofile Message-ID: <1192833063.65.0.266920639685.issue1302@psf.upfronthosting.co.za> Christian Heimes added the comment: Sure there is a patch ... well it's ... *uhm* ... it's hidden under your bed. O:-) Added file: http://bugs.python.org/file8569/py3k_profile_fix.patches __________________________________ Tracker __________________________________ -------------- next part -------------- A non-text attachment was scrubbed... Name: py3k_profile_fix.patches Type: application/octet-stream Size: 5818 bytes Desc: not available Url : http://mail.python.org/pipermail/python-bugs-list/attachments/20071019/57b37bc9/attachment.obj From report at bugs.python.org Sat Oct 20 00:32:42 2007 From: report at bugs.python.org (Brett Cannon) Date: Fri, 19 Oct 2007 22:32:42 -0000 Subject: [issue1263] PEP 3137 patch - str8/str comparison should return false Message-ID: <1192833162.62.0.715697799226.issue1263@psf.upfronthosting.co.za> Changes by Brett Cannon: Removed file: http://bugs.python.org/file8543/unnamed __________________________________ Tracker __________________________________ From report at bugs.python.org Sat Oct 20 00:44:50 2007 From: report at bugs.python.org (Georg Brandl) Date: Fri, 19 Oct 2007 22:44:50 -0000 Subject: [issue1303] adapt str8 constructor to bytes constructor Message-ID: <1192833890.07.0.771268986482.issue1303@psf.upfronthosting.co.za> New submission from Georg Brandl: This makes the str8 constructor accept the same kinds of types as the bytes constructor. I had to fix instances of str8("abc") to str8(b"abc") to make tests pass again. The only remaining failure should be test_str -- the string test suite must be thoroughly redesigned to fit all three string-like types. ---------- assignee: gvanrossum components: Interpreter Core files: str_constructor.diff keywords: py3k messages: 56572 nosy: georg.brandl, gvanrossum severity: normal status: open title: adapt str8 constructor to bytes constructor versions: Python 3.0 Added file: http://bugs.python.org/file8570/str_constructor.diff __________________________________ Tracker __________________________________ -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: str_constructor.diff Url: http://mail.python.org/pipermail/python-bugs-list/attachments/20071019/6836c4fe/attachment.txt From report at bugs.python.org Sat Oct 20 00:59:21 2007 From: report at bugs.python.org (Amaury Forgeot d'Arc) Date: Fri, 19 Oct 2007 22:59:21 -0000 Subject: [issue1304] py3k compilation on Windows Message-ID: <1192834761.88.0.529928768511.issue1304@psf.upfronthosting.co.za> New submission from Amaury Forgeot d'Arc: This patch is needed to have py3k compile on win32, since the introduction of bytes_methods.c. Also, use the recently re-added md5module.c and sha1module.c, because a precompiled openssl library is difficult to obtain on Windows. Note: I tested only with VS2005. I will watch the buildbots to verify that compilation actually succeeds. ---------- components: Build, Windows files: win32build.diff messages: 56573 nosy: amaury.forgeotdarc severity: normal status: open title: py3k compilation on Windows versions: Python 3.0 Added file: http://bugs.python.org/file8571/win32build.diff __________________________________ Tracker __________________________________ -------------- next part -------------- A non-text attachment was scrubbed... Name: win32build.diff Type: application/octet-stream Size: 2798 bytes Desc: not available Url : http://mail.python.org/pipermail/python-bugs-list/attachments/20071019/798b5330/attachment-0001.obj From report at bugs.python.org Sat Oct 20 01:17:12 2007 From: report at bugs.python.org (Guido van Rossum) Date: Fri, 19 Oct 2007 23:17:12 -0000 Subject: [issue1267] Py3K cannot run as ``python -S`` Message-ID: <1192835832.12.0.47719034016.issue1267@psf.upfronthosting.co.za> Guido van Rossum added the comment: Committed revision 58553 (with minor tweaks only). Thanks! ---------- resolution: -> accepted status: open -> closed __________________________________ Tracker __________________________________ From report at bugs.python.org Sat Oct 20 01:22:26 2007 From: report at bugs.python.org (Christian Heimes) Date: Fri, 19 Oct 2007 23:22:26 -0000 Subject: [issue1278] imp.find_module() ignores -*- coding: Latin-1 -*- Message-ID: <1192836146.88.0.601597763692.issue1278@psf.upfronthosting.co.za> Christian Heimes added the comment: The bug was fixed in r58553 together with http://bugs.python.org/issue1267. Please close this bug. __________________________________ Tracker __________________________________ From report at bugs.python.org Sat Oct 20 01:25:53 2007 From: report at bugs.python.org (Brett Cannon) Date: Fri, 19 Oct 2007 23:25:53 -0000 Subject: [issue1263] PEP 3137 patch - str8/str comparison should return false Message-ID: <1192836353.52.0.132053046793.issue1263@psf.upfronthosting.co.za> Brett Cannon added the comment: The file I just uploaded is unicode-string-eq-false-all-r4.patch with the codecs.c and structmember.c parts of the patch removed. ---------- nosy: +brett.cannon Added file: http://bugs.python.org/file8572/r4-revised.patch __________________________________ Tracker __________________________________ -------------- next part -------------- A non-text attachment was scrubbed... Name: r4-revised.patch Type: application/octet-stream Size: 1591 bytes Desc: not available Url : http://mail.python.org/pipermail/python-bugs-list/attachments/20071019/83515544/attachment.obj From report at bugs.python.org Sat Oct 20 01:36:58 2007 From: report at bugs.python.org (Guido van Rossum) Date: Fri, 19 Oct 2007 23:36:58 -0000 Subject: [issue1278] imp.find_module() ignores -*- coding: Latin-1 -*- Message-ID: <1192837018.96.0.778821365228.issue1278@psf.upfronthosting.co.za> Changes by Guido van Rossum: ---------- resolution: -> fixed status: open -> closed __________________________________ Tracker __________________________________ From report at bugs.python.org Sat Oct 20 01:51:22 2007 From: report at bugs.python.org (Guido van Rossum) Date: Fri, 19 Oct 2007 23:51:22 -0000 Subject: [issue1298] Support for z/OS and EBCDIC. Message-ID: <1192837882.29.0.963333659492.issue1298@psf.upfronthosting.co.za> Guido van Rossum added the comment: FYI, I checked the moderation queue for python-dev and didn't find your message. You might want to resend. __________________________________ Tracker __________________________________ From report at bugs.python.org Sat Oct 20 02:11:49 2007 From: report at bugs.python.org (Brett Cannon) Date: Sat, 20 Oct 2007 00:11:49 -0000 Subject: [issue1263] PEP 3137 patch - str8/str comparison should return false Message-ID: <1192839109.0.0.78300327128.issue1263@psf.upfronthosting.co.za> Brett Cannon added the comment: Attached is a patch to fix test_compile. Simple fix of turning an empty string into ``str8('')``. Added file: http://bugs.python.org/file8573/fix_test_compile.diff __________________________________ Tracker __________________________________ -------------- next part -------------- A non-text attachment was scrubbed... Name: fix_test_compile.diff Type: application/octet-stream Size: 568 bytes Desc: not available Url : http://mail.python.org/pipermail/python-bugs-list/attachments/20071020/7ab05c56/attachment.obj From report at bugs.python.org Sat Oct 20 02:30:49 2007 From: report at bugs.python.org (Guido van Rossum) Date: Sat, 20 Oct 2007 00:30:49 -0000 Subject: [issue1267] Py3K cannot run as ``python -S`` In-Reply-To: <1192835832.12.0.47719034016.issue1267@psf.upfronthosting.co.za> Message-ID: Guido van Rossum added the comment: FWIW, on Mac I get six failures (all these pass on Linux): test_cmd_line test_inspect test_modulefinder test_pyclbr test_quopri test_runpy __________________________________ Tracker __________________________________ From report at bugs.python.org Sat Oct 20 02:44:24 2007 From: report at bugs.python.org (Brett Cannon) Date: Sat, 20 Oct 2007 00:44:24 -0000 Subject: [issue1263] PEP 3137 patch - str8/str comparison should return false Message-ID: <1192841064.89.0.0417851840309.issue1263@psf.upfronthosting.co.za> Brett Cannon added the comment: Attached a fix for test_format. It was testing string interpolation on both str8 and str and using a str for the comparison. Since string interpolation is going away for str8 once it becomes bytes I just removed the testing of str8. The failures I know of left are: test_modulefinder test_sqlite test_str test_struct test_subprocess Added file: http://bugs.python.org/file8574/fix_test_format.diff __________________________________ Tracker __________________________________ -------------- next part -------------- A non-text attachment was scrubbed... Name: fix_test_format.diff Type: application/octet-stream Size: 14456 bytes Desc: not available Url : http://mail.python.org/pipermail/python-bugs-list/attachments/20071020/ca1ad23f/attachment-0001.obj From report at bugs.python.org Sat Oct 20 03:00:32 2007 From: report at bugs.python.org (Brett Cannon) Date: Sat, 20 Oct 2007 01:00:32 -0000 Subject: [issue1267] Py3K cannot run as ``python -S`` In-Reply-To: Message-ID: Brett Cannon added the comment: Yeah, I just noticed this as well. is it definitely this change? On 10/19/07, Guido van Rossum wrote: > > Guido van Rossum added the comment: > > FWIW, on Mac I get six failures (all these pass on Linux): > > test_cmd_line test_inspect test_modulefinder test_pyclbr test_quopri test_runpy > > __________________________________ > Tracker > > __________________________________ > __________________________________ Tracker __________________________________ From report at bugs.python.org Sat Oct 20 03:03:57 2007 From: report at bugs.python.org (Brett Cannon) Date: Sat, 20 Oct 2007 01:03:57 -0000 Subject: [issue1303] adapt str8 constructor to bytes constructor Message-ID: <1192842237.14.0.46096755619.issue1303@psf.upfronthosting.co.za> Changes by Brett Cannon: ---------- keywords: +patch __________________________________ Tracker __________________________________ From report at bugs.python.org Sat Oct 20 03:04:08 2007 From: report at bugs.python.org (Brett Cannon) Date: Sat, 20 Oct 2007 01:04:08 -0000 Subject: [issue1303] adapt str8 constructor to bytes constructor Message-ID: <1192842248.06.0.889927653094.issue1303@psf.upfronthosting.co.za> Changes by Brett Cannon: ---------- nosy: +brett.cannon __________________________________ Tracker __________________________________ From report at bugs.python.org Sat Oct 20 03:17:07 2007 From: report at bugs.python.org (Christian Heimes) Date: Sat, 20 Oct 2007 01:17:07 -0000 Subject: [issue1267] Py3K cannot run as ``python -S`` Message-ID: <1192843027.18.0.497764138867.issue1267@psf.upfronthosting.co.za> Christian Heimes added the comment: I don't have a Mac at my disposal any more. :( Can you attach the output of the failing tests to the bug report? Maybe I can be of assistance. __________________________________ Tracker __________________________________ From report at bugs.python.org Sat Oct 20 03:20:37 2007 From: report at bugs.python.org (Brett Cannon) Date: Sat, 20 Oct 2007 01:20:37 -0000 Subject: [issue1267] Py3K cannot run as ``python -S`` In-Reply-To: <1192843027.18.0.497764138867.issue1267@psf.upfronthosting.co.za> Message-ID: Brett Cannon added the comment: runpy is failing because pkgutil is failing because it is giving compile() part of a source file instead of the entire thing:: Traceback (most recent call last): File "/Users/drifty/Dev/python/3.x/pristine/Lib/runpy.py", line 97, in _run_module_as_main loader, code, fname = _get_module_details(mod_name) File "/Users/drifty/Dev/python/3.x/pristine/Lib/runpy.py", line 82, in _get_module_details code = loader.get_code(mod_name) File "/Users/drifty/Dev/python/3.x/pristine/Lib/pkgutil.py", line 275, in get_code self.code = compile(source, self.filename, 'exec') File "/Users/drifty/Dev/python/3.x/pristine/Lib/tokenize.py", line 2 "UR'''": single3prog, 'UR"""': double3prog, ^ IndentationError: unexpected indent That bad line is the first line in the 'source' variable being passed to compile(). So somewhere the beginning of the source file is being chopped up. On 10/19/07, Christian Heimes wrote: > > Christian Heimes added the comment: > > I don't have a Mac at my disposal any more. :( > > Can you attach the output of the failing tests to the bug report? Maybe > I can be of assistance. > > __________________________________ > Tracker > > __________________________________ > __________________________________ Tracker __________________________________ From report at bugs.python.org Sat Oct 20 03:30:30 2007 From: report at bugs.python.org (Brett Cannon) Date: Sat, 20 Oct 2007 01:30:30 -0000 Subject: [issue1267] Py3K cannot run as ``python -S`` Message-ID: <1192843830.49.0.594251439172.issue1267@psf.upfronthosting.co.za> Brett Cannon added the comment: It looks like the file object returned by imp.find_module() has its read position WAY too far forward (at least on OS X). Re-opening. ---------- status: closed -> open __________________________________ Tracker __________________________________ From report at bugs.python.org Sat Oct 20 03:32:57 2007 From: report at bugs.python.org (Christian Heimes) Date: Sat, 20 Oct 2007 01:32:57 -0000 Subject: [issue1267] Py3K cannot run as ``python -S`` In-Reply-To: Message-ID: <47195AC4.9050701@cheimes.de> Christian Heimes added the comment: > runpy is failing because pkgutil is failing because it is giving > compile() part of a source file instead of the entire thing:: > > Traceback (most recent call last): > File "/Users/drifty/Dev/python/3.x/pristine/Lib/runpy.py", line 97, > in _run_module_as_main > loader, code, fname = _get_module_details(mod_name) > File "/Users/drifty/Dev/python/3.x/pristine/Lib/runpy.py", line 82, > in _get_module_details > code = loader.get_code(mod_name) > File "/Users/drifty/Dev/python/3.x/pristine/Lib/pkgutil.py", line > 275, in get_code > self.code = compile(source, self.filename, 'exec') > File "/Users/drifty/Dev/python/3.x/pristine/Lib/tokenize.py", line 2 > "UR'''": single3prog, 'UR"""': double3prog, > ^ > IndentationError: unexpected indent > > That bad line is the first line in the 'source' variable being passed > to compile(). So somewhere the beginning of the source file is being > chopped up. Could you please comment out the PyTokenizer_FindEncoding(fp) call in Python/import.c to check if it is related to it? That's the only change (I can think of) that may be related to the problem. I always rewind the fp in the function but it may not work on Mac. Christian __________________________________ Tracker __________________________________ From report at bugs.python.org Sat Oct 20 03:37:14 2007 From: report at bugs.python.org (Christian Heimes) Date: Sat, 20 Oct 2007 01:37:14 -0000 Subject: [issue1267] Py3K cannot run as ``python -S`` In-Reply-To: <1192843830.49.0.594251439172.issue1267@psf.upfronthosting.co.za> Message-ID: <47195BC7.6020304@cheimes.de> Christian Heimes added the comment: Brett Cannon wrote: > Brett Cannon added the comment: > > It looks like the file object returned by imp.find_module() has its read > position WAY too far forward (at least on OS X). That's strange. It should never read more than 2 lines of a file. I don't understand how it could happen. char * PyTokenizer_FindEncoding(FILE *fp) { struct tok_state *tok; char *p_start=NULL, *p_end=NULL; if ((tok = PyTokenizer_FromFile(fp, NULL, NULL, NULL)) == NULL) { rewind(fp); return NULL; } while(((tok->lineno <= 2) && (tok->done == E_OK))) { PyTokenizer_Get(tok, &p_start, &p_end); } rewind(fp); return tok->encoding; } __________________________________ Tracker __________________________________ From report at bugs.python.org Sat Oct 20 03:38:54 2007 From: report at bugs.python.org (Brett Cannon) Date: Sat, 20 Oct 2007 01:38:54 -0000 Subject: [issue1267] Py3K cannot run as ``python -S`` Message-ID: <1192844334.57.0.48734361119.issue1267@psf.upfronthosting.co.za> Brett Cannon added the comment: PyTokenizer_FindEncoding() is the culprit. If I comment it out in Python/import.c:call_find_module(), and thus just use the system encoding, runpy works again. __________________________________ Tracker __________________________________ From report at bugs.python.org Sat Oct 20 03:46:01 2007 From: report at bugs.python.org (Christian Heimes) Date: Sat, 20 Oct 2007 01:46:01 -0000 Subject: [issue1267] Py3K cannot run as ``python -S`` In-Reply-To: <47195BC7.6020304@cheimes.de> Message-ID: <47195DD7.5060905@cheimes.de> Christian Heimes added the comment: It's unrelated to the problem but Parser/tokenizer.c:1619 has a minor bug. > while(((tok->lineno <= 2) && (tok->done == E_OK))) { > PyTokenizer_Get(tok, &p_start, &p_end); > } (tok->lineno < 2) is sufficient. See line 516 Christian __________________________________ Tracker __________________________________ From report at bugs.python.org Sat Oct 20 04:17:04 2007 From: report at bugs.python.org (Brett Cannon) Date: Sat, 20 Oct 2007 02:17:04 -0000 Subject: [issue1267] Py3K cannot run as ``python -S`` Message-ID: <1192846624.43.0.787308902814.issue1267@psf.upfronthosting.co.za> Brett Cannon added the comment: OK, for some reason, when PyTokenizer_FindEncoding() is called and the resulting file is big enough, it starts off with a seek position (according to TextIOWrapper.tell()) of 4096. That happens to be exactly half the size of the buffer used by io. But I am not sure what the magical size is as creating a file of 4095, 4096, and 4097 bytes does not trigger this bug. __________________________________ Tracker __________________________________ From report at bugs.python.org Sat Oct 20 04:28:04 2007 From: report at bugs.python.org (Christian Heimes) Date: Sat, 20 Oct 2007 02:28:04 -0000 Subject: [issue1267] Py3K cannot run as ``python -S`` Message-ID: <1192847284.35.0.819707259777.issue1267@psf.upfronthosting.co.za> Christian Heimes added the comment: I've made a short unit tests which tests a large file with and w/o -*- coding: -*-. It passes on Linux. Added file: http://bugs.python.org/file8575/py3k_test_issue1267.patch __________________________________ Tracker __________________________________ -------------- next part -------------- A non-text attachment was scrubbed... Name: py3k_test_issue1267.patch Type: text/x-diff Size: 867 bytes Desc: not available Url : http://mail.python.org/pipermail/python-bugs-list/attachments/20071020/ec078ad6/attachment-0001.patch From report at bugs.python.org Sat Oct 20 04:33:56 2007 From: report at bugs.python.org (Christian Heimes) Date: Sat, 20 Oct 2007 02:33:56 -0000 Subject: [issue1267] Py3K cannot run as ``python -S`` In-Reply-To: <1192846624.43.0.787308902814.issue1267@psf.upfronthosting.co.za> Message-ID: <47196912.9060203@cheimes.de> Christian Heimes added the comment: Brett Cannon wrote: > Brett Cannon added the comment: > > OK, for some reason, when PyTokenizer_FindEncoding() is called and the > resulting file is big enough, it starts off with a seek position > (according to TextIOWrapper.tell()) of 4096. That happens to be exactly > half the size of the buffer used by io. > > But I am not sure what the magical size is as creating a file of 4095, > 4096, and 4097 bytes does not trigger this bug. Maybe rewind() doesn't do what is should do? Could you replace the rewind() calls with fseek(fd, 0, 0)? w/o the rewind() calls in PyTokenizer_FindEncoding I'm getting an error in my new test: Traceback (most recent call last): File "Lib/test/test_imp.py", line 66, in test_main() File "Lib/test/test_imp.py", line 62, in test_main ImportTests, File "/home/heimes/dev/python/py3k/Lib/test/test_support.py", line 541, in run_unittest _run_suite(suite) File "/home/heimes/dev/python/py3k/Lib/test/test_support.py", line 524, in _run_suite raise TestFailed(err) test.test_support.TestFailed: Traceback (most recent call last): File "Lib/test/test_imp.py", line 50, in test_issue1267 self.assertEqual(fd.tell(), 0) AssertionError: 4096 != 0 The number is looking familiar, isn't it? :) Is it the default buffer size on Unix? Christian __________________________________ Tracker __________________________________ From report at bugs.python.org Sat Oct 20 04:54:42 2007 From: report at bugs.python.org (Brett Cannon) Date: Sat, 20 Oct 2007 02:54:42 -0000 Subject: [issue1267] Py3K cannot run as ``python -S`` Message-ID: <1192848882.85.0.829978186056.issue1267@psf.upfronthosting.co.za> Brett Cannon added the comment: I checked in your ``< 2`` change and plugged a memory leak since you were not freeing the struct tok_state. Checked in r58555. __________________________________ Tracker __________________________________ From report at bugs.python.org Sat Oct 20 04:58:28 2007 From: report at bugs.python.org (Brett Cannon) Date: Sat, 20 Oct 2007 02:58:28 -0000 Subject: [issue1267] Py3K cannot run as ``python -S`` Message-ID: <1192849108.64.0.877579738468.issue1267@psf.upfronthosting.co.za> Brett Cannon added the comment: Nope, didn't do it. I also checked using gdb a few minutes ago and ftell() was reporting a position of 0 all they way back to PyObject_MethodCall(). __________________________________ Tracker __________________________________ From report at bugs.python.org Sat Oct 20 05:18:43 2007 From: report at bugs.python.org (Brett Cannon) Date: Sat, 20 Oct 2007 03:18:43 -0000 Subject: [issue1267] Py3K cannot run as ``python -S`` Message-ID: <1192850323.82.0.1571901904.issue1267@psf.upfronthosting.co.za> Brett Cannon added the comment: OK, I think I might have a solution, and it is really stupid. I will run the unit test suite to see if it really fixes everything. __________________________________ Tracker __________________________________ From report at bugs.python.org Sat Oct 20 05:26:30 2007 From: report at bugs.python.org (Guido van Rossum) Date: Sat, 20 Oct 2007 03:26:30 -0000 Subject: [issue1267] Py3K cannot run as ``python -S`` In-Reply-To: <1192850323.82.0.1571901904.issue1267@psf.upfronthosting.co.za> Message-ID: Guido van Rossum added the comment: > OK, I think I might have a solution, and it is really stupid. I will > run the unit test suite to see if it really fixes everything. Here's keeping my fingers crossed. I do note that the new code still leaks the encoding string which is malloc'ed in PyTokenizer_FindEncoding but never freed by call_find_module. BTW, the test_inspect failure I saw was shallow; I'd renamed the parent directory and the failure was due to the wrong filename being baked into the .pyc file. The other 5 failures are all related to the issue you are chasing here. __________________________________ Tracker __________________________________ From report at bugs.python.org Sat Oct 20 05:38:31 2007 From: report at bugs.python.org (Guido van Rossum) Date: Sat, 20 Oct 2007 03:38:31 -0000 Subject: [issue1179] [CVE-2007-4965] Integer overflow in imageop module Message-ID: <1192851511.89.0.866942602608.issue1179@psf.upfronthosting.co.za> Guido van Rossum added the comment: Neal, didn't you say you had a fix for this? ---------- nosy: +nnorwitz __________________________________ Tracker __________________________________ From report at bugs.python.org Sat Oct 20 05:49:36 2007 From: report at bugs.python.org (Brett Cannon) Date: Sat, 20 Oct 2007 03:49:36 -0000 Subject: [issue1267] Py3K cannot run as ``python -S`` Message-ID: <1192852176.62.0.0513306170104.issue1267@psf.upfronthosting.co.za> Brett Cannon added the comment: 58557 as the fix. Yes, it was stupid on OS X's part and I was lucky to just think of the possible solution. Basically OS X does not like it when you do stuff with a file pointer but then poke around with the file descriptor. That means that when PyTokenizer_FindEncoding() seeked on the file pointer it was not being picked up by the the file descriptor that the file pointer represented. This suggests that perhaps we should standardize on file pointers or file descriptors in Python to prevent something like this from happening again. ---------- assignee: gvanrossum -> brett.cannon status: open -> closed __________________________________ Tracker __________________________________ From report at bugs.python.org Sat Oct 20 05:59:50 2007 From: report at bugs.python.org (Christian Heimes) Date: Sat, 20 Oct 2007 03:59:50 -0000 Subject: [issue1267] Py3K cannot run as ``python -S`` In-Reply-To: <1192852176.62.0.0513306170104.issue1267@psf.upfronthosting.co.za> Message-ID: <47197D33.9030004@cheimes.de> Christian Heimes added the comment: Brett Cannon wrote: > This suggests that perhaps we should standardize on file pointers or > file descriptors in Python to prevent something like this from happening > again. rewind() it used couple of times in the Python code. Have you checked if the other calls are safe? Thx for finding the bug :) Great work! Christian __________________________________ Tracker __________________________________ From report at bugs.python.org Sat Oct 20 06:06:24 2007 From: report at bugs.python.org (Brett Cannon) Date: Sat, 20 Oct 2007 04:06:24 -0000 Subject: [issue1267] Py3K cannot run as ``python -S`` In-Reply-To: <47197D33.9030004@cheimes.de> Message-ID: Brett Cannon added the comment: On 10/19/07, Christian Heimes wrote: > > Christian Heimes added the comment: > > Brett Cannon wrote: > > This suggests that perhaps we should standardize on file pointers or > > file descriptors in Python to prevent something like this from happening > > again. > > rewind() it used couple of times in the Python code. Have you checked if > the other calls are safe? > No. I am still rather frustrated that was the problem. The only reason I feel safe with this solution is that the file pointer is not directly used except by _fileio to get the file descriptor. I would not trust this if the file pointer and file descriptor had intertwined uses. But I would trust rewind() if the file pointer is used the entire time. > Thx for finding the bug :) Great work! Thanks. I just wish this whole ordeal had not been necessary (filed a bug report with Apple in hopes that this can be prevented for someone else). I can see why some people prefer to hack on PyPy, IronPython, or Jython instead of dealing with the joys of C. =) __________________________________ Tracker __________________________________ From report at bugs.python.org Sat Oct 20 06:22:20 2007 From: report at bugs.python.org (Christian Heimes) Date: Sat, 20 Oct 2007 04:22:20 -0000 Subject: [issue1267] Py3K cannot run as ``python -S`` In-Reply-To: Message-ID: <47198279.9070102@cheimes.de> Christian Heimes added the comment: Brett Cannon wrote: > Thanks. I just wish this whole ordeal had not been necessary (filed a > bug report with Apple in hopes that this can be prevented for someone > else). I can see why some people prefer to hack on PyPy, IronPython, > or Jython instead of dealing with the joys of C. =) The bug is rather strange. I would have imagined that fseek() and rewind() are using the file descriptor internally. It's more than weird that an operation on the file handler doesn't affect the file descriptor. I wonder how they were able to manage it ... IronPython might be fun but I've hacked PythonDotNet. You get the worst from the C, .NET/C# and Mono together. Debugging is fun when you have to do multiple turns with two debuggers and one of the debuggers is partly broken. :[ __________________________________ Tracker __________________________________ From report at bugs.python.org Sat Oct 20 06:58:37 2007 From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=) Date: Sat, 20 Oct 2007 04:58:37 -0000 Subject: [issue1302] Fixes for profile/cprofile Message-ID: <1192856317.5.0.421986598727.issue1302@psf.upfronthosting.co.za> Changes by Martin v. L?wis: ---------- keywords: +patch __________________________________ Tracker __________________________________ From report at bugs.python.org Sat Oct 20 08:11:09 2007 From: report at bugs.python.org (andres) Date: Sat, 20 Oct 2007 06:11:09 -0000 Subject: [issue1305] socket.py hangs on Mac OS X Message-ID: <1192860669.18.0.477878627649.issue1305@psf.upfronthosting.co.za> New submission from andres: Repeated socket connection attempts hang for >2s on Python 2.5.1 & OS X 10.4 after 250 attempts have been made. ---------- components: Library (Lib), Macintosh files: sockettest.py messages: 56601 nosy: andres severity: normal status: open title: socket.py hangs on Mac OS X type: behavior versions: Python 2.5 Added file: http://bugs.python.org/file8576/sockettest.py __________________________________ Tracker __________________________________ -------------- next part -------------- A non-text attachment was scrubbed... Name: sockettest.py Type: text/x-python-script Size: 408 bytes Desc: not available Url : http://mail.python.org/pipermail/python-bugs-list/attachments/20071020/c8eb4f75/attachment-0001.bin From report at bugs.python.org Sat Oct 20 09:43:00 2007 From: report at bugs.python.org (Georg Brandl) Date: Sat, 20 Oct 2007 07:43:00 -0000 Subject: [issue1061] ABC caches should use weak refs Message-ID: <1192866180.25.0.563238197223.issue1061@psf.upfronthosting.co.za> Georg Brandl added the comment: Attaching a new patch; this one passes regrtest -R:: of test_io without apparent reference leaks. ---------- assignee: georg.brandl -> gvanrossum Added file: http://bugs.python.org/file8577/wr.diff __________________________________ Tracker __________________________________ -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: wr.diff Url: http://mail.python.org/pipermail/python-bugs-list/attachments/20071020/1c3f5232/attachment.txt From report at bugs.python.org Sat Oct 20 15:35:10 2007 From: report at bugs.python.org (Karemir) Date: Sat, 20 Oct 2007 13:35:10 -0000 Subject: [issue1306] Embedded python reinitialization Message-ID: <1192887310.11.0.424828418654.issue1306@psf.upfronthosting.co.za> New submission from Karemir: Hi, I'm embedding stackless python in a c++ application under linux. When I try to Finalize and Initialize again, I'm getting errors. this is a sample code that doesn't work: int main() { Py_Initialize(); Py_Finalize(); Py_Initialize(); Py_Finalize(); } Second call to Init throws out a nice Segmentation Fault. Here's a stack trace: PyDict_SetItem (op=0x0, key=0x2aaaaab1a4c8, value=0x6bab20) at Objects/dictobject.c:616 616 if (!PyDict_Check(op)) { Current language: auto; currently c (gdb) bt #0 PyDict_SetItem (op=0x0, key=0x2aaaaab1a4c8, value=0x6bab20) at Objects/dictobject.c:616 #1 0x0000000000476ac9 in PyDict_SetItemString (v=0x0, key=Variable "key" is not available. ) at Objects/dictobject.c:2178 #2 0x00000000004ea77f in PyErr_PrintEx (set_sys_last_vars=1) at Python/pythonrun.c:1098 #3 0x00000000004ebfb9 in Py_InitializeEx (install_sigs=1) at Python/pythonrun.c:995 #4 0x000000000044a8cc in main () at main.cpp:23 I'm using gcc 3.4.6, and Python 2.5.1 Stackless 3.1b3. ---------- components: Interpreter Core messages: 56603 nosy: Karemir severity: urgent status: open title: Embedded python reinitialization type: crash versions: Python 2.5 __________________________________ Tracker __________________________________ From report at bugs.python.org Sat Oct 20 17:36:07 2007 From: report at bugs.python.org (Guido van Rossum) Date: Sat, 20 Oct 2007 15:36:07 -0000 Subject: [issue1267] Py3K cannot run as ``python -S`` In-Reply-To: <47198279.9070102@cheimes.de> Message-ID: Guido van Rossum added the comment: Thanks for persevering!!! The dangers of switching between fileno(fp) and fp are actually well documented in the C and/or POSIX standards. The problem is caused in PyFile_FromFileEx() -- it creates a Python file object from the file descriptor. The fix actually only works because we're not using the FILE struct once PyTokenizer_FindEncoding() is called. I think it would be better to move the lseek() into call_find_module() so the FILE abstraction is not broken by PyTokenizer_FindEncoding(). I think there's still a bug or two lurking in this area: first, each time you call imp.find_module() you leak a FILE object; second, the encoding allocated in PyTokenizer_FindEncoding() is leaked. You're right that a lot of this could be avoided if we used file descriptors consistently. It seems find_module() itself doesn't read the file; it just needs to know that it's possible to open the file. Rewriting everywhere that uses PyFile_FromFile[Ex] to use file descriptors doesn't seem too hard; there are only a few places. __________________________________ Tracker __________________________________ From report at bugs.python.org Sat Oct 20 17:39:09 2007 From: report at bugs.python.org (Guido van Rossum) Date: Sat, 20 Oct 2007 15:39:09 -0000 Subject: [issue1267] Py3K cannot run as ``python -S`` In-Reply-To: Message-ID: Guido van Rossum added the comment: Sorry, I was wrong about the encoding leak; you fixed that. The FILE/fd issue is real though. __________________________________ Tracker __________________________________ From report at bugs.python.org Sat Oct 20 17:45:41 2007 From: report at bugs.python.org (BULOT) Date: Sat, 20 Oct 2007 15:45:41 -0000 Subject: [issue1294] Management of KeyboardInterrupt in cmd.py In-Reply-To: <1192815269.84.0.891380547821.issue1294@psf.upfronthosting.co.za> Message-ID: BULOT added the comment: Well, I made it with a diff -ruN, it works fine on my ubuntu. It is only a ctrl-C management only, not a ctrl-D. What do you mean by broken? Regards. Stephbul 2007/10/19, Guido van Rossum : > > > Guido van Rossum added the comment: > > Hmm... I don't think this is the right thing to do. The code is broken > in several ways. I recommend you find someone to help you come up with > a better patch in comp.lang.python. > > ---------- > keywords: +patch > > __________________________________ > Tracker > > __________________________________ > Added file: http://bugs.python.org/file8578/unnamed __________________________________ Tracker __________________________________ -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: unnamed Url: http://mail.python.org/pipermail/python-bugs-list/attachments/20071020/ddd46c70/attachment.txt From report at bugs.python.org Sat Oct 20 20:00:04 2007 From: report at bugs.python.org (Christian Heimes) Date: Sat, 20 Oct 2007 18:00:04 -0000 Subject: [issue1267] Py3K cannot run as ``python -S`` In-Reply-To: Message-ID: <471A4221.4070504@cheimes.de> Christian Heimes added the comment: Guido van Rossum wrote: > You're right that a lot of this could be avoided if we used file > descriptors consistently. It seems find_module() itself doesn't read > the file; it just needs to know that it's possible to open the file. > > Rewriting everywhere that uses PyFile_FromFile[Ex] to use file > descriptors doesn't seem too hard; there are only a few places. If I understand you right you want to alter the interface of PyFile_FromFile and PyFile_FromFileEx from PyFile_FromFileEx(FILE *fp, char *name, char *mode, int (*close)(FILE*), int buffering, char *encoding, char *newline) to PyFile_FromFileEx(int fd, char *name, char *mode, int (*close)(FILE*), int buffering, char *encoding, char *newline) ? I could write a patch and remove int (*close)(FILE*), too. It's no longer used by the functions. Christian __________________________________ Tracker __________________________________ From report at bugs.python.org Sat Oct 20 20:50:25 2007 From: report at bugs.python.org (Brett Cannon) Date: Sat, 20 Oct 2007 18:50:25 -0000 Subject: [issue1267] Py3K cannot run as ``python -S`` In-Reply-To: <471A4221.4070504@cheimes.de> Message-ID: Brett Cannon added the comment: On 10/20/07, Christian Heimes wrote: > > Christian Heimes added the comment: > > Guido van Rossum wrote: > > You're right that a lot of this could be avoided if we used file > > descriptors consistently. It seems find_module() itself doesn't read > > the file; it just needs to know that it's possible to open the file. > > > > Rewriting everywhere that uses PyFile_FromFile[Ex] to use file > > descriptors doesn't seem too hard; there are only a few places. > > If I understand you right you want to alter the interface of > PyFile_FromFile and PyFile_FromFileEx from > > PyFile_FromFileEx(FILE *fp, char *name, char *mode, int (*close)(FILE*), > int buffering, char *encoding, char *newline) > > to > > PyFile_FromFileEx(int fd, char *name, char *mode, int (*close)(FILE*), > int buffering, char *encoding, char *newline) > > ? > > I could write a patch and remove int (*close)(FILE*), too. It's no > longer used by the functions. Yes, I think you got it. -Brett __________________________________ Tracker __________________________________ From report at bugs.python.org Sat Oct 20 21:42:22 2007 From: report at bugs.python.org (Christian Heimes) Date: Sat, 20 Oct 2007 19:42:22 -0000 Subject: [issue1267] Py3K cannot run as ``python -S`` In-Reply-To: Message-ID: <471A5A1B.80500@cheimes.de> Christian Heimes added the comment: > Yes, I think you got it. Guido, Brett, how much of the code should I change? import.c is mainly using file pointers. Should I replace all operations on FILE with operations on a file descriptor? Christian __________________________________ Tracker __________________________________ From report at bugs.python.org Sat Oct 20 21:59:25 2007 From: report at bugs.python.org (Guido van Rossum) Date: Sat, 20 Oct 2007 19:59:25 -0000 Subject: [issue1267] Py3K cannot run as ``python -S`` In-Reply-To: <471A5A1B.80500@cheimes.de> Message-ID: Guido van Rossum added the comment: > Guido, Brett, how much of the code should I change? import.c is mainly > using file pointers. Should I replace all operations on FILE with > operations on a file descriptor? I think find_module() should return a file descriptor (fd), not a FILE*, but most of the rest of the code should call fdopen() on that fd. Only call_find_module() should use the fd to turn it into a Python file object. Then the amount of change should be pretty minimal. I recommend changing the name of the API used to turn a fd into file object while we're at it; that's one of the few guidelines we have for C API changes. __________________________________ Tracker __________________________________ From report at bugs.python.org Sat Oct 20 22:17:08 2007 From: report at bugs.python.org (Christian Heimes) Date: Sat, 20 Oct 2007 20:17:08 -0000 Subject: [issue1267] Py3K cannot run as ``python -S`` In-Reply-To: Message-ID: <471A6241.5090907@cheimes.de> Christian Heimes added the comment: Guido van Rossum wrote: > I think find_module() should return a file descriptor (fd), not a > FILE*, but most of the rest of the code should call fdopen() on that > fd. Only call_find_module() should use the fd to turn it into a Python > file object. Then the amount of change should be pretty minimal. K, I understand. > I recommend changing the name of the API used to turn a fd into file > object while we're at it; that's one of the few guidelines we have for > C API changes. Is PyFile_FromFd and PyFile_FromFdEx fine with you or do you prefer a different name like PyFile_FromFD and PyFile_FromFDEx or PyFile_FromFileDescriptor? I've another question. The os.tmpfile method is using tmpfile() which returns a file pointer. Do I have to dup its file number and explictely close the file pointer as shown below or is a simple fileno() enough? I haven't found sample code how to use a file descriptor after the file pointer is closed. static PyObject * posix_tmpfile(PyObject *self, PyObject *noargs) { FILE *fp; int fd; fp = tmpfile(); if (fp == NULL) return posix_error(); fd = dup(fileno(fp)); if (fd == -1) return posix_error(); fclose(fp); return PyFile_FromFD(fd, "", "w+b"); } __________________________________ Tracker __________________________________ From report at bugs.python.org Sat Oct 20 23:12:30 2007 From: report at bugs.python.org (Christian Heimes) Date: Sat, 20 Oct 2007 21:12:30 -0000 Subject: [issue1267] Py3K cannot run as ``python -S`` In-Reply-To: Message-ID: <471A6F3C.4030606@cheimes.de> Christian Heimes added the comment: > The dangers of switching between fileno(fp) and fp are actually well > documented in the C and/or POSIX standards. The problem is caused in > PyFile_FromFileEx() -- it creates a Python file object from the file > descriptor. The fix actually only works because we're not using the > FILE struct once PyTokenizer_FindEncoding() is called. I think it > would be better to move the lseek() into call_find_module() so the > FILE abstraction is not broken by PyTokenizer_FindEncoding(). FYI: http://www.gnu.org/software/libc/manual/html_mono/libc.html#Stream_002fDescriptor-Precautions http://www.gnu.org/software/libc/manual/html_mono/libc.html#Cleaning-Streams Christian __________________________________ Tracker __________________________________ From report at bugs.python.org Sun Oct 21 00:36:16 2007 From: report at bugs.python.org (Guido van Rossum) Date: Sat, 20 Oct 2007 22:36:16 -0000 Subject: [issue1267] Py3K cannot run as ``python -S`` In-Reply-To: <471A6241.5090907@cheimes.de> Message-ID: Guido van Rossum added the comment: > Is PyFile_FromFd and PyFile_FromFdEx fine with you or do you prefer a > different name like PyFile_FromFD and PyFile_FromFDEx or > PyFile_FromFileDescriptor? Let's have a single function PyFile_FromFd(fd, name, mode, buffering, encoding, newline). > I've another question. The os.tmpfile method is using tmpfile() which > returns a file pointer. Do I have to dup its file number and explictely > close the file pointer as shown below or is a simple fileno() enough? You should dup it; if you don't dup it, the fd will be closed when you call fclose(), rendering it useless; or when you don't call fclose(), you leak a FILE struct each time. __________________________________ Tracker __________________________________ From report at bugs.python.org Sun Oct 21 02:35:07 2007 From: report at bugs.python.org (Brett Cannon) Date: Sun, 21 Oct 2007 00:35:07 -0000 Subject: [issue1263] PEP 3137 patch - str8/str comparison should return false Message-ID: <1192926907.3.0.113013801667.issue1263@psf.upfronthosting.co.za> Brett Cannon added the comment: Attached is a fix for modulefinder. It is an ugly hack as modulefinder took the numeric opcode numbers from dis and passed them to chr(). But that doesn't work since that returns Unicode. So I took those single characters and passed them to str8(). Once str8() has its constructor match bytes() then the chr() call can be ditched and the dis values can be tossed into a single-item list. Added file: http://bugs.python.org/file8579/fix_modulefinder.diff __________________________________ Tracker __________________________________ -------------- next part -------------- A non-text attachment was scrubbed... Name: fix_modulefinder.diff Type: application/octet-stream Size: 1360 bytes Desc: not available Url : http://mail.python.org/pipermail/python-bugs-list/attachments/20071021/f3094036/attachment.obj From report at bugs.python.org Sun Oct 21 03:41:35 2007 From: report at bugs.python.org (Brett Cannon) Date: Sun, 21 Oct 2007 01:41:35 -0000 Subject: [issue1263] PEP 3137 patch - str8/str comparison should return false Message-ID: <1192930894.98.0.736872793764.issue1263@psf.upfronthosting.co.za> Brett Cannon added the comment: Attached is a fix for sqlite3. First issue was that the dictionary that was being used to store converters was having keys in Python code as Unicode but being compared against str8 in C. The second issue was that when an object was serialized using __conform__ and a Unicode object was returned, it was being unserialized as a str8 no matter what type of argument was returned. That makes the most sense if only a single type is going to be returned, so I left it as such and fixed the test to decode str8 to UTF-8 if passed to __init__. Added file: http://bugs.python.org/file8580/sqlite_fix.diff __________________________________ Tracker __________________________________ -------------- next part -------------- A non-text attachment was scrubbed... Name: sqlite_fix.diff Type: application/octet-stream Size: 1820 bytes Desc: not available Url : http://mail.python.org/pipermail/python-bugs-list/attachments/20071021/6ec8048d/attachment.obj From report at bugs.python.org Sun Oct 21 03:51:06 2007 From: report at bugs.python.org (Derek Shockey) Date: Sun, 21 Oct 2007 01:51:06 -0000 Subject: [issue1307] smtpd.SMTPServer throws exception on MAIL command with no arg Message-ID: <1192931466.78.0.585745682774.issue1307@psf.upfronthosting.co.za> New submission from Derek Shockey: smtpd.SMTPChannel contains a bug such that when connected to an SMTPServer (or any subclass thereof), issuing a MAIL command with no argument closes the socket and gives this error on the server: (:'NoneType' object is unsubscriptable ... smtpd.py|__getaddr|212]) The desired result is of course is to respond with a 501 Syntax error. The problem arises because the arg parameter passed to each smtp_* command handler function is None when there is no argument. arg is passed on to __getaddr which attempts a slice on the None object. A check for None in __getaddr that returns will allow the existing code to issue the appropriate 501 Syntax error. ---------- components: Library (Lib) messages: 56616 nosy: dshockey severity: normal status: open title: smtpd.SMTPServer throws exception on MAIL command with no arg versions: Python 2.5 __________________________________ Tracker __________________________________ From report at bugs.python.org Sun Oct 21 03:52:23 2007 From: report at bugs.python.org (Brett Cannon) Date: Sun, 21 Oct 2007 01:52:23 -0000 Subject: [issue1263] PEP 3137 patch - str8/str comparison should return false Message-ID: <1192931543.39.0.59696411771.issue1263@psf.upfronthosting.co.za> Brett Cannon added the comment: Attached is a patch to fix test_str. Basically there were a bunch of redundant tests for making sure that calling str() on an object called it's __str__ method. str8 no longer is directly relevant since it is no longer an actual string type. Added file: http://bugs.python.org/file8581/fix_test_str.diff __________________________________ Tracker __________________________________ -------------- next part -------------- A non-text attachment was scrubbed... Name: fix_test_str.diff Type: application/octet-stream Size: 2079 bytes Desc: not available Url : http://mail.python.org/pipermail/python-bugs-list/attachments/20071021/907f6685/attachment.obj From report at bugs.python.org Sun Oct 21 04:10:08 2007 From: report at bugs.python.org (Brett Cannon) Date: Sun, 21 Oct 2007 02:10:08 -0000 Subject: [issue1263] PEP 3137 patch - str8/str comparison should return false Message-ID: <1192932608.13.0.67340056363.issue1263@psf.upfronthosting.co.za> Brett Cannon added the comment: Guido, what do you want to do about the struct module for the various string formats (i.e., c, s, p)? Should they return str8 or Unicode? __________________________________ Tracker __________________________________ From report at bugs.python.org Sun Oct 21 04:15:26 2007 From: report at bugs.python.org (Brett Cannon) Date: Sun, 21 Oct 2007 02:15:26 -0000 Subject: [issue1263] PEP 3137 patch - str8/str comparison should return false Message-ID: <1192932926.76.0.543806070691.issue1263@psf.upfronthosting.co.za> Brett Cannon added the comment: Attached is a fix for test_subprocess. Simply had to change a call to str8() to str(). I am going to run the test suite, but that should leave only test_struct failing and that can be fixed as soon as Guido makes a call on whether str8 or str should be used for the string formats. Added file: http://bugs.python.org/file8582/fix_test_subprocess.diff __________________________________ Tracker __________________________________ -------------- next part -------------- A non-text attachment was scrubbed... Name: fix_test_subprocess.diff Type: application/octet-stream Size: 558 bytes Desc: not available Url : http://mail.python.org/pipermail/python-bugs-list/attachments/20071021/6c63f1de/attachment.obj From report at bugs.python.org Sun Oct 21 04:25:34 2007 From: report at bugs.python.org (Derek Shockey) Date: Sun, 21 Oct 2007 02:25:34 -0000 Subject: [issue1307] smtpd.SMTPServer throws exception on MAIL command with no arg Message-ID: <1192933534.27.0.412811489751.issue1307@psf.upfronthosting.co.za> Derek Shockey added the comment: Very simple patch that adds a ternary operator to skip the call to __getaddr if there is no arg. Added file: http://bugs.python.org/file8583/smtpd.diff __________________________________ Tracker __________________________________ -------------- next part -------------- A non-text attachment was scrubbed... Name: smtpd.diff Type: application/octet-stream Size: 471 bytes Desc: not available Url : http://mail.python.org/pipermail/python-bugs-list/attachments/20071021/2f994768/attachment-0001.obj From report at bugs.python.org Sun Oct 21 06:32:02 2007 From: report at bugs.python.org (Christian Heimes) Date: Sun, 21 Oct 2007 04:32:02 -0000 Subject: [issue1302] Fixes for profile/cprofile Message-ID: <1192941122.07.0.690431871356.issue1302@psf.upfronthosting.co.za> Christian Heimes added the comment: The new patch does a far more better job. I had the idea after a discussion with Alexandre on #python and a small debugging session. The tests for profile, cProfile and doctest are failing on my Linux box because Py_FileSystemDefaultEncoding is "UTF-8" but PyUnicode_Decode() has a shortcut for "utf-8" only. I've added a tolower loop and shortcuts for UTF-16 and UTF-32 to PyUnicode_Decode(). I've also disabled the tests on system with a fs encoding that isn't built in. ---------- nosy: +alexandre.vassalotti type: -> behavior Added file: http://bugs.python.org/file8584/py3k_profile_fix2.patches __________________________________ Tracker __________________________________ -------------- next part -------------- A non-text attachment was scrubbed... Name: py3k_profile_fix2.patches Type: application/octet-stream Size: 2651 bytes Desc: not available Url : http://mail.python.org/pipermail/python-bugs-list/attachments/20071021/1088341f/attachment.obj From report at bugs.python.org Sun Oct 21 06:40:47 2007 From: report at bugs.python.org (Christian Heimes) Date: Sun, 21 Oct 2007 04:40:47 -0000 Subject: [issue1267] Py3K cannot run as ``python -S`` Message-ID: <1192941646.96.0.901982833563.issue1267@psf.upfronthosting.co.za> Christian Heimes added the comment: > I think find_module() should return a file descriptor (fd), not a > FILE*, but most of the rest of the code should call fdopen() on that > fd. Only call_find_module() should use the fd to turn it into a Python > file object. Then the amount of change should be pretty minimal. I'd have to touch most functions in import.c and related files to change find_module() to use a file descriptor. It's a PITA and I don't think it's worse the effort for now. The new patch adds PyFile_FromFd and removes the other PyFile_FromFile* functions. It also changes some methods to use a file descriptor and some documentation. Two minor changes aren't related to the bug but they nagged me. Added file: http://bugs.python.org/file8585/py3k_filefromfd.patch __________________________________ Tracker __________________________________ -------------- next part -------------- A non-text attachment was scrubbed... Name: py3k_filefromfd.patch Type: text/x-diff Size: 10917 bytes Desc: not available Url : http://mail.python.org/pipermail/python-bugs-list/attachments/20071021/66c7a83e/attachment.patch From report at bugs.python.org Sun Oct 21 13:59:58 2007 From: report at bugs.python.org (Georg Brandl) Date: Sun, 21 Oct 2007 11:59:58 -0000 Subject: [issue1307] smtpd.SMTPServer throws exception on MAIL command with no arg Message-ID: <1192967998.9.0.606626200507.issue1307@psf.upfronthosting.co.za> Changes by Georg Brandl: ---------- keywords: +patch __________________________________ Tracker __________________________________ From report at bugs.python.org Sun Oct 21 18:00:25 2007 From: report at bugs.python.org (Guido van Rossum) Date: Sun, 21 Oct 2007 16:00:25 -0000 Subject: [issue1267] Py3K cannot run as ``python -S`` In-Reply-To: <1192941646.96.0.901982833563.issue1267@psf.upfronthosting.co.za> Message-ID: Guido van Rossum added the comment: Do you have access to Windows? I believe it doesn't have dup(). :-( __________________________________ Tracker __________________________________ From report at bugs.python.org Sun Oct 21 18:02:44 2007 From: report at bugs.python.org (Guido van Rossum) Date: Sun, 21 Oct 2007 16:02:44 -0000 Subject: [issue1263] PEP 3137 patch - str8/str comparison should return false In-Reply-To: <1192932608.13.0.67340056363.issue1263@psf.upfronthosting.co.za> Message-ID: Guido van Rossum added the comment: > Guido, what do you want to do about the struct module for the various > string formats (i.e., c, s, p)? Should they return str8 or Unicode? Oh, tough call. I think they should return str8 (i.e. bytes after the rename) because the encoding isn't known. Even though this will break more code, since I'm sure there's lots of code out there that assumes they return "text". __________________________________ Tracker __________________________________ From report at bugs.python.org Sun Oct 21 20:09:26 2007 From: report at bugs.python.org (Christian Heimes) Date: Sun, 21 Oct 2007 18:09:26 -0000 Subject: [issue1267] Py3K cannot run as ``python -S`` In-Reply-To: Message-ID: <471B95D3.1000804@cheimes.de> Christian Heimes added the comment: Guido van Rossum wrote: > Guido van Rossum added the comment: > > Do you have access to Windows? I believe it doesn't have dup(). :-( I've an old laptop with Win2k at my disposal but it has no VS yet. Can you point me to a set of instruction how to install VS 2003? I've just VS .NET 2005 available. __________________________________ Tracker __________________________________ From report at bugs.python.org Sun Oct 21 20:46:33 2007 From: report at bugs.python.org (Guido van Rossum) Date: Sun, 21 Oct 2007 18:46:33 -0000 Subject: [issue1267] Py3K cannot run as ``python -S`` In-Reply-To: <471B95D3.1000804@cheimes.de> Message-ID: Guido van Rossum added the comment: > > Do you have access to Windows? I believe it doesn't have dup(). :-( > > I've an old laptop with Win2k at my disposal but it has no VS yet. Can > you point me to a set of instruction how to install VS 2003? I've just > VS .NET 2005 available. Sorry, I'm as green as you when it comes to these. :-( But I believe I was mistaken about dup() not existing on Windows; dup() can't be used to duplicate sockets, but that's irrelevant here. So the dup()-based solution is fine. Alas, my family won't let me use the computer for more than a minute at a time today, so I won't be able to review any code... :-) __________________________________ Tracker __________________________________ From report at bugs.python.org Sun Oct 21 21:17:48 2007 From: report at bugs.python.org (billiejoex) Date: Sun, 21 Oct 2007 19:17:48 -0000 Subject: [issue1745035] DoS smtpd vulnerability Message-ID: <1192994268.09.0.346678877498.issue1745035@psf.upfronthosting.co.za> billiejoex added the comment: > What does this do when a line longer than 4096 bytes > is found? Does it report an error to the SMTP client? > That's my only concern. Sorry for replying so late. No, it does not report the error and this is bad. I've searched through RFCs and I found that RFC 821 and RFC 2821 at chapter 4.2.2 say that a 500 "Syntax error, command unrecognized" response could be used to report errors such as command lines too long. Modified smtpd.py in attachment. It should be definitively fine for inclusion now. ---------- severity: normal -> urgent type: -> security Added file: http://bugs.python.org/file8586/smtpd.py _____________________________________ Tracker _____________________________________ -------------- next part -------------- A non-text attachment was scrubbed... Name: smtpd.py Type: text/x-python Size: 18840 bytes Desc: not available Url : http://mail.python.org/pipermail/python-bugs-list/attachments/20071021/c7e67162/attachment-0001.py From report at bugs.python.org Sun Oct 21 21:18:13 2007 From: report at bugs.python.org (billiejoex) Date: Sun, 21 Oct 2007 19:18:13 -0000 Subject: [issue1745035] DoS smtpd vulnerability Message-ID: <1192994293.71.0.0208658023914.issue1745035@psf.upfronthosting.co.za> Changes by billiejoex: Added file: http://bugs.python.org/file8587/smtpd.diff _____________________________________ Tracker _____________________________________ From report at bugs.python.org Sun Oct 21 22:45:10 2007 From: report at bugs.python.org (James G. sack (jim)) Date: Sun, 21 Oct 2007 20:45:10 -0000 Subject: [issue1308] unicode(None) anomaly Message-ID: <1192999510.61.0.176237814745.issue1308@psf.upfronthosting.co.za> New submission from James G. sack (jim): '2.5 (r25:51908, Apr 10 2007, 10:27:40) \n[GCC 4.1.2 20070403 (Red Hat 4.1.2-8)]' unicode(None) u'None' This doesn't seem right, ;-) Regards, ,,jim ---------- components: Unicode messages: 56628 nosy: jgsack severity: normal status: open title: unicode(None) anomaly type: behavior versions: Python 2.5 __________________________________ Tracker __________________________________ From report at bugs.python.org Sun Oct 21 22:47:13 2007 From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=) Date: Sun, 21 Oct 2007 20:47:13 -0000 Subject: [issue1308] unicode(None) anomaly Message-ID: <1192999633.84.0.108327082833.issue1308@psf.upfronthosting.co.za> Martin v. L?wis added the comment: What answer did you expect instead? ---------- nosy: +loewis __________________________________ Tracker __________________________________ From report at bugs.python.org Sun Oct 21 23:12:53 2007 From: report at bugs.python.org (James G. sack (jim)) Date: Sun, 21 Oct 2007 21:12:53 -0000 Subject: [issue1308] unicode(None) anomaly Message-ID: <1193001173.65.0.220154720918.issue1308@psf.upfronthosting.co.za> James G. sack (jim) added the comment: (aside: Wow! that was a fast response to my posting!) I'm not really sure what makes the most sense, possibly: - an exception - u'' - None but not u'None'; not a string of length 4. That's quite unexpected! Regards, ..jim PS: I don't understand why I couldn't reply via email. I got an autoresponse You are not a registered user. Please register at: http://bugs.python.org/user?@template=register ...before sending mail to the tracker. Unknown address: jgsack... I tried the registration, but that failed. I thought I _was_ registered. Oh, well. :-[ ..jim __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Oct 22 01:28:03 2007 From: report at bugs.python.org (Guido van Rossum) Date: Sun, 21 Oct 2007 23:28:03 -0000 Subject: [issue1267] Py3K cannot run as ``python -S`` Message-ID: <1193009283.47.0.904750921061.issue1267@psf.upfronthosting.co.za> Changes by Guido van Rossum: ---------- resolution: accepted -> status: closed -> open __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Oct 22 02:10:52 2007 From: report at bugs.python.org (Guido van Rossum) Date: Mon, 22 Oct 2007 00:10:52 -0000 Subject: [issue1267] Py3K cannot run as ``python -S`` Message-ID: <1193011852.25.0.158561440136.issue1267@psf.upfronthosting.co.za> Guido van Rossum added the comment: OK, checked in. You might want to compare what I checked in to your patch; I did a few style cleanups. I also moved the lseek() call into import.c, where it seems more appropriate. Committed revision 58587. ---------- resolution: -> accepted status: open -> closed __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Oct 22 02:35:13 2007 From: report at bugs.python.org (Christian Heimes) Date: Mon, 22 Oct 2007 00:35:13 -0000 Subject: [issue1309] windows build fix Message-ID: <1193013313.48.0.697778250167.issue1309@psf.upfronthosting.co.za> New submission from Christian Heimes: bytes_methods.c isn't in PCbuild/pythoncore.vcproj ---------- components: Windows files: py3k_pcbuild_bytes.patch messages: 56632 nosy: tiran severity: normal status: open title: windows build fix type: compile error versions: Python 3.0 Added file: http://bugs.python.org/file8588/py3k_pcbuild_bytes.patch __________________________________ Tracker __________________________________ -------------- next part -------------- A non-text attachment was scrubbed... Name: py3k_pcbuild_bytes.patch Type: text/x-diff Size: 559 bytes Desc: not available Url : http://mail.python.org/pipermail/python-bugs-list/attachments/20071022/d54609b8/attachment.patch From report at bugs.python.org Mon Oct 22 02:59:21 2007 From: report at bugs.python.org (Christian Heimes) Date: Mon, 22 Oct 2007 00:59:21 -0000 Subject: [issue1267] Py3K cannot run as ``python -S`` In-Reply-To: <1193011852.25.0.158561440136.issue1267@psf.upfronthosting.co.za> Message-ID: <471BF5E7.1060400@cheimes.de> Christian Heimes added the comment: Guido van Rossum wrote: > You might want to compare what I checked in to your patch; I did a few > style cleanups. I also moved the lseek() call into import.c, where it > seems more appropriate. Ah I see that you prefer to keep assignment and check against NULL/-1 on two separate lines. I had the lseek() in PyTokenizer_FindEncoding() because I prefer functions that restore their environment. I find it less surprising when it restores the position of the file descriptor. By the way I got Windows, VS 2003 and several SDKs installed in VMWare today. It's annoying and it takes hours. Most unit tests are passing. http://wiki.python.org/moin/Building_Python_with_the_free_MS_C_Toolkit __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Oct 22 03:03:24 2007 From: report at bugs.python.org (James G. sack (jim)) Date: Mon, 22 Oct 2007 01:03:24 -0000 Subject: [issue1308] unicode(None) anomaly Message-ID: <1193015004.73.0.0232656348814.issue1308@psf.upfronthosting.co.za> James G. sack (jim) added the comment: Here's more: >>> unicode(object) u"" There seems to be an call to repr() somewhere in the process. This seems, at least to me, to violate the principle of least surprise, and I'm thinking that unicode(x) ought to return UnicodeDecodeError if x is not a string. Maybe this is argueable. If so, I'd like to be educated. :-) Regards, ..jim __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Oct 22 03:11:00 2007 From: report at bugs.python.org (Alexandre Vassalotti) Date: Mon, 22 Oct 2007 01:11:00 -0000 Subject: [issue1302] Fixes for profile/cprofile Message-ID: <1193015460.09.0.351659922484.issue1302@psf.upfronthosting.co.za> Alexandre Vassalotti added the comment: I don't think it's possible to add shortcuts in PyUnicode_Decode for UTF-16 and UTF-32 because the byte-order can be different depending of the platform. So, these two need to pass through the codecs module. I am sure if it's better, but I factored out the normalization routine into its own function. Added file: http://bugs.python.org/file8589/py3k_profile_fix-3.patch __________________________________ Tracker __________________________________ -------------- next part -------------- A non-text attachment was scrubbed... Name: py3k_profile_fix-3.patch Type: text/x-patch Size: 2881 bytes Desc: not available Url : http://mail.python.org/pipermail/python-bugs-list/attachments/20071022/7d8e7550/attachment-0001.bin From report at bugs.python.org Mon Oct 22 03:16:28 2007 From: report at bugs.python.org (Alexandre Vassalotti) Date: Mon, 22 Oct 2007 01:16:28 -0000 Subject: [issue1286] fileinput, StringIO, and cStringIO do not support the with protocol Message-ID: <1193015788.33.0.091704178688.issue1286@psf.upfronthosting.co.za> Alexandre Vassalotti added the comment: Do you have a use-case for this? In Py3k, I don't think adding support for the 'with' statement to StringIO makes any sense, since the close() method does nothing. ---------- nosy: +alexandre.vassalotti __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Oct 22 03:17:03 2007 From: report at bugs.python.org (Christian Heimes) Date: Mon, 22 Oct 2007 01:17:03 -0000 Subject: [issue1302] Fixes for profile/cprofile In-Reply-To: <1193015460.09.0.351659922484.issue1302@psf.upfronthosting.co.za> Message-ID: <471BFA0D.9090109@cheimes.de> Christian Heimes added the comment: Alexandre Vassalotti wrote: > I don't think it's possible to add shortcuts in PyUnicode_Decode for > UTF-16 and UTF-32 because the byte-order can be different depending of > the platform. So, these two need to pass through the codecs module. utf-16 and utf-32 are the the names for the native codecs. The explicit names are e.g. utf-16-be or utf-32-le. The last argument 0 also means "native byte order". I used a shorter algorithm to optimize the normalization for the special cases of the strcmp() shortcuts. Your version is fine but takes several CPU cycles longer. I don't think it has a large performance impact. ;) Christian __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Oct 22 04:23:04 2007 From: report at bugs.python.org (Christian Heimes) Date: Mon, 22 Oct 2007 02:23:04 -0000 Subject: [issue1310] tempfile breaks on Windows Message-ID: <1193019783.77.0.732948071539.issue1310@psf.upfronthosting.co.za> New submission from Christian Heimes: tempfile breaks on Windows because exception objectss no longer support e[0]. The fix is simple and short: Index: Lib/tempfile.py =================================================================== --- Lib/tempfile.py (Revision 58587) +++ Lib/tempfile.py (Arbeitskopie) @@ -201,7 +201,7 @@ del fp, fd return dir except (OSError, IOError) as e: - if e[0] != _errno.EEXIST: + if e.args[0] != _errno.EEXIST: break # no point trying more names in this directory pass ---------- components: Library (Lib) messages: 56638 nosy: tiran severity: normal status: open title: tempfile breaks on Windows type: behavior versions: Python 3.0 __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Oct 22 05:01:09 2007 From: report at bugs.python.org (Travis Oliphant) Date: Mon, 22 Oct 2007 03:01:09 -0000 Subject: [issue708374] add offset to mmap Message-ID: <1193022069.26.0.334828732304.issue708374@psf.upfronthosting.co.za> Travis Oliphant added the comment: I think this patch can be committed to SVN. Paul Moore has tested it on Windows and I (Travis Oliphant) have tested it on UNIX (Mac OS X). The patch also includes documentation updates and tests. ---------- nosy: +teoliphant ____________________________________ Tracker ____________________________________ From report at bugs.python.org Mon Oct 22 08:03:09 2007 From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=) Date: Mon, 22 Oct 2007 06:03:09 -0000 Subject: [issue1308] unicode(None) anomaly Message-ID: <1193032989.59.0.562306079166.issue1308@psf.upfronthosting.co.za> Martin v. L?wis added the comment: Ok. This is not a bug, but by design. unicode(X)==unicode(str(X)) for most things, and str(X)==repr(X) for most things. repr(None)=='None', hence the result you see. Closing as invalid. P.S. To respond via email, you have to add your email address to Your Details (you need to add all email addresses you want to use as From addresses). ---------- resolution: -> invalid status: open -> closed __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Oct 22 08:04:21 2007 From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=) Date: Mon, 22 Oct 2007 06:04:21 -0000 Subject: [issue1309] windows build fix Message-ID: <1193033061.08.0.0310966047945.issue1309@psf.upfronthosting.co.za> Changes by Martin v. L?wis: ---------- keywords: +patch __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Oct 22 08:05:35 2007 From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=) Date: Mon, 22 Oct 2007 06:05:35 -0000 Subject: [issue1310] tempfile breaks on Windows Message-ID: <1193033135.28.0.407856729217.issue1310@psf.upfronthosting.co.za> Changes by Martin v. L?wis: ---------- keywords: +patch __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Oct 22 08:28:39 2007 From: report at bugs.python.org (James G. sack (jim)) Date: Mon, 22 Oct 2007 06:28:39 -0000 Subject: [issue1308] unicode(None) anomaly In-Reply-To: <1193032989.59.0.562306079166.issue1308@psf.upfronthosting.co.za> Message-ID: <471C4310.4040504@san.rr.com> James G. sack (jim) added the comment: Martin v. L?wis wrote: > Martin v. L?wis added the comment: > > Ok. This is not a bug, but by design. unicode(X)==unicode(str(X)) for > most things, and str(X)==repr(X) for most things. repr(None)=='None', > hence the result you see. Closing as invalid. > > P.S. To respond via email, you have to add your email address to Your > Details (you need to add all email addresses you want to use as From > addresses). > > ---------- > resolution: -> invalid > status: open -> closed > > __________________________________ > Tracker > > __________________________________ > OK, thanks Martin. Now that I think about it, I do understand. My difficulty (and source of my surprise) was in mistakenly thinking of unicode() as performing a string translation operation (that is, an operation on strings). I would now say that it is better thought of as a representation function quite parallel to the str() function. With that mindset, there is no surprise. Thanks again, for your prompt attention and useful replies. Regards, ..jim __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Oct 22 09:38:37 2007 From: report at bugs.python.org (Brett Cannon) Date: Mon, 22 Oct 2007 07:38:37 -0000 Subject: [issue1263] PEP 3137 patch - str8/str comparison should return false Message-ID: <1193038717.27.0.301903940927.issue1263@psf.upfronthosting.co.za> Brett Cannon added the comment: Attached is a fix for test_struct. All of the string tests now assume str8 is returned when arguments of bytes, str8 or str are given for the various string formats. All tests now pass. Re-assigning to myself to check everything in when it isn't so late at night. =) ---------- assignee: gvanrossum -> brett.cannon Added file: http://bugs.python.org/file8590/fix_test_struct.diff __________________________________ Tracker __________________________________ -------------- next part -------------- A non-text attachment was scrubbed... Name: fix_test_struct.diff Type: application/octet-stream Size: 3285 bytes Desc: not available Url : http://mail.python.org/pipermail/python-bugs-list/attachments/20071022/297e6df1/attachment.obj From report at bugs.python.org Mon Oct 22 09:39:01 2007 From: report at bugs.python.org (Brett Cannon) Date: Mon, 22 Oct 2007 07:39:01 -0000 Subject: [issue1263] PEP 3137 patch - str8/str comparison should return false Message-ID: <1193038741.19.0.437705720438.issue1263@psf.upfronthosting.co.za> Changes by Brett Cannon: ---------- keywords: +py3k priority: -> immediate type: rfe -> behavior __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Oct 22 10:05:51 2007 From: report at bugs.python.org (Yitz Gale) Date: Mon, 22 Oct 2007 08:05:51 -0000 Subject: [issue1286] fileinput, StringIO, and cStringIO do not support the with protocol Message-ID: <1193040351.92.0.947877213236.issue1286@psf.upfronthosting.co.za> Yitz Gale added the comment: These objects are supposed to be drop-in replacements for file handles. Except in legacy code, the way you use a file handle is: with function_to_create_fh as fh: If these objects do not support the with protocol, the only way to use them is to refactor this code. That may not even be possible, e.g., if it is in a library, or it may not be desirable to refactor. Even if you can refactor it, I don't think you can call these objects file-like objects if you can't use them like a file. Note that in legacy code, you used to write: fh = function_to_get_fh try: finally: fh.close() If function_to_get_fh happens to return some other file-like object and not an actual file, this still works fine without any refactoring. You wrote: > In Py3k, I don't think adding support > for the 'with' statement to StringIO makes > any sense, since the close() > method does nothing. So do you propse removing the close() method altogether? Of course the answer is "no", because then you could not use the object like a file. The same is true for the with protocol. (I now retract the words "that needs to be closed" from my original comment. All file-like objects should support the with protocol, regardles of whether their close() method actually does anything.) __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Oct 22 14:04:18 2007 From: report at bugs.python.org (=?utf-8?q?David_K=C3=A5gedal?=) Date: Mon, 22 Oct 2007 12:04:18 -0000 Subject: [issue1311] os.path.exists(os.devnul) regression on windows Message-ID: <1193054658.57.0.203252941268.issue1311@psf.upfronthosting.co.za> New submission from David K?gedal: When moving from Python 2.4 to Python 2.5, my program stopped working on win32 because of a change in os.path.exists. I couldn't find any description of the change, so I can only assume it's a bug. The os.devnul variable contains the name of the "null file", which is "/dev/null" on posix, and "nul" on win32. As I understand it, "NUL" is a file that exists in every directory on win32. Opening the "nul" file with open("nul", "r") works fine, but os.path.exists("nul") returns False. In Python 2.4, it returns True. ---------- components: Library (Lib) messages: 56644 nosy: d_kagedal severity: normal status: open title: os.path.exists(os.devnul) regression on windows versions: Python 2.5 __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Oct 22 14:23:20 2007 From: report at bugs.python.org (=?utf-8?q?David_K=C3=A5gedal?=) Date: Mon, 22 Oct 2007 12:23:20 -0000 Subject: [issue1311] os.path.exists(os.devnull) regression on windows Message-ID: <1193055800.15.0.576636131835.issue1311@psf.upfronthosting.co.za> David K?gedal added the comment: It's called os.devnull, and nothing else. ---------- title: os.path.exists(os.devnul) regression on windows -> os.path.exists(os.devnull) regression on windows __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Oct 22 14:42:56 2007 From: report at bugs.python.org (Georg Brandl) Date: Mon, 22 Oct 2007 12:42:56 -0000 Subject: [issue1310] tempfile breaks on Windows Message-ID: <1193056976.54.0.884413918518.issue1310@psf.upfronthosting.co.za> Georg Brandl added the comment: Fixed in r58590. ---------- nosy: +georg.brandl resolution: -> fixed status: open -> closed __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Oct 22 15:32:24 2007 From: report at bugs.python.org (Lauri Alanko) Date: Mon, 22 Oct 2007 13:32:24 -0000 Subject: [issue1298] Support for z/OS and EBCDIC. Message-ID: <1193059944.59.0.415522680726.issue1298@psf.upfronthosting.co.za> Lauri Alanko added the comment: Further comments on the port can be at: http://mail.python.org/pipermail/python-dev/2007-October/074991.html __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Oct 22 18:00:53 2007 From: report at bugs.python.org (Guido van Rossum) Date: Mon, 22 Oct 2007 16:00:53 -0000 Subject: [issue1309] windows build fix Message-ID: <1193068853.57.0.969987752728.issue1309@psf.upfronthosting.co.za> Guido van Rossum added the comment: Committed revision 58592. ---------- nosy: +gvanrossum resolution: -> accepted status: open -> closed __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Oct 22 18:27:57 2007 From: report at bugs.python.org (Guido van Rossum) Date: Mon, 22 Oct 2007 16:27:57 -0000 Subject: [issue1307] smtpd.SMTPServer throws exception on MAIL command with no arg Message-ID: <1193070477.96.0.537407683143.issue1307@psf.upfronthosting.co.za> Guido van Rossum added the comment: Thanks! Committed revision 58594. Is there time to backport this to 2.5.2? ---------- assignee: -> nnorwitz nosy: +gvanrossum, nnorwitz resolution: -> accepted __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Oct 22 18:34:34 2007 From: report at bugs.python.org (Guido van Rossum) Date: Mon, 22 Oct 2007 16:34:34 -0000 Subject: [issue1304] py3k compilation on Windows Message-ID: <1193070874.88.0.326509940945.issue1304@psf.upfronthosting.co.za> Guido van Rossum added the comment: This doesn't apply cleanly with today's trunk, and that's not just due to the fix by Christian Heimes (which I checked in before noticing this) that fixes the same issue (bytes_methods.c). Can you & Christian please work together on a new patch? I don't have Windows access but I will check it in if it applies cleanly. ---------- keywords: +patch nosy: +gvanrossum __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Oct 22 18:45:05 2007 From: report at bugs.python.org (Guido van Rossum) Date: Mon, 22 Oct 2007 16:45:05 -0000 Subject: [issue1305] socket.py hangs on Mac OS X Message-ID: <1193071505.12.0.223281320262.issue1305@psf.upfronthosting.co.za> Guido van Rossum added the comment: Odd. Smells like an OSX issue that we can't do anything about. I note that only attempts 250, 500, 750 (and so on if you increase the counter) have this behavior. I wonder if you'r simply filling up some kernel queue too fast; if I insert time.sleep(0.001) in the for loop it won't happen. ---------- nosy: +gvanrossum resolution: -> wont fix status: open -> closed __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Oct 22 19:13:49 2007 From: report at bugs.python.org (Facundo Batista) Date: Mon, 22 Oct 2007 17:13:49 -0000 Subject: [issue1311] os.path.exists(os.devnull) regression on windows Message-ID: <1193073229.94.0.917122689802.issue1311@psf.upfronthosting.co.za> Facundo Batista added the comment: You migrated only of Python version, or also of windows installation? I checked Py25 and Py23 in my Win 2k, and in both I have the same behaviour: C:\Python23>python Python 2.3.5 (#62, Feb 8 2005, 16:23:02) [MSC v.1200 32 bit (Intel)] on win32 Type "help", "copyright", "credits" or "license" for more information. >>> import os >>> os.stat("nul") Traceback (most recent call last): File "", line 1, in ? OSError: [Errno 22] Invalid argument: 'nul' >>> os.path.exists("nul") False >>> I checked the os.stat() function because the documentation says that if it gives an error, exists() will return False (and that this is how it's implemented). BTW, note that if you call to the GetFileAttributesEx() function of kernel32.dll by yourself, it will give error for the "NUL" file, showing that it actually does not exist. Because of this, I'd say that current behaviour of os.exists() is ok, but I want to know the answer of my question regarding your change before closing this as not-a-bug. Thanks! ---------- nosy: +facundobatista __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Oct 22 20:08:36 2007 From: report at bugs.python.org (Kurt B. Kaiser) Date: Mon, 22 Oct 2007 18:08:36 -0000 Subject: [issue1253] IDLE - Percolator overhaul Message-ID: <1193076516.33.0.537955601982.issue1253@psf.upfronthosting.co.za> Kurt B. Kaiser added the comment: What change was required to allow Squeezer and ShellLogger to co-exist? __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Oct 22 21:41:54 2007 From: report at bugs.python.org (Neal Norwitz) Date: Mon, 22 Oct 2007 19:41:54 -0000 Subject: [issue1307] smtpd.SMTPServer throws exception on MAIL command with no arg Message-ID: <1193082114.38.0.760908102771.issue1307@psf.upfronthosting.co.za> Neal Norwitz added the comment: It would be great to get this into 2.5.2. ---------- assignee: nnorwitz -> gvanrossum __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Oct 22 22:19:07 2007 From: report at bugs.python.org (Daniel Nouri) Date: Mon, 22 Oct 2007 20:19:07 -0000 Subject: [issue1312] doctest EXCEPTION_RE can't handle preceding output Message-ID: <1193084346.99.0.810572537289.issue1312@psf.upfronthosting.co.za> New submission from Daniel Nouri: doctest.DocTestParser._EXCEPTION_RE does not allow for output before the actual traceback. Attached is a simple test that demonstrates the problem. This patch fixes it: --- /usr/lib/python2.5/doctest.py 2007-10-22 21:45:21.000000000 +0200 +++ /home/daniel/tmp/doctest.py 2007-10-22 22:19:12.000000000 +0200 @@ -513,7 +513,7 @@ _EXCEPTION_RE = re.compile(r""" # Grab the traceback header. Different versions of Python have # said different things on the first traceback line. - ^(?P Traceback\ \( + .*^(?P Traceback\ \( (?: most\ recent\ call\ last | innermost\ last ) \) : _EXCEPTION_RE = re.compile(r""" # Grab the traceback header. Different versions of Python have # said different things on the first traceback line. ^(?P Traceback\ \( (?: most\ recent\ call\ last | innermost\ last ) \) : ) \s* $ # toss trailing whitespace on the header. (?P .*?) # don't blink: absorb stuff until... ^ (?P \w+ .*) # a line *starts* with alphanum. """, re.VERBOSE | re.MULTILINE | re.DOTALL) ---------- components: Library (Lib) files: doctest-bug.py messages: 56655 nosy: nouri severity: normal status: open title: doctest EXCEPTION_RE can't handle preceding output versions: Python 2.5 Added file: http://bugs.python.org/file8591/doctest-bug.py __________________________________ Tracker __________________________________ -------------- next part -------------- A non-text attachment was scrubbed... Name: doctest-bug.py Type: text/x-python Size: 302 bytes Desc: not available Url : http://mail.python.org/pipermail/python-bugs-list/attachments/20071022/a822c701/attachment-0001.py From report at bugs.python.org Mon Oct 22 22:25:29 2007 From: report at bugs.python.org (Brett Cannon) Date: Mon, 22 Oct 2007 20:25:29 -0000 Subject: [issue1263] PEP 3137 patch - str8/str comparison should return false Message-ID: <1193084729.12.0.474030385821.issue1263@psf.upfronthosting.co.za> Brett Cannon added the comment: Everything committed in r58596. Thanks for the help, Thomas! ---------- resolution: -> accepted status: open -> closed __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Oct 22 22:31:01 2007 From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=) Date: Mon, 22 Oct 2007 20:31:01 -0000 Subject: [issue1312] doctest EXCEPTION_RE can't handle preceding output Message-ID: <1193085061.59.0.145692253768.issue1312@psf.upfronthosting.co.za> Changes by Martin v. L?wis: ---------- keywords: +patch __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Oct 22 22:38:12 2007 From: report at bugs.python.org (Facundo Batista) Date: Mon, 22 Oct 2007 20:38:12 -0000 Subject: [issue1305] socket.py hangs on Mac OS X Message-ID: <1193085492.0.0.119633970807.issue1305@psf.upfronthosting.co.za> Facundo Batista added the comment: What happens if you force the garbage collector to collect the just opened and not used socket? Maybe the problem is that the operating system run out of file handlers (if you leave some time in the middle, the GC collects the sockets, freeinig the file handlers). Other test could be to disable the GC, and see what happens with that time.sleep in the middle. ---------- nosy: +facundobatista __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Oct 22 23:09:56 2007 From: report at bugs.python.org (Nathan Haines) Date: Mon, 22 Oct 2007 21:09:56 -0000 Subject: [issue1313] Typo in Python Library Reference documentation: logging module Message-ID: <1193087395.88.0.157483594139.issue1313@psf.upfronthosting.co.za> New submission from Nathan Haines: In the Python Library Reference manual, in section 14.5 (logging), there is a typo in the debug function example code. In the 2.5 PDF this is on page 446. The last line reads: logging.warning("Protocol problem: %s", "connection reset", extra=d) This should read: logging.warning("Protocol problem: %s", "connection reset", extra=dict) This error persists in the 2.6 and 3.0 documentation. ---------- components: Documentation messages: 56658 nosy: nhaines severity: normal status: open title: Typo in Python Library Reference documentation: logging module versions: Python 2.5, Python 2.6, Python 3.0 __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Oct 22 23:43:05 2007 From: report at bugs.python.org (James Antill) Date: Mon, 22 Oct 2007 21:43:05 -0000 Subject: [issue1179] [CVE-2007-4965] Integer overflow in imageop module Message-ID: <1193089385.5.0.175139958818.issue1179@psf.upfronthosting.co.za> James Antill added the comment: Not sure who Neal is, and this probably isn't a final upstream fix ... but it's what I've applied to Fedora's python. It's basically the same patch as before, but it keeps the original * tests instead of just replacing them with / tests. So given: if x * y != len ...the first patch did: if len / x != y ...and this patch does: if x * y != len || len / x != y Added file: http://bugs.python.org/file8592/python-2.5.CVE-2007-4965-int-overflow.patch __________________________________ Tracker __________________________________ -------------- next part -------------- A non-text attachment was scrubbed... Name: python-2.5.CVE-2007-4965-int-overflow.patch Type: text/x-patch Size: 6281 bytes Desc: not available Url : http://mail.python.org/pipermail/python-bugs-list/attachments/20071022/eb921328/attachment.bin From report at bugs.python.org Tue Oct 23 00:08:21 2007 From: report at bugs.python.org (Amaury Forgeot d'Arc) Date: Mon, 22 Oct 2007 22:08:21 -0000 Subject: [issue1304] py3k compilation on Windows Message-ID: <1193090901.3.0.502619902989.issue1304@psf.upfronthosting.co.za> Amaury Forgeot d'Arc added the comment: I generated the file with "svn diff", on Windows. Is it a line ending issue in the diff file? Many text files have the svn:eol-style=native property, but the PCBuild8/*/*.vcproj don't. I upload a new version of the patch, with all line endings converted to Unix mode. It should match your local copy. Added file: http://bugs.python.org/file8593/win32build.2.diff __________________________________ Tracker __________________________________ -------------- next part -------------- A non-text attachment was scrubbed... Name: win32build.2.diff Type: application/octet-stream Size: 2858 bytes Desc: not available Url : http://mail.python.org/pipermail/python-bugs-list/attachments/20071022/679ced72/attachment.obj From report at bugs.python.org Tue Oct 23 00:19:15 2007 From: report at bugs.python.org (Guido van Rossum) Date: Mon, 22 Oct 2007 22:19:15 -0000 Subject: [issue1304] py3k compilation on Windows Message-ID: <1193091555.4.0.702916419235.issue1304@psf.upfronthosting.co.za> Guido van Rossum added the comment: Yup, I think that was it. Sorry. Committed revision 58597. ---------- resolution: -> accepted status: open -> closed __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Oct 23 00:59:47 2007 From: report at bugs.python.org (Guido van Rossum) Date: Mon, 22 Oct 2007 22:59:47 -0000 Subject: [issue708374] add offset to mmap Message-ID: <1193093987.2.0.0682856570251.issue708374@psf.upfronthosting.co.za> Guido van Rossum added the comment: Fine with me! ---------- nosy: +gvanrossum ____________________________________ Tracker ____________________________________ From report at bugs.python.org Tue Oct 23 02:31:05 2007 From: report at bugs.python.org (Brett Cannon) Date: Tue, 23 Oct 2007 00:31:05 -0000 Subject: [issue1303] adapt str8 constructor to bytes constructor Message-ID: <1193099465.96.0.655278115781.issue1303@psf.upfronthosting.co.za> Brett Cannon added the comment: The changes to str8 look fine. Now it's time to find out how badly tests break since Georg's patch was generated. =) ---------- assignee: gvanrossum -> brett.cannon __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Oct 23 04:44:12 2007 From: report at bugs.python.org (Travis Oliphant) Date: Tue, 23 Oct 2007 02:44:12 -0000 Subject: [issue708374] add offset to mmap Message-ID: <1193107452.07.0.874881869417.issue708374@psf.upfronthosting.co.za> Travis Oliphant added the comment: I applied phuang's patch in revision 58598. This can be closed. ____________________________________ Tracker ____________________________________ From report at bugs.python.org Tue Oct 23 04:45:09 2007 From: report at bugs.python.org (Travis Oliphant) Date: Tue, 23 Oct 2007 02:45:09 -0000 Subject: [issue1089974] mmap missing offset parameter Message-ID: <1193107509.87.0.322385230167.issue1089974@psf.upfronthosting.co.za> Travis Oliphant added the comment: This issue can be closed. The issue is resolved in SVN. ---------- nosy: +teoliphant _____________________________________ Tracker _____________________________________ From report at bugs.python.org Tue Oct 23 05:13:35 2007 From: report at bugs.python.org (Guido van Rossum) Date: Tue, 23 Oct 2007 03:13:35 -0000 Subject: [issue708374] add offset to mmap Message-ID: <1193109215.01.0.529774963447.issue708374@psf.upfronthosting.co.za> Changes by Guido van Rossum: ---------- resolution: -> accepted status: open -> closed ____________________________________ Tracker ____________________________________ From report at bugs.python.org Tue Oct 23 05:26:05 2007 From: report at bugs.python.org (Christian Heimes) Date: Tue, 23 Oct 2007 03:26:05 -0000 Subject: [issue1303] adapt str8 constructor to bytes constructor Message-ID: <1193109965.74.0.932231158282.issue1303@psf.upfronthosting.co.za> Changes by Christian Heimes: ---------- nosy: +tiran __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Oct 23 05:49:08 2007 From: report at bugs.python.org (Guido van Rossum) Date: Tue, 23 Oct 2007 03:49:08 -0000 Subject: [issue1061] ABC caches should use weak refs Message-ID: <1193111348.88.0.595176811299.issue1061@psf.upfronthosting.co.za> Guido van Rossum added the comment: Thanks Georg; please check it in! ---------- assignee: gvanrossum -> georg.brandl resolution: -> accepted __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Oct 23 07:32:11 2007 From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=) Date: Tue, 23 Oct 2007 05:32:11 -0000 Subject: [issue1298] Support for z/OS and EBCDIC. Message-ID: <1193117531.18.0.538603965423.issue1298@psf.upfronthosting.co.za> Martin v. L?wis added the comment: I'm marking the patch as rejected, but leave it open. It seems clear that it cannot be incorporated into Python because of the maintenance issues (the only reasonable way to incorporate it would be if a long-time Python contributor steps forward and offers to maintain it, which seems unlikely). I'm leaving it open for the moment so people can easily find it. I encourage you to find some new home for the patch, e.g. by submitting it to PyPI (or to some System z community page if there is one); at this point, it should be closed. If the patch is still around five years from now, and still maintained, I might be interested in stepping forward to support it (assuming I am still a Python contributor at this point). ---------- nosy: +loewis resolution: -> rejected __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Oct 23 07:35:54 2007 From: report at bugs.python.org (Neal Norwitz) Date: Tue, 23 Oct 2007 05:35:54 -0000 Subject: [issue1307] smtpd.SMTPServer throws exception on MAIL command with no arg Message-ID: <1193117754.63.0.623679695044.issue1307@psf.upfronthosting.co.za> Neal Norwitz added the comment: Thanks for the patch. Committed revision 58599. (2.5) ---------- status: open -> closed __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Oct 23 07:45:02 2007 From: report at bugs.python.org (Neal Norwitz) Date: Tue, 23 Oct 2007 05:45:02 -0000 Subject: [issue1313] Typo in Python Library Reference documentation: logging module Message-ID: <1193118302.48.0.437906844556.issue1313@psf.upfronthosting.co.za> Neal Norwitz added the comment: Thanks for the report. Committed revision 58600. (2.5) Committed revision 58601. 3.0 will be fixed when we merge. ---------- assignee: -> nnorwitz nosy: +nnorwitz resolution: -> fixed status: open -> closed __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Oct 23 08:02:48 2007 From: report at bugs.python.org (Brett Cannon) Date: Tue, 23 Oct 2007 06:02:48 -0000 Subject: [issue1303] adapt str8 constructor to bytes constructor Message-ID: <1193119368.27.0.801583759811.issue1303@psf.upfronthosting.co.za> Brett Cannon added the comment: Attached is an updated patch. I didn't touch Georg's code short of tossing in some comments on whether we wanted to sneak around some APIs for performance or not. Anything I added was to make all but one test pass. And that one test is test_str. There is now this odd mixture of test_unicode, test_str, and test_bytes. But that doesn't really fit anymore since unicode is now str, so that file should probably get renamed. And str8 is becoming more like bytes. That means that string_tests is really just tests for what is now str and we need a bytes_tests thing for str8 and bytes. Assigning back to Guido since he seems to be assigned everything that is holding up 3.0a2. =) If I am lucky I will be able to help with this testing reorg, but that is iffy. ---------- assignee: brett.cannon -> gvanrossum Added file: http://bugs.python.org/file8594/str_constructor_updated.diff __________________________________ Tracker __________________________________ -------------- next part -------------- A non-text attachment was scrubbed... Name: str_constructor_updated.diff Type: application/octet-stream Size: 20100 bytes Desc: not available Url : http://mail.python.org/pipermail/python-bugs-list/attachments/20071023/128d1fe9/attachment-0001.obj From report at bugs.python.org Tue Oct 23 08:27:05 2007 From: report at bugs.python.org (Georg Brandl) Date: Tue, 23 Oct 2007 06:27:05 -0000 Subject: [issue1061] ABC caches should use weak refs Message-ID: <1193120825.53.0.350422568895.issue1061@psf.upfronthosting.co.za> Georg Brandl added the comment: Committed r58602. ---------- status: open -> closed __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Oct 23 08:31:24 2007 From: report at bugs.python.org (Georg Brandl) Date: Tue, 23 Oct 2007 06:31:24 -0000 Subject: [issue1303] adapt str8 constructor to bytes constructor Message-ID: <1193121084.39.0.006665922146.issue1303@psf.upfronthosting.co.za> Georg Brandl added the comment: I'll perhaps find some time today to try and make the tests useful and consistent again. __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Oct 23 08:53:22 2007 From: report at bugs.python.org (Georg Brandl) Date: Tue, 23 Oct 2007 06:53:22 -0000 Subject: [issue1071] unicode.translate() doesn't error out on invalid translation table Message-ID: <1193122401.92.0.971312044659.issue1071@psf.upfronthosting.co.za> Georg Brandl added the comment: Committed to Py3k as r58603. ---------- resolution: -> accepted status: open -> closed __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Oct 23 08:59:52 2007 From: report at bugs.python.org (Georg Brandl) Date: Tue, 23 Oct 2007 06:59:52 -0000 Subject: [issue1089974] mmap missing offset parameter Message-ID: <1193122792.6.0.256618906908.issue1089974@psf.upfronthosting.co.za> Changes by Georg Brandl: ---------- resolution: -> fixed status: open -> closed superseder: -> add offset to mmap _____________________________________ Tracker _____________________________________ From report at bugs.python.org Tue Oct 23 09:09:27 2007 From: report at bugs.python.org (=?utf-8?q?David_K=C3=A5gedal?=) Date: Tue, 23 Oct 2007 07:09:27 -0000 Subject: [issue1311] os.path.exists(os.devnull) regression on windows Message-ID: <1193123367.57.0.546891088026.issue1311@psf.upfronthosting.co.za> David K?gedal added the comment: I tried it on two different machines, and got two different answers: conan$ /cygdrive/c/Python25/python -c 'import os.path; print os.path.exists("nul")' False conan$ /cygdrive/c/Python24/python -c 'import os.path; print os.path.exists("nul")' False conan$ /cygdrive/c/Python24/python -c 'import os; print os.stat("nul")' Traceback (most recent call last): File "", line 1, in ? OSError: [Errno 22] Invalid argument: 'nul' conan$ /cygdrive/c/Python25/python -c 'import os; print os.stat("nul")' Traceback (most recent call last): File "", line 1, in WindowsError: [Error 87] The parameter is incorrect: 'nul' titti$ /cygdrive/c/Python24/python -c 'import os.path; print os.path.exists("nul")' True titti$ /cygdrive/c/Python25/python -c 'import os.path; print os.path.exists("nul")' False titti$ /cygdrive/c/Python24/python -c 'import os; print os.stat("nul")' (33206, 0L, 3, 1, 0, 0, 0L, -1, -1, -1) titti$ /cygdrive/c/Python25/python -c 'import os; print os.stat("nul")'Traceback (most recent call last): File "", line 1, in WindowsError: [Error 87] The parameter is incorrect: 'nul' I ran it from a cygwin prompt, but the pythons are native. So you are correct that it doesn't work as I expected in Python 2.4 either on the "conan" host.. On "titti", there is a difference in how os.path.exist works between 2.4 and 2.5. On "conan" there is actually also a difference, but only in the exception raised by os.stat. I don't know what the differences between these installation are. __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Oct 23 10:36:00 2007 From: report at bugs.python.org (Christian Heimes) Date: Tue, 23 Oct 2007 08:36:00 -0000 Subject: [issue1314] Patch for strftime problem on German Windows Message-ID: <1193128559.94.0.435784915491.issue1314@psf.upfronthosting.co.za> New submission from Christian Heimes: The patch fixes the failing unit tests for time and strptime on German and probably other Windows installations. - ret = PyUnicode_FromStringAndSize(outbuf, buflen); + ret = PyUnicode_Decode(outbuf, buflen, + TZNAME_ENCODING, NULL); ---------- components: Extension Modules files: py3k_win_strftime.patch messages: 56675 nosy: tiran severity: normal status: open title: Patch for strftime problem on German Windows type: behavior versions: Python 3.0 Added file: http://bugs.python.org/file8595/py3k_win_strftime.patch __________________________________ Tracker __________________________________ -------------- next part -------------- A non-text attachment was scrubbed... Name: py3k_win_strftime.patch Type: text/x-diff Size: 473 bytes Desc: not available Url : http://mail.python.org/pipermail/python-bugs-list/attachments/20071023/ec394a3a/attachment.patch From report at bugs.python.org Tue Oct 23 11:46:55 2007 From: report at bugs.python.org (Jean-Yves MENGANT) Date: Tue, 23 Oct 2007 09:46:55 -0000 Subject: [issue1298] Support for z/OS and EBCDIC. Message-ID: <1193132815.73.0.435321557595.issue1298@psf.upfronthosting.co.za> Jean-Yves MENGANT added the comment: Let me provide my contribution to this discussion around this ZOS port topic : I initially made the Python 2.2 and 2.4 for ZOS platform and ask the python community to link to my pages as a support to ZOS at that time Lauri get in touch with me couple of weeks ago asking if I was planning to make a port of the 2.5 ; since I was waiting for 2.6 before initiating a new port, He goes ahead and makes the 2.5 port happen now. About how important is the ZOS system ; let me argue around that : even if ZOS is an IBM proprietary OS which has been there for decades it will be there for a long time since it occupies a very specific 'niche' on the os'es market And since IBM has heavily spoiled the migration path to Unix in order to keep its revenues on it migrating those systems to plain vanilla unixes is a nightmare => Today every US or European big company s having a ZOS sytem somewhere. Next even if ZOS is proprietary and EBCDIC it has a peasonable POSIX.5 compliant subsystem and a descent C/C++ compiler which makes the port of python not too complex. >From a script standpoint there are today 3 available scripting languages availables : - REXX (the mike cowlishaw script language) , perl and python) So keeping an accurate version of python on this platform makes sense as well to increase the python language usage Next I am still happy to continue supporting the ZOS port and I perfectly understand that fully integrating the ZOS idiosynchrasies into the Python main branch generates maintenability problems ... But some of the submitted problems included into Lauri patch are not ZOS specific and increase and simply increase the portability of the python Kernel to EBCDIC platform(ZOS and OS400) So finally my opinion here is the the problem can be splitted into two parts : 1 General improvements patches which improves the Python kernel which can be incorporated in the python kernel and which may not be to complicated to maintain on the main branch 2 ZOS idiosynchrasies (mainly located in making the autoconf/automake and build scripts compliant with ZOS ); this can be done specifically by zos python specialists which have access to ZOS mainframe in order to be able to test. I am happy to continue to make the topic 2 availables on the ZOS python port pages with the help of others contributors like Lauri and give them credit on the ZOS port page. So I propose to integrate lauri's patch in the 2.5.1 current and provide a modified ZOS compliant source tar containing modified autoconf/automake and dynamic loading stuff I Finally should emphazise on 2 complementary arguments : - The ZOS port has been used in industrial products(including the company for which I work today) and contributes to promote the python language on important non unix platforms showing the extreme portability of the language. - Even the IBM Labs in Boulder(colorado) get in touch with me in order to integrate the port in one of their project. ---------- nosy: +JYMEN __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Oct 23 14:31:42 2007 From: report at bugs.python.org (Georg Brandl) Date: Tue, 23 Oct 2007 12:31:42 -0000 Subject: [issue1286] fileinput, StringIO, and cStringIO do not support the with protocol Message-ID: <1193142702.3.0.248171943866.issue1286@psf.upfronthosting.co.za> Georg Brandl added the comment: Makes sense to me. ---------- nosy: +georg.brandl __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Oct 23 15:00:01 2007 From: report at bugs.python.org (Derek Shockey) Date: Tue, 23 Oct 2007 13:00:01 -0000 Subject: [issue1307] smtpd.SMTPServer throws exception on MAIL command with no arg Message-ID: <1193144401.53.0.506476600196.issue1307@psf.upfronthosting.co.za> Derek Shockey added the comment: I'm really sorry I didn't notice this earlier, but RCPT has the same bug! This patch applies the same fix to that function as well. Added file: http://bugs.python.org/file8597/smtpd-patch2.diff __________________________________ Tracker __________________________________ -------------- next part -------------- A non-text attachment was scrubbed... Name: smtpd-patch2.diff Type: application/octet-stream Size: 493 bytes Desc: not available Url : http://mail.python.org/pipermail/python-bugs-list/attachments/20071023/5a52f6ac/attachment.obj From report at bugs.python.org Tue Oct 23 15:49:34 2007 From: report at bugs.python.org (Tal Einat) Date: Tue, 23 Oct 2007 13:49:34 -0000 Subject: [issue1253] IDLE - Percolator overhaul Message-ID: <1193147373.99.0.943550571281.issue1253@psf.upfronthosting.co.za> Tal Einat added the comment: The change required for Squeezer and ShellLogger is the separation of the Tk Text specific logic into a subclass, which makes Percolator a generally useful class. Along with the simple patch to Delegator.py which allows delegation to callables, this change allows one to replace a method with a Percolator instance. I want to do this for EditorWindow.write, since both Squeezer and ShellLogger need to hook onto this call somehow. Furthermore, ShellLogger must catch this call before Squeezer does, since Squeezer may change the output, but the original output should pass through ShellLogger first. Since there is no way to control the order in which extensions are loaded, this constraint must be enforced by the extensions themselves. Using the patched Percolator is the simplest way I could come up with to support this. (IMHO adding a constraint solver for extensions at this point would be overkill.) __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Oct 23 16:17:48 2007 From: report at bugs.python.org (Guido van Rossum) Date: Tue, 23 Oct 2007 14:17:48 -0000 Subject: [issue1315] Bug in pstats.print_callers Message-ID: <1193149068.65.0.160914133951.issue1315@psf.upfronthosting.co.za> Guido van Rossum added the comment: This will get more attention if you suggest a patch... ---------- nosy: +gvanrossum __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Oct 23 18:58:45 2007 From: report at bugs.python.org (Raghuram Devarakonda) Date: Tue, 23 Oct 2007 16:58:45 -0000 Subject: [issue1256] subprocess Popen wait() function hangs when stdout is > 20480 Message-ID: <1193158725.23.0.0395698555458.issue1256@psf.upfronthosting.co.za> Raghuram Devarakonda added the comment: PIPE on POSIX are implemented using pipe system call so it will have all the limitations of the system buffering that is used for implementing pipes. The buffer size is system dependent. For example, on my Linux, I hit the hang condition at 64K and not 20480 bytes (as is your case). What basically happens is that the child fills up the pipe buffer and is blocked until space is available. Since the parent in your test script is not reading the bytes, space will never be freed up. I suggest that the bug is closed as invalid. ---------- nosy: +draghuram __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Oct 23 19:00:17 2007 From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=) Date: Tue, 23 Oct 2007 17:00:17 -0000 Subject: [issue1314] Patch for strftime problem on German Windows Message-ID: <1193158817.33.0.395273283939.issue1314@psf.upfronthosting.co.za> Changes by Martin v. L?wis: ---------- keywords: +patch __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Oct 23 19:14:06 2007 From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=) Date: Tue, 23 Oct 2007 17:14:06 -0000 Subject: [issue1298] Support for z/OS and EBCDIC. Message-ID: <1193159646.42.0.217575630054.issue1298@psf.upfronthosting.co.za> Martin v. L?wis added the comment: Jean-Yves, please understand that no amount of discussion can likely change Guido's or my view on this patch. We both fully understand the relevance of OS/390, and *still* reject it, for the reasons discussed. Besides, integration into 2.5.1 is not possible, as it would violate our maintenance policy of not integrating new features into bug fix (2.x.y) releases. Integrating it into 2.6 might be possibly technically, but could be a waste of time since 2.x will shortly (i.e. within a few years) reach the end of its life. I doubt that the patch as it stands will work correctly on 3.x (as *that* stands). As you seem to be proposing that supporting EBCDIC will be "easy", just try to port the patch to 3.x to see how this assumption is wrong. In Python 3.x, Python source code *cannot* be interpreted as EBCDIC, without an encoding declaration, since the language specification says that the source code is UTF-8; there is no room for platform-specific derivations from that default. Also consider Guido's discussion of the networking code; unless you can report that httplib and ftplib work correctly, I doubt that the port is really complete. So I think the only choice is to maintain this port outside of the Python source tree, for a few more years. If you plan to contribute it again to the Python core some day, please keep track of all the individual contributors, as we will then require copyright agreements from everyone. __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Oct 23 19:37:11 2007 From: report at bugs.python.org (Kevin Dwyer) Date: Tue, 23 Oct 2007 17:37:11 -0000 Subject: [issue1311] os.path.exists(os.devnull) regression on windows Message-ID: <1193161031.48.0.620130164946.issue1311@psf.upfronthosting.co.za> Kevin Dwyer added the comment: I tried this under Python 2.3.3, 2.5.1 (native) and 2.3.4 (cygwin). The operating system is Windows 2000 SP4. C:\Python23>python Python 2.3.3 (#51, Dec 18 2003, 20:22:39) [MSC v.1200 32 bit (Intel)] on win32 Type "help", "copyright", "credits" or "license" for more information. >>> import os.path >>> print os.path.exists('nul') True C:\Python25>python Python 2.5.1 (r251:54863, Apr 18 2007, 08:51:08) [MSC v.1310 32 bit (Intel)] on win32 Type "help", "copyright", "credits" or "license" for more information. >>> import os.path >>> print os.path.exists('nul') False $ python Python 2.3.4 (#1, Jun 13 2004, 11:21:03) [GCC 3.3.1 (cygming special)] on cygwin Type "help", "copyright", "credits" or "license" for more information. >>> import os.path >>> print os.path.exists('nul') True So there does seem to be a change in behaviour at 2.5. ---------- nosy: +kdwyer __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Oct 23 20:41:36 2007 From: report at bugs.python.org (Georg Brandl) Date: Tue, 23 Oct 2007 18:41:36 -0000 Subject: [issue1316] fix a few PyInt_Check vs PyLong_Check problems Message-ID: <1193164896.58.0.699335652661.issue1316@psf.upfronthosting.co.za> New submission from Georg Brandl: This fixes a few places where PyInt_Check and PyLong_Check are used redundantly, and where the checks must be changed now that there's only PyLong. ---------- assignee: gvanrossum files: long_check.diff keywords: patch, py3k messages: 56685 nosy: georg.brandl, gvanrossum severity: normal status: open title: fix a few PyInt_Check vs PyLong_Check problems versions: Python 3.0 Added file: http://bugs.python.org/file8598/long_check.diff __________________________________ Tracker __________________________________ -------------- next part -------------- A non-text attachment was scrubbed... Name: long_check.diff Type: application/pgp-signature Size: 7749 bytes Desc: not available Url : http://mail.python.org/pipermail/python-bugs-list/attachments/20071023/def0e6f1/attachment-0001.pgp From report at bugs.python.org Tue Oct 23 20:56:54 2007 From: report at bugs.python.org (Georg Brandl) Date: Tue, 23 Oct 2007 18:56:54 -0000 Subject: [issue1303] adapt str8 constructor to bytes constructor Message-ID: <1193165814.44.0.463993532065.issue1303@psf.upfronthosting.co.za> Georg Brandl added the comment: Okay, somebody seems to have started this, so I won't interfere for now. __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Oct 23 21:20:22 2007 From: report at bugs.python.org (Guido van Rossum) Date: Tue, 23 Oct 2007 19:20:22 -0000 Subject: [issue1316] fix a few PyInt_Check vs PyLong_Check problems Message-ID: <1193167222.56.0.736079728894.issue1316@psf.upfronthosting.co.za> Guido van Rossum added the comment: Please check in and close -- thanks for finding these! ---------- assignee: gvanrossum -> georg.brandl resolution: -> accepted __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Oct 23 21:24:30 2007 From: report at bugs.python.org (Fred L. Drake, Jr.) Date: Tue, 23 Oct 2007 19:24:30 -0000 Subject: [issue1317] smtplib.SMTP docs Message-ID: <1193167470.47.0.372860933497.issue1317@psf.upfronthosting.co.za> New submission from Fred L. Drake, Jr.: The docstring for the smtplib.SMTP class includes descriptions of some instance attributes that are not covered by the documentation: does_esmtp ehlo_resp esmtp_features helo_resp If these are intended as part of the public interface, they should be documented in the .tex/.rst documentation, otherwise their descriptions should be in a comment instead of a docstring. (helo_resp is mentioned in Misc/HISTORY, if that actually means anything.) ---------- components: Documentation messages: 56688 nosy: fdrake severity: normal status: open title: smtplib.SMTP docs type: rfe versions: Python 2.5, Python 2.6, Python 3.0 __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Oct 23 21:24:34 2007 From: report at bugs.python.org (Georg Brandl) Date: Tue, 23 Oct 2007 19:24:34 -0000 Subject: [issue1316] fix a few PyInt_Check vs PyLong_Check problems Message-ID: <1193167474.65.0.338456187806.issue1316@psf.upfronthosting.co.za> Georg Brandl added the comment: Committed r58617. ---------- status: open -> closed __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Oct 23 21:26:28 2007 From: report at bugs.python.org (Guido van Rossum) Date: Tue, 23 Oct 2007 19:26:28 -0000 Subject: [issue1307] smtpd.SMTPServer throws exception on MAIL command with no arg Message-ID: <1193167588.57.0.441368105092.issue1307@psf.upfronthosting.co.za> Guido van Rossum added the comment: Committed revision 58618. There better not be any others. :-) Neal, can you add this to 2.5.2 and then close? ---------- assignee: gvanrossum -> nnorwitz status: closed -> open __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Oct 23 21:39:58 2007 From: report at bugs.python.org (Guido van Rossum) Date: Tue, 23 Oct 2007 19:39:58 -0000 Subject: [issue1312] doctest EXCEPTION_RE can't handle preceding output Message-ID: <1193168398.58.0.209216312958.issue1312@psf.upfronthosting.co.za> Changes by Guido van Rossum: ---------- assignee: -> tim_one nosy: +tim_one __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Oct 23 21:43:34 2007 From: report at bugs.python.org (Guido van Rossum) Date: Tue, 23 Oct 2007 19:43:34 -0000 Subject: [issue1314] Patch for strftime problem on German Windows Message-ID: <1193168614.95.0.0671253494957.issue1314@psf.upfronthosting.co.za> Guido van Rossum added the comment: Committed revision 58619. ---------- assignee: -> gvanrossum nosy: +gvanrossum resolution: -> accepted status: open -> closed __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Oct 23 22:24:45 2007 From: report at bugs.python.org (Facundo Batista) Date: Tue, 23 Oct 2007 20:24:45 -0000 Subject: [issue1755179] Deadlocks with fork() and multithreading Message-ID: <1193171085.88.0.963295878772.issue1755179@psf.upfronthosting.co.za> Changes by Facundo Batista: ---------- assignee: -> facundobatista nosy: +facundobatista _____________________________________ Tracker _____________________________________ From report at bugs.python.org Tue Oct 23 22:56:48 2007 From: report at bugs.python.org (Kevin Dwyer) Date: Tue, 23 Oct 2007 20:56:48 -0000 Subject: [issue1311] os.path.exists(os.devnull) regression on windows Message-ID: <1193173008.25.0.296762863738.issue1311@psf.upfronthosting.co.za> Kevin Dwyer added the comment: Ok, it seems that Python 2.5 implements two new functions Py_GetFileAttributesExA and Py_GetFileAttributesExW in posixmodule.c within the #ifdef MS_WINDOWS block that may return ERROR_INVALID_PARAMETER to os.stat, which will percolate WindowsError up to os.exists(): In both functions we find: static BOOL WINAPI Py_GetFileAttributesExA(LPCSTR pszFile, GET_FILEEX_INFO_LEVELS level, LPVOID pv) { BOOL result; LPWIN32_FILE_ATTRIBUTE_DATA pfad = pv; /* First try to use the system's implementation, if that is available and either succeeds to gives an error other than that it isn't implemented. */ check_gfax(); if (gfaxa) { result = gfaxa(pszFile, level, pv); if (result || GetLastError() != ERROR_CALL_NOT_IMPLEMENTED) return result; } /* It's either not present, or not implemented. Emulate using FindFirstFile. */ if (level != GetFileExInfoStandard) { SetLastError(ERROR_INVALID_PARAMETER); return FALSE; ... static BOOL WINAPI Py_GetFileAttributesExW(LPCWSTR pszFile, GET_FILEEX_INFO_LEVELS level, LPVOID pv) { BOOL result; LPWIN32_FILE_ATTRIBUTE_DATA pfad = pv; /* First try to use the system's implementation, if that is available and either succeeds to gives an error other than that it isn't implemented. */ check_gfax(); if (gfaxa) { result = gfaxw(pszFile, level, pv); if (result || GetLastError() != ERROR_CALL_NOT_IMPLEMENTED) return result; } /* It's either not present, or not implemented. Emulate using FindFirstFile. */ if (level != GetFileExInfoStandard) { SetLastError(ERROR_INVALID_PARAMETER); return FALSE; ... I'm neither a C nor a win32api programmer - can anyone explain the purpose of this code? __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Oct 23 23:22:21 2007 From: report at bugs.python.org (Christian Heimes) Date: Tue, 23 Oct 2007 21:22:21 -0000 Subject: [issue1318] Remove os.tmpnam() and os.tempnam() [patch] Message-ID: <1193174541.45.0.8073399338.issue1318@psf.upfronthosting.co.za> New submission from Christian Heimes: I couldn't stand the compiler warnings any more. :) The patch removes os.tmpnam() and os.tempnam() from the posix module. It also updates the docs and tests. TMP_MAX is kept for the tempfile module. I haven't figured out how to remove the defines from pyconfig.h. I guess they are always added by autoconf/automake. ---------- components: Documentation, Extension Modules files: py3k_remove_os_tmpnam.patch messages: 56693 nosy: tiran severity: normal status: open title: Remove os.tmpnam() and os.tempnam() [patch] type: resource usage versions: Python 3.0 Added file: http://bugs.python.org/file8599/py3k_remove_os_tmpnam.patch __________________________________ Tracker __________________________________ -------------- next part -------------- A non-text attachment was scrubbed... Name: py3k_remove_os_tmpnam.patch Type: text/x-diff Size: 9957 bytes Desc: not available Url : http://mail.python.org/pipermail/python-bugs-list/attachments/20071023/8678788c/attachment-0001.patch From report at bugs.python.org Wed Oct 24 00:37:41 2007 From: report at bugs.python.org (Guido van Rossum) Date: Tue, 23 Oct 2007 22:37:41 -0000 Subject: [issue1318] Remove os.tmpnam() and os.tempnam() [patch] Message-ID: <1193179061.39.0.0551924883913.issue1318@psf.upfronthosting.co.za> Guido van Rossum added the comment: Martin, why do we need to keep these when we already have tempfile.py? I don't see that they solve any particular POSIX compatibility requirement. And they *are* unsafe. (Admitted, sometimes there's no alternative -- even tempfile.py still provides unsafe APIs by necessity.) ---------- nosy: +gvanrossum __________________________________ Tracker __________________________________ From report at bugs.python.org Wed Oct 24 00:50:18 2007 From: report at bugs.python.org (Amaury Forgeot d'Arc) Date: Tue, 23 Oct 2007 22:50:18 -0000 Subject: [issue1319] py3k: fixes for test_ctypes Message-ID: <1193179818.56.0.0105500594667.issue1319@psf.upfronthosting.co.za> New submission from Amaury Forgeot d'Arc: Updates to ctypes for python 3.0 to make the tests pass. Notable changes are: - return bytes instead of str8 - integers in range(256) are accepted as "one char string": libc.strchr("abcdef", 98) is now valid. - directly use the wide-char version of the win32 function LoadLibrary. Tested on WinXP, with Visual Studio Express 2005. ---------- components: Interpreter Core files: ctypes.diff messages: 56696 nosy: amaury.forgeotdarc severity: normal status: open title: py3k: fixes for test_ctypes versions: Python 3.0 Added file: http://bugs.python.org/file8600/ctypes.diff __________________________________ Tracker __________________________________ -------------- next part -------------- A non-text attachment was scrubbed... Name: ctypes.diff Type: application/octet-stream Size: 20925 bytes Desc: not available Url : http://mail.python.org/pipermail/python-bugs-list/attachments/20071023/14281ee8/attachment-0001.obj From report at bugs.python.org Wed Oct 24 01:55:46 2007 From: report at bugs.python.org (Christian Heimes) Date: Tue, 23 Oct 2007 23:55:46 -0000 Subject: [issue1318] Remove os.tmpnam() and os.tempnam() [patch] Message-ID: <1193183746.15.0.819077657687.issue1318@psf.upfronthosting.co.za> Christian Heimes added the comment: First, you are right. It's not a compiler but a linker warning. I don't see the point in keeping the methods. They are dangerous to use, warned upon for a long time and they have a sane replacement that does a far better job. __________________________________ Tracker __________________________________ From report at bugs.python.org Wed Oct 24 05:12:35 2007 From: report at bugs.python.org (Joseph Armbruster) Date: Wed, 24 Oct 2007 03:12:35 -0000 Subject: [issue1320] PCBuild8 Solution Support Changes Message-ID: <1193195555.05.0.403245196794.issue1320@psf.upfronthosting.co.za> New submission from Joseph Armbruster: The following observations were made of the PCBuild8 solution: 1 pyproject.vsprops was missing usermacros for tcltk / msi 2 no vcproj for ssl module like the PCBuild solution has 3 _msi project did not havea valid includedir 4 _tkinter did not have a valid includedir Suggested Changes: 1 I would like to suggest adding macros such as the following to the pyproject.vsprops. These could then be referenced throughout the associated projects. Reasoning: To continue to promote pyproject.vsprops as being an almost-one-stop-shop for setting relative locations of third party libraries. This can be done in the following way: - tcltkDir could be used to add a valid includedir to the _tkinter project - msinstDir could be used to add a valid includedir to the _msi project. 2 no vcproj for ssl module like the PCBuild solution has See: pcbuild8_for_ssl.patch... The only thing left to do is add the associated _ssl project to the vsproj. Reasoning: To let their be a way to build the ssl module. Note: I suppose there could have been good reason for not putting in the _ssl module, since it uses a support .bat / .py to build (but that's for better people to decide) 3 If 1 is satisfied, a standard includedir variable could be added 4 If 1 is satisfied, a standard includedir variable could be added I am hesitant to submit a full patch for all of these here, since it may be decided that some of these be treated as separate issues. If a full patch is desired I can submit one. ---------- components: Build, Windows files: pcbuild8_for_ssl.patch messages: 56698 nosy: JosephArmbruster severity: normal status: open title: PCBuild8 Solution Support Changes versions: Python 2.6 Added file: http://bugs.python.org/file8601/pcbuild8_for_ssl.patch __________________________________ Tracker __________________________________ -------------- next part -------------- A non-text attachment was scrubbed... Name: pcbuild8_for_ssl.patch Type: application/octet-stream Size: 13003 bytes Desc: not available Url : http://mail.python.org/pipermail/python-bugs-list/attachments/20071024/7c5b2113/attachment.obj From report at bugs.python.org Wed Oct 24 05:53:59 2007 From: report at bugs.python.org (Neal Norwitz) Date: Wed, 24 Oct 2007 03:53:59 -0000 Subject: [issue1307] smtpd.SMTPServer throws exception on MAIL command with no arg Message-ID: <1193198039.18.0.870822881154.issue1307@psf.upfronthosting.co.za> Neal Norwitz added the comment: Committed revision 58625. (2.5) ---------- status: open -> closed __________________________________ Tracker __________________________________ From report at bugs.python.org Wed Oct 24 07:56:19 2007 From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=) Date: Wed, 24 Oct 2007 05:56:19 -0000 Subject: [issue1318] Remove os.tmpnam() and os.tempnam() [patch] Message-ID: <1193205379.51.0.779220701575.issue1318@psf.upfronthosting.co.za> Martin v. L?wis added the comment: Removing them because there is a replacement already is a better reason than removing them because they give (bogus) warnings, so I'm -0 now. As you say, tempfile is not any better from a security point of view in the cases where tmpnam or tempnam would be used (e.g. if you want a child process create a file whose name you specify). Whether the tempfile.py implementation is actually better than the one in the C library, I cannot tell (hence the -0: I don't know whether tempfile.py or the C library wrapper should be removed). One issue I just noticed is that tempfile.mkstemp promise of not inheriting the file descriptor is bogus in the presence of threads and race conditions. If the rationale for the patch is to eliminate duplication, then os.tmpfile should be removed as well. __________________________________ Tracker __________________________________ From report at bugs.python.org Wed Oct 24 07:57:30 2007 From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=) Date: Wed, 24 Oct 2007 05:57:30 -0000 Subject: [issue1319] py3k: fixes for test_ctypes Message-ID: <1193205450.25.0.0193696918923.issue1319@psf.upfronthosting.co.za> Martin v. L?wis added the comment: Thomas, can you take a look? If not, please unassign. ---------- assignee: -> theller keywords: +patch nosy: +loewis, theller __________________________________ Tracker __________________________________ From report at bugs.python.org Wed Oct 24 10:18:16 2007 From: report at bugs.python.org (Moshe Cohen) Date: Wed, 24 Oct 2007 08:18:16 -0000 Subject: [issue1321] TimedRotatingFileHandler logic for day of week is wrong Message-ID: <1193213896.73.0.793108305919.issue1321@psf.upfronthosting.co.za> Changes by Moshe Cohen: ---------- components: None nosy: mosheco severity: major status: open title: TimedRotatingFileHandler logic for day of week is wrong type: behavior versions: Python 2.4 __________________________________ Tracker __________________________________ From report at bugs.python.org Wed Oct 24 10:21:32 2007 From: report at bugs.python.org (Moshe Cohen) Date: Wed, 24 Oct 2007 08:21:32 -0000 Subject: [issue1321] TimedRotatingFileHandler logic for day of week is wrong Message-ID: <1193214092.14.0.69992677384.issue1321@psf.upfronthosting.co.za> New submission from Moshe Cohen: The logic for determining the time till midnight on the requested day of week is reversed. >From logging/handlers.py:234 if day > self.dayOfWeek: daysToWait = (day - self.dayOfWeek) - 1 self.rolloverAt = self.rolloverAt + (daysToWait * (60 * 60 * 24)) if day < self.dayOfWeek: daysToWait = (6 - self.dayOfWeek) + day self.rolloverAt = self.rolloverAt + (daysToWait * (60 * 60 * 24)) The two cases are reversed. 'day' is the current day. 'self.dayOfWeek' is the desired day. __________________________________ Tracker __________________________________ From report at bugs.python.org Wed Oct 24 10:22:59 2007 From: report at bugs.python.org (Moshe Cohen) Date: Wed, 24 Oct 2007 08:22:59 -0000 Subject: [issue1321] TimedRotatingFileHandler logic for day of week is wrong Message-ID: <1193214179.85.0.842967622265.issue1321@psf.upfronthosting.co.za> Moshe Cohen added the comment: The comments before the code are correct, by the way. The code should do exactly that. __________________________________ Tracker __________________________________ From report at bugs.python.org Wed Oct 24 10:54:34 2007 From: report at bugs.python.org (Georg Brandl) Date: Wed, 24 Oct 2007 08:54:34 -0000 Subject: [issue1321] TimedRotatingFileHandler logic for day of week is wrong Message-ID: <1193216074.62.0.532262460615.issue1321@psf.upfronthosting.co.za> Changes by Georg Brandl: ---------- assignee: -> vsajip nosy: +vsajip __________________________________ Tracker __________________________________ From report at bugs.python.org Wed Oct 24 12:14:51 2007 From: report at bugs.python.org (Lauri Alanko) Date: Wed, 24 Oct 2007 10:14:51 -0000 Subject: [issue1298] Support for z/OS and EBCDIC. Message-ID: <1193220891.47.0.452528155631.issue1298@psf.upfronthosting.co.za> Lauri Alanko added the comment: The port is certainly not yet "complete" in any sense. I have only fixed the most obvious places where explicit conversion between ASCII/Unicode values and platform-specific characters is required. There are a number of remaining issues, some of which cannot be fixed without major rehauls. The point of this first release is just to allow other interested people to chime in, to test the patch, and to suggest what should be done with it. The latter has certainly happened. :) I have no great interest in whether the patch ever gets incorporated into the main Python distribution. I do think, though, that it's a good idea to make the relationship between characters and Unicode values more explicit in the code in any case, and my patch shouldn't affect the behavior on any other platforms. Guido's comment about networking code is quite accurate, but the problem is social, not technical: there is already networking code that assumes that 8-bit string literals represent ASCII strings, and there is already text-processing code that assumes that 8-bit string literals represent "text" as found in ordinary text files on the platform. There is no reliable way to make both kinds of code work on a platform whose native encoding is not ASCII-compatible. In this sense, it is indeed impossible to port Python 2.x to an EBCDIC platform "completely", so that all existing code would continue to do "the right thing" without modifications. However, Py3k presents a fresh start, and one where this particular problem is gone, since string literals are no longer associated with a particular encoding, and bytes literals explicitly represent the ASCII values of the characters in the literal expression. Then text-processing code will likely use string literals, and it easy to make the default encoding platform-specific when transferring data between local text files and string objects. As far as I can see, EBCDIC shouldn't pose any special problems then. >From what I read in PEP 3120 and the Py3k docs, there seems to be some confusion regarding source encoding issues. Firstly, Python source code is fundamentally _text_. For instance, a string literal is delimited by single quote or double quote characters. Characters themselves are abstract entities that have no inherent numeric values, although we can name them with e.g. Unicode code points, so we can say that the string delimiters are characters represented by the code points U+0022 and U+0027. What PEP 3120 specifies is a mechanism for mapping octet sequences into these abstract characters. If this is made part of the language specification, it presumably means that a conformant Py3k source file must start as UTF-8 at least until an encoding declaration is encountered. Further, a conformant Py3k implementation must accept such UTF-8 source files and decode them as specified in the PEP. So far so good. however, there is nothing to prevent an implementation from providing (as an extension) a facility to allow _other_ kinds of source as well. "There is no room for platform-specific derivations" is an arbitrary restriction: there are certainly quite a number of ways to support both UTF-8 and CP1047 source on z/OS: for instance, the filesystem allows storing the encoding of a text file as metadata. Moreover, there is a semantics-preserving mapping from UTF-8 source files to CP1047 source files: since non-ASCII characters can only appear in comments an string literals, and comments have no semantics, it suffices to \u-escape the exotic characters in string literals. Hence all Python source can be represented as native text on an EBCDIC platform. Of course you can declare that support for such extensions would be heretical and no EBCDIC source file would be True Python Source and no EBCDIC implementation would be a True Python Implementation, but I don't really care. Python 3000 _can_ be ported to z/OS much better than 2.x, and it probably will, even if you don't like it. Oh the wonders of open source. :) __________________________________ Tracker __________________________________ From report at bugs.python.org Wed Oct 24 12:54:05 2007 From: report at bugs.python.org (Vinay Sajip) Date: Wed, 24 Oct 2007 10:54:05 -0000 Subject: [issue1321] TimedRotatingFileHandler logic for day of week is wrong Message-ID: <1193223245.8.0.149277945685.issue1321@psf.upfronthosting.co.za> Vinay Sajip added the comment: Fixed checked into trunk: r58628. Also checked into release25-maint. ---------- resolution: -> fixed status: open -> closed __________________________________ Tracker __________________________________ From report at bugs.python.org Wed Oct 24 13:06:56 2007 From: report at bugs.python.org (Aristotelis Mikropoulos) Date: Wed, 24 Oct 2007 11:06:56 -0000 Subject: [issue1778443] robotparser.py fixes Message-ID: <1193224016.95.0.190434478521.issue1778443@psf.upfronthosting.co.za> Aristotelis Mikropoulos added the comment: Yes, of course I meant spaces on both sides of ">=", it was just a typo of mine. I am sorry. I am glad you recommend applying my patch. I hope it helps. ---------- nosy: +Indy _____________________________________ Tracker _____________________________________ From report at bugs.python.org Wed Oct 24 15:19:41 2007 From: report at bugs.python.org (Facundo Batista) Date: Wed, 24 Oct 2007 13:19:41 -0000 Subject: [issue419903] Non-contiguous indexing and slicing Message-ID: <1193231981.59.0.42271704543.issue419903@psf.upfronthosting.co.za> Facundo Batista added the comment: The idea is rejected, so I close the bug. If wanted, push further discussion of this in the lists. ---------- nosy: +facundobatista status: open -> closed ____________________________________ Tracker ____________________________________ From report at bugs.python.org Wed Oct 24 16:32:49 2007 From: report at bugs.python.org (Guido van Rossum) Date: Wed, 24 Oct 2007 14:32:49 -0000 Subject: [issue1298] Support for z/OS and EBCDIC. Message-ID: <1193236369.51.0.555649579091.issue1298@psf.upfronthosting.co.za> Guido van Rossum added the comment: I have no desire or time to continue this discussion. The ASCII assumption will be ingrained as deeply or deeper in 3.0 than in 2.x, just like 8-bit bytes and 2's complement. The computer industry has chosen, and there just isn't any incentive to invent abstractions for properties that are constant in 99.999999% of all practical situations. ---------- status: open -> closed __________________________________ Tracker __________________________________ From report at bugs.python.org Wed Oct 24 18:12:31 2007 From: report at bugs.python.org (Facundo Batista) Date: Wed, 24 Oct 2007 16:12:31 -0000 Subject: [issue588756] python should obey the FHS Message-ID: <1193242351.89.0.397505196996.issue588756@psf.upfronthosting.co.za> Facundo Batista added the comment: Added to the PEP 42, rev 58638. ---------- nosy: +facundobatista status: open -> closed ____________________________________ Tracker ____________________________________ From report at bugs.python.org Wed Oct 24 18:28:45 2007 From: report at bugs.python.org (Facundo Batista) Date: Wed, 24 Oct 2007 16:28:45 -0000 Subject: [issue1290] xml.dom.minidom not able to handle utf-8 data Message-ID: <1193243325.81.0.0833896196342.issue1290@psf.upfronthosting.co.za> Changes by Facundo Batista: Removed file: http://bugs.python.org/file8559/unnamed __________________________________ Tracker __________________________________ From report at bugs.python.org Wed Oct 24 18:28:51 2007 From: report at bugs.python.org (Facundo Batista) Date: Wed, 24 Oct 2007 16:28:51 -0000 Subject: [issue1290] xml.dom.minidom not able to handle utf-8 data Message-ID: <1193243331.23.0.777960916893.issue1290@psf.upfronthosting.co.za> Changes by Facundo Batista: Removed file: http://bugs.python.org/file8560/unnamed __________________________________ Tracker __________________________________ From report at bugs.python.org Wed Oct 24 19:21:04 2007 From: report at bugs.python.org (Yann Cointepas) Date: Wed, 24 Oct 2007 17:21:04 -0000 Subject: [issue1322] platform.dist() has unpredictable result under Linux Message-ID: <1193246464.1.0.269134020057.issue1322@psf.upfronthosting.co.za> New submission from Yann Cointepas: The distribution name returned by platform.dist() depends on the order of os.path.listdir( '/etc' ). It selects the first file matching the regex r'(\w+)[-_](release|version)' and takes part of the file name (i.e. matchResult.groups()[0]) as distribution name. But there are often several files matching this pattern (at least on Fedora and Mandriva). For instance, on a Mandriva 2007.1 official, I can see the following files: [login at localhost ~]$ ls -l /etc/*-release -rw-r--r-- 1 root root 137 jan 18 2007 /etc/lsb-release lrwxrwxrwx 1 root root 16 oct 7 17:32 /etc/mandrakelinux-release -> mandriva-r elease lrwxrwxrwx 1 root root 16 oct 7 17:32 /etc/mandrake-release -> mandriva-releas e -rw-r--r-- 1 root root 50 avr 2 2007 /etc/mandriva-release lrwxrwxrwx 1 root root 16 oct 7 17:32 /etc/redhat-release -> mandriva-release Therefore, the result for platform.distrib()[0] could be mandriva, mandrake, redhat or even lsb. The first match wins ! Ignoring symlinks could remove part of the problem. On Mandriva, it would leave only lsb-release and mandriva-release. It is possible to select the good one by ignoring lsb-release or by verifying the file's content (mandriva-release has one line and lsb-release has several lines). I do not know if the second method is portable. ---------- messages: 56710 nosy: sapetnioc severity: major status: open title: platform.dist() has unpredictable result under Linux type: behavior versions: Python 2.5 __________________________________ Tracker __________________________________ From report at bugs.python.org Wed Oct 24 20:14:43 2007 From: report at bugs.python.org (Guido van Rossum) Date: Wed, 24 Oct 2007 18:14:43 -0000 Subject: [issue1319] py3k: fixes for test_ctypes Message-ID: <1193249683.23.0.980975659977.issue1319@psf.upfronthosting.co.za> Guido van Rossum added the comment: Looks good to me. I can check it in if Thomas is okay with that (or if he remains silent long enough :-). ---------- nosy: +gvanrossum __________________________________ Tracker __________________________________ From report at bugs.python.org Wed Oct 24 20:18:05 2007 From: report at bugs.python.org (Guido van Rossum) Date: Wed, 24 Oct 2007 18:18:05 -0000 Subject: [issue1322] platform.dist() has unpredictable result under Linux Message-ID: <1193249885.97.0.294632370102.issue1322@psf.upfronthosting.co.za> Guido van Rossum added the comment: Do you have a patch? That would help tremendously. ---------- nosy: +gvanrossum __________________________________ Tracker __________________________________ From report at bugs.python.org Wed Oct 24 20:25:57 2007 From: report at bugs.python.org (Guido van Rossum) Date: Wed, 24 Oct 2007 18:25:57 -0000 Subject: [issue1317] smtplib.SMTP docs Message-ID: <1193250357.06.0.913975887267.issue1317@psf.upfronthosting.co.za> Changes by Guido van Rossum: ---------- priority: -> low __________________________________ Tracker __________________________________ From report at bugs.python.org Wed Oct 24 20:30:08 2007 From: report at bugs.python.org (Thomas Heller) Date: Wed, 24 Oct 2007 18:30:08 -0000 Subject: [issue1319] py3k: fixes for test_ctypes In-Reply-To: <1193249683.23.0.980975659977.issue1319@psf.upfronthosting.co.za> Message-ID: <471F8F2A.1040409@ctypes.org> Thomas Heller added the comment: Guido van Rossum schrieb: > Looks good to me. I can check it in if Thomas is okay with that (or if > he remains silent long enough :-). Looks good to me too. Please check it in if you have time ;-) __________________________________ Tracker __________________________________ From report at bugs.python.org Wed Oct 24 20:30:38 2007 From: report at bugs.python.org (Guido van Rossum) Date: Wed, 24 Oct 2007 18:30:38 -0000 Subject: [issue1286] fileinput, StringIO, and cStringIO do not support the with protocol Message-ID: <1193250638.06.0.983932344886.issue1286@psf.upfronthosting.co.za> Guido van Rossum added the comment: Let's not get overexcited. I agree that it makes sense for fileinput, but I disagree about *StringIO; its close() isn't needed to free resources (since it doesn't use up a scarce resource like a file descriptor). Can you whip up a patch for fileinput? Please include unit tests and documentation. ---------- nosy: +gvanrossum priority: -> low versions: -Python 2.5 __________________________________ Tracker __________________________________ From report at bugs.python.org Wed Oct 24 20:41:47 2007 From: report at bugs.python.org (Guido van Rossum) Date: Wed, 24 Oct 2007 18:41:47 -0000 Subject: [issue1319] py3k: fixes for test_ctypes Message-ID: <1193251307.44.0.146326039586.issue1319@psf.upfronthosting.co.za> Guido van Rossum added the comment: Committed revision 58639. You're welcome, Thomas. And Thanks, Amaury! Keep them coming...! ---------- assignee: theller -> gvanrossum resolution: -> accepted status: open -> closed __________________________________ Tracker __________________________________ From report at bugs.python.org Wed Oct 24 20:42:49 2007 From: report at bugs.python.org (Guido van Rossum) Date: Wed, 24 Oct 2007 18:42:49 -0000 Subject: [issue1303] adapt str8 constructor to bytes constructor Message-ID: <1193251369.22.0.99552268083.issue1303@psf.upfronthosting.co.za> Guido van Rossum added the comment: Georg, can you check this in even with test_str failing? And who is working on that? If I don't get a name I'll tackle it myself. ---------- assignee: gvanrossum -> georg.brandl __________________________________ Tracker __________________________________ From report at bugs.python.org Wed Oct 24 20:57:39 2007 From: report at bugs.python.org (Georg Brandl) Date: Wed, 24 Oct 2007 18:57:39 -0000 Subject: [issue1303] adapt str8 constructor to bytes constructor Message-ID: <1193252259.38.0.0424721320155.issue1303@psf.upfronthosting.co.za> Georg Brandl added the comment: Okay, committed in r58640. Gregory wrote this in test_bytes: # I've started porting some of those into buffer_tests.py, we should port # the rest that make sense (the code can be cleaned up to use modern # unittest methods at the same time). ---------- status: open -> closed __________________________________ Tracker __________________________________ From report at bugs.python.org Wed Oct 24 21:07:21 2007 From: report at bugs.python.org (Guido van Rossum) Date: Wed, 24 Oct 2007 19:07:21 -0000 Subject: [issue1302] Fixes for profile/cprofile Message-ID: <1193252841.68.0.072118284184.issue1302@psf.upfronthosting.co.za> Guido van Rossum added the comment: I like Chris's patch better, but he should use (sizeof(lower)-1) instead of 8, and he should use the TOLOWER macro from bytes_methods.h. Please submit a new one and I'll check it in! ---------- priority: -> normal __________________________________ Tracker __________________________________ From report at bugs.python.org Wed Oct 24 21:12:12 2007 From: report at bugs.python.org (Facundo Batista) Date: Wed, 24 Oct 2007 19:12:12 -0000 Subject: [issue1290] xml.dom.minidom not able to handle utf-8 data Message-ID: <1193253132.27.0.409788011786.issue1290@psf.upfronthosting.co.za> Facundo Batista added the comment: CharacterData.__repr__ was constructing a string in response that keeped having a non-ascii character. Fixed in rev 58641. ---------- resolution: works for me -> fixed __________________________________ Tracker __________________________________ From report at bugs.python.org Wed Oct 24 21:16:32 2007 From: report at bugs.python.org (Thomas Heller) Date: Wed, 24 Oct 2007 19:16:32 -0000 Subject: [issue1319] py3k: fixes for test_ctypes In-Reply-To: <1193251307.44.0.146326039586.issue1319@psf.upfronthosting.co.za> Message-ID: <471F9A0E.2080105@ctypes.org> Thomas Heller added the comment: Looking again, I found a bug in the patch. In the function _get_args(), the local variable 'name' was changed from 'char *' to 'PyObject *'. In line 2995, it is passed to PyErr_Format with a '%s' format code: if (name) PyErr_Format(PyExc_TypeError, ==> "required argument '%s' missing", name); A unittest but no fix for the bug for this issue is attached (can I submit patches via mail?) Added file: http://bugs.python.org/file8602/test_prototypes.patch __________________________________ Tracker __________________________________ -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: test_prototypes.patch Url: http://mail.python.org/pipermail/python-bugs-list/attachments/20071024/67807d8f/attachment.txt From report at bugs.python.org Wed Oct 24 21:19:39 2007 From: report at bugs.python.org (Georg Brandl) Date: Wed, 24 Oct 2007 19:19:39 -0000 Subject: [issue1077] itertools missing, causes interactive help to break Message-ID: <1193253579.21.0.429543902009.issue1077@psf.upfronthosting.co.za> Changes by Georg Brandl: ---------- status: open -> pending __________________________________ Tracker __________________________________ From report at bugs.python.org Wed Oct 24 21:20:06 2007 From: report at bugs.python.org (Georg Brandl) Date: Wed, 24 Oct 2007 19:20:06 -0000 Subject: [issue1753371] Open always create new tab or new browser Message-ID: <1193253606.19.0.713816921428.issue1753371@psf.upfronthosting.co.za> Changes by Georg Brandl: ---------- status: pending -> closed _____________________________________ Tracker _____________________________________ From report at bugs.python.org Wed Oct 24 21:20:38 2007 From: report at bugs.python.org (Georg Brandl) Date: Wed, 24 Oct 2007 19:20:38 -0000 Subject: [issue1077] itertools missing, causes interactive help to break Message-ID: <1193253638.87.0.40363736339.issue1077@psf.upfronthosting.co.za> Changes by Georg Brandl: ---------- status: pending -> closed __________________________________ Tracker __________________________________ From report at bugs.python.org Wed Oct 24 21:27:37 2007 From: report at bugs.python.org (Thomas Heller) Date: Wed, 24 Oct 2007 19:27:37 -0000 Subject: [issue1319] py3k: fixes for test_ctypes In-Reply-To: <471F9A0E.2080105@ctypes.org> Message-ID: <471F9CA8.9020207@ctypes.org> Thomas Heller added the comment: Here's the bugfix - is it correct? Added file: http://bugs.python.org/file8603/_ctypes.patch __________________________________ Tracker __________________________________ -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: _ctypes.patch Url: http://mail.python.org/pipermail/python-bugs-list/attachments/20071024/1bc3b83b/attachment-0001.txt From report at bugs.python.org Wed Oct 24 21:34:00 2007 From: report at bugs.python.org (Guido van Rossum) Date: Wed, 24 Oct 2007 19:34:00 -0000 Subject: [issue1319] py3k: fixes for test_ctypes Message-ID: <1193254440.42.0.991586971716.issue1319@psf.upfronthosting.co.za> Guido van Rossum added the comment: Looks good. Can you check it in? __________________________________ Tracker __________________________________ From report at bugs.python.org Wed Oct 24 21:34:30 2007 From: report at bugs.python.org (Kurt B. Kaiser) Date: Wed, 24 Oct 2007 19:34:30 -0000 Subject: [issue1252] IDLE - patch Delegator to support callables Message-ID: <1193254470.66.0.423033503729.issue1252@psf.upfronthosting.co.za> Kurt B. Kaiser added the comment: Despite your explanation, I don't understand what is being accomplished here. Delegates are not intended to be callable. They have methods, e.g. insert, which are callable, and the insert call is propagated down the chain by calls like (from ColorDelegator): def insert(self, index, chars, tags=None): index = self.index(index) self.delegate.insert(index, chars, tags) self.notify_range(index, index + "+%dc" % len(chars)) IMHO it's an incorrect usage of the Delegator mixin to affect the callable nature of the class to which it's being added. Also, this __call__ method, if actually used, propagates to the end of the Delegator chain and calls the function at the end, (assuming it is a function). Or it will skip non-callable Delegators and stop at the first callable one. I doubt this is what was intended, and people trying to understand the code will be further confused, it seems to me. Try adding delegator.txt (below) to your Delegator.py and running the module! I think this patch increases the complexity and obscurity of the Delegator/Percolator/WidgetRedirector code, rather than improving it. Apparently you want to sometimes call a chain of methods (as in current usage) and sometimes call a chain of functions. The semantic overload, which was bad enough already, is too great. If Squeezer and ShellLogger require this change, then I'd suggest changing them to match current Percolator usage, instead. Currently I don't see a Delegator being used in Squeezer. Could you be more specific about why the change is needed for those two extensions? Added file: http://bugs.python.org/file8604/delegator.txt __________________________________ Tracker __________________________________ -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: delegator.txt Url: http://mail.python.org/pipermail/python-bugs-list/attachments/20071024/d19d8031/attachment.txt From report at bugs.python.org Wed Oct 24 21:37:55 2007 From: report at bugs.python.org (Thomas Heller) Date: Wed, 24 Oct 2007 19:37:55 -0000 Subject: [issue1319] py3k: fixes for test_ctypes In-Reply-To: <1193254440.42.0.991586971716.issue1319@psf.upfronthosting.co.za> Message-ID: <471F9F12.5060801@ctypes.org> Thomas Heller added the comment: Committed as rev 58642. __________________________________ Tracker __________________________________ From report at bugs.python.org Wed Oct 24 21:57:40 2007 From: report at bugs.python.org (Guido van Rossum) Date: Wed, 24 Oct 2007 19:57:40 -0000 Subject: [issue1258] Removal of basestring type In-Reply-To: <4713FD43.5090009@cheimes.de> Message-ID: Guido van Rossum added the comment: 2007/10/15, Christian Heimes : > > Christian Heimes added the comment: > > Guido van Rossum wrote: > > BTW we need a 2to3 fixer for this. Should be trivial -- just replace > > *all* occurrences of basestring with str. > > I believe you that it's trivial for *you* but I've never dealt with the > fixers or the grammar. Fortunately for me I was able to copy the fixer > for standarderror. It toke just some minor tweaks :) > > Let's see if the mail interface can handle attachments. It did. :-) I renamed it to fix_basestring and submitted it. See: Committed revision 58644. __________________________________ Tracker __________________________________ From report at bugs.python.org Wed Oct 24 22:00:29 2007 From: report at bugs.python.org (Matthias Klose) Date: Wed, 24 Oct 2007 20:00:29 -0000 Subject: [issue1292] libffi needs an update to support mips64, arm and armeabi on linux Message-ID: <1193256029.55.0.700029777115.issue1292@psf.upfronthosting.co.za> Matthias Klose added the comment: committed the following patch to the trunk (lets the buildds test the ctypes extension) Added file: http://bugs.python.org/file8605/arm.diff __________________________________ Tracker __________________________________ -------------- next part -------------- A non-text attachment was scrubbed... Name: arm.diff Type: text/x-patch Size: 720 bytes Desc: not available Url : http://mail.python.org/pipermail/python-bugs-list/attachments/20071024/f8152ca6/attachment.bin From report at bugs.python.org Wed Oct 24 22:02:52 2007 From: report at bugs.python.org (Guido van Rossum) Date: Wed, 24 Oct 2007 20:02:52 -0000 Subject: [issue1022] use bytes for code objects Message-ID: <1193256172.72.0.876276482508.issue1022@psf.upfronthosting.co.za> Guido van Rossum added the comment: We won't be doing it this way. ---------- resolution: remind -> rejected status: open -> closed __________________________________ Tracker __________________________________ From report at bugs.python.org Wed Oct 24 22:04:16 2007 From: report at bugs.python.org (Guido van Rossum) Date: Wed, 24 Oct 2007 20:04:16 -0000 Subject: [issue1004] MultiMethods with type annotations in 3000 Message-ID: <1193256256.03.0.221662106542.issue1004@psf.upfronthosting.co.za> Guido van Rossum added the comment: Phillip, do you have any interest left in moving PEP 3124 forward? ---------- assignee: gvanrossum -> pje nosy: +pje __________________________________ Tracker __________________________________ From report at bugs.python.org Wed Oct 24 22:12:27 2007 From: report at bugs.python.org (Phillip J. Eby) Date: Wed, 24 Oct 2007 20:12:27 -0000 Subject: [issue1004] MultiMethods with type annotations in 3000 Message-ID: <1193256747.57.0.417124393088.issue1004@psf.upfronthosting.co.za> Phillip J. Eby added the comment: Interested, yes. Have time for at the moment, no. :( Seems unlikely I'll have time before 2008Q1 at this point. __________________________________ Tracker __________________________________ From report at bugs.python.org Wed Oct 24 22:20:54 2007 From: report at bugs.python.org (Guido van Rossum) Date: Wed, 24 Oct 2007 20:20:54 -0000 Subject: [issue1004] MultiMethods with type annotations in 3000 In-Reply-To: <1193256747.57.0.417124393088.issue1004@psf.upfronthosting.co.za> Message-ID: Guido van Rossum added the comment: OK, that's fine. __________________________________ Tracker __________________________________ From report at bugs.python.org Wed Oct 24 23:41:24 2007 From: report at bugs.python.org (Georg Brandl) Date: Wed, 24 Oct 2007 21:41:24 -0000 Subject: [issue1287] os.environ.pop doesn't work Message-ID: <1193262084.55.0.485451312086.issue1287@psf.upfronthosting.co.za> Georg Brandl added the comment: Fixed in r58651 for 2.6. ---------- nosy: +georg.brandl resolution: -> fixed status: open -> closed __________________________________ Tracker __________________________________ From report at bugs.python.org Thu Oct 25 00:30:33 2007 From: report at bugs.python.org (Amaury Forgeot d'Arc) Date: Wed, 24 Oct 2007 22:30:33 -0000 Subject: [issue1323] py3k: file.truncate() changes the file position Message-ID: <1193265033.18.0.927714620141.issue1323@psf.upfronthosting.co.za> New submission from Amaury Forgeot d'Arc: This patch corrects a problem in test_file.py on Windows: f.truncate() seeks to the truncation point, but does not empty the buffers. In the test, f.tell() returns -1... Now we flush the file before, and seek to the initial position after. The same trick was present in 2.5, in fileobject.c::file_truncate. The same comments apply as well. Reviewers needed! Flushing may change the behaviour, but seems more correct to me (and closer to python2.5). Should we add specific tests for this? Also, change the test to be sure to close the file before trying to remove it (it seems that in a finally: block, the exception still references all the local variables in the traceback). Otherwise the previous problem is hidden by a "file locked" error in the finally block. ---------- components: Windows files: truncate.diff messages: 56732 nosy: amaury.forgeotdarc severity: normal status: open title: py3k: file.truncate() changes the file position versions: Python 3.0 Added file: http://bugs.python.org/file8606/truncate.diff __________________________________ Tracker __________________________________ -------------- next part -------------- A non-text attachment was scrubbed... Name: truncate.diff Type: application/octet-stream Size: 2111 bytes Desc: not available Url : http://mail.python.org/pipermail/python-bugs-list/attachments/20071024/ec80455c/attachment-0001.obj From report at bugs.python.org Thu Oct 25 05:44:04 2007 From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=) Date: Thu, 25 Oct 2007 03:44:04 -0000 Subject: [issue1323] py3k: file.truncate() changes the file position Message-ID: <1193283844.34.0.617497300232.issue1323@psf.upfronthosting.co.za> Changes by Martin v. L?wis: ---------- keywords: +patch __________________________________ Tracker __________________________________ From report at bugs.python.org Thu Oct 25 06:01:57 2007 From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=) Date: Thu, 25 Oct 2007 04:01:57 -0000 Subject: [issue1311] os.path.exists(os.devnull) regression on windows Message-ID: <1193284917.56.0.725055384743.issue1311@psf.upfronthosting.co.za> Martin v. L?wis added the comment: The purpose of Py_GetFileAttributesEx* is to wrap GetFileAttributesEx, on systems where it doesn't exist (Windows 95 in particular). If it doesn't exist, it is emulated; if it exists, it is directly called. ---------- nosy: +loewis __________________________________ Tracker __________________________________ From report at bugs.python.org Thu Oct 25 06:05:41 2007 From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=) Date: Thu, 25 Oct 2007 04:05:41 -0000 Subject: [issue1311] os.path.exists(os.devnull) regression on windows Message-ID: <1193285141.46.0.0269611318148.issue1311@psf.upfronthosting.co.za> Martin v. L?wis added the comment: As Facundo found out, the behavior of os.path.exists is fairly irrelevant here, as that functions is trivial. What really matters is whether os.stat succeeds for NUL. Can those users for whom it succeeds please report what Windows versions they are using, and what precisely the stat result for NUL is (and perhaps also for CON, PRN, etc)? __________________________________ Tracker __________________________________ From report at bugs.python.org Thu Oct 25 07:21:26 2007 From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=) Date: Thu, 25 Oct 2007 05:21:26 -0000 Subject: [issue1311] os.path.exists(os.devnull) regression on windows Message-ID: <1193289685.74.0.456038800682.issue1311@psf.upfronthosting.co.za> Martin v. L?wis added the comment: Please disregard Cygwin Python for this discussion. It (probably) uses the stat implementation from cygwin1.dll, which may work differently from Cygwin release to Cygwin release. __________________________________ Tracker __________________________________ From report at bugs.python.org Thu Oct 25 09:04:59 2007 From: report at bugs.python.org (Matthias Klose) Date: Thu, 25 Oct 2007 07:04:59 -0000 Subject: [issue1324] r58034 breaks building _ctypes with the upstream libffi. Message-ID: <1193295899.21.0.371258619006.issue1324@psf.upfronthosting.co.za> New submission from Matthias Klose: This breaks building _ctypes with the upstream libffi. r58034 | thomas.heller | 2007-09-07 08:32:17 +0200 (Fr, 07 Sep 2007) | 1 line Add a 'c_longdouble' type to the ctypes module. gcc -pthread -fPIC -fno-strict-aliasing -g -Wall -Wstrict-prototypes -I/usr/include -I. -I/home/pybot/buildarea-armeabi/trunk.klose-linux-armeabi/build/./Include -I./Include -IInclude -I. -I/usr/local/include -I/home/pybot/buildarea-armeabi/trunk.klose-linux-armeabi/build/Include -I/home/pybot/buildarea-armeabi/trunk.klose-linux-armeabi/build -c /home/pybot/buildarea-armeabi/trunk.klose-linux-armeabi/build/Modules/_ctypes/cfield.c -o build/temp.linux-armv5tel-2.6/home/pybot/buildarea-armeabi/trunk.klose-linux-armeabi/build/Modules/_ctypes/cfield.o /home/pybot/buildarea-armeabi/trunk.klose-linux-armeabi/build/Modules/_ctypes/cfield.c:1756: error: redefinition of 'ffi_type_double' /home/pybot/buildarea-armeabi/trunk.klose-linux-armeabi/build/Modules/_ctypes/cfield.c:1755: error: previous definition of 'ffi_type_double' was here ffi.h has: #if 0 extern ffi_type ffi_type_longdouble; #else #define ffi_type_longdouble ffi_type_double #endif ---------- assignee: theller components: Extension Modules messages: 56736 nosy: doko, theller severity: normal status: open title: r58034 breaks building _ctypes with the upstream libffi. versions: Python 2.6 __________________________________ Tracker __________________________________ From report at bugs.python.org Thu Oct 25 09:05:11 2007 From: report at bugs.python.org (Matthias Klose) Date: Thu, 25 Oct 2007 07:05:11 -0000 Subject: [issue1324] r58034 breaks building _ctypes with the upstream libffi. Message-ID: <1193295911.82.0.619137680542.issue1324@psf.upfronthosting.co.za> Changes by Matthias Klose: ---------- type: -> compile error __________________________________ Tracker __________________________________ From report at bugs.python.org Thu Oct 25 09:09:57 2007 From: report at bugs.python.org (Matthias Klose) Date: Thu, 25 Oct 2007 07:09:57 -0000 Subject: [issue1324] r58034 breaks building _ctypes with the upstream libffi. Message-ID: <1193296197.5.0.247926194612.issue1324@psf.upfronthosting.co.za> Matthias Klose added the comment: Index: Modules/_ctypes/cfield.c =================================================================== --- Modules/_ctypes/cfield.c (revision 58651) +++ Modules/_ctypes/cfield.c (working copy) @@ -1753,6 +1753,9 @@ ffi_type ffi_type_float = { sizeof(float), FLOAT_ALIGN, FFI_TYPE_FLOAT }; ffi_type ffi_type_double = { sizeof(double), DOUBLE_ALIGN, FFI_TYPE_DOUBLE }; +#ifdef ffi_type_longdouble +#undef ffi_type_longdouble +#endif ffi_type ffi_type_longdouble = { sizeof(long double), LONGDOUBLE_ALIGN, FFI_TYPE_LONGDOUBLE }; __________________________________ Tracker __________________________________ From report at bugs.python.org Thu Oct 25 10:17:06 2007 From: report at bugs.python.org (Matthias Klose) Date: Thu, 25 Oct 2007 08:17:06 -0000 Subject: [issue1324] r58034 breaks building _ctypes with the upstream libffi. Message-ID: <1193300226.35.0.204475119633.issue1324@psf.upfronthosting.co.za> Changes by Matthias Klose: ---------- keywords: +patch __________________________________ Tracker __________________________________ From report at bugs.python.org Thu Oct 25 11:44:29 2007 From: report at bugs.python.org (Christian Heimes) Date: Thu, 25 Oct 2007 09:44:29 -0000 Subject: [issue1318] Remove os.tmpnam() and os.tempnam() [patch] Message-ID: <1193305469.47.0.0144353397817.issue1318@psf.upfronthosting.co.za> Christian Heimes added the comment: os.tmpfile() is the only method that has no duplicate in tempfile. I chose to keep it for this very reason. But you made good point, too. What do you think about renaming tmpfile to _tmpfile and make it available from the tempfile module as tempfile.tmpfile()? I totally agree with your opinion on tmpnam and tempnam. As far as I know it's impossible to prevent a child process from doing something harmful. The child must be mature enough to do the right think and open a file with the correct flags. The promise of tempfile.mkstemp is also bogus for every OS except Windows. IIRC only Windows supports O_NOINHERIT. Let me rephrase the rational for my patch: I want to remove duplicate code to have just but one implementation to create a temporary file (name). I want the one implementation be under our control and not depend on some possible broken or stupid C library like Windows where tmpnam may create the temporary files in C:\. I want an unified way to get the TEMP dir independent of the API. __________________________________ Tracker __________________________________ From report at bugs.python.org Thu Oct 25 12:47:36 2007 From: report at bugs.python.org (Christian Heimes) Date: Thu, 25 Oct 2007 10:47:36 -0000 Subject: [issue1302] Fixes for profile/cprofile Message-ID: <1193309256.58.0.864514607952.issue1302@psf.upfronthosting.co.za> Christian Heimes added the comment: Why should I use (sizeof(lower)-1)? Do you mean PyMem_Malloc(strlen(encoding) + 1)? Changes since last patch: * added #include "bytes_methods.h" in unicodeobject.c * fix all is* to use the macros from bytes_methods.h * use malloc/free the lower version instead of using a fixed buffer * replace '_' with '-' in encoding I still think that a fixed buffer of 12 chars (strlen(iso-8859-1) + 1 + \0) is sufficient and faster. * also check for iso-8859-1 Added file: http://bugs.python.org/file8607/py3k_profile_fix3.patch __________________________________ Tracker __________________________________ -------------- next part -------------- A non-text attachment was scrubbed... Name: py3k_profile_fix3.patch Type: text/x-diff Size: 4838 bytes Desc: not available Url : http://mail.python.org/pipermail/python-bugs-list/attachments/20071025/06fb261b/attachment.patch From report at bugs.python.org Thu Oct 25 14:09:00 2007 From: report at bugs.python.org (Yitz Gale) Date: Thu, 25 Oct 2007 12:09:00 -0000 Subject: [issue1286] fileinput, StringIO, and cStringIO do not support the with protocol Message-ID: <1193314140.09.0.314444594945.issue1286@psf.upfronthosting.co.za> Yitz Gale added the comment: I was actually bitten badly by this issue with StringIO. I added fileinput only as an afterthought. In an xml.sax app, I needed seek() support for a codec-wrapped file handle, so I over-wrapped it with StringIO. The result was that I had to refactor code all over the place to handle StringIO as a special case. What a mess! Why is this getting over-excited? It's a very lightweight change. You can't beat the cost/benefit ratio. __________________________________ Tracker __________________________________ From report at bugs.python.org Thu Oct 25 15:01:37 2007 From: report at bugs.python.org (Jean-Paul Calderone) Date: Thu, 25 Oct 2007 13:01:37 -0000 Subject: [issue1325] zipimport.zipimporter.archive undocumented and untested Message-ID: <1193317296.93.0.487573711229.issue1325@psf.upfronthosting.co.za> New submission from Jean-Paul Calderone: zipimporter instances have a read-only "archive" attribute, but there is no documentation referring to it, nor any test coverage for its existence. It's quite useful to know what a zipimporter is pointed at (for debugging and other introspection). It'd be nice to know that this is a real feature and isn't going to disappear. ---------- components: Documentation, Library (Lib) messages: 56741 nosy: exarkun severity: normal status: open title: zipimport.zipimporter.archive undocumented and untested type: rfe __________________________________ Tracker __________________________________ From report at bugs.python.org Thu Oct 25 15:08:00 2007 From: report at bugs.python.org (Jean-Paul Calderone) Date: Thu, 25 Oct 2007 13:08:00 -0000 Subject: [issue1326] "internal" zipimport.zipimporter feature untested Message-ID: <1193317680.83.0.000309828654595.issue1326@psf.upfronthosting.co.za> New submission from Jean-Paul Calderone: It's possible to construct a zipimporter with a "path" which points first to a zip file and then continues to refer to a file within that zip file. For example, /foo/bar.zip/baz where /foo/bar.zip is not a directory, but a zip file, and baz is a file or directory in the contents of the zip file. There is no test coverage for this functionality, though. ---------- components: Library (Lib) messages: 56742 nosy: exarkun severity: normal status: open title: "internal" zipimport.zipimporter feature untested type: rfe __________________________________ Tracker __________________________________ From report at bugs.python.org Thu Oct 25 15:09:53 2007 From: report at bugs.python.org (Facundo Batista) Date: Thu, 25 Oct 2007 13:09:53 -0000 Subject: [issue1301] Bad assertion in _tkinter.c Message-ID: <1193317793.28.0.186242919346.issue1301@psf.upfronthosting.co.za> Facundo Batista added the comment: Really do not understand that assert. It says: assert(size < size * sizeof(Tcl_UniChar)); For that to be true, considering size to be positive, the result of sizeof needs to be greater than 0. If you modify it, and also accepts it to be 0, and considering that the result of sizeof won't be negative, what is the point of keeping the assert? ---------- nosy: +facundobatista __________________________________ Tracker __________________________________ From report at bugs.python.org Thu Oct 25 15:22:57 2007 From: report at bugs.python.org (Jean-Paul Calderone) Date: Thu, 25 Oct 2007 13:22:57 -0000 Subject: [issue1325] zipimport.zipimporter.archive undocumented and untested Message-ID: <1193318577.2.0.235076540334.issue1325@psf.upfronthosting.co.za> Changes by Jean-Paul Calderone: ---------- nosy: +fijal __________________________________ Tracker __________________________________ From report at bugs.python.org Thu Oct 25 15:23:07 2007 From: report at bugs.python.org (Jean-Paul Calderone) Date: Thu, 25 Oct 2007 13:23:07 -0000 Subject: [issue1326] "internal" zipimport.zipimporter feature untested Message-ID: <1193318587.15.0.24842725098.issue1326@psf.upfronthosting.co.za> Changes by Jean-Paul Calderone: ---------- nosy: +fijal __________________________________ Tracker __________________________________ From report at bugs.python.org Thu Oct 25 15:35:09 2007 From: report at bugs.python.org (Jean-Paul Calderone) Date: Thu, 25 Oct 2007 13:35:09 -0000 Subject: [issue805194] Inappropriate error received using socket timeout Message-ID: <1193319309.32.0.0834364383175.issue805194@psf.upfronthosting.co.za> Jean-Paul Calderone added the comment: The APR comment is indeed correct, so this is probably a Python bug. ---------- nosy: +exarkun ____________________________________ Tracker ____________________________________ From report at bugs.python.org Thu Oct 25 15:54:58 2007 From: report at bugs.python.org (Raghuram Devarakonda) Date: Thu, 25 Oct 2007 13:54:58 -0000 Subject: [issue1287] os.environ.pop doesn't work Message-ID: <1193320498.59.0.127460184743.issue1287@psf.upfronthosting.co.za> Raghuram Devarakonda added the comment: After reading the change, I think one more small change may be required. Index: Lib/os.py =================================================================== --- Lib/os.py (revision 58654) +++ Lib/os.py (working copy) @@ -452,7 +452,7 @@ del self.data[key] def pop(self, key, *args): unsetenv(key) - return self.data.pop(key, *args) + return self.data.pop(key.upper(), *args) def has_key(self, key): return key.upper() in self.data def __contains__(self, key): __________________________________ Tracker __________________________________ From report at bugs.python.org Thu Oct 25 16:11:39 2007 From: report at bugs.python.org (Hirokazu Yamamoto) Date: Thu, 25 Oct 2007 14:11:39 -0000 Subject: [issue1700463] VC6 build patch for trunk Message-ID: <1193321499.76.0.855429185449.issue1700463@psf.upfronthosting.co.za> Hirokazu Yamamoto added the comment: I updated patch. To avoid conflict and , WIN32_LEAN_AND_MEAN is needed. Added file: http://bugs.python.org/file8608/vc6-trunk-ver2.patch _____________________________________ Tracker _____________________________________ -------------- next part -------------- A non-text attachment was scrubbed... Name: vc6-trunk-ver2.patch Type: text/x-patch Size: 5249 bytes Desc: not available Url : http://mail.python.org/pipermail/python-bugs-list/attachments/20071025/52ab4d1d/attachment-0001.bin From report at bugs.python.org Thu Oct 25 16:31:59 2007 From: report at bugs.python.org (Raghuram Devarakonda) Date: Thu, 25 Oct 2007 14:31:59 -0000 Subject: [issue1322] platform.dist() has unpredictable result under Linux Message-ID: <1193322719.49.0.0590594606782.issue1322@psf.upfronthosting.co.za> Raghuram Devarakonda added the comment: I think it is safe to ignore lsb-release. In fact, there seems to be a command "lsb_release" that gives information about distribution. On my SuSE box, this is what I get: marvin:~# lsb_release -i Distributor ID: SUSE LINUX marvin:~# lsb_release -d Description: SUSE LINUX 10.1 (i586) marvin:~# lsb_release -r Release: 10.1 sapetnioc, can you check if this command exists on your system and if so, it's output? platform.dist() can check for this command's existence and if present, can perhaps use it to glean distro information. Please let me know if you want to write the patch. I will do it otherwise. ---------- nosy: +draghuram __________________________________ Tracker __________________________________ From report at bugs.python.org Thu Oct 25 18:29:48 2007 From: report at bugs.python.org (Yann Cointepas) Date: Thu, 25 Oct 2007 16:29:48 -0000 Subject: [issue1322] platform.dist() has unpredictable result under Linux In-Reply-To: <1193322719.49.0.0590594606782.issue1322@psf.upfronthosting.co.za> Message-ID: <63d336510710250929waf1312fl428a76070ddd6bc1@mail.gmail.com> Yann Cointepas added the comment: I can easily do the patch to ignore symlinks and /etc/lsb-release but I am not sure of the appropriate way to look for lsb_update command, is distutils.spawn.find_executable( 'lsb_release' ) ok ? If you need the patch earlier than begining of next week, you should do it. Otherwise I can make it. On Mandriva 2007.1, the command exists if the package "lsb-release" is installed. I do not know if it is always installed (I selected a checkbox "LSB" during install, this checkbox is unchecked by default). The output is: [yann at localhost ~]$ lsb_release -a LSB Version: lsb-3.1-ia32:lsb-3.1-noarch:core-3.0-ia32:core-3.0-noarch:core-3.1-ia32:core-3.1-noarch:cxx-3.0-ia32:cxx-3.0-noarch:graphics-3.0-ia32:graphics-3.0-noarch:lsb-3.0-ia32:lsb-3.0-noarch:qt4-3.1-ia32:qt4-3.1-noarch Distributor ID: MandrivaLinux Description: Mandriva Linux Release: 2007.1 Codename: Official [yann at localhost ~]$ lsb_release -i Distributor ID: MandrivaLinux [yann at localhost ~]$ lsb_release -d Description: Mandriva Linux [yann at localhost ~]$ lsb_release -r Release: 2007.1 On Fedora 4 (rather old) , the command is in the package "redhat-lsb". yc176684:src$ lsb_release -a LSB Version: 1.3 Distributor ID: FedoraCore Description: Fedora Core release 4 (Stentz) Release: 4 Codename: Stentz yc176684:src$ lsb_release -i Distributor ID: FedoraCore yc176684:src$ lsb_release -d Description: Fedora Core release 4 (Stentz) yc176684:src$ lsb_release -r Release: 4 On Fedora 7, the command is in the package "redhat-lsb" and seem to be installed by default. gargamel:riviere% lsb_release -a LSB Version: :core-3.1-ia32:core-3.1-noarch: graphics-3.1-ia32:graphics-3.1-noarch Distributor ID: Fedora Description: Fedora release 7 (Moonshine) Release: 7 Codename: Moonshine gargamel:riviere% lsb_release -i Distributor ID: Fedora gargamel:riviere% lsb_release -d Description: Fedora release 7 (Moonshine) gargamel:riviere% lsb_release -r Release: 7 On 10/25/07, Raghuram Devarakonda < report at bugs.python.org> wrote: > > > Raghuram Devarakonda added the comment: > > I think it is safe to ignore lsb-release. In fact, there seems to be a > command "lsb_release" that gives information about distribution. On my > SuSE box, this is what I get: > > marvin:~# lsb_release -i > Distributor ID: SUSE LINUX > marvin:~# lsb_release -d > Description: SUSE LINUX 10.1 (i586) > marvin:~# lsb_release -r > Release: 10.1 > > sapetnioc, can you check if this command exists on your system and if > so, it's output? platform.dist() can check for this command's existence > and if present, can perhaps use it to glean distro information. Please > let me know if you want to write the patch. I will do it otherwise. > > ---------- > nosy: +draghuram > > __________________________________ > Tracker > > __________________________________ > Added file: http://bugs.python.org/file8609/unnamed __________________________________ Tracker __________________________________ -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: unnamed Url: http://mail.python.org/pipermail/python-bugs-list/attachments/20071025/c14bf407/attachment.txt From report at bugs.python.org Thu Oct 25 18:46:07 2007 From: report at bugs.python.org (Raghuram Devarakonda) Date: Thu, 25 Oct 2007 16:46:07 -0000 Subject: [issue1322] platform.dist() has unpredictable result under Linux In-Reply-To: <63d336510710250929waf1312fl428a76070ddd6bc1@mail.gmail.com> Message-ID: <2c51ecee0710250946l759ae69bp78f60fac25d3573e@mail.gmail.com> Raghuram Devarakonda added the comment: On 10/25/07, Yann Cointepas wrote: > I can easily do the patch to ignore symlinks and /etc/lsb-release but I am > not sure of the appropriate way to look for lsb_update command, is > distutils.spawn.find_executable( 'lsb_release' ) ok ? You can just execute the command and if there is any error, default to the current code. There is no need to explicitly check for the binary's existence. > If you need the patch earlier than begining of next week, you should do it. > Otherwise I can make it. I don't "need" the patch :-). If you can't get to it some time next week, I will try to come up with the patch. > > On Mandriva 2007.1, the command exists if the package "lsb-release" is > installed. I do not know if it is always installed (I selected a checkbox > "LSB" during install, this checkbox is unchecked by default). > The output is: > > [yann at localhost ~]$ lsb_release -a > LSB Version: > lsb-3.1-ia32:lsb-3.1-noarch:core-3.0-ia32:core-3.0-noarch:core-3.1-ia32:core-3.1-noarch:cxx-3.0-ia32:cxx-3.0-noarch:graphics-3.0-ia32:graphics-3.0-noarch:lsb-3.0-ia32:lsb-3.0-noarch:qt4-3.1-ia32:qt4-3.1-noarch > Distributor ID: MandrivaLinux > Description: Mandriva Linux > Release: 2007.1 > Codename: Official > > [yann at localhost ~]$ lsb_release -i > Distributor ID: MandrivaLinux > > [yann at localhost ~]$ lsb_release -d > Description: Mandriva Linux > > [yann at localhost ~]$ lsb_release -r > Release: 2007.1 > > On Fedora 4 (rather old) , the command is in the package "redhat-lsb". > > yc176684:src$ lsb_release -a > LSB Version: 1.3 > Distributor ID: FedoraCore > Description: Fedora Core release 4 (Stentz) > Release: 4 > Codename: Stentz > > yc176684:src$ lsb_release -i > Distributor ID: FedoraCore > > yc176684:src$ lsb_release -d > Description: Fedora Core release 4 (Stentz) > > yc176684:src$ lsb_release -r > Release: 4 > > On Fedora 7, the command is in the package "redhat-lsb" and seem to be > installed by default. > > gargamel:riviere% lsb_release -a > LSB > Version: :core-3.1-ia32:core-3.1-noarch: > graphics-3.1-ia32:graphics-3.1-noarch > Distributor ID: Fedora > Description: Fedora release 7 (Moonshine) > Release: 7 > Codename: Moonshine > > gargamel:riviere% lsb_release -i > Distributor ID: Fedora > > gargamel:riviere% lsb_release -d > Description: Fedora release 7 (Moonshine) > > gargamel:riviere% lsb_release -r > Release: 7 > > On 10/25/07, Raghuram Devarakonda < report at bugs.python.org> wrote: > > > > > > Raghuram Devarakonda added the comment: > > > > I think it is safe to ignore lsb-release. In fact, there seems to be a > > command "lsb_release" that gives information about distribution. On my > > SuSE box, this is what I get: > > > > marvin:~# lsb_release -i > > Distributor ID: SUSE LINUX > > marvin:~# lsb_release -d > > Description: SUSE LINUX 10.1 (i586) > > marvin:~# lsb_release -r > > Release: 10.1 > > > > sapetnioc, can you check if this command exists on your system and if > > so, it's output? platform.dist() can check for this command's existence > > and if present, can perhaps use it to glean distro information. Please > > let me know if you want to write the patch. I will do it otherwise. > > > > ---------- > > nosy: +draghuram > > > > __________________________________ > > Tracker > > > > __________________________________ > > > > Added file: http://bugs.python.org/file8609/unnamed > > __________________________________ > Tracker > > __________________________________ > __________________________________ Tracker __________________________________ From report at bugs.python.org Thu Oct 25 19:12:03 2007 From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=) Date: Thu, 25 Oct 2007 17:12:03 -0000 Subject: [issue1318] Remove os.tmpnam() and os.tempnam() In-Reply-To: <1193305469.47.0.0144353397817.issue1318@psf.upfronthosting.co.za> Message-ID: <4720CE60.3080509@v.loewis.de> Martin v. L?wis added the comment: > os.tmpfile() is the only method that has no duplicate in tempfile. Why do you say that? tempfile.mkstemp() does essentially the same as os.tmpfile(). > The promise of tempfile.mkstemp is also bogus for every OS except > Windows. IIRC only Windows supports O_NOINHERIT. Please read the code. It tries to set the CLOEXEC flag on Unix, which should work on most systems. > Let me rephrase the rational for my patch: I want to remove duplicate > code to have just but one implementation to create a temporary file > (name). I want the one implementation be under our control and not > depend on some possible broken or stupid C library like Windows where > tmpnam may create the temporary files in C:\. I want an unified way to > get the TEMP dir independent of the API. As I said, I agree with most of this rationale, except that I'm uncertain whether it is good to trade a stupid C library for a stupid Python implementation. With this rationale, again, I think tmpfile should be removed as well. Regards, Martin ---------- title: Remove os.tmpnam() and os.tempnam() [patch] -> Remove os.tmpnam() and os.tempnam() __________________________________ Tracker __________________________________ From report at bugs.python.org Thu Oct 25 21:32:54 2007 From: report at bugs.python.org (Tal Einat) Date: Thu, 25 Oct 2007 19:32:54 -0000 Subject: [issue1252] IDLE - patch Delegator to support callables Message-ID: <1193340774.34.0.512157048606.issue1252@psf.upfronthosting.co.za> Tal Einat added the comment: I understand your argument, but am not convinced. I'll try to explain how I see this and how I came to this view. I wished to wrap a specific method (or function) instead of wrapping the father object with a Delegator and implementing a single method. But I needed more than simple function wrapping - I wanted a chain of functions where each wraps the next, and the ability to change the order of links in this chain. So what I really wanted was a Percolator, but instead of having it wrap an object and delegate methods, I wanted it to delegate direct calls. My first idea was to implement a FunctionDelegator class. But I realized I would have to implement a FunctionPercolator class, which would be indentical to the existing Percolator class except that it would inherit from FunctionDelegator instead of Delegator. >From there I had three choices: 1) create a second pair of delegator/percolator classes which are nearly identical (much code ducplication) 2) make a Percolator generator function, which accepts a Delegator class, and returns a Percolator class/object which uses it (possibly inheriting from it) 3) make Delegator able to delegate direct calls The third option is obviously the simplest to implement, requiring the least code without any code duplication. After some thought, I came to the point-of-view described below, and realized that the third option is actually what I would expect if I were thinking about delegators and percolators as transparent proxies. > Delegates are not intended to be callable. Why not? IMO, the nice thing about the Delegator class is that you can use an instance just as if it were the underlying object, transparently. The major exception from this behavior was that calling a Delegator never works, even if the underlying object is callable. From this point of view, my patch makes the Delegator concept complete, while before it was broken. > I think this patch increases the complexity and obscurity of the > Delegator/Percolator/WidgetRedirector code, rather than improving > it. Apparently you want to sometimes call a chain of methods (as > in current usage) and sometimes call a chain of functions. The > semantic overload, which was bad enough already, is too great. You describe method calls and direct calls as though they were fundamentally different. Therefore you find that delegating both is too much semantic overloading. However, if one views direct calling of an object as a special case of calling a method (since functions are also objects) -- the __call__ method -- then delegating both method calls and direct calls is The Right Thing. > Also, this __call__ method, if actually used, propagates to the > end of the Delegator chain and calls the function at the end, > (assuming it is a function). Or it will skip non-callable > Delegators and stop at the first callable one. True, since this is precisely what Delegators do for any method call -- this is the expected behavior. > If Squeezer and ShellLogger require this change, then I'd > suggest changing them to match current Percolator usage, instead. > Currently I don't see a Delegator being used in Squeezer. Could > you be more specific about why the change is needed for those > two extensions? Squeezer currently replaces PyShell's write method with a method of its own. ShellLogger also needs to hook onto the write method, but ShellLogger's function must be called before Squeezer's method, since Squeezer can insert a button without calling the underlying write method. But extensions must replace the write method in their constructor, and the order of their construction is "random". In other words, a rudimentary form of constraint enforcement is required, which can be achieved using a Percolator. Without the suggested change to Delegator, this can be accomplished by wrapping EditorWindow with a Percolator, and having extensions insert Delegators (filters) as appropriate. However, this is a much larger change to the code -- for example, this breaks type checks, e.g. assert isinstance(editwin, EditorWindow)). This would also add overhead to every method call done on EditorWindow, with this overhead growing linearly with the number of Delegators inserted. I find wrapping specific methods to be more straightforward and therefore simpler, but this can be argued. __________________________________ Tracker __________________________________ From report at bugs.python.org Thu Oct 25 21:48:41 2007 From: report at bugs.python.org (Thomas Heller) Date: Thu, 25 Oct 2007 19:48:41 -0000 Subject: [issue1324] r58034 breaks building _ctypes with the upstream libffi. Message-ID: <1193341721.13.0.700431102929.issue1324@psf.upfronthosting.co.za> Thomas Heller added the comment: Maybe I should give up the idea to define the ffi_type_... types myself. Committed as rev 58655. Thanks. ---------- resolution: -> accepted status: open -> closed __________________________________ Tracker __________________________________ From report at bugs.python.org Thu Oct 25 21:58:01 2007 From: report at bugs.python.org (Thomas Heller) Date: Thu, 25 Oct 2007 19:58:01 -0000 Subject: [issue1292] libffi needs an update to support mips64, arm and armeabi on linux Message-ID: <1193342281.14.0.0317063180778.issue1292@psf.upfronthosting.co.za> Thomas Heller added the comment: I'm unsure how to proceed with this. Replacing the copy of libffi in the ctypes sources - I'm very afraid to do that. It has it's own configure system, written by someone else. Then it has several changes from various people for Python, which would be overwritten. All these on systems that I do not have direct access to, and we do not have buildbots for all of them. So, it looks like --with-system-ffi should be made the default (on systems that have libffi installed?) There are also test failures since I committed the c_longdouble patch (on alpha debian, and S390 Debian, for example). Maybe newer libffi versions have a fix for that... Last comment: Experimental changes COULD be tested out in a branch, we would only have to manually trigger the build from the buildbot web pages. __________________________________ Tracker __________________________________ From report at bugs.python.org Thu Oct 25 22:58:44 2007 From: report at bugs.python.org (Wummel) Date: Thu, 25 Oct 2007 20:58:44 -0000 Subject: [issue1159051] Handle corrupted gzip files with unexpected EOF Message-ID: <1193345924.83.0.835316745836.issue1159051@psf.upfronthosting.co.za> Wummel added the comment: Here is a new test script that works with simple strings and no file objects. It reproduces the error by cutting off the last two bytes of the GZIP data. The resulting struct error is due to the read() methods missing a check that the requested amount of data is actually returned. In this case read(4) returned 2 bytes instead of 4, and the struct raises an error. I think the easiest way to handle this is to introduce a read_save(fileobj, size) method that checks that the read() data is of the requested size, else raise an error (perhaps an IOError?). btw: you can remove the t.{gz,py} files, the test_gzip_error.py replaces them. Added file: http://bugs.python.org/file8610/test_gzip_error.py _____________________________________ Tracker _____________________________________ -------------- next part -------------- A non-text attachment was scrubbed... Name: test_gzip_error.py Type: text/x-python Size: 413 bytes Desc: not available Url : http://mail.python.org/pipermail/python-bugs-list/attachments/20071025/18596e86/attachment.py From report at bugs.python.org Fri Oct 26 00:43:00 2007 From: report at bugs.python.org (Guido van Rossum) Date: Thu, 25 Oct 2007 22:43:00 -0000 Subject: [issue1318] Remove os.tmpnam() and os.tempnam() Message-ID: <1193352180.16.0.0347724576627.issue1318@psf.upfronthosting.co.za> Guido van Rossum added the comment: Christian can you revise your patch to also remove os.tmpfile per Martin's request? Make sure unit tests and docs are fixed too. __________________________________ Tracker __________________________________ From report at bugs.python.org Fri Oct 26 00:44:13 2007 From: report at bugs.python.org (Guido van Rossum) Date: Thu, 25 Oct 2007 22:44:13 -0000 Subject: [issue1322] platform.dist() has unpredictable result under Linux Message-ID: <1193352253.61.0.0534493440283.issue1322@psf.upfronthosting.co.za> Changes by Guido van Rossum: ---------- nosy: -gvanrossum __________________________________ Tracker __________________________________ From report at bugs.python.org Fri Oct 26 00:48:59 2007 From: report at bugs.python.org (Guido van Rossum) Date: Thu, 25 Oct 2007 22:48:59 -0000 Subject: [issue1286] fileinput, StringIO, and cStringIO do not support the with protocol In-Reply-To: <1193314140.09.0.314444594945.issue1286@psf.upfronthosting.co.za> Message-ID: Guido van Rossum added the comment: 2007/10/25, Yitz Gale : > I was actually bitten badly by this issue with > StringIO. I added fileinput only as an afterthought. > > In an xml.sax app, I needed seek() support for a > codec-wrapped file handle, so I over-wrapped it with > StringIO. The result was that I had to refactor code all over > the place to handle StringIO as a special case. What a > mess! I don't understand. What did your code look like after the refactoring? I find that typically a useful idiom is to have one piece of code handle opening/closing of streams and let the rest of the code just deal with streams without ever closing them. E.g. f = open(filename) try: process(f) finally: f.close() or, if you want: with open(filename) as f: process(f) As I don't understand how you are working the StringIO() call into this I'm still not sure what the issue is. > Why is this getting over-excited? It's a very > lightweight change. You can't beat the cost/benefit ratio. Until you submit a patch it's more work for me. :-) __________________________________ Tracker __________________________________ From report at bugs.python.org Fri Oct 26 00:52:06 2007 From: report at bugs.python.org (Christian Heimes) Date: Thu, 25 Oct 2007 22:52:06 -0000 Subject: [issue1318] Remove os.tmpnam() and os.tempnam() In-Reply-To: <1193352180.16.0.0347724576627.issue1318@psf.upfronthosting.co.za> Message-ID: <47211E10.9050005@cheimes.de> Christian Heimes added the comment: Guido van Rossum wrote: > Christian can you revise your patch to also remove os.tmpfile per > Martin's request? Make sure unit tests and docs are fixed too. I can do that for you. But I still believe that os.tmpfile() works different than tempfile.mkstemp(). The former returns a file descriptor of a file w/o directory entry and the later a file in tempfile.tempdir. Christian __________________________________ Tracker __________________________________ From report at bugs.python.org Fri Oct 26 00:59:36 2007 From: report at bugs.python.org (James G. sack (jim)) Date: Thu, 25 Oct 2007 22:59:36 -0000 Subject: [issue1328] feature request: force BOM option Message-ID: <1193353176.1.0.485065586233.issue1328@psf.upfronthosting.co.za> New submission from James G. sack (jim): The behavior of codecs utf_16_[bl]e is to omit the BOM. In a testing environment (and perhaps elsewhere), a forced BOM is useful. I'm requesting an optional argument something like force_BOM=False I guess it would require such an option in multiple function calls, sorry I don't know enough to itemize them. If this is implemented, it might be desirable to think about the aliases like unicode*unmarked. Regards, ..jim ---------- components: Unicode messages: 56759 nosy: jgsack severity: minor status: open title: feature request: force BOM option type: behavior versions: Python 2.5 __________________________________ Tracker __________________________________ From report at bugs.python.org Fri Oct 26 01:00:33 2007 From: report at bugs.python.org (Guido van Rossum) Date: Thu, 25 Oct 2007 23:00:33 -0000 Subject: [issue1318] Remove os.tmpnam() and os.tempnam() In-Reply-To: <47211E10.9050005@cheimes.de> Message-ID: Guido van Rossum added the comment: 2007/10/25, Christian Heimes : > I can do that for you. But I still believe that os.tmpfile() works > different than tempfile.mkstemp(). The former returns a file descriptor > of a file w/o directory entry and the later a file in tempfile.tempdir. True. But tempfile.TemporaryFile() returns a temp file without a name. __________________________________ Tracker __________________________________ From report at bugs.python.org Fri Oct 26 01:00:51 2007 From: report at bugs.python.org (Christian Heimes) Date: Thu, 25 Oct 2007 23:00:51 -0000 Subject: [issue1318] Remove os.tmpnam() and os.tempnam() Message-ID: <1193353251.51.0.101959909358.issue1318@psf.upfronthosting.co.za> Changes by Christian Heimes: Added file: http://bugs.python.org/file8612/py3k_remove_os_tmp.patch __________________________________ Tracker __________________________________ From report at bugs.python.org Fri Oct 26 01:07:48 2007 From: report at bugs.python.org (Jean Brouwers) Date: Thu, 25 Oct 2007 23:07:48 -0000 Subject: [issue1329] Different 3.0a1 exit behavior Message-ID: <1193353667.97.0.10282198755.issue1329@psf.upfronthosting.co.za> New submission from Jean Brouwers: Python 3.0a1 on Linux and MacOS X 10.4.10 exits differently than Python 2.4 and 2.5. With previous Python binaries the destructor** function of any pre- loaded shared library is called prior to exit. With Python 3.0a1 it is not, neither when exiting Python from the command line with Ctrl-D nor when using exit(). A workaround is to install a SIGABRT signal handler from the library and exit Python with os.abort(). Python 3.0a1 was built from source using the standard build sequence without any ./configure options except --prefix. --- **) defined with GNU __attribute__((destructor)). The shared library is loaded through environment variable LD_PRELOAD on Linux and DYLD_INSERT_LIBRARIES on MacOS X. ---------- components: Interpreter Core messages: 56761 nosy: MrJean1 severity: normal status: open title: Different 3.0a1 exit behavior versions: Python 3.0 __________________________________ Tracker __________________________________ From report at bugs.python.org Fri Oct 26 01:19:02 2007 From: report at bugs.python.org (Guido van Rossum) Date: Thu, 25 Oct 2007 23:19:02 -0000 Subject: [issue1318] Remove os.tmpnam() and os.tempnam() Message-ID: <1193354342.08.0.952586592499.issue1318@psf.upfronthosting.co.za> Guido van Rossum added the comment: Committed revision 58657. Thanks! ---------- resolution: -> accepted status: open -> closed __________________________________ Tracker __________________________________ From report at bugs.python.org Fri Oct 26 01:23:49 2007 From: report at bugs.python.org (Guido van Rossum) Date: Thu, 25 Oct 2007 23:23:49 -0000 Subject: [issue1323] py3k: file.truncate() changes the file position Message-ID: <1193354629.72.0.0507982870686.issue1323@psf.upfronthosting.co.za> Guido van Rossum added the comment: Looks fine to me. Committed revision 58658. ---------- nosy: +gvanrossum resolution: -> accepted status: open -> closed __________________________________ Tracker __________________________________ From report at bugs.python.org Fri Oct 26 01:48:39 2007 From: report at bugs.python.org (Guido van Rossum) Date: Thu, 25 Oct 2007 23:48:39 -0000 Subject: [issue1302] Fixes for profile/cprofile Message-ID: <1193356119.1.0.70757769402.issue1302@psf.upfronthosting.co.za> Guido van Rossum added the comment: Committed revision 58659. I'm sorry I confused you; I was fine with the version that has char lower[N] but I wanted you to not repeat N-1 later in the code. See what I checked in. :-) ---------- resolution: -> accepted status: open -> closed __________________________________ Tracker __________________________________ From report at bugs.python.org Fri Oct 26 02:00:48 2007 From: report at bugs.python.org (Christian Heimes) Date: Fri, 26 Oct 2007 00:00:48 -0000 Subject: [issue1302] Fixes for profile/cprofile In-Reply-To: <1193356119.1.0.70757769402.issue1302@psf.upfronthosting.co.za> Message-ID: <47212E2A.1080902@cheimes.de> Christian Heimes added the comment: Guido van Rossum wrote: > Guido van Rossum added the comment: > > Committed revision 58659. > > I'm sorry I confused you; I was fine with the version that has char > lower[N] but I wanted you to not repeat N-1 later in the code. See what > I checked in. :-) I still don't understand why you are using (sizeof lower) - 2 and what &lower[(sizeof lower) - 2] returns. Is it the memory address of lower[17]? __________________________________ Tracker __________________________________ From report at bugs.python.org Fri Oct 26 02:19:29 2007 From: report at bugs.python.org (Alexandre Vassalotti) Date: Fri, 26 Oct 2007 00:19:29 -0000 Subject: [issue1302] Fixes for profile/cprofile Message-ID: <1193357969.06.0.923641373901.issue1302@psf.upfronthosting.co.za> Alexandre Vassalotti added the comment: > I still don't understand why you are using (sizeof lower) - 2 It is simply to avoid duplicating the constant (a.k.a. the Don't Repeat Yourself (DRY) rule). > and what &lower[(sizeof lower) - 2] returns. Is it the memory address > of lower[17]? It the address of lower[18] to be exact. (l < &lower[(sizeof lower) - 2]) is simply tricky notation to check the bound of the array. Personally, I used like to subtract pointer, ((lower - l + 1) < (sizeof lower)) to get the bound. But now, I find Guido's trick more cute (and less error-prone). :) __________________________________ Tracker __________________________________ From report at bugs.python.org Fri Oct 26 02:29:04 2007 From: report at bugs.python.org (Alexandre Vassalotti) Date: Fri, 26 Oct 2007 00:29:04 -0000 Subject: [issue1302] Fixes for profile/cprofile Message-ID: <1193358544.17.0.908608233246.issue1302@psf.upfronthosting.co.za> Alexandre Vassalotti added the comment: > Personally, I used like to subtract pointer, ((lower - l + 1) < > (sizeof lower)) to get the bound. Doh. I got it backward. It's (l - lower + 1), not (lower - l + 1). > But now, I find Guido's trick more cute (and less error-prone). At least, I got that right. :) __________________________________ Tracker __________________________________ From report at bugs.python.org Fri Oct 26 02:30:36 2007 From: report at bugs.python.org (Christian Heimes) Date: Fri, 26 Oct 2007 00:30:36 -0000 Subject: [issue1302] Fixes for profile/cprofile In-Reply-To: <1193357969.06.0.923641373901.issue1302@psf.upfronthosting.co.za> Message-ID: <47213527.1070201@cheimes.de> Christian Heimes added the comment: Alexandre Vassalotti wrote: > It the address of lower[18] to be exact. (l < &lower[(sizeof lower) - > 2]) is simply tricky notation to check the bound of the array. > Personally, I used like to subtract pointer, ((lower - l + 1) < (sizeof > lower)) to get the bound. But now, I find Guido's trick more cute (and > less error-prone). :) Wow, that's a cool trick. The old wizard has still some astonishing tricks in the sleeves of his robe. :] __________________________________ Tracker __________________________________ From report at bugs.python.org Fri Oct 26 03:39:31 2007 From: report at bugs.python.org (Christian Heimes) Date: Fri, 26 Oct 2007 01:39:31 -0000 Subject: [issue1330] Fix truncate on Windows, this time for real Message-ID: <1193362771.35.0.841578891036.issue1330@psf.upfronthosting.co.za> New submission from Christian Heimes: The patch fixes for real what "Patch # 1323 by Amaury Forgeot d'Arc" claims to have fixed. I reverted his patch to io.py and implemented the fix in the Windows specific part of truncate in _fileio.c. It fixes two tests for raw io on Windows. ---------- components: Library (Lib) files: py3k_win_io.patch messages: 56769 nosy: tiran severity: normal status: open title: Fix truncate on Windows, this time for real type: behavior versions: Python 3.0 Added file: http://bugs.python.org/file8613/py3k_win_io.patch __________________________________ Tracker __________________________________ -------------- next part -------------- A non-text attachment was scrubbed... Name: py3k_win_io.patch Type: text/x-diff Size: 2166 bytes Desc: not available Url : http://mail.python.org/pipermail/python-bugs-list/attachments/20071026/6665671d/attachment.patch From report at bugs.python.org Fri Oct 26 03:40:15 2007 From: report at bugs.python.org (Christian Heimes) Date: Fri, 26 Oct 2007 01:40:15 -0000 Subject: [issue1330] Fix truncate on Windows, this time for real Message-ID: <1193362815.33.0.141805652421.issue1330@psf.upfronthosting.co.za> Changes by Christian Heimes: ---------- nosy: +gvanrossum, nnorwitz __________________________________ Tracker __________________________________ From report at bugs.python.org Fri Oct 26 04:21:15 2007 From: report at bugs.python.org (Christian Heimes) Date: Fri, 26 Oct 2007 02:21:15 -0000 Subject: [issue1331] More fixes for Windows Message-ID: <1193365275.63.0.0756380747917.issue1331@psf.upfronthosting.co.za> New submission from Christian Heimes: The patch fixes some of the problems on Windows. It doesn't introduce addition problems on Linux. ---------- components: Library (Lib) files: py3k_misc_win.patch messages: 56770 nosy: gvanrossum, nnorwitz, tiran severity: normal status: open title: More fixes for Windows type: behavior versions: Python 3.0 Added file: http://bugs.python.org/file8614/py3k_misc_win.patch __________________________________ Tracker __________________________________ -------------- next part -------------- A non-text attachment was scrubbed... Name: py3k_misc_win.patch Type: text/x-diff Size: 7054 bytes Desc: not available Url : http://mail.python.org/pipermail/python-bugs-list/attachments/20071026/facf7426/attachment-0001.patch From report at bugs.python.org Fri Oct 26 04:38:23 2007 From: report at bugs.python.org (Facundo Batista) Date: Fri, 26 Oct 2007 02:38:23 -0000 Subject: [issue1255] Strange Python hangup Message-ID: <1193366303.28.0.816398794515.issue1255@psf.upfronthosting.co.za> Facundo Batista added the comment: The deadlock happens because strptime has an import inside it, and recursive imports are not allowed in different threads. As a general rule and good coding style, don't run your code when the module is imported, but put it in a function like "main" in the second file,import it and call it from the first one. This will solve your problem. Note that this happens to you with strptime, but could happen with a lot, *a lot*, of functions that do this internal import of something else. So, you'll never be sure. You can follow the python-dev thread titled "Deadlock by a second import in a thread" for more info. ---------- nosy: +facundobatista resolution: -> wont fix status: open -> closed __________________________________ Tracker __________________________________ From report at bugs.python.org Fri Oct 26 04:48:31 2007 From: report at bugs.python.org (Warren DeLano) Date: Fri, 26 Oct 2007 02:48:31 -0000 Subject: [issue1332] threading.RLock().aquire(0) fails with python-2.5.1.amd64.msi Message-ID: <1193366911.48.0.10009390282.issue1332@psf.upfronthosting.co.za> Changes by Warren DeLano: ---------- components: Windows nosy: delwarl severity: normal status: open title: threading.RLock().aquire(0) fails with python-2.5.1.amd64.msi type: behavior versions: Python 2.5 __________________________________ Tracker __________________________________ From report at bugs.python.org Fri Oct 26 04:54:02 2007 From: report at bugs.python.org (Warren DeLano) Date: Fri, 26 Oct 2007 02:54:02 -0000 Subject: [issue1332] threading.RLock().aquire(0) fails with python-2.5.1.amd64.msi Message-ID: <1193367242.94.0.6471500852.issue1332@psf.upfronthosting.co.za> New submission from Warren DeLano: import threading rlock = threading.RLock() rlock.acquire(0) # always returns False with python-2.5.1.amd64.msi # even though rlock.acquire() # returns True as expected. # All attempts to acquire locks without blocking are foiled! __________________________________ Tracker __________________________________ From report at bugs.python.org Fri Oct 26 05:08:19 2007 From: report at bugs.python.org (Christian Heimes) Date: Fri, 26 Oct 2007 03:08:19 -0000 Subject: [issue1322] platform.dist() has unpredictable result under Linux Message-ID: <1193368099.9.0.964347002476.issue1322@psf.upfronthosting.co.za> Christian Heimes added the comment: Ony my Ubuntu box lsb_release is just a small Python script that parses /etc/lsb-release. I suggest that your read the LSB standards about the file and use the information to parse it instead of invoking a program. ---------- nosy: +tiran __________________________________ Tracker __________________________________ From report at bugs.python.org Fri Oct 26 05:19:07 2007 From: report at bugs.python.org (Guido van Rossum) Date: Fri, 26 Oct 2007 03:19:07 -0000 Subject: [issue1330] Fix truncate on Windows, this time for real Message-ID: <1193368747.3.0.251954001041.issue1330@psf.upfronthosting.co.za> Changes by Guido van Rossum: ---------- assignee: -> gvanrossum keywords: +patch, py3k __________________________________ Tracker __________________________________ From report at bugs.python.org Fri Oct 26 05:33:30 2007 From: report at bugs.python.org (Raghuram Devarakonda) Date: Fri, 26 Oct 2007 03:33:30 -0000 Subject: [issue1322] platform.dist() has unpredictable result under Linux In-Reply-To: <1193368099.9.0.964347002476.issue1322@psf.upfronthosting.co.za> Message-ID: <2c51ecee0710252033y74870d72s882700dfed41dda9@mail.gmail.com> Raghuram Devarakonda added the comment: > Ony my Ubuntu box lsb_release is just a small Python script that parses > /etc/lsb-release. I suggest that your read the LSB standards about the > file and use the information to parse it instead of invoking a program. Can you please check if it supports all the options mentioned previously in the bug report? I agree that reading from a file is preferable to running a command, if issues OP mentioned can be addressed. __________________________________ Tracker __________________________________ From report at bugs.python.org Fri Oct 26 05:43:43 2007 From: report at bugs.python.org (Christian Heimes) Date: Fri, 26 Oct 2007 03:43:43 -0000 Subject: [issue1322] platform.dist() has unpredictable result under Linux Message-ID: <1193370223.3.0.83146260959.issue1322@psf.upfronthosting.co.za> Christian Heimes added the comment: heimes at seneca:~$ /usr/bin/lsb_release -a LSB Version: core-2.0-noarch:core-3.0-noarch:core-3.1-noarch:core-2.0-ia32:core-3.0-ia32:core-3.1-ia32:cxx-2.0-noarch:cxx-3.0-noarch:cxx-3.1-noarch:cxx-2.0-ia32:cxx-3.0-ia32:cxx-3.1-ia32:graphics-2.0-noarch:graphics-3.0-noarch:graphics-3.1-noarch:graphics-2.0-ia32:graphics-3.0-ia32:graphics-3.1-ia32:desktop-3.1-noarch:desktop-3.1-ia32 Distributor ID: Ubuntu Description: Ubuntu 7.10 Release: 7.10 Codename: gutsy heimes at seneca:~$ /usr/bin/lsb_release -i Distributor ID: Ubuntu heimes at seneca:~$ /usr/bin/lsb_release -d Description: Ubuntu 7.10 heimes at seneca:~$ /usr/bin/lsb_release -c Codename: gutsy heimes at seneca:~$ /usr/bin/lsb_release -r Release: 7.10 Please read http://linux.die.net/man/1/lsb_release. It explains the content of /etc/*-release in detail. __________________________________ Tracker __________________________________ From report at bugs.python.org Fri Oct 26 06:13:51 2007 From: report at bugs.python.org (Guido van Rossum) Date: Fri, 26 Oct 2007 04:13:51 -0000 Subject: [issue1330] Fix truncate on Windows, this time for real Message-ID: <1193372031.11.0.667861675633.issue1330@psf.upfronthosting.co.za> Guido van Rossum added the comment: While I like fixing the position restore in _fileio.c, I also liked Amaury's flush() call in _BufferedIOMixin. Perhaps you can keep that part (while losing the position restore)? __________________________________ Tracker __________________________________ From report at bugs.python.org Fri Oct 26 06:29:46 2007 From: report at bugs.python.org (Guido van Rossum) Date: Fri, 26 Oct 2007 04:29:46 -0000 Subject: [issue1331] More fixes for Windows Message-ID: <1193372986.08.0.24354624059.issue1331@psf.upfronthosting.co.za> Guido van Rossum added the comment: Tested on OSX as well. Thanks!! Committed revision 58662. ---------- assignee: -> gvanrossum keywords: +patch, py3k resolution: -> accepted status: open -> closed __________________________________ Tracker __________________________________ From report at bugs.python.org Fri Oct 26 06:44:55 2007 From: report at bugs.python.org (Christian Heimes) Date: Fri, 26 Oct 2007 04:44:55 -0000 Subject: [issue1330] Fix truncate on Windows, this time for real In-Reply-To: <1193372031.11.0.667861675633.issue1330@psf.upfronthosting.co.za> Message-ID: <472170C1.4060301@cheimes.de> Christian Heimes added the comment: > While I like fixing the position restore in _fileio.c, I also liked > Amaury's flush() call in _BufferedIOMixin. Perhaps you can keep that > part (while losing the position restore)? Good point. We have to call flush() in _BufferedIOMixin as you said. I checked if I could add a flush call to _fileio but it makes no sense. We are working on file descriptors which means we don't have to use fflush() and FileIO's flush() is a NOOP. Added file: http://bugs.python.org/file8615/py3k_win_io2.patch __________________________________ Tracker __________________________________ -------------- next part -------------- A non-text attachment was scrubbed... Name: py3k_win_io2.patch Type: text/x-patch Size: 2183 bytes Desc: not available Url : http://mail.python.org/pipermail/python-bugs-list/attachments/20071026/aac521bc/attachment.bin From report at bugs.python.org Fri Oct 26 08:28:16 2007 From: report at bugs.python.org (Neal Norwitz) Date: Fri, 26 Oct 2007 06:28:16 -0000 Subject: [issue1329] Different 3.0a1 exit behavior Message-ID: <1193380096.39.0.939707888211.issue1329@psf.upfronthosting.co.za> Neal Norwitz added the comment: Thanks for testing 3.0. Do you have any idea why they are no longer called? I don't recall any changes related to this area. Can you try to debug further? ---------- nosy: +nnorwitz __________________________________ Tracker __________________________________ From report at bugs.python.org Fri Oct 26 08:33:33 2007 From: report at bugs.python.org (James G. sack (jim)) Date: Fri, 26 Oct 2007 06:33:33 -0000 Subject: [issue1328] feature request: force BOM option Message-ID: <1193380413.29.0.984877318762.issue1328@psf.upfronthosting.co.za> James G. sack (jim) added the comment: Feature Request REVISION ======================== Upon reflection and more playing around with some test cases, I wish to revise my feature request. I think the utf8 codecs should accept input with or without the "sig". On output, only the utf_8_sig should write the 3-byte "sig". This behavior change would not seem disruptive to current applications. For utf16, (arguably) a missing BOM should merely assume machian endianess. For utf_16_le, utf_16_be input, both should accept & discard a BOM. On output, I'm not sure; maybe all should write a BOM unless passed a flag signifying no bom? Or to preserve backward compat, could have a parm write_bom defaulting to True for utf16 and False for utf_16_le and utf_16_be. This is a modification of the originial request (for a force_bom flag). Unless I have confused myself with my test cases, the current codecs are slightly inconsistent for the utf8 codecs: utf8 treats "sig" as real data, if present, but.. utf_8_sig works right even without the "sig" (so this one I like as is!) The 16'ers seem to match the (inferred) specs, but for completeness here: utf_16 refuses to proceed w/o BOM (even with correct endian input data) utf_16_le treats BOM as data utf_16_be treats BOM as data Regards, ..jim __________________________________ Tracker __________________________________ From report at bugs.python.org Fri Oct 26 08:36:34 2007 From: report at bugs.python.org (Jiri Krivanek) Date: Fri, 26 Oct 2007 06:36:34 -0000 Subject: [issue1255] Strange Python hangup Message-ID: <1193380594.03.0.882870073649.issue1255@psf.upfronthosting.co.za> Jiri Krivanek added the comment: In the mena time, by intuition, I have resolved my troube exactly the way you recommend. Thanks to you, currently I also know what is he core of the problem. So the issue can be closed... __________________________________ Tracker __________________________________ From report at bugs.python.org Fri Oct 26 08:43:59 2007 From: report at bugs.python.org (James G. sack (jim)) Date: Fri, 26 Oct 2007 06:43:59 -0000 Subject: [issue1328] feature request: force BOM option Message-ID: <1193381039.2.0.766967767699.issue1328@psf.upfronthosting.co.za> James G. sack (jim) added the comment: Later note: kind of weird! On my LE machine, utf16 reads my BE-formatted test data (no BOM) apparently assumng some kind of surrogate format, until it finds an "illegal UTF-16 surrogate". That I fail to understand, especially since it quits upon seeing a BOM with valid LE data. Test data and test code available on request. Regards, ..jim __________________________________ Tracker __________________________________ From report at bugs.python.org Fri Oct 26 11:47:57 2007 From: report at bugs.python.org (Ralf Schmitt) Date: Fri, 26 Oct 2007 09:47:57 -0000 Subject: [issue1089358] need siginterrupt() on Linux - impossible to do timeouts Message-ID: <1193392077.67.0.368951692998.issue1089358@psf.upfronthosting.co.za> Ralf Schmitt added the comment: PyOS_setsig in pythonrun.c now calls siginterrupt(sig, 1) (in Python 2.4.4/Python 2.5.1, but not in Python 2.3). So you should be able to timeout the system calls with a signal.alarm call. However, having siginterrupt available would still be useful. I have some patches for the signal module and will clean them up in some days and attach to this bug. Here's an implementation using ctypes: def siginterrupt(signum, flag): """change restart behavior when a function is interrupted by the specified signal. see man siginterrupt. """ import ctypes import sys if flag: flag = 1 else: flag = 0 if sys.platform=='darwin': libc = ctypes.CDLL("libc.dylib") elif sys.platform=='linux2': libc = ctypes.CDLL("libc.so.6") else: libc = ctypes.CDLL("libc.so") if libc.siginterrupt(signum, flag)!=0: raise OSError("siginterrupt failed") ---------- nosy: +schmir _____________________________________ Tracker _____________________________________ From report at bugs.python.org Fri Oct 26 13:39:38 2007 From: report at bugs.python.org (Yann Cointepas) Date: Fri, 26 Oct 2007 11:39:38 -0000 Subject: [issue1322] platform.dist() has unpredictable result under Linux Message-ID: <1193398778.75.0.0834754771338.issue1322@psf.upfronthosting.co.za> Yann Cointepas added the comment: I am writing a patch but I have a few questions: 1) There are at most three places where the distribution name can be found. What is the priority order to select only one name ? The three places are: a) Inside the /etc/lsb-release file b) In the name of the /etc/-release file c) In the content of the /etc/-release file For instance, on Mandriva 2007.1 the possible names are: a) 'MandrivaLinux' b) 'mandriva' c) 'Mandriva Linux' I would suggest to put a) first to be compatible with LSB but on most systems it would change the value returned by platform.dist after the patch (is it a problem ?). I would have liked to use c) as second choice but this space in the name set by Mandriva could be a problem (It's possible to suppress spaces in the result though). 2) Can I remove supported_dists parameter of platform.dist ? There could be a list of supported distributions but why as a parameter of this function ? __________________________________ Tracker __________________________________ From report at bugs.python.org Fri Oct 26 13:45:57 2007 From: report at bugs.python.org (Christian Heimes) Date: Fri, 26 Oct 2007 11:45:57 -0000 Subject: [issue1322] platform.dist() has unpredictable result under Linux In-Reply-To: <1193398778.75.0.0834754771338.issue1322@psf.upfronthosting.co.za> Message-ID: <4721D36C.9040201@cheimes.de> Christian Heimes added the comment: > I am writing a patch but I have a few questions: > > 1) There are at most three places where the distribution name can be > found. What is the priority order to select only one name ? > The three places are: > a) Inside the /etc/lsb-release file > b) In the name of the /etc/-release file > c) In the content of the /etc/-release file As far as I remember the specs a /etc/*-release file has a higher priority than /etc/lsb-release. > 2) Can I remove supported_dists parameter of platform.dist ? > There could be a list of supported distributions but why > as a parameter of this function ? I agree. A module global list is better than a list as a function argument. Can you also use a global variable instead of "/etc"? Something like ETC_DIR = "/etc" for example. It would allow you to ship samples from several distribution and run unit tests against each. Christian __________________________________ Tracker __________________________________ From report at bugs.python.org Fri Oct 26 13:48:51 2007 From: report at bugs.python.org (Christian Heimes) Date: Fri, 26 Oct 2007 11:48:51 -0000 Subject: [issue1322] platform.dist() has unpredictable result under Linux In-Reply-To: <4721D36C.9040201@cheimes.de> Message-ID: <4721D41C.1000504@cheimes.de> Christian Heimes added the comment: > Can you also use a global variable instead of "/etc"? Something like > ETC_DIR = "/etc" for example. It would allow you to ship samples from > several distribution and run unit tests against each. I've attached the two relevant files from Ubuntu 7.10 Gutsy. Added file: http://bugs.python.org/file8616/debian_version Added file: http://bugs.python.org/file8617/lsb-release __________________________________ Tracker __________________________________ -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: debian_version Url: http://mail.python.org/pipermail/python-bugs-list/attachments/20071026/950d4438/attachment.txt -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: lsb-release Url: http://mail.python.org/pipermail/python-bugs-list/attachments/20071026/950d4438/attachment-0001.txt From report at bugs.python.org Fri Oct 26 14:16:28 2007 From: report at bugs.python.org (anatoly techtonik) Date: Fri, 26 Oct 2007 12:16:28 -0000 Subject: [issue1333] merge urllib and urlparse functionality Message-ID: <1193400988.05.0.68480909797.issue1333@psf.upfronthosting.co.za> New submission from anatoly techtonik: The purpose is to encapsulate all URL handling functions in one module. At the moment there are three modules that dissect URLs for various bits of information. These are urlparse - to split url into components, urllib - to decode splitted data and cgi - to parse query component. To outline the API of the proposed module I'll start with urlparse : http://docs.python.org/lib/module-urlparse.html 1. There are two identical functions - urlparse and urlsplit that make the same parsing operation, but vary in format of return arguments. They could be replaced with one - let's call it urlsplitex - that returns result in a class with attributes - not a subclass of list, but rather dictionary subclass, because positional arguments are evil and you always have to look into reference to find out the correct order if you read or debug the code. 2. Returned class should not be immutable. It must be possible to modify the results to unset extra parts (like fragments) or edit required parts as needed and get the target URL via urlunsplitex or embedded method of the same class. Thus arguments "default_scheme" and "allow_fragments" will be useless as well as function urldefrag. 3. urlparsex, a replacement for "parsing" function of the new library should be high-level functions to dissect url information into tree-like structure with atomic leafs. This includes decoding url entities and splitting parameters into child structures. The proposed structure of url class attributes is: scheme string netloc class username string password string server string port integer path list with objects of class part string param list with objects of class name string value string query list with objects of class name string value string fragment string 4. urlunparsex will be provided to reassemble class back into URL. This will deprecate series of functions from urllib like quote, unquote, urlencode and also functions parse_qs and parse_qsl from cgi module. References: http://mail.python.org/pipermail/patches/2005-February/016972.html http://bugs.python.org/issue1722348 http://bugs.python.org/issue1462525 ---------- components: Library (Lib) messages: 56787 nosy: techtonik severity: normal status: open title: merge urllib and urlparse functionality type: rfe versions: Python 3.0 __________________________________ Tracker __________________________________ From report at bugs.python.org Fri Oct 26 15:16:09 2007 From: report at bugs.python.org (Tal Einat) Date: Fri, 26 Oct 2007 13:16:09 -0000 Subject: [issue1334] IDLE - Fix several highlighting bugs Message-ID: <1193404569.43.0.620999793422.issue1334@psf.upfronthosting.co.za> New submission from Tal Einat: This patch fixes the following bugs: * Configured selection highlighting colors were ignored * Updating highlighting in the config dialog would cause non-Python files to be colored as if they were Python source Additionally, adding and removing of ColorDelegators to the Percolator was not being done in an organized fashion, causing multiple colorizers to be present simultaneously in certain cases. This patch ensures that there will always be at most one colorizer present in the Percolator. This patch also reduces code duplication by grouping colorization code into EditorWindow.ResetColorizer, and having __init__ let ResetColorizer do its thing. There is one side effect to this patch - applying a new highlighting scheme or renaming a file causes the screen to "blink". This can be avoided without too much work, but IMHO is minor enough to leave as it is. ---------- components: IDLE files: IDLE_highlighting.071026.patch messages: 56788 nosy: kbk, taleinat severity: normal status: open title: IDLE - Fix several highlighting bugs versions: Python 2.5, Python 2.6 Added file: http://bugs.python.org/file8618/IDLE_highlighting.071026.patch __________________________________ Tracker __________________________________ -------------- next part -------------- A non-text attachment was scrubbed... Name: IDLE_highlighting.071026.patch Type: application/octet-stream Size: 5388 bytes Desc: not available Url : http://mail.python.org/pipermail/python-bugs-list/attachments/20071026/1ef27895/attachment.obj From report at bugs.python.org Fri Oct 26 15:50:39 2007 From: report at bugs.python.org (Christian Heimes) Date: Fri, 26 Oct 2007 13:50:39 -0000 Subject: [issue1335] bytesiterator patch Message-ID: <1193406639.07.0.00963695082717.issue1335@psf.upfronthosting.co.za> New submission from Christian Heimes: Here is the long promised bytes iterator view. It was much, *much* easier to write it than I have thought. In fact I spent more time fixing the indention than to modify the code from striterator. I haven't written an unit test for it. The other iterators don't have extra tests, too. >>> iter(bytes(b"abc")) >>> for i in iter(bytes(b"abc")): print(i) ... 97 98 99 >>> for i in bytes(b"abc"): print(i) ... 97 98 99 ---------- components: Interpreter Core files: py3k_bytesiterator.patch messages: 56789 nosy: gvanrossum, tiran severity: normal status: open title: bytesiterator patch type: rfe versions: Python 3.0 Added file: http://bugs.python.org/file8619/py3k_bytesiterator.patch __________________________________ Tracker __________________________________ -------------- next part -------------- A non-text attachment was scrubbed... Name: py3k_bytesiterator.patch Type: text/x-diff Size: 4646 bytes Desc: not available Url : http://mail.python.org/pipermail/python-bugs-list/attachments/20071026/f0a8f418/attachment-0001.patch From report at bugs.python.org Fri Oct 26 16:04:12 2007 From: report at bugs.python.org (Jonathan Amsterdam) Date: Fri, 26 Oct 2007 14:04:12 -0000 Subject: [issue1336] subprocess.Popen hangs when child writes to stderr Message-ID: <1193407452.43.0.999665750675.issue1336@psf.upfronthosting.co.za> New submission from Jonathan Amsterdam: This is under Linux (2.6). I occasionally see subprocess.Popen() fail to return, and I have finally figured out roughly what's going on. It involves the GC and stderr. 1. os.fork() 2. Parent blocks reading from errpipe_read (subprocess.py:982) 3. In child, a GC occurs before the exec. 4. The GC attempts to free a file descriptor, calling file_dealloc. 5. That function gets an error closing the descriptor ("close failed: [Errno 9] Bad file descriptor\n," is the string I extracted via gdb). 6. It attempts to write the error to stderr and blocks. Since it never execs or writes to errpipe_write, both child and parent are hung. Here is the pstack output on the child: #0 0x006587a2 in _dl_sysinfo_int80 () from /lib/ld-linux.so.2 #1 0x0072f11b in __write_nocancel () from /lib/tls/libc.so.6 #2 0x006d409f in _IO_new_file_write () from /lib/tls/libc.so.6 #3 0x006d42ec in _IO_new_file_xsputn () from /lib/tls/libc.so.6 #4 0x006afce9 in buffered_vfprintf () from /lib/tls/libc.so.6 #5 0x006afe8b in vfprintf () from /lib/tls/libc.so.6 #6 0x080dd4af in mywrite () #7 0x080dd505 in PySys_WriteStderr () #8 0x08064cd0 in file_dealloc () #9 0x08079c88 in dict_dealloc () #10 0x0808931d in subtype_dealloc () #11 0x08079af3 in PyDict_Clear () #12 0x0807bb6a in dict_tp_clear () #13 0x080e0ead in collect () #14 0x080e1912 in _PyObject_GC_New () #15 0x0805e50b in PyInstance_NewRaw () #16 0x0805e5d7 in PyInstance_New () #17 0x0805bdc0 in PyObject_Call () #18 0x080aecef in PyEval_CallObjectWithKeywords () #19 0x080ca975 in PyErr_NormalizeException () #20 0x080b492c in PyEval_EvalFrame () #21 0x080b5eb2 in PyEval_EvalCodeEx () #22 0x080b3c83 in PyEval_EvalFrame () #23 0x080b5734 in PyEval_EvalFrame () #24 0x080b5eb2 in PyEval_EvalCodeEx () #25 0x080fce92 in function_call () #26 0x0805bdc0 in PyObject_Call () #27 0x080641e5 in instancemethod_call () #28 0x0805bdc0 in PyObject_Call () #29 0x0808ffce in slot_tp_init () #30 0x08088b3a in type_call () #31 0x0805bdc0 in PyObject_Call () #32 0x080b0f05 in PyEval_EvalFrame () #33 0x080b5eb2 in PyEval_EvalCodeEx () #34 0x080fce92 in function_call () #35 0x0805bdc0 in PyObject_Call () #36 0x080641e5 in instancemethod_call () #37 0x0805bdc0 in PyObject_Call () #38 0x0808ffce in slot_tp_init () #39 0x08088b3a in type_call () #40 0x0805bdc0 in PyObject_Call () #41 0x080b0f05 in PyEval_EvalFrame () #42 0x080b5734 in PyEval_EvalFrame () #43 0x080b5eb2 in PyEval_EvalCodeEx () #44 0x080fce92 in function_call () #45 0x0805bdc0 in PyObject_Call () #46 0x080641e5 in instancemethod_call () #47 0x0805bdc0 in PyObject_Call () #48 0x0808ffce in slot_tp_init () #49 0x08088b3a in type_call () #50 0x0805bdc0 in PyObject_Call () #51 0x080b0f05 in PyEval_EvalFrame () #52 0x080b5eb2 in PyEval_EvalCodeEx () #53 0x080fce92 in function_call () #54 0x0805bdc0 in PyObject_Call () #55 0x080b075f in PyEval_EvalFrame () #56 0x080b5734 in PyEval_EvalFrame () #57 0x080b5734 in PyEval_EvalFrame () #58 0x080b5734 in PyEval_EvalFrame () #59 0x080b5eb2 in PyEval_EvalCodeEx () #60 0x080b3c83 in PyEval_EvalFrame () #61 0x080b5734 in PyEval_EvalFrame () #62 0x080b5734 in PyEval_EvalFrame () #63 0x080b5eb2 in PyEval_EvalCodeEx () #64 0x080b3c83 in PyEval_EvalFrame () #65 0x080b5eb2 in PyEval_EvalCodeEx () #66 0x080b3c83 in PyEval_EvalFrame () #67 0x080b5eb2 in PyEval_EvalCodeEx () #68 0x080b3c83 in PyEval_EvalFrame () #69 0x080b5734 in PyEval_EvalFrame () #70 0x080b5734 in PyEval_EvalFrame () #71 0x080b5734 in PyEval_EvalFrame () #72 0x080b5734 in PyEval_EvalFrame () #73 0x080b5734 in PyEval_EvalFrame () #74 0x080b5eb2 in PyEval_EvalCodeEx () #75 0x080fce92 in function_call () #76 0x0805bdc0 in PyObject_Call () #77 0x080b075f in PyEval_EvalFrame () #78 0x080b5eb2 in PyEval_EvalCodeEx () #79 0x080b3c83 in PyEval_EvalFrame () #80 0x080b5eb2 in PyEval_EvalCodeEx () #81 0x080b3c83 in PyEval_EvalFrame () #82 0x080b5eb2 in PyEval_EvalCodeEx () #83 0x080b3c83 in PyEval_EvalFrame () #84 0x080b5734 in PyEval_EvalFrame () #85 0x080b5734 in PyEval_EvalFrame () #86 0x080b5eb2 in PyEval_EvalCodeEx () #87 0x080b601a in PyEval_EvalCode () #88 0x080d9ff4 in PyRun_FileExFlags () #89 0x080da8d6 in PyRun_SimpleFileExFlags () #90 0x08055617 in Py_Main () #91 0x08054e3f in main () ---------- components: Library (Lib) messages: 56790 nosy: jba severity: normal status: open title: subprocess.Popen hangs when child writes to stderr type: crash versions: Python 2.4 __________________________________ Tracker __________________________________ From report at bugs.python.org Fri Oct 26 16:10:25 2007 From: report at bugs.python.org (Kevin Watters) Date: Fri, 26 Oct 2007 14:10:25 -0000 Subject: [issue1337] Tools/msi/msi.py does not work with PCBuild8 Message-ID: <1193407824.97.0.744123721135.issue1337@psf.upfronthosting.co.za> New submission from Kevin Watters: The msi.py script for creating an Windows MSI installer from a Python source tree has hardcoded values for "PCBuild." The newer MSVC 2005 build directory is "PCBuild8" and has a slightly different structure. msi.py needs to be changed to be able to work with a 2005-built Python tree as well. ---------- components: Build messages: 56791 nosy: kevinwatters severity: normal status: open title: Tools/msi/msi.py does not work with PCBuild8 type: rfe versions: Python 2.6, Python 3.0 __________________________________ Tracker __________________________________ From report at bugs.python.org Fri Oct 26 17:28:31 2007 From: report at bugs.python.org (Jean Brouwers) Date: Fri, 26 Oct 2007 15:28:31 -0000 Subject: [issue1329] Different 3.0a1 exit behavior Message-ID: <1193412511.13.0.904140839167.issue1329@psf.upfronthosting.co.za> Jean Brouwers added the comment: Here is one thought, maybe 3.0a calls _exit() while 2.x uses exit() to terminate. With _exit() any functions installed with atexit() or on_exit() are *not* called. That would explain the difference but only if destructor functions are installed with atexit() or on_exit(). I do not know whether that. __________________________________ Tracker __________________________________ From report at bugs.python.org Fri Oct 26 17:30:26 2007 From: report at bugs.python.org (Jean Brouwers) Date: Fri, 26 Oct 2007 15:30:26 -0000 Subject: [issue1329] Different 3.0a1 exit behavior Message-ID: <1193412626.2.0.598298530268.issue1329@psf.upfronthosting.co.za> Jean Brouwers added the comment: Sorry, premature submit. I will try using atexit() and report what happens there. __________________________________ Tracker __________________________________ From report at bugs.python.org Fri Oct 26 17:43:57 2007 From: report at bugs.python.org (Eric Sammons) Date: Fri, 26 Oct 2007 15:43:57 -0000 Subject: [issue1327] Python 2.4+ spends too much time in PyEval_EvalFrame w/ xmlrpmclib Message-ID: <1193413437.88.0.0877613719759.issue1327@psf.upfronthosting.co.za> Eric Sammons added the comment: I have tested 2.4.4 and 2.5.1 from python.org and both suffer from the exact same issue. I have also compared ceval.c from 2.3, the last known working copy and ceval.c from 2.4+ and found that ceval.c has undergone some pretty significant changes. __________________________________ Tracker __________________________________ From report at bugs.python.org Fri Oct 26 19:07:12 2007 From: report at bugs.python.org (Facundo Batista) Date: Fri, 26 Oct 2007 17:07:12 -0000 Subject: [issue1311] os.path.exists(os.devnull) regression on windows Message-ID: <1193418432.26.0.34904916557.issue1311@psf.upfronthosting.co.za> Facundo Batista added the comment: >>> import os.path >>> os.path.exists("con") False >>> os.path.exists("nul") False >>> os.path.exists("prn") False This is in Windows 2000 (5.00.2195) sp4, using *both* Python 2.3.5 and 2.5.1, no cygwin. Personally, I'm +1 with Mark Hammond about this: I agree it is unfortunate that the behaviour has changed, but these special names are broken enough on Windows that rely on the kernel32 function and behaves like it says seems the sanest thing to do. Taking in consideration that *now* it behaves equally in different windows systems, but not before, I think this issue should be closed as "invalid" (it's not a bug). I'll wait some days to get more behaviour responses, though. Regards, __________________________________ Tracker __________________________________ From report at bugs.python.org Fri Oct 26 19:18:28 2007 From: report at bugs.python.org (Jean Brouwers) Date: Fri, 26 Oct 2007 17:18:28 -0000 Subject: [issue1329] Different 3.0a1 exit behavior Message-ID: <1193419108.04.0.446922475461.issue1329@psf.upfronthosting.co.za> Jean Brouwers added the comment: Using atexit() to install the destructor function does not help. The function in not called when 3.0a1 exits, but with 2.5.1 it is. Same behavior on Linux and MacOS X. Btw, that would mean that any C extension which uses atexit() directly may be affected by this issue. Running python with the debugger shows that 3.0a1 and 2.5.1 both exit thru exit() and not _exit(). A breakpoint at _exit is hit, but the call originates from exit and not anywhere in the python binary. There is a new atexitmodule.c in 3.0a1 which did not exits in 2.5.1. But that is handling the atexit functionality at the Python level and not C. This man page mentions that all registered atexit functions are removed after a fork+exec. But breakpoints set at fork, fork1, forkpty and vfork are never hit by 3.0a1. That is as far as I got. __________________________________ Tracker __________________________________ From report at bugs.python.org Fri Oct 26 19:21:45 2007 From: report at bugs.python.org (Guido van Rossum) Date: Fri, 26 Oct 2007 17:21:45 -0000 Subject: [issue1330] Fix truncate on Windows, this time for real Message-ID: <1193419305.08.0.425277196991.issue1330@psf.upfronthosting.co.za> Guido van Rossum added the comment: Committed revision 58673. I made one change, hopefully I didn't screw it up: skip the positional restore if the truncation itself failed. Otherwise the positional restore might overwrite the error from the truncation. After an error from this function they shouldn't make any assumptions about the position anyway! ---------- resolution: -> accepted status: open -> closed __________________________________ Tracker __________________________________ From report at bugs.python.org Fri Oct 26 19:40:25 2007 From: report at bugs.python.org (Guido van Rossum) Date: Fri, 26 Oct 2007 17:40:25 -0000 Subject: [issue1335] bytesiterator patch Message-ID: <1193420425.14.0.775800582978.issue1335@psf.upfronthosting.co.za> Guido van Rossum added the comment: Committed revision 58674. I added a change to _abcoll.py to remove the registration of bytes as a subclass of Iterable. ---------- resolution: -> accepted status: open -> closed __________________________________ Tracker __________________________________ From report at bugs.python.org Fri Oct 26 19:42:19 2007 From: report at bugs.python.org (Guido van Rossum) Date: Fri, 26 Oct 2007 17:42:19 -0000 Subject: [issue1325] zipimport.zipimporter.archive undocumented and untested Message-ID: <1193420539.94.0.109512438989.issue1325@psf.upfronthosting.co.za> Guido van Rossum added the comment: If you submit a patch that adds docs and a unit test, your wish will be fulfilled. ---------- nosy: +gvanrossum __________________________________ Tracker __________________________________ From report at bugs.python.org Fri Oct 26 19:42:58 2007 From: report at bugs.python.org (Guido van Rossum) Date: Fri, 26 Oct 2007 17:42:58 -0000 Subject: [issue1326] "internal" zipimport.zipimporter feature untested Message-ID: <1193420578.7.0.737578165363.issue1326@psf.upfronthosting.co.za> Guido van Rossum added the comment: Please submit a patch for docs and a unittest... ---------- nosy: +gvanrossum __________________________________ Tracker __________________________________ From report at bugs.python.org Fri Oct 26 19:44:31 2007 From: report at bugs.python.org (Guido van Rossum) Date: Fri, 26 Oct 2007 17:44:31 -0000 Subject: [issue1328] feature request: force BOM option Message-ID: <1193420671.66.0.389363050844.issue1328@psf.upfronthosting.co.za> Guido van Rossum added the comment: Can't you force a BOM by simply writing \ufffe at the start of the file? ---------- nosy: +gvanrossum __________________________________ Tracker __________________________________ From report at bugs.python.org Fri Oct 26 19:47:53 2007 From: report at bugs.python.org (Guido van Rossum) Date: Fri, 26 Oct 2007 17:47:53 -0000 Subject: [issue1329] Different 3.0a1 exit behavior Message-ID: <1193420873.13.0.749284051074.issue1329@psf.upfronthosting.co.za> Guido van Rossum added the comment: Can you provide a very small shared library that demonstrates this problem? (E.g. you could start by modifying Modules/xxmodule.c, adding a 'destructor' function.) ---------- nosy: +gvanrossum __________________________________ Tracker __________________________________ From report at bugs.python.org Fri Oct 26 19:52:35 2007 From: report at bugs.python.org (Guido van Rossum) Date: Fri, 26 Oct 2007 17:52:35 -0000 Subject: [issue1332] threading.RLock().aquire(0) fails with python-2.5.1.amd64.msi Message-ID: <1193421155.55.0.0322642148757.issue1332@psf.upfronthosting.co.za> Guido van Rossum added the comment: Can you step through it with a C/C++ debugger to see where it goes wrong? ---------- nosy: +gvanrossum __________________________________ Tracker __________________________________ From report at bugs.python.org Fri Oct 26 19:55:29 2007 From: report at bugs.python.org (Guido van Rossum) Date: Fri, 26 Oct 2007 17:55:29 -0000 Subject: [issue1333] merge urllib and urlparse functionality Message-ID: <1193421329.44.0.130671090552.issue1333@psf.upfronthosting.co.za> Guido van Rossum added the comment: You missed urllib2 I think. :-) I agree it's a mess. I'm sure it all started out with backwards compatibility in mind. I find myself often importing cgi only to use the tiny function escape() that is defined there... I wonder if web-sig wouldn't be a good place to get some kindred spirits together to redesign these APIs for Py3k? ---------- nosy: +gvanrossum __________________________________ Tracker __________________________________ From report at bugs.python.org Fri Oct 26 20:00:47 2007 From: report at bugs.python.org (Guido van Rossum) Date: Fri, 26 Oct 2007 18:00:47 -0000 Subject: [issue1336] subprocess.Popen hangs when child writes to stderr Message-ID: <1193421647.43.0.624297760555.issue1336@psf.upfronthosting.co.za> Guido van Rossum added the comment: I don't think we can prevent GC from occurring between fork and exec -- it's legal to just call os.fork() and execute Python code in the subprocess forever. I think the right solution might be to ignore errors in file_close(). Can you try to whip up a patch for that and test it? ---------- nosy: +gvanrossum __________________________________ Tracker __________________________________ From report at bugs.python.org Fri Oct 26 20:26:19 2007 From: report at bugs.python.org (Guido van Rossum) Date: Fri, 26 Oct 2007 18:26:19 -0000 Subject: [issue1247] PEP 3137 patch (repr, names, parser) Message-ID: <1193423179.8.0.208251663808.issue1247@psf.upfronthosting.co.za> Guido van Rossum added the comment: Setting to 'high' everything related to PEP 3137. ---------- priority: -> high __________________________________ Tracker __________________________________ From report at bugs.python.org Fri Oct 26 20:31:03 2007 From: report at bugs.python.org (Georg Brandl) Date: Fri, 26 Oct 2007 18:31:03 -0000 Subject: [issue1287] os.environ.pop doesn't work Message-ID: <1193423463.78.0.827664907678.issue1287@psf.upfronthosting.co.za> Georg Brandl added the comment: You're right, fixed that in r58675. __________________________________ Tracker __________________________________ From report at bugs.python.org Fri Oct 26 20:38:36 2007 From: report at bugs.python.org (Warren DeLano) Date: Fri, 26 Oct 2007 18:38:36 -0000 Subject: [issue1332] threading.RLock().aquire(0) fails with python-2.5.1.amd64.msi Message-ID: <1193423916.95.0.713369511348.issue1332@psf.upfronthosting.co.za> Warren DeLano added the comment: Yes. Here's what I think the problem is: InterlockedCompareExchange called from EnterNonRecursiveMutex in thread_nt.h:101 seems to returns (-1) as 0x00000000FFFFFFFF instead of 0xFFFFFFFFFFFFFFFF. Still working out why though... __________________________________ Tracker __________________________________ From report at bugs.python.org Fri Oct 26 21:06:01 2007 From: report at bugs.python.org (Guido van Rossum) Date: Fri, 26 Oct 2007 19:06:01 -0000 Subject: [issue1338] pickling bytes? Message-ID: <1193425561.23.0.273747744158.issue1338@psf.upfronthosting.co.za> New submission from Guido van Rossum: Alexandre Vassalotti suggested the following: A simple way to add specific pickling support for bytes/buffer objects would be to define two new constants: BYTES = b'\x8c' # push a bytes object BUFFER = b'\x8d' # push a buffer object And add the following pickling and unpickling procedures: def save_bytes(self, obj, pack=struct.pack): n = len(obj) self.write(BYTES + pack(" __________________________________ From report at bugs.python.org Fri Oct 26 21:10:13 2007 From: report at bugs.python.org (Jean Brouwers) Date: Fri, 26 Oct 2007 19:10:13 -0000 Subject: [issue1329] Different 3.0a1 exit behavior Message-ID: <1193425813.75.0.748101049634.issue1329@psf.upfronthosting.co.za> Jean Brouwers added the comment: Yes, I will make a small library. But first, here is another piece of evidence. As I mentioned, using std atexit does not work on 3.0a1. But surprisingly, the destructor function is not called either when installed with Py_AtExit on 3.0a1. On 2.5.1 it is. There must something in Py_Terminate or Py_Finalize which is different in 3.0a1. __________________________________ Tracker __________________________________ From report at bugs.python.org Fri Oct 26 21:12:06 2007 From: report at bugs.python.org (Warren DeLano) Date: Fri, 26 Oct 2007 19:12:06 -0000 Subject: [issue1332] threading.RLock().aquire(0) fails with python-2.5.1.amd64.msi Message-ID: <1193425926.53.0.595615795852.issue1332@psf.upfronthosting.co.za> Warren DeLano added the comment: Hmm. Well, for one thing, we're falling back on Python's interlocked_cmp_xchg instead of using Windows' InterlockedCompareExchange (or should it InterlockCompareExchange64?). Python's implementation is clearly assuming 64 bit counters, but the other native Windows Interlocked* functions may indeed be operating on 32 bit counters, hence the mismatch. __________________________________ Tracker __________________________________ From report at bugs.python.org Fri Oct 26 21:28:45 2007 From: report at bugs.python.org (Georg Brandl) Date: Fri, 26 Oct 2007 19:28:45 -0000 Subject: [issue1338] pickling bytes? Message-ID: <1193426925.9.0.00514161931436.issue1338@psf.upfronthosting.co.za> Georg Brandl added the comment: Having explicit support for sets at least would be consistent with all other types for which there is a display form. (Or else, {1,2,3} could be a different thing after unpickling if the set builtin is overwritten.) ---------- nosy: +georg.brandl __________________________________ Tracker __________________________________ From report at bugs.python.org Fri Oct 26 21:34:47 2007 From: report at bugs.python.org (James G. sack (jim)) Date: Fri, 26 Oct 2007 19:34:47 -0000 Subject: [issue1328] feature request: force BOM option Message-ID: <1193427287.5.0.456307192978.issue1328@psf.upfronthosting.co.za> James G. sack (jim) added the comment: re: msg56782 Yes, of course I can explicitly write the BOM. I did realize that after my first post ( my-'duh' :-[ ). But after playing some more, I do think this issue has become a worthwhile one. My second post msg56780 asks that utf_8 be tolerant of the 3-byte sig BOM, and uf_16_[be]e be tolerant of their BOMs, which I argue is consistent with "be liberal on what you accept". A second half of that message suggests that it might be worth considering something like a write_bom parameter with utf_16 defaulting to True, and utf_16_[bl]e defaulting to False. My third post (m56782) may actually represent a bug. I have a unittest for this and would be glad to provide (although I need to reduuce a larger test to a simple case). I will look at this again, and re-pester you as required. Regards (and thanks for the reply), ..jim __________________________________ Tracker __________________________________ From report at bugs.python.org Fri Oct 26 21:36:45 2007 From: report at bugs.python.org (Guido van Rossum) Date: Fri, 26 Oct 2007 19:36:45 -0000 Subject: [issue1328] feature request: force BOM option In-Reply-To: <1193427287.5.0.456307192978.issue1328@psf.upfronthosting.co.za> Message-ID: Guido van Rossum added the comment: If you can, please submit a patch that fixes all those issues, with unit tests and doc changes if at all possible. That will make it much easier to evaluate the ramifications of your proposal(s). __________________________________ Tracker __________________________________ From report at bugs.python.org Fri Oct 26 21:36:54 2007 From: report at bugs.python.org (Warren DeLano) Date: Fri, 26 Oct 2007 19:36:54 -0000 Subject: [issue1332] threading.RLock().aquire(0) fails with python-2.5.1.amd64.msi Message-ID: <1193427414.66.0.448927376921.issue1332@psf.upfronthosting.co.za> Warren DeLano added the comment: Disabling Python's emulated InterlockedCompareExchange (for Win95 compatibility) cures the problem, so the underlying question is why the existence of InterlockedCompareExchange is not being autodetected on 64 bit systems -- and that is apparently because GetProcAddress (kernel,"InterlockedCompareExchange") returns NULL -- which makes sense since InterlockedCompareExchange appears to be implemented using macros instead of being served up through kernel32.dll. So is Win95 still a supported platform? If not, then perhaps InterlockedCompareExchange emulation can simply be deleted. If so, then either some other approach needs to be adopted to activate emulation, or the emulated code needs to be fixed to behave like the native windows functions (which appear to only operate on the lowest 32 bits). __________________________________ Tracker __________________________________ From report at bugs.python.org Fri Oct 26 21:39:38 2007 From: report at bugs.python.org (Guido van Rossum) Date: Fri, 26 Oct 2007 19:39:38 -0000 Subject: [issue1332] threading.RLock().aquire(0) fails with python-2.5.1.amd64.msi In-Reply-To: <1193427414.66.0.448927376921.issue1332@psf.upfronthosting.co.za> Message-ID: Guido van Rossum added the comment: > Disabling Python's emulated InterlockedCompareExchange (for Win95 > compatibility) cures the problem, so the underlying question is why the > existence of InterlockedCompareExchange is not being autodetected on 64 > bit systems -- and that is apparently because GetProcAddress > (kernel,"InterlockedCompareExchange") returns NULL -- which makes sense > since InterlockedCompareExchange appears to be implemented using macros > instead of being served up through kernel32.dll. > > So is Win95 still a supported platform? Heavens no! > If not, then perhaps InterlockedCompareExchange emulation can simply be > deleted. Patch please? __________________________________ Tracker __________________________________ From report at bugs.python.org Fri Oct 26 21:54:12 2007 From: report at bugs.python.org (James G. sack (jim)) Date: Fri, 26 Oct 2007 19:54:12 -0000 Subject: [issue1328] feature request: force BOM option Message-ID: <1193428452.42.0.165759344393.issue1328@psf.upfronthosting.co.za> James G. sack (jim) added the comment: OK, I will work on it. I have just downloaded trunk and will see what I can do. Might be a week or two. ..jim __________________________________ Tracker __________________________________ From report at bugs.python.org Fri Oct 26 22:03:50 2007 From: report at bugs.python.org (Jean Brouwers) Date: Fri, 26 Oct 2007 20:03:50 -0000 Subject: [issue1329] Different 3.0a1 exit behavior Message-ID: <1193429030.38.0.744784198423.issue1329@psf.upfronthosting.co.za> Jean Brouwers added the comment: Attached is a simple test case which demonstrates the problem on Linux and MacOS X. It is not an xxmodule example, though and hope this is OK. See the comments for build steps and example output with 3 different Python builds on both platforms. If you need another test case which uses Py_AtExit, let me know. Added file: http://bugs.python.org/file8620/dlibtest.c __________________________________ Tracker __________________________________ -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: dlibtest.c Url: http://mail.python.org/pipermail/python-bugs-list/attachments/20071026/89f96ccd/attachment.txt From report at bugs.python.org Fri Oct 26 22:15:20 2007 From: report at bugs.python.org (Warren DeLano) Date: Fri, 26 Oct 2007 20:15:20 -0000 Subject: [issue1332] threading.RLock().aquire(0) fails with python-2.5.1.amd64.msi Message-ID: <1193429720.18.0.202878668732.issue1332@psf.upfronthosting.co.za> Warren DeLano added the comment: Patch attached. Do note that this patch will break threading on Win95 in order to achieve 64-bit compatibility. Win98 and up should be fine -- however, that assertion has not yet been confirmed. Added file: http://bugs.python.org/file8621/thread_nt_fix.patch __________________________________ Tracker __________________________________ -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: thread_nt_fix.patch Url: http://mail.python.org/pipermail/python-bugs-list/attachments/20071026/6da7b7ca/attachment.txt From report at bugs.python.org Fri Oct 26 22:22:44 2007 From: report at bugs.python.org (Jean Brouwers) Date: Fri, 26 Oct 2007 20:22:44 -0000 Subject: [issue1329] Different 3.0a1 exit behavior Message-ID: <1193430164.89.0.916420681843.issue1329@psf.upfronthosting.co.za> Jean Brouwers added the comment: Here is the same file with an #if to use to Py_AtExit or destructor case. Please us this one instead of the earlier one. Added file: http://bugs.python.org/file8622/dlibtest.c __________________________________ Tracker __________________________________ -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: dlibtest.c Url: http://mail.python.org/pipermail/python-bugs-list/attachments/20071026/2f9644d7/attachment.txt From report at bugs.python.org Fri Oct 26 22:30:11 2007 From: report at bugs.python.org (Guido van Rossum) Date: Fri, 26 Oct 2007 20:30:11 -0000 Subject: [issue1329] Different 3.0a1 exit behavior In-Reply-To: <1193430164.89.0.916420681843.issue1329@psf.upfronthosting.co.za> Message-ID: Guido van Rossum added the comment: > Here is the same file with an #if to use to Py_AtExit or destructor case. > Please us this one instead of the earlier one. > > Added file: http://bugs.python.org/file8622/dlibtest.c I can build it just fine on Ubuntu dapper, but I can't run it. The command given in the comment fails immediately: $ env LD_PRELOAD dlibtest.so ~/p3/python env: LD_PRELOAD: No such file or directory $ When I modify it slightly I get another error: $ env LD_PRELOAD=dlibtest.so ~/p3/python ERROR: ld.so: object 'dlibtest.so' from LD_PRELOAD cannot be preloaded: ignored. Python 3.0a1+ (py3k, Oct 26 2007, 12:30:11) [GCC 4.0.3 (Ubuntu 4.0.3-1ubuntu5)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> ^D $ __________________________________ Tracker __________________________________ From report at bugs.python.org Fri Oct 26 22:50:10 2007 From: report at bugs.python.org (Christian Heimes) Date: Fri, 26 Oct 2007 20:50:10 -0000 Subject: [issue1332] threading.RLock().aquire(0) fails with python-2.5.1.amd64.msi Message-ID: <1193431810.26.0.176776432368.issue1332@psf.upfronthosting.co.za> Christian Heimes added the comment: The patch doesn't apply (r58677 of release25-maint). Can you please create an unified diff against the latest subversion checkout with svn diff or TortoiseSVN? $ patch -p1 < thread_nt_fix.patch missing header for context diff at line 3 of patch patching file Python/thread_nt.h Hunk #2 FAILED at 14. Hunk #3 FAILED at 40. 2 out of 3 hunks FAILED -- saving rejects to file Python/thread_nt.h.rej ---------- nosy: +nnorwitz, tiran __________________________________ Tracker __________________________________ From report at bugs.python.org Fri Oct 26 23:02:18 2007 From: report at bugs.python.org (Jean Brouwers) Date: Fri, 26 Oct 2007 21:02:18 -0000 Subject: [issue1329] Different 3.0a1 exit behavior Message-ID: <1193432538.12.0.557885310515.issue1329@psf.upfronthosting.co.za> Jean Brouwers added the comment: My fault, sorry. The command line to run should be env LD_PRELOAD=./dlibtest.so ... i.e. with '=' sign and no spaces. And the library file may have to be an absolute path. __________________________________ Tracker __________________________________ From report at bugs.python.org Fri Oct 26 23:15:56 2007 From: report at bugs.python.org (Guido van Rossum) Date: Fri, 26 Oct 2007 21:15:56 -0000 Subject: [issue1329] Different 3.0a1 exit behavior Message-ID: <1193433356.58.0.501042028454.issue1329@psf.upfronthosting.co.za> Changes by Guido van Rossum: Removed file: http://bugs.python.org/file8620/dlibtest.c __________________________________ Tracker __________________________________ From report at bugs.python.org Fri Oct 26 23:16:34 2007 From: report at bugs.python.org (Guido van Rossum) Date: Fri, 26 Oct 2007 21:16:34 -0000 Subject: [issue1329] Different 3.0a1 exit behavior Message-ID: <1193433394.93.0.943108483017.issue1329@psf.upfronthosting.co.za> Guido van Rossum added the comment: OK, confirmed. But no insignt in what happened yet... Do you know where the atexit stuff happens in 2.5? __________________________________ Tracker __________________________________ From report at bugs.python.org Fri Oct 26 23:30:45 2007 From: report at bugs.python.org (Jean Brouwers) Date: Fri, 26 Oct 2007 21:30:45 -0000 Subject: [issue1329] Different 3.0a1 exit behavior Message-ID: <1193434245.07.0.0309170295992.issue1329@psf.upfronthosting.co.za> Jean Brouwers added the comment: The Py_AtExit function is in Python/pythonrun.c. The calls to all installed C functions are made in call_ll_exitfuncs, also in pythonrun.c. The call to call_ll_exitfuncs is at the very end of Py_Finalize also in pythonrun.c. I am just getting down there now and Py_Finalize is called and reaches the call to PyGrammar_RemoveAccelerators a few lines higher. But call_ll_exitfuncs is not called, as far as I can tell. __________________________________ Tracker __________________________________ From report at bugs.python.org Fri Oct 26 23:38:42 2007 From: report at bugs.python.org (Jean Brouwers) Date: Fri, 26 Oct 2007 21:38:42 -0000 Subject: [issue1329] Different 3.0a1 exit behavior Message-ID: <1193434722.22.0.279833723776.issue1329@psf.upfronthosting.co.za> Jean Brouwers added the comment: One more thing. Stepping with the debugger thru Py_Finalize looks exactly the same for 2.5.1 and 3.0a1 in the last part of that function. __________________________________ Tracker __________________________________ From report at bugs.python.org Sat Oct 27 00:20:20 2007 From: report at bugs.python.org (Jean Brouwers) Date: Fri, 26 Oct 2007 22:20:20 -0000 Subject: [issue1329] Different 3.0a1 exit behavior Message-ID: <1193437220.9.0.310507675196.issue1329@psf.upfronthosting.co.za> Jean Brouwers added the comment: I put a bunch of printf's in the Py_Finalize function of 2.5.1 and 3.0a1. All those show up when 2.5.1 exists including the call to call_ll_exitfuncs. But in 3.0a1 only a few show up and the last one is just before the call to PyImport_Cleanup near line 393. It looks like that call never returns. That call never returns, it seems. __________________________________ Tracker __________________________________ From report at bugs.python.org Sat Oct 27 01:18:28 2007 From: report at bugs.python.org (Bill Fenner) Date: Fri, 26 Oct 2007 23:18:28 -0000 Subject: [issue829951] Fixes smtplib starttls HELO errors Message-ID: <1193440708.85.0.985686053998.issue829951@psf.upfronthosting.co.za> Bill Fenner added the comment: Yes, the state that should be reset includes helo_resp, ehlo_resp, esmtp_features, and does_esmtp. The workaround commonly proposed is to always call ehlo() after starttls() . While this works (most of the time?), it seems arbitrary to require an explicit ehlo() call in this case but not other cases. ---------- nosy: +fenner versions: +Python 2.4 ____________________________________ Tracker ____________________________________ From report at bugs.python.org Sat Oct 27 01:26:14 2007 From: report at bugs.python.org (Bill Fenner) Date: Fri, 26 Oct 2007 23:26:14 -0000 Subject: [issue1339] smtplib starttls() should ehlo() if it needs to Message-ID: <1193441174.56.0.280335873353.issue1339@psf.upfronthosting.co.za> New submission from Bill Fenner: smtplib's "complex" methods, login and sendmail, try to EHLO or HELO if it hasn't been done yet. login also checks to see if the EHLO response included the ability to do authorization. starttls seems to me to be similar in nature: why should it not try to EHLO or HELO, and check that self.has_extn("starttls")? ---------- components: Library (Lib) messages: 56829 nosy: fenner severity: normal status: open title: smtplib starttls() should ehlo() if it needs to type: rfe versions: Python 2.4 __________________________________ Tracker __________________________________ From report at bugs.python.org Sat Oct 27 01:28:10 2007 From: report at bugs.python.org (Amaury Forgeot d'Arc) Date: Fri, 26 Oct 2007 23:28:10 -0000 Subject: [issue1340] correction for test_tempfile in py3k on Windows Message-ID: <1193441289.92.0.979777798118.issue1340@psf.upfronthosting.co.za> New submission from Amaury Forgeot d'Arc: This tiny patch correct a failure in test_tempfile on Windows: in SpooledTemporaryFile, avoid translating the newlines twice. Otherwise, in "universal" text mode, \n gets transformed to \r\n, then to \r\r\n, which is read as \n\n. Passing the encoding is OK, since the round-trip gives the same result, and it allow encoding errors to occur at the right place. Index: Lib/tempfile.py =================================================================== --- Lib/tempfile.py (revision 58680) +++ Lib/tempfile.py (working copy) @@ -495,7 +495,7 @@ if 'b' in mode: self._file = _io.BytesIO() else: - self._file = _io.StringIO(encoding=encoding, newline=newline) + self._file = _io.StringIO(encoding=encoding) self._max_size = max_size self._rolled = False self._TemporaryFileArgs = {'mode': mode, 'buffering': buffering, ---------- components: Windows messages: 56830 nosy: amaury.forgeotdarc severity: normal status: open title: correction for test_tempfile in py3k on Windows versions: Python 3.0 __________________________________ Tracker __________________________________ From report at bugs.python.org Sat Oct 27 01:28:13 2007 From: report at bugs.python.org (Neal Norwitz) Date: Fri, 26 Oct 2007 23:28:13 -0000 Subject: [issue1329] Different 3.0a1 exit behavior In-Reply-To: <1193437220.9.0.310507675196.issue1329@psf.upfronthosting.co.za> Message-ID: Neal Norwitz added the comment: Maybe that's because site and io get cleaned up and then there is some fatal error that can't be printed? __________________________________ Tracker __________________________________ From report at bugs.python.org Sat Oct 27 01:55:07 2007 From: report at bugs.python.org (Jean Brouwers) Date: Fri, 26 Oct 2007 23:55:07 -0000 Subject: [issue1329] Different 3.0a1 exit behavior Message-ID: <1193442907.82.0.525095529989.issue1329@psf.upfronthosting.co.za> Jean Brouwers added the comment: This is quite bizarre and difficult to reproduce. With gdb, 3.0a1 does get to the very end of Py_Finalize, but without gdb it doesn't. Also, the call to static function call_all_exitfuncs is inlined, its while loop is shown inside Py_Finalize on MacOS X. On Linux that is not visible, probably due to differences in gcc/gdb, 4.0.1 or MacOS X and 3.4.6 on Linux. __________________________________ Tracker __________________________________ From report at bugs.python.org Sat Oct 27 01:59:30 2007 From: report at bugs.python.org (Amaury Forgeot d'Arc) Date: Fri, 26 Oct 2007 23:59:30 -0000 Subject: [issue1341] correction for test_fileinput in py3k on Windows Message-ID: <1193443170.37.0.0840293747234.issue1341@psf.upfronthosting.co.za> New submission from Amaury Forgeot d'Arc: This patch corrects test_fileinput on Windows: when redirecting stdout, os.open should be given O_BINARY, because the file descriptor is then wrapped in a text-mode file; os.fdopen(fd, "w"). ---------- files: fileinput.diff messages: 56833 nosy: amaury.forgeotdarc severity: normal status: open title: correction for test_fileinput in py3k on Windows Added file: http://bugs.python.org/file8623/fileinput.diff __________________________________ Tracker __________________________________ -------------- next part -------------- A non-text attachment was scrubbed... Name: fileinput.diff Type: application/octet-stream Size: 880 bytes Desc: not available Url : http://mail.python.org/pipermail/python-bugs-list/attachments/20071026/a39dbda9/attachment.obj From report at bugs.python.org Sat Oct 27 02:00:36 2007 From: report at bugs.python.org (Amaury Forgeot d'Arc) Date: Sat, 27 Oct 2007 00:00:36 -0000 Subject: [issue1341] correction for test_fileinput in py3k on Windows Message-ID: <1193443236.98.0.738343862103.issue1341@psf.upfronthosting.co.za> Changes by Amaury Forgeot d'Arc: ---------- components: +Windows versions: +Python 3.0 __________________________________ Tracker __________________________________ From report at bugs.python.org Sat Oct 27 02:01:32 2007 From: report at bugs.python.org (Neal Norwitz) Date: Sat, 27 Oct 2007 00:01:32 -0000 Subject: [issue1329] Different 3.0a1 exit behavior In-Reply-To: <1193442907.82.0.525095529989.issue1329@psf.upfronthosting.co.za> Message-ID: Neal Norwitz added the comment: I suggest you configure --with-pydebug. That will disable optimization, enable debugging symbols and will make it easier to develop. Note that a debug version runs much slower due to asserts() and other internal changes. Otherwise, it should work the same. On Oct 26, 2007 4:55 PM, Jean Brouwers wrote: > > Jean Brouwers added the comment: > > This is quite bizarre and difficult to reproduce. With gdb, 3.0a1 does > get to the very end of Py_Finalize, but without gdb it doesn't. > > Also, the call to static function call_all_exitfuncs is inlined, its > while loop is shown inside Py_Finalize on MacOS X. On Linux that is not > visible, probably due to differences in gcc/gdb, 4.0.1 or MacOS X and > 3.4.6 on Linux. > > > __________________________________ > Tracker > > __________________________________ > __________________________________ Tracker __________________________________ From report at bugs.python.org Sat Oct 27 02:09:03 2007 From: report at bugs.python.org (Jean Brouwers) Date: Sat, 27 Oct 2007 00:09:03 -0000 Subject: [issue1329] Different 3.0a1 exit behavior Message-ID: <1193443743.0.0.737313364168.issue1329@psf.upfronthosting.co.za> Jean Brouwers added the comment: OK, I try that. __________________________________ Tracker __________________________________ From report at bugs.python.org Sat Oct 27 02:13:12 2007 From: report at bugs.python.org (Warren DeLano) Date: Sat, 27 Oct 2007 00:13:12 -0000 Subject: [issue1332] threading.RLock().aquire(0) fails with python-2.5.1.amd64.msi Message-ID: <1193443992.86.0.304362723648.issue1332@psf.upfronthosting.co.za> Warren DeLano added the comment: No need -- turns out the problem was fixed on April 21st a mere three days after Python 2.5.1 was released. Please close this issue -- my rookie mistake not working with SVN source from the start! (gee, I should have known better...) Sorry for wasting your time and mine. However, considering the severity of this problem (threading.Lock.acquire(0) broken on 64-bit Windows), what do you think about issuing a 2.5.2 maintenance release? __________________________________ Tracker __________________________________ From report at bugs.python.org Sat Oct 27 02:22:55 2007 From: report at bugs.python.org (Guido van Rossum) Date: Sat, 27 Oct 2007 00:22:55 -0000 Subject: [issue1332] threading.RLock().aquire(0) fails with python-2.5.1.amd64.msi In-Reply-To: <1193443992.86.0.304362723648.issue1332@psf.upfronthosting.co.za> Message-ID: Guido van Rossum added the comment: > However, considering the severity of this problem > (threading.Lock.acquire(0) broken on 64-bit Windows), what do you think > about issuing a 2.5.2 maintenance release? Neal Norwitz and Anthony Baxter have been planning to release 2.5.2 for a while now; unfortunately both seem too busy to make much progress. Any volunteers? __________________________________ Tracker __________________________________ From report at bugs.python.org Sat Oct 27 02:28:18 2007 From: report at bugs.python.org (Jean Brouwers) Date: Sat, 27 Oct 2007 00:28:18 -0000 Subject: [issue1329] Different 3.0a1 exit behavior Message-ID: <1193444898.42.0.638350099488.issue1329@psf.upfronthosting.co.za> Jean Brouwers added the comment: The 3.0a1 build --with-pydebug behaves the same as before (on Linux). The problem does occur without gdb but not with gdb. __________________________________ Tracker __________________________________ From report at bugs.python.org Sat Oct 27 02:50:51 2007 From: report at bugs.python.org (Warren DeLano) Date: Sat, 27 Oct 2007 00:50:51 -0000 Subject: [issue1332] threading.RLock().aquire(0) fails with python-2.5.1.amd64.msi Message-ID: <1193446251.73.0.606221139809.issue1332@psf.upfronthosting.co.za> Warren DeLano added the comment: I wouldn't know how take the lead, but with customers breathing down my neck for x64 support, my own threading.Rlock-dependent software product cannot support x64 until an official Python release supports it. So I guess that automatically puts me in the **highly- motivated/willing-to-help** camp, if there's anything useful I can actually do towards 2.5.2. __________________________________ Tracker __________________________________ From report at bugs.python.org Sat Oct 27 03:49:40 2007 From: report at bugs.python.org (Jean Brouwers) Date: Sat, 27 Oct 2007 01:49:40 -0000 Subject: [issue1329] Different 3.0a1 exit behavior Message-ID: <1193449780.56.0.22056875828.issue1329@psf.upfronthosting.co.za> Jean Brouwers added the comment: It looks like the problem may indeed just be that I/O is being shut down somewhere inside PyImport_Cleanup. I am modifying the test case to demonstrate that and will submit that version as soon as it runs. __________________________________ Tracker __________________________________ From report at bugs.python.org Sat Oct 27 05:40:36 2007 From: report at bugs.python.org (Christian Heimes) Date: Sat, 27 Oct 2007 03:40:36 -0000 Subject: [issue1342] Crash on Windows if Python runs from a directory with umlauts Message-ID: <1193456436.1.0.972609600257.issue1342@psf.upfronthosting.co.za> New submission from Christian Heimes: Python 3.0 doesn't run from a directory with umlauts and possible other non ASCII chars. I renamed my development folder from C:\dev\ to c:\test ???? name\. Python crashes after a few moments before it can reach its shell. python30.dll!PyErr_SetObject(_object * exception=0x1e1b9888, _object * value=0x00a0b8a0) Zeile 56 + 0xb Bytes C python30.dll!PyErr_SetString(_object * exception=0x1e1b9888, const char * string=0x1e18c358) Zeile 77 + 0xd Bytes C python30.dll!find_module(char * fullname=0x0021fcc0, char * subname=0x00000000, _object * path=0x00000000, char * buf=0x0021fb70, unsigned int buflen=257, _iobuf * * p_fp=0x0021fb64, _object * * p_loader=0x0021fb68) Zeile 1228 + 0x10 Bytes C python30.dll!import_submodule(_object * mod=0x1e1c6a88, char * subname=0x0021fcc0, char * fullname=0x00000000) Zeile 2313 + 0x27 Bytes C python30.dll!load_next(_object * mod=0x1e1c6a88, _object * altmod=0x1e1c6a88, char * * p_name=0x00000000, char * buf=0x0021fcc0, int * p_buflen=0x0021fcbc) Zeile 2127 + 0x15 Bytes C python30.dll!import_module_level(char * name=0x00000000, _object * globals=0x00000000, _object * locals=0x1e069ec3, _object * fromlist=0x00000000, int level=0) Zeile 1908 + 0x1a Bytes C python30.dll!PyImport_ImportModuleLevel(char * name=0x1e184b04, _object * globals=0x00000000, _object * locals=0x00000000, _object * fromlist=0x00000000, int level=0) Zeile 1979 + 0x18 Bytes C python30.dll!_PyCodecRegistry_Init() Zeile 841 + 0x12 Bytes C python30.dll!PyCodec_LookupError(const char * name=0x00000000) Zeile 436 + 0xc Bytes C python30.dll!unicode_decode_call_errorhandler(const char * errors=0x00000000, _object * * errorHandler=0x00000009, const char * encoding=0x1e1979ec, const char * reason=0x00000000, const char * * input=0x0021fe80, const char * * inend=0x0021fe84, int * startinpos=0x0021fe6c, int * endinpos=0x0021fe68, _object * * exceptionObject=0x00000000, const char * * inptr=0x0021fe90, _object * * output=0x0021fe70, int * outpos=0x0021fe88, unsigned short * * outptr=0x0021fe74) Zeile 1384 + 0xa Bytes C python30.dll!PyUnicodeUCS2_DecodeUTF8Stateful(const char * s=0x1e1dd010, int size=48, const char * errors=0x00000000, int * consumed=0x00000000) Zeile 1967 + 0x47 Bytes C python30.dll!PyUnicodeUCS2_FromStringAndSize(const char * u=0x1e1dd008, int size=48) Zeile 464 + 0xb Bytes C python30.dll!PyUnicodeUCS2_FromString(const char * u=0x1e1dd008) Zeile 482 + 0x7 Bytes C python30.dll!_PySys_Init() Zeile 1084 + 0xb Bytes C python30.dll!Py_InitializeEx(int install_sigs=1) Zeile 220 C python30.dll!Py_Initialize() Zeile 292 + 0x7 Bytes C python30.dll!Py_Main(int argc=2, char * * argv=0x00000001) Zeile 432 C > python.exe!mainCRTStartup() Zeile 398 + 0xe Bytes C kernel32.dll!7c816fd7() ---------- components: Interpreter Core messages: 56841 nosy: tiran severity: normal status: open title: Crash on Windows if Python runs from a directory with umlauts type: crash versions: Python 3.0 __________________________________ Tracker __________________________________ From report at bugs.python.org Sat Oct 27 05:41:23 2007 From: report at bugs.python.org (Christian Heimes) Date: Sat, 27 Oct 2007 03:41:23 -0000 Subject: [issue1042] test_glob fails with UnicodeDecodeError Message-ID: <1193456483.48.0.327739239066.issue1042@psf.upfronthosting.co.za> Christian Heimes added the comment: I think the problem is solved now. I haven't seen glob crashing for a while. ---------- nosy: +tiran __________________________________ Tracker __________________________________ From report at bugs.python.org Sat Oct 27 06:05:38 2007 From: report at bugs.python.org (Christian Heimes) Date: Sat, 27 Oct 2007 04:05:38 -0000 Subject: [issue1247] PEP 3137 patch (repr, names, parser) Message-ID: <1193457938.47.0.501889450019.issue1247@psf.upfronthosting.co.za> Christian Heimes added the comment: Here is the patch that contains only the harmless parts of the previous patches. It changes a bunch of doc strings, changes the name of the types and their repr() and str(). It also adds __builtin__.buffer but it leaves __builtin__.bytes, __builtin__.str8 and b'' as they are. Added file: http://bugs.python.org/file8624/py3k-pep3137_harmless.patch __________________________________ Tracker __________________________________ -------------- next part -------------- A non-text attachment was scrubbed... Name: py3k-pep3137_harmless.patch Type: text/x-diff Size: 12023 bytes Desc: not available Url : http://mail.python.org/pipermail/python-bugs-list/attachments/20071027/18443db3/attachment.patch From report at bugs.python.org Sat Oct 27 08:03:50 2007 From: report at bugs.python.org (Jean Brouwers) Date: Sat, 27 Oct 2007 06:03:50 -0000 Subject: [issue1329] Different 3.0a1 exit behavior Message-ID: <1193465030.1.0.223862094209.issue1329@psf.upfronthosting.co.za> Jean Brouwers added the comment: Attached is an updated dlibtest.c file. It prints a message in the con- /destructor functions and if that fails it calls _exit(9). Compile and run it as before and check the exit status. If the latter is 9 or 011, a printf error occurred indicating e.g. that stdout was closed or something similar. This version can also be used with gdb, either by pre-loading the dlibtest.so library within gdb or before invoking gdb. To preload the library within gdb (on Linux) use gdb .../python (gdb) set environment LD_PRELOAD ./dlibtest.so (gdb) run ..... or to preload before gdb use setenv LD_PRELOAD ./dlibtest.so gdb .../python (gdb) run ..... Lastly, my previous observations about this issue were clearly a "trompe d'oeil", especially my statement that PyImport_Cleanup never returned. The missing print statements *after* the PyImport_Cleanup call are simply due to printf errors, and nothing else ;-) Added file: http://bugs.python.org/file8625/dlibtest.c __________________________________ Tracker __________________________________ -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: dlibtest.c Url: http://mail.python.org/pipermail/python-bugs-list/attachments/20071027/c64cf035/attachment.txt From report at bugs.python.org Sat Oct 27 08:20:09 2007 From: report at bugs.python.org (Neal Norwitz) Date: Sat, 27 Oct 2007 06:20:09 -0000 Subject: [issue1329] Different 3.0a1 exit behavior Message-ID: <1193466009.76.0.147620859173.issue1329@psf.upfronthosting.co.za> Neal Norwitz added the comment: When I run with the attached patch, I see the message: *** dtor called in python ... Is that the behavior you expect? Added file: http://bugs.python.org/file8626/stdout-close.patch __________________________________ Tracker __________________________________ -------------- next part -------------- A non-text attachment was scrubbed... Name: stdout-close.patch Type: text/x-patch Size: 1009 bytes Desc: not available Url : http://mail.python.org/pipermail/python-bugs-list/attachments/20071027/3187b9e3/attachment-0001.bin From report at bugs.python.org Sat Oct 27 08:43:30 2007 From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=) Date: Sat, 27 Oct 2007 06:43:30 -0000 Subject: [issue1341] correction for test_fileinput in py3k on Windows Message-ID: <1193467410.68.0.306142202145.issue1341@psf.upfronthosting.co.za> Changes by Martin v. L?wis: ---------- keywords: +patch __________________________________ Tracker __________________________________ From report at bugs.python.org Sat Oct 27 13:07:30 2007 From: report at bugs.python.org (Scott Tsai) Date: Sat, 27 Oct 2007 11:07:30 -0000 Subject: [issue1597850] Cross compiling patches for MINGW Message-ID: <1193483250.75.0.815673772133.issue1597850@psf.upfronthosting.co.za> Scott Tsai added the comment: I messed up while generating cross-2.5.1.patch last time. Added a hackish way to set "disabled_module_list" in setup.py from corresponding environment variable. Added file: http://bugs.python.org/file8628/cross-2.5.1.patch _____________________________________ Tracker _____________________________________ -------------- next part -------------- A non-text attachment was scrubbed... Name: cross-2.5.1.patch Type: text/x-patch Size: 21587 bytes Desc: not available Url : http://mail.python.org/pipermail/python-bugs-list/attachments/20071027/7e1b474e/attachment-0001.bin From report at bugs.python.org Sat Oct 27 13:11:01 2007 From: report at bugs.python.org (Scott Tsai) Date: Sat, 27 Oct 2007 11:11:01 -0000 Subject: [issue1597850] Cross compiling patches for MINGW Message-ID: <1193483461.6.0.147437416763.issue1597850@psf.upfronthosting.co.za> Scott Tsai added the comment: Grumble, uploaded wrong version of patch. Added file: http://bugs.python.org/file8629/cross-2.5.1.patch _____________________________________ Tracker _____________________________________ -------------- next part -------------- A non-text attachment was scrubbed... Name: cross-2.5.1.patch Type: text/x-patch Size: 22528 bytes Desc: not available Url : http://mail.python.org/pipermail/python-bugs-list/attachments/20071027/00694e12/attachment-0001.bin From report at bugs.python.org Sat Oct 27 15:34:58 2007 From: report at bugs.python.org (panzi) Date: Sat, 27 Oct 2007 13:34:58 -0000 Subject: [issue1343] XMLGenerator: nice elements Message-ID: <1193492098.31.0.498120271289.issue1343@psf.upfronthosting.co.za> panzi added the comment: patch for xml/sax/saxutils.py Added file: http://bugs.python.org/file8631/xml.sax.saxutils.patch __________________________________ Tracker __________________________________ -------------- next part -------------- A non-text attachment was scrubbed... Name: xml.sax.saxutils.patch Type: text/x-patch Size: 2985 bytes Desc: not available Url : http://mail.python.org/pipermail/python-bugs-list/attachments/20071027/5f846afc/attachment.bin From report at bugs.python.org Sat Oct 27 15:35:29 2007 From: report at bugs.python.org (panzi) Date: Sat, 27 Oct 2007 13:35:29 -0000 Subject: [issue1343] XMLGenerator: nice elements Message-ID: <1193492129.02.0.490053431987.issue1343@psf.upfronthosting.co.za> panzi added the comment: patch for _xmlplus.sax.saxutils.py Added file: http://bugs.python.org/file8632/_xmlplus.sax.saxutils.patch __________________________________ Tracker __________________________________ -------------- next part -------------- A non-text attachment was scrubbed... Name: _xmlplus.sax.saxutils.patch Type: text/x-patch Size: 5704 bytes Desc: not available Url : http://mail.python.org/pipermail/python-bugs-list/attachments/20071027/eacc4ea5/attachment.bin From report at bugs.python.org Sat Oct 27 16:03:17 2007 From: report at bugs.python.org (Christian Heimes) Date: Sat, 27 Oct 2007 14:03:17 -0000 Subject: [issue1342] Crash on Windows if Python runs from a directory with umlauts Message-ID: <1193493797.32.0.756568797834.issue1342@psf.upfronthosting.co.za> Christian Heimes added the comment: The patch fixes parts of the problem. At least Python doesn't crash any more when run from a directory with non ASCII chars. It just fails with an import error in initstdio(). Added file: http://bugs.python.org/file8633/py3k_more_win_fsencoding.patch __________________________________ Tracker __________________________________ -------------- next part -------------- A non-text attachment was scrubbed... Name: py3k_more_win_fsencoding.patch Type: text/x-diff Size: 3980 bytes Desc: not available Url : http://mail.python.org/pipermail/python-bugs-list/attachments/20071027/592d4499/attachment.patch From report at bugs.python.org Sat Oct 27 16:13:22 2007 From: report at bugs.python.org (Christian Heimes) Date: Sat, 27 Oct 2007 14:13:22 -0000 Subject: [issue1342] Crash on Windows if Python runs from a directory with umlauts Message-ID: <1193494402.83.0.554453431335.issue1342@psf.upfronthosting.co.za> Christian Heimes added the comment: I've added a fprintf(stderr, "%s", path) to makepathobject(). I suspect that PC/getpathp.c doesn't handle non ASCII chars correctly. It's using char instead of w_char all over the place. Could that be related to the issue, Neal? Microsoft Windows XP [Version 5.1.2600] (C) Copyright 1985-2001 Microsoft Corp. c:\test???\PCBuild8\win32release>set PYTHONPATH=c:\test???\Lib c:\test???\PCBuild8\win32release>python c:\test???\Lib;c:\test???\PCBuild8\win32release\python30.zip;c:\test???\DLLs;c:\ test???\lib;c:\test???\lib\plat-win;c:\test???\lib\lib-tk;c:\test???\PCBuild8\wi n32releaseFatal Python error: Py_Initialize: can't initialize sys standard strea ms object : ImportError('No module named encodings.utf_8',) type : ImportError refcount: 4 address : 00A43540 lost sys.stderr This application has requested the Runtime to terminate it in an unusual way. Please contact the application's support team for more information. ---------- nosy: +nnorwitz __________________________________ Tracker __________________________________ From report at bugs.python.org Sat Oct 27 17:12:54 2007 From: report at bugs.python.org (Jean Brouwers) Date: Sat, 27 Oct 2007 15:12:54 -0000 Subject: [issue1329] Different 3.0a1 exit behavior Message-ID: <1193497974.43.0.340394999772.issue1329@psf.upfronthosting.co.za> Jean Brouwers added the comment: Yes, that is the expected behavior in this case. __________________________________ Tracker __________________________________ From report at bugs.python.org Sat Oct 27 17:37:47 2007 From: report at bugs.python.org (Hirokazu Yamamoto) Date: Sat, 27 Oct 2007 15:37:47 -0000 Subject: [issue1135] xview/yview of Tix.Grid is broken Message-ID: <1193499467.25.0.374904966151.issue1135@psf.upfronthosting.co.za> Hirokazu Yamamoto added the comment: Sorry for late repry. I couldn't apply Issue1522587's patch itself because it was too old, so I tried only [xy]view{,_moveto,_scroll} functions by applying patch partially. (partial.patch) And yes, it worked. Added file: http://bugs.python.org/file8634/partial.patch __________________________________ Tracker __________________________________ -------------- next part -------------- A non-text attachment was scrubbed... Name: partial.patch Type: text/x-patch Size: 1749 bytes Desc: not available Url : http://mail.python.org/pipermail/python-bugs-list/attachments/20071027/7223062b/attachment.bin From report at bugs.python.org Sat Oct 27 18:39:39 2007 From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=) Date: Sat, 27 Oct 2007 16:39:39 -0000 Subject: [issue1135] xview/yview of Tix.Grid is broken Message-ID: <1193503179.18.0.641663166307.issue1135@psf.upfronthosting.co.za> Changes by Martin v. L?wis: ---------- keywords: +patch __________________________________ Tracker __________________________________ From report at bugs.python.org Sat Oct 27 18:41:20 2007 From: report at bugs.python.org (Jean Brouwers) Date: Sat, 27 Oct 2007 16:41:20 -0000 Subject: [issue1329] Different 3.0a1 exit behavior Message-ID: <1193503280.4.0.048794582936.issue1329@psf.upfronthosting.co.za> Jean Brouwers added the comment: One final comment as confirmation. If the messages are written to a file, other than stdout and stderr, they do appear in unpatched 3.0a1 and 3.0a1 behaves as expected. The root cause of the problem was the closed stdout. __________________________________ Tracker __________________________________ From report at bugs.python.org Sat Oct 27 19:04:41 2007 From: report at bugs.python.org (Guido van Rossum) Date: Sat, 27 Oct 2007 17:04:41 -0000 Subject: [issue1329] Different 3.0a1 exit behavior Message-ID: <1193504681.82.0.783094000931.issue1329@psf.upfronthosting.co.za> Guido van Rossum added the comment: So is there even a bug? Arguably you shouldn't be writing anything that late in the life of a shared library. __________________________________ Tracker __________________________________ From report at bugs.python.org Sat Oct 27 19:15:09 2007 From: report at bugs.python.org (Dean Sturtevant) Date: Sat, 27 Oct 2007 17:15:09 -0000 Subject: [issue1344] subprocess.communication doc could use clarification Message-ID: <1193505309.53.0.688990452376.issue1344@psf.upfronthosting.co.za> New submission from Dean Sturtevant: It would be helpful for the documentation for subprocess.communicate to point out that when Popening a process, stdin=PIPE needs to be set if the input parameter to communicate is to have any meaning. Similary, stdout=PIPE and stderr=PIPE need to be set in order for the respective component of the return value not to be None. That is, if that is indeed correct (I observed this using Python 2.5 (r25:51908, Sep 19 2006, 09:52:17) [MSC v.1310 32 bit (Intel)] on win32) ---------- components: Documentation messages: 56858 nosy: dsturtevant severity: normal status: open title: subprocess.communication doc could use clarification versions: Python 2.5 __________________________________ Tracker __________________________________ From report at bugs.python.org Sat Oct 27 20:48:10 2007 From: report at bugs.python.org (Jean Brouwers) Date: Sat, 27 Oct 2007 18:48:10 -0000 Subject: [issue1329] Different 3.0a1 exit behavior Message-ID: <1193510890.19.0.141740150722.issue1329@psf.upfronthosting.co.za> Jean Brouwers added the comment: It is quite common to pre-load libraries into existing binaries e.g. for profiling Typically, those write to stdout or stderr only if the option for an output file is not used. That is how I happened to run into the issue the other day. For a while, the initial symptoms looked like the different exit behavior in 3.0a1 might be a serious problem. It was not obvious that stdout and -err might have been closed and caused the difference. All the Python 2.x versions never closed stdout and -err. Therefore, 3.0 should probably not do that either. But that is really your call. __________________________________ Tracker __________________________________ From report at bugs.python.org Sat Oct 27 21:45:56 2007 From: report at bugs.python.org (Christian Heimes) Date: Sat, 27 Oct 2007 19:45:56 -0000 Subject: [issue1332] threading.RLock().aquire(0) fails with python-2.5.1.amd64.msi In-Reply-To: <1193446251.73.0.606221139809.issue1332@psf.upfronthosting.co.za> Message-ID: <4723956A.40408@cheimes.de> Christian Heimes added the comment: Warren DeLano wrote: > So I guess that automatically puts me in the **highly- > motivated/willing-to-help** camp, if there's anything useful I can > actually do towards 2.5.2. You can check every bugs related to 2.5 with urgent, high or no priority and see if the bugs needs to be fixed for 2.5.2. http://bugs.python.org/issue?@columns=title,id,activity,status&@sort=activity&@group=priority&@filter=versions,status&@pagesize=50&@startwith=0&status=1&versions=2 I guess at least the urgent and high priority bugs have to be addressed for the new release. Christian __________________________________ Tracker __________________________________ From report at bugs.python.org Sat Oct 27 23:02:32 2007 From: report at bugs.python.org (Christian Heimes) Date: Sat, 27 Oct 2007 21:02:32 -0000 Subject: [issue1340] correction for test_tempfile in py3k on Windows Message-ID: <1193518952.76.0.284917097848.issue1340@psf.upfronthosting.co.za> Christian Heimes added the comment: The patch is fine but you should add a short comment to avoid future trouble. On the first glance it's not obvious why the StringIO instance mustn't have a newline argument. ---------- nosy: +gvanrossum, tiran __________________________________ Tracker __________________________________ From report at bugs.python.org Sat Oct 27 23:34:53 2007 From: report at bugs.python.org (Kurt B. Kaiser) Date: Sat, 27 Oct 2007 21:34:53 -0000 Subject: [issue1252] IDLE - patch Delegator to support callables Message-ID: <1193520893.64.0.103730097869.issue1252@psf.upfronthosting.co.za> Kurt B. Kaiser added the comment: First, I'm changing my mind about Percolator inheriting from Delegator. A Percolator acts as a container for Delegators: it "hasa" (chain) of them. But it fails "isa" Delegator. It has no use for the Delegator's caching, and chaining Percolators doesn't make sense. Inheriting from Delegator just confuses things further, it seems to me. Delegator is just a mixin implementing a node in the chain. I do support splitting TkTextPercolator off Percolator. > 3) make Delegator able to delegate direct calls Except that the Delegator mixin doesn't know to what function to delegate the call. Delegating a function call down the nodes doesn't do anything, except possibly error out if the bottom object isn't callable, as in delegator.txt. > IMO, the nice thing about the Delegator class is that you can > use an instance just as if it were the underlying object, transparently. > The major exception from this behavior was that calling a Delegator > never works, even if the underlying object is callable. But it does work, if the filter that is using the Delegator mixin has a __call__ method. See delegator2.txt above. Note that the Delegator __call__ method is removed. You have to override the latter anyway if you want to run some code in the filter. Do you have some reason for mixing callable and non-callable filter instances in the percolator chain? I can see adding a __call__ method to Percolator, which would call self.top(). Then each instance in the chain would have a __call__ to appropriate code. We have two goals: solve your specific requirement of being able to replace a method with a percolator, and increasing the clarity of the existing WidgetRedirector/Delegator/Percolator code. Yes, a Percolator already has semantic overload. Right now, there are two ways to access the chain: 1. Since the delegate link is exposed, filters can directly call specific methods further down the chain, e.g. self.delegate.index() 2. The caching and __getattr__() allows a "delegator" to call unimplemented methods; they will be looked up on the chain. This allows ColorDelegator to access its Text instance's methods without having been passed a reference to the instance, as you noted. Whether this adds or detracts from the clarity of the code is debatable. Once you understand how it works, it's not a problem, but it would be for people new to the code. Further, it's fragile, since the first method with the correct name will be called. Adding a __call__() method to Delegator doesn't seem to do anything that can't be accomplished better by adding it to the class implementing the filter. Why add complexity prematurely? ---------- assignee: -> kbk priority: -> normal Added file: http://bugs.python.org/file8635/delegator2.txt __________________________________ Tracker __________________________________ -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: delegator2.txt Url: http://mail.python.org/pipermail/python-bugs-list/attachments/20071027/ac870a8e/attachment.txt From report at bugs.python.org Sat Oct 27 23:45:48 2007 From: report at bugs.python.org (Christian Heimes) Date: Sat, 27 Oct 2007 21:45:48 -0000 Subject: [issue1345] Fix for test_netrc on Windows Message-ID: <1193521548.65.0.259822939924.issue1345@psf.upfronthosting.co.za> New submission from Christian Heimes: Index: Lib/test/test_netrc.py =================================================================== --- Lib/test/test_netrc.py (revision 58695) +++ Lib/test/test_netrc.py (working copy) @@ -25,7 +25,7 @@ mode = 'w' if sys.platform not in ['cygwin']: mode += 't' - fp = open(temp_filename, mode) + fp = open(temp_filename, mode, newline='') fp.write(TEST_NETRC) fp.close() ---------- components: Library (Lib) messages: 56863 nosy: tiran severity: normal status: open title: Fix for test_netrc on Windows type: behavior versions: Python 3.0 __________________________________ Tracker __________________________________ From report at bugs.python.org Sun Oct 28 00:06:33 2007 From: report at bugs.python.org (Christian Heimes) Date: Sat, 27 Oct 2007 22:06:33 -0000 Subject: =?utf-8?q?[issue1262]_IDLE_does_not_start_if_windows_environment_variable_containing_'German_Umlaute:_=C3=A4=C3=B6=C3=BC'_exists?= Message-ID: <1193522793.45.0.507767566372.issue1262@psf.upfronthosting.co.za> Christian Heimes added the comment: Confirmed! Python 3.0 doesn't start at all on Windows when an environment variable with non ASCII chars is present. This bug is related to http://bugs.python.org/issue1342. However on Linux Python 3.0 can handle unicode characters in paths and environ vars fine. $ UNITEST="umlauts ??? ? " ./python -c "import os; print(os.environ['UNITEST'])" umlauts ??? ? ---------- nosy: +tiran severity: normal -> urgent __________________________________ Tracker __________________________________ From report at bugs.python.org Sun Oct 28 00:09:42 2007 From: report at bugs.python.org (Christian Heimes) Date: Sat, 27 Oct 2007 22:09:42 -0000 Subject: [issue1342] Crash on Windows if Python runs from a directory with umlauts Message-ID: <1193522982.76.0.700261907645.issue1342@psf.upfronthosting.co.za> Christian Heimes added the comment: The bug is related to http://bugs.python.org/issue1262 ---------- nosy: +gvanrossum severity: normal -> urgent __________________________________ Tracker __________________________________ From report at bugs.python.org Sun Oct 28 00:33:15 2007 From: report at bugs.python.org (Dale) Date: Sat, 27 Oct 2007 22:33:15 -0000 Subject: [issue1346] Error using >>> from OpenGL.GLUT import * Message-ID: <1193524395.52.0.467041983847.issue1346@psf.upfronthosting.co.za> New submission from Dale: I get the response shown below when trying to use OpenGL. I have Python 2.5, PIL-1.1.6, and PyOpenGL 3.0 installed. Any help would be greatly appreciated. Thanks, Dale >>> from OpenGL.GLUT import * Traceback (most recent call last): File "", line 1, in from OpenGL.GLUT import * File "build\bdist.win32\egg\OpenGL\GLUT\__init__.py", line 4, in File "build\bdist.win32\egg\OpenGL\GLUT\special.py", line 73, in AttributeError: 'NoneType' object has no attribute 'glutDestroyWindow' >>> __init__.py line 4 is; from OpenGL.GLUT.special import * special.py line 73 is; _base_glutDestroyWindow = GLUT.glutDestroyWindow ---------- components: Windows messages: 56866 nosy: neuralsensor severity: normal status: open title: Error using >>> from OpenGL.GLUT import * type: compile error versions: Python 2.5 __________________________________ Tracker __________________________________ From report at bugs.python.org Sun Oct 28 01:28:51 2007 From: report at bugs.python.org (Gabriel Genellina) Date: Sat, 27 Oct 2007 23:28:51 -0000 Subject: [issue1346] Error using >>> from OpenGL.GLUT import * Message-ID: <1193527731.91.0.428945416548.issue1346@psf.upfronthosting.co.za> Gabriel Genellina added the comment: Looks like GLUT in special.py is None. You should ask the PyOpenGL author/community for help. This is not a Python bug. ---------- nosy: +gagenellina __________________________________ Tracker __________________________________ From report at bugs.python.org Sun Oct 28 01:53:49 2007 From: report at bugs.python.org (Gabriel Genellina) Date: Sat, 27 Oct 2007 23:53:49 -0000 Subject: [issue1336] subprocess.Popen hangs when child writes to stderr Message-ID: <1193529229.87.0.761338641696.issue1336@psf.upfronthosting.co.za> Changes by Gabriel Genellina: ---------- nosy: +gagenellina __________________________________ Tracker __________________________________ From report at bugs.python.org Sun Oct 28 02:06:36 2007 From: report at bugs.python.org (Bill Janssen) Date: Sun, 28 Oct 2007 00:06:36 -0000 Subject: [issue1347] BaseHTTPServer writing strings to bytes interface Message-ID: <1193529996.43.0.859664216454.issue1347@psf.upfronthosting.co.za> New submission from Bill Janssen: A number of places in the BaseHTTPServer got missed when converting between bytes and strings. Here's a patch to fix that. ---------- components: Library (Lib) files: a messages: 56868 nosy: janssen severity: normal status: open title: BaseHTTPServer writing strings to bytes interface type: behavior versions: Python 3.0 Added file: http://bugs.python.org/file8636/a __________________________________ Tracker __________________________________ -------------- next part -------------- A non-text attachment was scrubbed... Name: a Type: application/octet-stream Size: 2090 bytes Desc: not available Url : http://mail.python.org/pipermail/python-bugs-list/attachments/20071028/83805cf7/attachment.obj From report at bugs.python.org Sun Oct 28 02:28:32 2007 From: report at bugs.python.org (Tal Einat) Date: Sun, 28 Oct 2007 00:28:32 -0000 Subject: [issue1252] IDLE - patch Delegator to support callables Message-ID: <1193531312.6.0.353927917933.issue1252@psf.upfronthosting.co.za> Tal Einat added the comment: It seems we're looking at Delegators and Percolators from increasingly different points of view. Let's back up a little. I see a Delegator object as a transparent proxy to its "delegate". This means that attribute access is automatically delegated to the delegate, unless it is explicitly overridden by the Delegator. That's it. Some use cases for such a transparent proxy are: * override only specific attributes/methods of an object * allow replacement of an object which is referenced in several places without having to update every reference (Caching is just an implementation detail, whose only purpose is to facilitate changing a Delegator's delegate.) As for Percolator, it really "is a" delegator -- it delegates attribute access to the bottom of the chain, unless it is explicitly overridden. True, in a "normal" Delegator this overriding can only be done in one place, and in a Percolator it can also happen in any of the chain's links. But the concept is identical -- it is a transparent proxy for an underlying object. IMO chaining Percolators makes just as much sense as chaining Delegators -- you're just chaining proxies. How each proxy works internally doesn't really matter (as long as they work :). Now, it seems to me that you aren't looking at Delegators and Peroclators as transparent proxies at all. Specifically, what you wrote implies that in order to proxy a callable, one should explicitly define an __call__ method in their Delegator class/instance. But this is exactly the opposite of the behavior with any other method/attribute, where I can implicitly have the underlying attribute used by not defining it in the Delegator. This is Delegator is for! I'm attaching a Python file which will hopefully show how __call__ is out of sync with the rest of Delegator's behavior. In its context, "forwarded" means explicitly defined by a Delegator. "intercepted" means that except for the interceptor and catcher, the method is not defined (i.e. by the passers). Please take a moment to run it. I should note that the situation is similar with other "magic" methods, e.g. len(). This seems to make Python a bit less dynamic that I would expect. Aside from implementation considerations such as speed, I'm not sure I see why this is the way it is, e.g. why dynamically giving a __call__ attribute to an instance shouldn't make it callable. I'll do some more searching and reading on this. Even though, I still think being able to delegate/percolate callables is important enough to warrant such a change. After all, at the bottom line, if the underlying object is callable then it will be called, and if not then an appropriate exception will be raised. Isn't that the Right Thing? Added file: http://bugs.python.org/file8637/Delegators3.py __________________________________ Tracker __________________________________ -------------- next part -------------- A non-text attachment was scrubbed... Name: Delegators3.py Type: text/x-python Size: 2360 bytes Desc: not available Url : http://mail.python.org/pipermail/python-bugs-list/attachments/20071028/1ba81060/attachment.py From report at bugs.python.org Sun Oct 28 02:49:13 2007 From: report at bugs.python.org (Bill Janssen) Date: Sun, 28 Oct 2007 00:49:13 -0000 Subject: [issue1348] httplib closes socket, then tries to read from it Message-ID: <1193532553.16.0.237482805264.issue1348@psf.upfronthosting.co.za> New submission from Bill Janssen: I can't get urllib.urlopen() to work with SSL, and it seems to be due to a bug in the re-write of httplib. HTTPConnection.getresponse() is closing the socket, but then returning a response object holding onto that closed socket to the caller, who then tries to read from the (closed) socket. Due to the delayed closing of sockets, this error is masked, but in SSL, the context is torn down on close, so we see real failures. ---------- components: Library (Lib) keywords: py3k messages: 56870 nosy: janssen priority: urgent severity: normal status: open title: httplib closes socket, then tries to read from it type: behavior versions: Python 3.0 __________________________________ Tracker __________________________________ From report at bugs.python.org Sun Oct 28 02:19:26 2007 From: report at bugs.python.org (Bill Janssen) Date: Sun, 28 Oct 2007 01:19:26 -0000 Subject: [issue1348] httplib closes socket, then tries to read from it Message-ID: <1193534365.98.0.0963803743099.issue1348@psf.upfronthosting.co.za> Bill Janssen added the comment: I believe this is all that's needed. Added file: http://bugs.python.org/file8638/c __________________________________ Tracker __________________________________ -------------- next part -------------- A non-text attachment was scrubbed... Name: c Type: application/octet-stream Size: 539 bytes Desc: not available Url : http://mail.python.org/pipermail/python-bugs-list/attachments/20071028/6ea4dd72/attachment-0001.obj From report at bugs.python.org Sun Oct 28 02:33:21 2007 From: report at bugs.python.org (Bill Janssen) Date: Sun, 28 Oct 2007 01:33:21 -0000 Subject: [issue1349] more uses of ord() in plat-mac/ic.py Message-ID: <1193535201.15.0.846048268818.issue1349@psf.upfronthosting.co.za> New submission from Bill Janssen: Neal, a patch to get rid of the other ord() calls in ic.py. ---------- assignee: nnorwitz components: Library (Lib), Macintosh files: d keywords: py3k messages: 56872 nosy: janssen, nnorwitz priority: high severity: normal status: open title: more uses of ord() in plat-mac/ic.py type: behavior versions: Python 3.0 Added file: http://bugs.python.org/file8639/d __________________________________ Tracker __________________________________ -------------- next part -------------- A non-text attachment was scrubbed... Name: d Type: application/octet-stream Size: 1274 bytes Desc: not available Url : http://mail.python.org/pipermail/python-bugs-list/attachments/20071028/bc067385/attachment.obj From report at bugs.python.org Sun Oct 28 02:40:09 2007 From: report at bugs.python.org (Gabriel Genellina) Date: Sun, 28 Oct 2007 01:40:09 -0000 Subject: [issue1328] feature request: force BOM option Message-ID: <1193535609.34.0.452967426055.issue1328@psf.upfronthosting.co.za> Changes by Gabriel Genellina: ---------- nosy: +gagenellina __________________________________ Tracker __________________________________ From report at bugs.python.org Sun Oct 28 02:55:07 2007 From: report at bugs.python.org (Gabriel Genellina) Date: Sun, 28 Oct 2007 01:55:07 -0000 Subject: [issue1311] os.path.exists(os.devnull) regression on windows Message-ID: <1193536507.91.0.872459159178.issue1311@psf.upfronthosting.co.za> Gabriel Genellina added the comment: All these tests on Windows XP SP4, executing os.stat("nul") Python 2.1 thru 2.4 raises: OSError: [Errno 22] Invalid argument: 'nul' Python 2.5 gives a different error: WindowsError: [Error 87] El par?metro no es correcto: 'nul' ---------- nosy: +gagenellina __________________________________ Tracker __________________________________ From report at bugs.python.org Sun Oct 28 03:42:49 2007 From: report at bugs.python.org (Kurt B. Kaiser) Date: Sun, 28 Oct 2007 02:42:49 -0000 Subject: [issue1252] IDLE - patch Delegator to support callables Message-ID: <1193539369.11.0.0710577455816.issue1252@psf.upfronthosting.co.za> Kurt B. Kaiser added the comment: I'll respond further shortly. In the meantime, please notice that Delegator3.py works the same whether or not your Delegator.__call__() method is commented out. That's because you needed to define __call__() methods in your filters. We are still suffering from semantic overload. Let's call the instances which are chained 'filters' and the Delegator mixin machinery 'nodes' for the purposes of this discussion (because they act much like the nodes in a traditional Lisp list). __________________________________ Tracker __________________________________ From report at bugs.python.org Sun Oct 28 03:49:25 2007 From: report at bugs.python.org (Tal Einat) Date: Sun, 28 Oct 2007 02:49:25 -0000 Subject: [issue1334] IDLE - Fix several highlighting bugs Message-ID: <1193539765.82.0.760712868992.issue1334@psf.upfronthosting.co.za> Tal Einat added the comment: The first patch contained a bug - a window opened using the "New Window" menu option would not be colorized. This patch removes the assumption that EditorWindow.ResetColorizer will be called by IOBinding code, by calling ResetColorizer during __init__ anyways. This means that in some cases it will be called multiple times, but this has no noticeable effect since the window is not shown until afterwards. (In the worst case scenario, the colors would "blink" once or twice.) Added file: http://bugs.python.org/file8640/IDLE_highlighting.071028.patch __________________________________ Tracker __________________________________ -------------- next part -------------- A non-text attachment was scrubbed... Name: IDLE_highlighting.071028.patch Type: application/octet-stream Size: 5182 bytes Desc: not available Url : http://mail.python.org/pipermail/python-bugs-list/attachments/20071028/76fb4344/attachment.obj From report at bugs.python.org Sun Oct 28 03:59:54 2007 From: report at bugs.python.org (Tal Einat) Date: Sun, 28 Oct 2007 02:59:54 -0000 Subject: [issue1350] IDLE - CallTips enhancement - show full doc-string in new window Message-ID: <1193540394.75.0.209428889105.issue1350@psf.upfronthosting.co.za> New submission from Tal Einat: This (relatively speaking) simple patch allows the full doc-string of a callable to be displayed in a textView window. Once a call-tip is being displayed, hitting one of the keys which is bound to the force-open-calltip virtual event (Control-backslash by default) opens the new window. If there is no extra documentation to be shown (in addition to what is already shown in the call-tip), the window is not displayed. ---------- components: IDLE files: IDLE_CallTips.071028.patch messages: 56876 nosy: kbk, taleinat severity: minor status: open title: IDLE - CallTips enhancement - show full doc-string in new window versions: Python 2.5, Python 2.6 Added file: http://bugs.python.org/file8641/IDLE_CallTips.071028.patch __________________________________ Tracker __________________________________ -------------- next part -------------- A non-text attachment was scrubbed... Name: IDLE_CallTips.071028.patch Type: application/octet-stream Size: 5961 bytes Desc: not available Url : http://mail.python.org/pipermail/python-bugs-list/attachments/20071028/ad9f917a/attachment-0001.obj From report at bugs.python.org Sun Oct 28 08:19:39 2007 From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=) Date: Sun, 28 Oct 2007 07:19:39 -0000 Subject: [issue1345] Fix for test_netrc on Windows Message-ID: <1193555979.07.0.0516964922945.issue1345@psf.upfronthosting.co.za> Changes by Martin v. L?wis: ---------- keywords: +patch __________________________________ Tracker __________________________________ From report at bugs.python.org Sun Oct 28 08:23:22 2007 From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=) Date: Sun, 28 Oct 2007 07:23:22 -0000 Subject: [issue1347] BaseHTTPServer writing strings to bytes interface Message-ID: <1193556202.31.0.208583983414.issue1347@psf.upfronthosting.co.za> Changes by Martin v. L?wis: ---------- keywords: +patch __________________________________ Tracker __________________________________ From report at bugs.python.org Sun Oct 28 08:23:57 2007 From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=) Date: Sun, 28 Oct 2007 07:23:57 -0000 Subject: [issue1349] more uses of ord() in plat-mac/ic.py Message-ID: <1193556237.45.0.0399271595989.issue1349@psf.upfronthosting.co.za> Changes by Martin v. L?wis: ---------- keywords: +patch __________________________________ Tracker __________________________________ From report at bugs.python.org Sun Oct 28 08:26:35 2007 From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=) Date: Sun, 28 Oct 2007 07:26:35 -0000 Subject: [issue1350] IDLE - CallTips enhancement - show full doc-string in new window Message-ID: <1193556395.53.0.0919818209153.issue1350@psf.upfronthosting.co.za> Changes by Martin v. L?wis: ---------- keywords: +patch __________________________________ Tracker __________________________________ From report at bugs.python.org Sun Oct 28 12:09:43 2007 From: report at bugs.python.org (Christian Heimes) Date: Sun, 28 Oct 2007 11:09:43 -0000 Subject: [issue1351] Add getsize() to io instances Message-ID: <1193569783.49.0.578170746692.issue1351@psf.upfronthosting.co.za> New submission from Christian Heimes: I always missed a getsize() method on file objects. The patch adds a method getsize() to all io instances. The method returns a SizeInfo object which can print a human readable name or the bare size in bytes. The method is using os.fstat and falls back to the seek(0,2), tell() pattern. >>> f = open("/etc/passwd") >>> f.getsize() >>> int(f.getsize()) 1721 >>> str(f.getsize()) '1.7 KiB' >>> (f.getsize().sizeinfo()) (1.681, 1) I'm going to provide unit tests and documentation if you like the feature. ---------- components: Library (Lib) files: py3k_sizeinfo.patch messages: 56877 nosy: tiran severity: normal status: open title: Add getsize() to io instances type: rfe versions: Python 3.0 Added file: http://bugs.python.org/file8642/py3k_sizeinfo.patch __________________________________ Tracker __________________________________ -------------- next part -------------- A non-text attachment was scrubbed... Name: py3k_sizeinfo.patch Type: text/x-diff Size: 2276 bytes Desc: not available Url : http://mail.python.org/pipermail/python-bugs-list/attachments/20071028/e7543558/attachment.patch From report at bugs.python.org Sun Oct 28 13:59:45 2007 From: report at bugs.python.org (Bill Janssen) Date: Sun, 28 Oct 2007 12:59:45 -0000 Subject: [issue1348] httplib closes socket, then tries to read from it Message-ID: <1193576385.67.0.928776770611.issue1348@psf.upfronthosting.co.za> Bill Janssen added the comment: I still think the semantics are wrong here, but someone needs to close this connection at some point, and right now the reference-counting semantics of socket.close() are the only thing preventing a leak. So I think my patch should not be applied. Instead, a larger fix needs to be thought through, which will probably require some changes to urllib and its cousins. ---------- keywords: +patch __________________________________ Tracker __________________________________ From report at bugs.python.org Sun Oct 28 14:10:58 2007 From: report at bugs.python.org (Bill Janssen) Date: Sun, 28 Oct 2007 13:10:58 -0000 Subject: [issue1223] httplib does not handle ssl end of file properly Message-ID: <1193577058.48.0.859788225166.issue1223@psf.upfronthosting.co.za> Bill Janssen added the comment: I have a slightly different version of this patch in the new SSL code. It (optionally, but defaulting to True) catches SSL_ERROR_EOF and returns None, but allows other ssl errors to go through. ---------- nosy: +janssen Added file: http://bugs.python.org/file8643/e __________________________________ Tracker __________________________________ -------------- next part -------------- A non-text attachment was scrubbed... Name: e Type: application/octet-stream Size: 232 bytes Desc: not available Url : http://mail.python.org/pipermail/python-bugs-list/attachments/20071028/622c8087/attachment.obj From report at bugs.python.org Sun Oct 28 14:51:14 2007 From: report at bugs.python.org (Christian Heimes) Date: Sun, 28 Oct 2007 13:51:14 -0000 Subject: [issue1352] Preliminary stderr patch Message-ID: <1193579474.79.0.743146991528.issue1352@psf.upfronthosting.co.za> New submission from Christian Heimes: Here is another patch related to stdio from me. It creates and sets up a very dumb and easy stderr writer until the new io infrastructure is initialized. It makes debugging problems in the init phase much easier. ---------- components: Interpreter Core files: py3k_preliminary_stderr.patch messages: 56880 nosy: tiran severity: normal status: open title: Preliminary stderr patch type: rfe versions: Python 3.0 Added file: http://bugs.python.org/file8644/py3k_preliminary_stderr.patch __________________________________ Tracker __________________________________ -------------- next part -------------- A non-text attachment was scrubbed... Name: py3k_preliminary_stderr.patch Type: text/x-diff Size: 4310 bytes Desc: not available Url : http://mail.python.org/pipermail/python-bugs-list/attachments/20071028/8ddad3f4/attachment.patch From report at bugs.python.org Sun Oct 28 15:59:14 2007 From: report at bugs.python.org (Guido van Rossum) Date: Sun, 28 Oct 2007 14:59:14 -0000 Subject: [issue1340] correction for test_tempfile in py3k on Windows Message-ID: <1193583554.41.0.550929130137.issue1340@psf.upfronthosting.co.za> Changes by Guido van Rossum: ---------- assignee: -> gvanrossum __________________________________ Tracker __________________________________ From report at bugs.python.org Sun Oct 28 16:12:51 2007 From: report at bugs.python.org (Guido van Rossum) Date: Sun, 28 Oct 2007 15:12:51 -0000 Subject: [issue1340] correction for test_tempfile in py3k on Windows Message-ID: <1193584371.12.0.947175253583.issue1340@psf.upfronthosting.co.za> Guido van Rossum added the comment: Committed revision 58699. (My own interpretation of the patch, with comment :-) I expect this will fix a bunch Windows failures; I've seen complaints inmplicating doubled newlines in a few places, and this mught just be the cause. Thanks! ---------- resolution: -> accepted status: open -> closed __________________________________ Tracker __________________________________ From report at bugs.python.org Sun Oct 28 16:31:17 2007 From: report at bugs.python.org (Jean Brouwers) Date: Sun, 28 Oct 2007 15:31:17 -0000 Subject: [issue1329] Different 3.0a1 exit behavior Message-ID: <1193585477.75.0.228758133837.issue1329@psf.upfronthosting.co.za> Jean Brouwers added the comment: One more argument. Without a fix, 3.0 would not even print a C debug message from a destructor function nor from any function installed with atexit or Py_AtExit. The dlibtest shows that for 2 of these 3. __________________________________ Tracker __________________________________ From report at bugs.python.org Sun Oct 28 16:33:22 2007 From: report at bugs.python.org (Guido van Rossum) Date: Sun, 28 Oct 2007 15:33:22 -0000 Subject: [issue1340] correction for test_tempfile in py3k on Windows Message-ID: <1193585602.63.0.854747807397.issue1340@psf.upfronthosting.co.za> Guido van Rossum added the comment: D'oh, I submitted to the wrong branch. The py3k branch will have to wait until after my son's birthday party. ;-) ---------- status: closed -> open __________________________________ Tracker __________________________________ From report at bugs.python.org Sun Oct 28 16:53:54 2007 From: report at bugs.python.org (Christian Heimes) Date: Sun, 28 Oct 2007 15:53:54 -0000 Subject: [issue1340] correction for test_tempfile in py3k on Windows In-Reply-To: <1193585602.63.0.854747807397.issue1340@psf.upfronthosting.co.za> Message-ID: <4724B090.7070507@cheimes.de> Christian Heimes added the comment: Guido van Rossum wrote: > Guido van Rossum added the comment: > > D'oh, I submitted to the wrong branch. The py3k branch will have to > wait until after my son's birthday party. ;-) Have a nice party! How old is he? IIRC he was about 4 on the pictures you showed us at EuroPython 2005 in G?teborg. __________________________________ Tracker __________________________________ From report at bugs.python.org Sun Oct 28 18:03:58 2007 From: report at bugs.python.org (Christian Heimes) Date: Sun, 28 Oct 2007 17:03:58 -0000 Subject: [issue1329] Different 3.0a1 exit behavior Message-ID: <1193591038.81.0.565635007659.issue1329@psf.upfronthosting.co.za> Christian Heimes added the comment: Can you try this patch, please? It has the same effect as the other patch from Neal but it doesn't loose ref counts. I've patched the dealloc function of _FileIO to keep fd 1 and fd 2 open. Index: Modules/_fileio.c =================================================================== --- Modules/_fileio.c (Revision 58699) +++ Modules/_fileio.c (Arbeitskopie) @@ -270,7 +270,8 @@ if (self->weakreflist != NULL) PyObject_ClearWeakRefs((PyObject *) self); - if (self->fd >= 0) { + /* Don't close stdout and stderr */ + if (self->fd == 0 || self->fd > 2) { errno = internal_close(self); if (errno < 0) { #ifdef HAVE_STRERROR ---------- nosy: +tiran __________________________________ Tracker __________________________________ From report at bugs.python.org Sun Oct 28 18:44:21 2007 From: report at bugs.python.org (Jean Brouwers) Date: Sun, 28 Oct 2007 17:44:21 -0000 Subject: [issue1329] Different 3.0a1 exit behavior Message-ID: <1193593461.54.0.171548511462.issue1329@psf.upfronthosting.co.za> Jean Brouwers added the comment: I could not try Neal's patch since it does not seem to apply to the 3.0a1 source I have. But the Modules/_fileio.c patch works just fine on my Linux and MacOS X. Here is the Linux result: $ env LD_PRELOAD=./dlibtest4.so ~/Python-3dbg/python *** ctor called in python ... *** atexit OK in python ... Python 3.0a1 (py3k, Oct 28 2007, 10:23:59) [GCC 3.4.6 20060404 (Red Hat 3.4.6-8)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> [36000 refs] [21985 refs] *** dtor called in python ... $ Most interesting is that this Python build --with-pydebug now prints 2 lines in [..] brackets on exit. That 2nd line, [21985 refs] never showed up before! Also, attached is another version of my test case renamed to dlibtest4. It includes 4 different use cases. More details inside. Added file: http://bugs.python.org/file8645/dlibtest4.c __________________________________ Tracker __________________________________ -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: dlibtest4.c Url: http://mail.python.org/pipermail/python-bugs-list/attachments/20071028/fc8417ab/attachment.txt From report at bugs.python.org Sun Oct 28 18:44:25 2007 From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=) Date: Sun, 28 Oct 2007 17:44:25 -0000 Subject: [issue1351] Add getsize() to io instances Message-ID: <1193593465.61.0.675129895248.issue1351@psf.upfronthosting.co.za> Martin v. L?wis added the comment: I'm skeptical: - If you add getsize, why not getlastchangeddate, getowner, getpermissions? - in general, streams (which really is the interface for file-like objects) don't have the notion of "size"; only some do. - what is the purpose of the f.tell fragment? ie. why could that work when fstat doesn't? ---------- nosy: +loewis __________________________________ Tracker __________________________________ From report at bugs.python.org Sun Oct 28 19:14:43 2007 From: report at bugs.python.org (Christian Heimes) Date: Sun, 28 Oct 2007 18:14:43 -0000 Subject: [issue1351] Add getsize() to io instances In-Reply-To: <1193593465.61.0.675129895248.issue1351@psf.upfronthosting.co.za> Message-ID: <4724D192.2000009@cheimes.de> Christian Heimes added the comment: Martin v. L?wis wrote: > I'm skeptical: > > - If you add getsize, why not getlastchangeddate, getowner, getpermissions? getowner() etc. work only with file based streams and not with memory buffers. getsize() works with every concrete class in io.py > - in general, streams (which really is the interface for file-like > objects) don't have the notion of "size"; only some do. I understand that getsize() doesn't make sense for e.g. a socket based stream. However the implementation of getsize() works with memory buffers and file descriptors > - what is the purpose of the f.tell fragment? ie. why could that work > when fstat doesn't? The tell(), seek(0,2) is a generic fall back for io instances that aren't based on a file descriptor. It's required for BytesIO and StringIO. However I could come up with an implementation for BytesIO that queries the buffer directly. __________________________________ Tracker __________________________________ From report at bugs.python.org Sun Oct 28 20:08:08 2007 From: report at bugs.python.org (Kurt B. Kaiser) Date: Sun, 28 Oct 2007 19:08:08 -0000 Subject: [issue1717170] "Really print?" Dialog Message-ID: <1193598488.08.0.886297565635.issue1717170@psf.upfronthosting.co.za> Kurt B. Kaiser added the comment: r58700. Thanks for the patch! (Used OK/Cancel and simplified message.) ---------- assignee: -> kbk nosy: +kbk resolution: -> accepted status: open -> closed _____________________________________ Tracker _____________________________________ From report at bugs.python.org Sun Oct 28 20:08:08 2007 From: report at bugs.python.org (Jean Brouwers) Date: Sun, 28 Oct 2007 19:08:08 -0000 Subject: [issue1329] Different 3.0a1 exit behavior Message-ID: <1193598488.84.0.593666815323.issue1329@psf.upfronthosting.co.za> Jean Brouwers added the comment: Perhaps, the proper behavior is the following. After calling all functions/methods installed at the Python level with atexit.register and all C functions installed with Py_AtExit, the objects sys.stdin, sys.stdout and sys.stderr are destroyed. However, the C level files stdin, stdout and stderr are *never* closed by Python. Those will be closed (like any other open file) after all functions installed with atexit or defined as destructors have been called. __________________________________ Tracker __________________________________ From report at bugs.python.org Sun Oct 28 20:20:02 2007 From: report at bugs.python.org (Kurt B. Kaiser) Date: Sun, 28 Oct 2007 19:20:02 -0000 Subject: =?utf-8?q?[issue1262]_IDLE_does_not_start_if_windows_environment_variable_containing_'German_Umlaute:_=C3=A4=C3=B6=C3=BC'_exists?= Message-ID: <1193599202.46.0.299608447109.issue1262@psf.upfronthosting.co.za> Kurt B. Kaiser added the comment: I believe this is a duplicate of http://bugs.python.org/issue1342 and not related to IDLE. ---------- nosy: +kbk resolution: -> duplicate status: open -> closed __________________________________ Tracker __________________________________ From report at bugs.python.org Sun Oct 28 20:22:15 2007 From: report at bugs.python.org (Ralf Schmitt) Date: Sun, 28 Oct 2007 19:22:15 -0000 Subject: [issue1183] race in SocketServer.ForkingMixIn.collect_children Message-ID: <1193599335.42.0.449962308045.issue1183@psf.upfronthosting.co.za> Ralf Schmitt added the comment: I've had the exact same error - but only when I used a subclass of XMLRPCServer, which installed signal handlers for SIGCHLD (which then called collect_children). Does your code install such a signal handler? (I found mine somewhere on the web). Do you start any subprocesses? ---------- nosy: +schmir __________________________________ Tracker __________________________________ From report at bugs.python.org Sun Oct 28 20:30:58 2007 From: report at bugs.python.org (Kurt B. Kaiser) Date: Sun, 28 Oct 2007 19:30:58 -0000 Subject: [issue1356720] Ctrl+C for copy does not work when caps-lock is on Message-ID: <1193599858.22.0.0920446181114.issue1356720@psf.upfronthosting.co.za> Kurt B. Kaiser added the comment: On systems other than Windows, people generally prefer to leave as much flexibility as possible by not binding various combinations of modifiers to the callback associated with a . If you need this change, add a binding as noamr suggests. ---------- resolution: -> wont fix status: open -> closed _____________________________________ Tracker _____________________________________ From report at bugs.python.org Sun Oct 28 20:33:22 2007 From: report at bugs.python.org (Kurt B. Kaiser) Date: Sun, 28 Oct 2007 19:33:22 -0000 Subject: [issue1004696] translate Windows cr-lf when installing scripts on Linux Message-ID: <1193600002.0.0.333996152812.issue1004696@psf.upfronthosting.co.za> Changes by Kurt B. Kaiser: ---------- assignee: kbk -> _____________________________________ Tracker _____________________________________ From report at bugs.python.org Sun Oct 28 22:54:07 2007 From: report at bugs.python.org (Tal Einat) Date: Sun, 28 Oct 2007 21:54:07 -0000 Subject: [issue1717170] "Really print?" Dialog Message-ID: <1193608447.4.0.51430829639.issue1717170@psf.upfronthosting.co.za> Tal Einat added the comment: :) Minor note - shouldn't there be a question mark at the end of the message? _____________________________________ Tracker _____________________________________ From report at bugs.python.org Mon Oct 29 00:12:49 2007 From: report at bugs.python.org (Kurt B. Kaiser) Date: Sun, 28 Oct 2007 23:12:49 -0000 Subject: [issue1334] IDLE - Fix several highlighting bugs Message-ID: <1193613169.33.0.102553310744.issue1334@psf.upfronthosting.co.za> Changes by Kurt B. Kaiser: ---------- assignee: -> kbk keywords: +patch __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Oct 29 00:40:56 2007 From: report at bugs.python.org (Kurt B. Kaiser) Date: Sun, 28 Oct 2007 23:40:56 -0000 Subject: [issue1612746] Enhanced tabbed pane widget Message-ID: <1193614856.43.0.798850441477.issue1612746@psf.upfronthosting.co.za> Kurt B. Kaiser added the comment: Can I ask you for an update? This no longer applies cleanly with the recent changes to configDialog.py, and I suspect you might have some further cleanup. ---------- assignee: -> kbk nosy: +kbk resolution: -> out of date _____________________________________ Tracker _____________________________________ From report at bugs.python.org Mon Oct 29 01:57:23 2007 From: report at bugs.python.org (Guido van Rossum) Date: Mon, 29 Oct 2007 00:57:23 -0000 Subject: [issue1329] Different 3.0a1 exit behavior In-Reply-To: <1193593461.54.0.171548511462.issue1329@psf.upfronthosting.co.za> Message-ID: Guido van Rossum added the comment: Right. I think the right solution is to add an option to _FileIO that says "don't close the filedescriptor when close() is called". This option should only be allowed when the "filename" argument is an integer file descriptor. It should be passed when stdin/out/err are created. It may also be helpful in some other places?! __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Oct 29 06:16:24 2007 From: report at bugs.python.org (Gregory P. Smith) Date: Mon, 29 Oct 2007 05:16:24 -0000 Subject: [issue1247] PEP 3137 patch (repr, names, parser) Message-ID: <1193634984.5.0.718774947496.issue1247@psf.upfronthosting.co.za> Changes by Gregory P. Smith: ---------- nosy: +gregory.p.smith __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Oct 29 10:03:34 2007 From: report at bugs.python.org (Christian Heimes) Date: Mon, 29 Oct 2007 09:03:34 -0000 Subject: [issue1329] Different 3.0a1 exit behavior Message-ID: <1193648614.05.0.517475193263.issue1329@psf.upfronthosting.co.za> Christian Heimes added the comment: Here you go, Guido! Added file: http://bugs.python.org/file8647/py3k_closefd.patch __________________________________ Tracker __________________________________ -------------- next part -------------- A non-text attachment was scrubbed... Name: py3k_closefd.patch Type: text/x-diff Size: 8081 bytes Desc: not available Url : http://mail.python.org/pipermail/python-bugs-list/attachments/20071029/4333a331/attachment.patch From report at bugs.python.org Mon Oct 29 11:52:10 2007 From: report at bugs.python.org (Christian Heimes) Date: Mon, 29 Oct 2007 10:52:10 -0000 Subject: [issue1352] Preliminary stderr patch Message-ID: <1193655130.21.0.857239963447.issue1352@psf.upfronthosting.co.za> Christian Heimes added the comment: Improved patch ---------- nosy: +gvanrossum Added file: http://bugs.python.org/file8648/py3k_preliminary_stderr2.patch __________________________________ Tracker __________________________________ -------------- next part -------------- A non-text attachment was scrubbed... Name: py3k_preliminary_stderr2.patch Type: text/x-diff Size: 5103 bytes Desc: not available Url : http://mail.python.org/pipermail/python-bugs-list/attachments/20071029/5d78769c/attachment-0001.patch From report at bugs.python.org Mon Oct 29 11:54:36 2007 From: report at bugs.python.org (Jacob) Date: Mon, 29 Oct 2007 10:54:36 -0000 Subject: [issue1353] mp4 missing from mimetypes.py Message-ID: <1193655276.24.0.947404053059.issue1353@psf.upfronthosting.co.za> New submission from Jacob: mp4 is missing from the mimetypes.py list of valid mimetypes. mp4 is registered with IANA and is defined in the mpeg-4 standard as a container for mpeg-4 codecs such as h264. Lack of this definition means the format cannot be recognised by software dependsing on the mimetypes modules, that don't use one of the suggested local mime definitions (OpenBSD). ---------- components: Library (Lib) files: mimetypes.py.patch messages: 56900 nosy: kraft severity: normal status: open title: mp4 missing from mimetypes.py type: rfe versions: Python 2.1.1, Python 2.1.2, Python 2.2, Python 2.2.1, Python 2.2.2, Python 2.2.3, Python 2.3, Python 2.4, Python 2.5 Added file: http://bugs.python.org/file8649/mimetypes.py.patch __________________________________ Tracker __________________________________ -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: mimetypes.py.patch Url: http://mail.python.org/pipermail/python-bugs-list/attachments/20071029/7f67641f/attachment.txt From report at bugs.python.org Mon Oct 29 12:16:05 2007 From: report at bugs.python.org (Raja R) Date: Mon, 29 Oct 2007 11:16:05 -0000 Subject: [issue1354] windows installer problem Message-ID: <1193656564.93.0.383203609595.issue1354@psf.upfronthosting.co.za> New submission from Raja R: Hi, I downloaded the python-2.5.msi yesterday and tried installing it but i am getting the following error "This installation package could not be opened . cOntact the application vendor to verify that this is a valid WIndows Installer package." I was able to install python 2.4.4 successfully in my system. I want python 2.5 urgently as I need to work in PyQt. My machine config is: Microsoft Windows XP, Media Center Edition Version 2002, Service Pack 2. Please advice on this problem at the earliest. Thanks, Raja. ---------- components: Installation messages: 56901 nosy: rajar severity: urgent status: open title: windows installer problem versions: Python 2.5 __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Oct 29 13:23:02 2007 From: report at bugs.python.org (whooey1830) Date: Mon, 29 Oct 2007 12:23:02 -0000 Subject: [issue1355] xml.dom refers to PyXML, which is no longer maintained Message-ID: <1193660582.0.0.373333913487.issue1355@psf.upfronthosting.co.za> New submission from whooey1830: http://docs.python.org/dev/library/xml.dom.html#module-xml.dom "PyXML Users that require a full-featured implementation of DOM should use the PyXML package." PyXML however is no longer maintained. Is it a wise idea to link to that resource? Novice users might trust blindly, before finding out about the restrictions they are going to face (maintainence, code fixes..) I suggest adding at least information, that no code fixes are being done, but documentation on the pyxml website is still updated (Thats how i've understood their website. Please correct me if i am wrong. I'm feeling a bit frustrated having spent time with a package, which is no longer maintained, to be honest.) ---------- components: Documentation messages: 56902 nosy: whooey1830 severity: normal status: open title: xml.dom refers to PyXML, which is no longer maintained versions: Python 2.5 __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Oct 29 13:59:31 2007 From: report at bugs.python.org (David Ripton) Date: Mon, 29 Oct 2007 12:59:31 -0000 Subject: [issue1183] race in SocketServer.ForkingMixIn.collect_children Message-ID: <1193662771.38.0.731341295623.issue1183@psf.upfronthosting.co.za> David Ripton added the comment: No signal handler. Yes, we run subprocesses. I don't believe either is necessary to trigger the race condition, though. __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Oct 29 14:04:11 2007 From: report at bugs.python.org (Tal Einat) Date: Mon, 29 Oct 2007 13:04:11 -0000 Subject: [issue1612746] Enhanced tabbed pane widget Message-ID: <1193663051.2.0.243403674228.issue1612746@psf.upfronthosting.co.za> Tal Einat added the comment: Update, as requested. After the recent configDialog.py changes, very little changes to it are required. I've included a much updated version of tabbedPages.py in this patch. Since posting the original patch, I've discovered and fixed a few bugs, implemented a 3d look for the tabs, and cleaned up the code. This version has also been tested more thoroughly. Also, this version very nicely supports tabbed panes with more than one row of tabs. However you can't see this with configDialog.py, you'll have to use the test code to check it out (just add several new pages and then play around with them). I've used this feature in implementing the extension config dialog, where every extension gets its own tab. I hope I can finally get to posting a patch for it... Enjoy! Added file: http://bugs.python.org/file8650/IDLE_tabbedPages.071029.patch _____________________________________ Tracker _____________________________________ -------------- next part -------------- A non-text attachment was scrubbed... Name: IDLE_tabbedPages.071029.patch Type: application/octet-stream Size: 21637 bytes Desc: not available Url : http://mail.python.org/pipermail/python-bugs-list/attachments/20071029/e351f386/attachment-0001.obj From report at bugs.python.org Mon Oct 29 14:31:13 2007 From: report at bugs.python.org (Raghuram Devarakonda) Date: Mon, 29 Oct 2007 13:31:13 -0000 Subject: [issue1354] windows installer problem Message-ID: <1193664673.54.0.811222562065.issue1354@psf.upfronthosting.co.za> Raghuram Devarakonda added the comment: I installed python 2.5 on multiple windows machines and had no problem. How ever, this doesn't look like it belongs in bug tracker. You will have better chance if you post to comp.lang.python. ---------- nosy: +draghuram __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Oct 29 16:26:39 2007 From: report at bugs.python.org (Kevin Watters) Date: Mon, 29 Oct 2007 15:26:39 -0000 Subject: [issue1320] PCBuild8 Solution Support Changes Message-ID: <1193671599.34.0.807499555927.issue1320@psf.upfronthosting.co.za> Kevin Watters added the comment: This patch did not work for me. After running build_ssl.bat, the last couple lines of my console are: cl /Fotmp32dll\cfb_enc.obj -Iinc32 -Itmp32dll /MD /Ox /O2 /Ob2 /W3 /WX /Gs0 /GF /Gy /nologo -DOPENSSL_SYSNAME_WIN32 -DWIN32_LEAN_AND_MEAN -DL_ENDIAN -D DSO_WIN32 -D_CRT_SECURE_NO_DEPRECATE -DBN_ASM -DMD5_ASM -DSHA1_ASM -DRMD160_ASM -DOPENSSL_USE_APPLINK -I. /Fdout32dll -DOPENSSL_NO_IDEA -DOPENSSL_NO_RC5 -DOPENS SL_NO_MDC2 -DOPENSSL_NO_KRB5 -D_WINDLL -DOPENSSL_BUILD_SHLIBCRYPTO -c .\crypto\ des\cfb_enc.c cfb_enc.c cl /Fotmp32dll\ofb64ede.obj -Iinc32 -Itmp32dll /MD /Ox /O2 /Ob2 /W3 /WX /Gs0 /GF /Gy /nologo -DOPENSSL_SYSNAME_WIN32 -DWIN32_LEAN_AND_MEAN -DL_ENDIAN - DDSO_WIN32 -D_CRT_SECURE_NO_DEPRECATE -DBN_ASM -DMD5_ASM -DSHA1_ASM -DRMD160_ASM -DOPENSSL_USE_APPLINK -I. /Fdout32dll -DOPENSSL_NO_IDEA -DOPENSSL_NO_RC5 -DOPEN SSL_NO_MDC2 -DOPENSSL_NO_KRB5 -D_WINDLL -DOPENSSL_BUILD_SHLIBCRYPTO -c .\crypto \des\ofb64ede.c ofb64ede.c cl /Fotmp32dll\enc_read.obj -Iinc32 -Itmp32dll /MD /Ox /O2 /Ob2 /W3 /WX /Gs0 /GF /Gy /nologo -DOPENSSL_SYSNAME_WIN32 -DWIN32_LEAN_AND_MEAN -DL_ENDIAN - DDSO_WIN32 -D_CRT_SECURE_NO_DEPRECATE -DBN_ASM -DMD5_ASM -DSHA1_ASM -DRMD160_ASM -DOPENSSL_USE_APPLINK -I. /Fdout32dll -DOPENSSL_NO_IDEA -DOPENSSL_NO_RC5 -DOPEN SSL_NO_MDC2 -DOPENSSL_NO_KRB5 -D_WINDLL -DOPENSSL_BUILD_SHLIBCRYPTO -c .\crypto \des\enc_read.c enc_read.c .\crypto\des\enc_read.c(150) : error C2220: warning treated as error - no 'objec t' file generated .\crypto\des\enc_read.c(150) : warning C4996: 'read' was declared deprecated C:\Program Files\Microsoft Visual Studio 8\VC\INCLUDE\io.h(329) : see de claration of 'read' Message: 'The POSIX name for this item is deprecated. Instead, use the I SO C++ conformant name: _read. See online help for details.' .\crypto\des\enc_read.c(172) : warning C4996: 'read' was declared deprecated C:\Program Files\Microsoft Visual Studio 8\VC\INCLUDE\io.h(329) : see de claration of 'read' Message: 'The POSIX name for this item is deprecated. Instead, use the I SO C++ conformant name: _read. See online help for details.' NMAKE : fatal error U1077: '"C:\Program Files\Microsoft Visual Studio 8\VC\BIN\c l.EXE"' : return code '0x2' Stop. Executing ms\ntdll.mak failed 2 ---------- nosy: +kevinwatters __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Oct 29 16:58:21 2007 From: report at bugs.python.org (Christian Heimes) Date: Mon, 29 Oct 2007 15:58:21 -0000 Subject: [issue1320] PCBuild8 Solution Support Changes Message-ID: <1193673501.21.0.953675483387.issue1320@psf.upfronthosting.co.za> Christian Heimes added the comment: Kevin, It's a known issue which is solved in newer version of OpenSSL. I hope to convince somebody to update the packages someday. ---------- nosy: +tiran __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Oct 29 17:35:45 2007 From: report at bugs.python.org (Jean Brouwers) Date: Mon, 29 Oct 2007 16:35:45 -0000 Subject: [issue1356] 3.0a1 Solaris w/ SUN C/C++ Message-ID: <1193675745.64.0.802991254571.issue1356@psf.upfronthosting.co.za> New submission from Jean Brouwers: Building 3.0a1 on Solaris 10 using SUN's C/C++ compilers fails due to one compilation error. The problem is the name of the last argument 'restrict' of function analyze_cells on line 473 in file Python/symtable.c. Changing that name to something else like 'restricted' makes the build build. There is an '*** Error code 1' at the very end of make test, but that is a separate issue. The ./configure command line needs to include the options --without-gcc and --with-cxx-main=CC. This is Solaris 10 on an Ultra 20 (Opteron) machine with SUN C/C++ 5.8 2005/10/13. ---------- components: Build messages: 56908 nosy: MrJean1 severity: normal status: open title: 3.0a1 Solaris w/ SUN C/C++ type: compile error versions: Python 3.0 __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Oct 29 17:38:16 2007 From: report at bugs.python.org (Isaac Morland) Date: Mon, 29 Oct 2007 16:38:16 -0000 Subject: [issue1462525] URI parsing library Message-ID: <1193675896.48.0.0706475211523.issue1462525@psf.upfronthosting.co.za> Isaac Morland added the comment: This is probably overkill, but I've created a Python script (attached) that runs all the tests given in Section 5.4 of RFC 3986. It reports the following: baseurl=http://a/b/c/d;p?q failed for ?y: got http://a/b/c/?y, expected http://a/b/c/d;p?y failed for ../../../g: got http://a/../g, expected http://a/g failed for ../../../../g: got http://a/../../g, expected http://a/g failed for /./g: got http://a/./g, expected http://a/g failed for /../g: got http://a/../g, expected http://a/g failed for http:g: got http://a/b/c/g, expected http:g The last of these is sanctioned by the RFC as acceptable for backward compatibility, so I'll ignore that. The remainder suggest that in addition to the query-relative bug, there is a problem with not reducing "/./" to just "/", and with dropping excess occurrences of ".." that would go above the root. On the other hand, these additional issues are listed in the RFC as "abnormal" so I'm not sure if people are going to want to put in the time to address them. ---------- nosy: +ijmorlan Added file: http://bugs.python.org/file8651/testurlparse.py _____________________________________ Tracker _____________________________________ -------------- next part -------------- A non-text attachment was scrubbed... Name: testurlparse.py Type: application/octet-stream Size: 1600 bytes Desc: not available Url : http://mail.python.org/pipermail/python-bugs-list/attachments/20071029/b7464c4c/attachment.obj From report at bugs.python.org Mon Oct 29 18:08:03 2007 From: report at bugs.python.org (Jean Brouwers) Date: Mon, 29 Oct 2007 17:08:03 -0000 Subject: [issue1357] 3.0a1 make test Error on Solaris w/ SUN C/C++ Message-ID: <1193677683.71.0.404085069091.issue1357@psf.upfronthosting.co.za> New submission from Jean Brouwers: The 3.0a1 Solaris build (see issue #1356) fails at the end of make test with the following error: .... test_zlib 278 tests OK. 5 tests failed: test_cookielib test_email test_fileio test_pipes test_uuid 39 tests skipped: test_aepack test_applesingle test_bsddb test_bsddb3 test_codecmaps_cn test_codecmaps_hk test_codecmaps_jp test_codecmaps_kr test_codecmaps_tw test_ctypes test_curses test_gdbm test_hashlib test_hmac test_macostools test_normalization test_ossaudiodev test_pep277 test_plistlib test_scriptpackages test_socket_ssl test_socketserver test_sqlite test_ssl test_startfile test_sundry test_tarfile test_tcl test_timeout test_unicode_file test_unicodedata test_urllib2 test_urllib2_localnet test_urllib2net test_urllibnet test_winreg test_winsound test_xmlrpc_net test_zipfile64 11 skips unexpected on sunos5: test_hashlib test_hmac test_urllib2_localnet test_urllib2net test_ctypes test_urllib2 test_tcl test_sundry test_ssl test_tarfile test_unicodedata *** Error code 1 make: Fatal error: Command failed for target `test' The entire log of make test is attached. If you need other make or configure logs or if I should rebuild with other options, let me know. ---------- components: Tests files: log.make_test messages: 56910 nosy: MrJean1 severity: normal status: open title: 3.0a1 make test Error on Solaris w/ SUN C/C++ versions: Python 3.0 Added file: http://bugs.python.org/file8652/log.make_test __________________________________ Tracker __________________________________ -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: log.make_test Url: http://mail.python.org/pipermail/python-bugs-list/attachments/20071029/e356c028/attachment-0001.txt From report at bugs.python.org Mon Oct 29 18:16:42 2007 From: report at bugs.python.org (Guido van Rossum) Date: Mon, 29 Oct 2007 17:16:42 -0000 Subject: [issue1340] correction for test_tempfile in py3k on Windows Message-ID: <1193678202.15.0.606997110382.issue1340@psf.upfronthosting.co.za> Guido van Rossum added the comment: New Revision: 58701. ---------- status: open -> closed __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Oct 29 18:17:41 2007 From: report at bugs.python.org (Tal Einat) Date: Mon, 29 Oct 2007 17:17:41 -0000 Subject: [issue1612746] Enhanced tabbed pane widget Message-ID: <1193678261.61.0.391924674005.issue1612746@psf.upfronthosting.co.za> Tal Einat added the comment: Bah, sorry, included wrong version of tabbedPages.py in the previous patch. (differences are very minor, just some code cleanup and one very minor bug) Added file: http://bugs.python.org/file8653/IDLE_tabbedPages.071029.patch _____________________________________ Tracker _____________________________________ -------------- next part -------------- A non-text attachment was scrubbed... Name: IDLE_tabbedPages.071029.patch Type: application/octet-stream Size: 21539 bytes Desc: not available Url : http://mail.python.org/pipermail/python-bugs-list/attachments/20071029/6eb1c35c/attachment-0001.obj From report at bugs.python.org Mon Oct 29 18:33:51 2007 From: report at bugs.python.org (Tal Einat) Date: Mon, 29 Oct 2007 17:33:51 -0000 Subject: [issue1252] IDLE - patch Delegator to support callables Message-ID: <1193679231.69.0.826069638441.issue1252@psf.upfronthosting.co.za> Tal Einat added the comment: I'm trying to keep this as simple as possible, because it seems we're tending to over-complicate. We're discussing two distinct issues: 1) Should Delegator delegate calls to callables 2) Should Percolator inherit from Delegator Have I missed something? Regarding the first issue, I do think Delegator should do this, because I view calling a callable as a special case of calling a method. To illustrate my point, please take the code in example1.py, run it once with Delegator as it is, and run it again after adding the __call__ method to Delegator's definition. Regarding the second issue, I don't think I can put my thoughts better than I already have: As for Percolator, it really "is a" delegator -- it delegates attribute access to the bottom of the chain, unless it is explicitly overridden. True, in a "normal" Delegator this overriding can only be done in one place, and in a Percolator it can also happen in any of the chain's links. But the concept is identical -- it is a transparent proxy for an underlying object. Added file: http://bugs.python.org/file8654/example1.py __________________________________ Tracker __________________________________ -------------- next part -------------- A non-text attachment was scrubbed... Name: example1.py Type: text/x-python Size: 534 bytes Desc: not available Url : http://mail.python.org/pipermail/python-bugs-list/attachments/20071029/225545af/attachment.py From report at bugs.python.org Mon Oct 29 18:35:19 2007 From: report at bugs.python.org (Guido van Rossum) Date: Mon, 29 Oct 2007 17:35:19 -0000 Subject: [issue1339] smtplib starttls() should ehlo() if it needs to Message-ID: <1193679319.08.0.54484973582.issue1339@psf.upfronthosting.co.za> Guido van Rossum added the comment: You'll get more traction on this if you submit a patch. ---------- nosy: +gvanrossum __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Oct 29 18:40:14 2007 From: report at bugs.python.org (Guido van Rossum) Date: Mon, 29 Oct 2007 17:40:14 -0000 Subject: [issue1341] correction for test_fileinput in py3k on Windows Message-ID: <1193679614.96.0.450606126486.issue1341@psf.upfronthosting.co.za> Guido van Rossum added the comment: Thanks, good catch! Committed revision 58704. (in the py3k branch) ---------- nosy: +gvanrossum resolution: -> accepted status: open -> closed __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Oct 29 18:44:29 2007 From: report at bugs.python.org (Guido van Rossum) Date: Mon, 29 Oct 2007 17:44:29 -0000 Subject: [issue1348] httplib closes socket, then tries to read from it Message-ID: <1193679869.64.0.112659604421.issue1348@psf.upfronthosting.co.za> Guido van Rossum added the comment: I don't think that patch is the right thing either. Certainly the comment on the line you're proposing to delete is suggesting that the close() call was added for a reason. ---------- nosy: +gvanrossum __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Oct 29 18:51:50 2007 From: report at bugs.python.org (Guido van Rossum) Date: Mon, 29 Oct 2007 17:51:50 -0000 Subject: [issue1345] Fix for test_netrc on Windows Message-ID: <1193680310.07.0.198103455549.issue1345@psf.upfronthosting.co.za> Guido van Rossum added the comment: Are you sure this is the proper fix? Why does netrc.py insist on not having \r\n line endings? It opens the file in text mode so I don't quite understand your patch. ---------- nosy: +gvanrossum __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Oct 29 18:52:55 2007 From: report at bugs.python.org (Christian Heimes) Date: Mon, 29 Oct 2007 17:52:55 -0000 Subject: [issue1357] 3.0a1 make test Error on Solaris w/ SUN C/C++ Message-ID: <1193680375.82.0.972390630089.issue1357@psf.upfronthosting.co.za> Christian Heimes added the comment: Please run the test suite in verbose mode and attach the output: $ ./python Lib/test/regrtest.py -v test_cookielib test_email test_fileio test_pipes test_uuid You seem to missing some packages to build additional extensions. Can you install sqlite, openssl, readline, TCL/TK, curses and BSDDB? ---------- nosy: +tiran __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Oct 29 18:54:34 2007 From: report at bugs.python.org (Guido van Rossum) Date: Mon, 29 Oct 2007 17:54:34 -0000 Subject: [issue1347] BaseHTTPServer writing strings to bytes interface Message-ID: <1193680474.51.0.40010722096.issue1347@psf.upfronthosting.co.za> Guido van Rossum added the comment: Looks good. You can check this in yourself right? ---------- assignee: -> janssen nosy: +gvanrossum resolution: -> accepted __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Oct 29 18:58:57 2007 From: report at bugs.python.org (Guido van Rossum) Date: Mon, 29 Oct 2007 17:58:57 -0000 Subject: [issue1349] more uses of ord() in plat-mac/ic.py Message-ID: <1193680737.61.0.911885182828.issue1349@psf.upfronthosting.co.za> Guido van Rossum added the comment: Looks good, though I can't find anything that would test this. Can you check this in yourself? ---------- assignee: nnorwitz -> janssen nosy: +gvanrossum __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Oct 29 19:14:49 2007 From: report at bugs.python.org (andres) Date: Mon, 29 Oct 2007 18:14:49 -0000 Subject: [issue1358] Compile error on OS X 10.5 Message-ID: <1193681689.41.0.805287335304.issue1358@psf.upfronthosting.co.za> New submission from andres: Compiling python 2.5.1 on Mac OS X 10.5 (Leopard) fails with the following message: gcc -fno-strict-aliasing -Wno-long-double -no-cpp-precomp -mno-fused-madd -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. -I./Include -DPy_BUILD_CORE -c ./Modules/posixmodule.c -o Modules/posixmodule.o ./Modules/posixmodule.c: In function ?posix_setpgrp?: ./Modules/posixmodule.c:3592: error: too few arguments to function ?setpgrp? make: *** [Modules/posixmodule.o] Error 1 I am also attaching the output of the configuration script. ---------- components: Macintosh files: configure.txt messages: 56921 nosy: andres severity: major status: open title: Compile error on OS X 10.5 type: compile error versions: Python 2.5 Added file: http://bugs.python.org/file8655/configure.txt __________________________________ Tracker __________________________________ -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: configure.txt Url: http://mail.python.org/pipermail/python-bugs-list/attachments/20071029/ecf79fa2/attachment.txt From report at bugs.python.org Mon Oct 29 20:33:11 2007 From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=) Date: Mon, 29 Oct 2007 19:33:11 -0000 Subject: [issue1354] windows installer problem Message-ID: <1193686391.25.0.493530919476.issue1354@psf.upfronthosting.co.za> Martin v. L?wis added the comment: Indeed, this tracker is not about obtaining support. It is a place for you to help us, not for us to help you. If you want to help, please report the precise URL, and compute and report the md5sum of the file you downloaded. ---------- nosy: +loewis __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Oct 29 20:34:43 2007 From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=) Date: Mon, 29 Oct 2007 19:34:43 -0000 Subject: [issue1355] xml.dom refers to PyXML, which is no longer maintained Message-ID: <1193686483.87.0.826743357951.issue1355@psf.upfronthosting.co.za> Martin v. L?wis added the comment: Yes, the documentation should be changed. I feel sorry that you've wasted your time. ---------- nosy: +loewis __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Oct 29 20:54:47 2007 From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=) Date: Mon, 29 Oct 2007 19:54:47 -0000 Subject: [issue1356] 3.0a1 Solaris w/ SUN C/C++ Message-ID: <1193687687.49.0.836561881123.issue1356@psf.upfronthosting.co.za> Martin v. L?wis added the comment: Thanks for the report. Fixed in r58705. ---------- nosy: +loewis __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Oct 29 21:00:53 2007 From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=) Date: Mon, 29 Oct 2007 20:00:53 -0000 Subject: [issue1358] Compile error on OS X 10.5 Message-ID: <1193688053.98.0.705650347605.issue1358@psf.upfronthosting.co.za> Martin v. L?wis added the comment: Can you please also attach config.log (perhaps compressed)? ---------- nosy: +loewis __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Oct 29 21:14:33 2007 From: report at bugs.python.org (Guido van Rossum) Date: Mon, 29 Oct 2007 20:14:33 -0000 Subject: [issue1352] Preliminary stderr patch Message-ID: <1193688873.3.0.914230657363.issue1352@psf.upfronthosting.co.za> Changes by Guido van Rossum: ---------- assignee: -> gvanrossum priority: -> high __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Oct 29 21:14:49 2007 From: report at bugs.python.org (Guido van Rossum) Date: Mon, 29 Oct 2007 20:14:49 -0000 Subject: [issue1171] allow subclassing of bytes type Message-ID: <1193688889.76.0.472401586493.issue1171@psf.upfronthosting.co.za> Changes by Guido van Rossum: ---------- priority: normal -> high __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Oct 29 21:23:52 2007 From: report at bugs.python.org (Guido van Rossum) Date: Mon, 29 Oct 2007 20:23:52 -0000 Subject: [issue1329] Different 3.0a1 exit behavior Message-ID: <1193689432.21.0.369962040535.issue1329@psf.upfronthosting.co.za> Changes by Guido van Rossum: ---------- assignee: -> gvanrossum __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Oct 29 21:27:59 2007 From: report at bugs.python.org (Ralf Schmitt) Date: Mon, 29 Oct 2007 20:27:59 -0000 Subject: [issue1089358] need siginterrupt() on Linux - impossible to do timeouts Message-ID: <1193689679.59.0.696609079872.issue1089358@psf.upfronthosting.co.za> Ralf Schmitt added the comment: here is a patch against 2.5.1 Added file: http://bugs.python.org/file8657/patch _____________________________________ Tracker _____________________________________ -------------- next part -------------- A non-text attachment was scrubbed... Name: patch Type: application/octet-stream Size: 1578 bytes Desc: not available Url : http://mail.python.org/pipermail/python-bugs-list/attachments/20071029/64602606/attachment.obj From report at bugs.python.org Mon Oct 29 21:49:12 2007 From: report at bugs.python.org (Guido van Rossum) Date: Mon, 29 Oct 2007 20:49:12 -0000 Subject: [issue1351] Add getsize() to io instances Message-ID: <1193690951.97.0.259734151069.issue1351@psf.upfronthosting.co.za> Guido van Rossum added the comment: I'm -1 myself. I've rarely needed this -- if I wanted to know the size, I was almost always going to read the data into memory anyway, so why not just read it and then ask how much you got? For files on the filesystem there's os.path.getsize(). If I ever were to let this in, here's some more criticism: (a) the SizeInfo class is overkill. getsize() should just return an int. (b) getsize() should check self.seekable() first and raise the appropriate error if the file isn't seekable. (c) os.fstat() is much less likely to work than the tell-seek-tell-seek sequence, so why not use that everywhere? (d) people will expect to use this on text files, but of course the outcome will be in bytes, hence useless. ---------- nosy: +gvanrossum __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Oct 29 21:53:27 2007 From: report at bugs.python.org (Guido van Rossum) Date: Mon, 29 Oct 2007 20:53:27 -0000 Subject: [issue1353] mp4 missing from mimetypes.py Message-ID: <1193691207.72.0.839161227702.issue1353@psf.upfronthosting.co.za> Guido van Rossum added the comment: Committed revision 58706. This is in the trunk, i.e. what will become Python 2.6. I don't think it's worth fixing in 2.5.2, but if you really think it should go there as well, petition Neal Norwitz. ---------- nosy: +gvanrossum resolution: -> accepted status: open -> closed __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Oct 29 21:55:31 2007 From: report at bugs.python.org (Guido van Rossum) Date: Mon, 29 Oct 2007 20:55:31 -0000 Subject: [issue1356] 3.0a1 Solaris w/ SUN C/C++ Message-ID: <1193691331.6.0.665708090849.issue1356@psf.upfronthosting.co.za> Changes by Guido van Rossum: ---------- resolution: -> accepted status: open -> closed __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Oct 29 21:56:59 2007 From: report at bugs.python.org (Guido van Rossum) Date: Mon, 29 Oct 2007 20:56:59 -0000 Subject: [issue1357] 3.0a1 make test Error on Solaris w/ SUN C/C++ Message-ID: <1193691419.06.0.576042839915.issue1357@psf.upfronthosting.co.za> Guido van Rossum added the comment: If this report is simply due to the lack of certain required packages, can it just be closed as invalid? ---------- nosy: +gvanrossum __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Oct 29 22:02:55 2007 From: report at bugs.python.org (Jean Brouwers) Date: Mon, 29 Oct 2007 21:02:55 -0000 Subject: [issue1357] 3.0a1 make test Error on Solaris w/ SUN C/C++ Message-ID: <1193691775.62.0.202890717831.issue1357@psf.upfronthosting.co.za> Jean Brouwers added the comment: Close it for now. Once I have the missing packages installed I will try again. My main concern was not the actual test failures, but the make test *** Error 1 ... itself. __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Oct 29 22:21:29 2007 From: report at bugs.python.org (Amaury Forgeot d'Arc) Date: Mon, 29 Oct 2007 21:21:29 -0000 Subject: [issue1359] py3k: out of bounds read in PyUnicode_DecodeUnicodeEscape Message-ID: <1193692889.31.0.0582486390862.issue1359@psf.upfronthosting.co.za> New submission from Amaury Forgeot d'Arc: A correction for the problem found by GvR in change 58692: > There's one mystery: if I remove ob_sstate from the PyStringObject struct, > some (unicode) string literals are mutilated, e.g. ('\\1', '\1') prints > ('\\1', '\t'). This must be an out of bounds write or something that I > can't track down. (It doesn't help that it doesn't occur in debug mode. > And no, make clean + recompilation doesn't help either.) > > So, in the mean time, I just keep the field, renamed to 'ob_placeholder'. I think I found the problem. It reproduces on Windows, with a slightly different input >>> ('\\2','\1') ('\\2', '\n') (the win32 release build is of the kind "optimized with debug info", so using the debugger is possible) The problem is in unicodeobject.c::PyUnicode_DecodeUnicodeEscape: - the input buffer is not null-terminated - when decoding octal escape, we increment s without checking if it is still in the limits. In my case, the "\1" was followed by a "2" in memory, hence the bogus chr(0o12) == '\n'. Also corrected a potential problem when the string ends with a \: PyUnicode_DecodeUnicodeEscape("\\t", 1) should return an error. ---------- components: Interpreter Core files: unicodeEscape.diff messages: 56933 nosy: amaury.forgeotdarc, gvanrossum severity: normal status: open title: py3k: out of bounds read in PyUnicode_DecodeUnicodeEscape versions: Python 3.0 Added file: http://bugs.python.org/file8658/unicodeEscape.diff __________________________________ Tracker __________________________________ -------------- next part -------------- A non-text attachment was scrubbed... Name: unicodeEscape.diff Type: application/octet-stream Size: 1688 bytes Desc: not available Url : http://mail.python.org/pipermail/python-bugs-list/attachments/20071029/a1541f32/attachment.obj From report at bugs.python.org Mon Oct 29 22:27:59 2007 From: report at bugs.python.org (Guido van Rossum) Date: Mon, 29 Oct 2007 21:27:59 -0000 Subject: [issue1357] 3.0a1 make test Error on Solaris w/ SUN C/C++ Message-ID: <1193693279.03.0.935672295013.issue1357@psf.upfronthosting.co.za> Guido van Rossum added the comment: Closing. The make fatal error is just what make prints when a command fails with a nonzero exit code; regrtest.py returns a nonzero exit code to the shell for just this purpose. ---------- resolution: -> invalid status: open -> closed __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Oct 29 22:45:50 2007 From: report at bugs.python.org (Guido van Rossum) Date: Mon, 29 Oct 2007 21:45:50 -0000 Subject: [issue1359] py3k: out of bounds read in PyUnicode_DecodeUnicodeEscape Message-ID: <1193694350.1.0.183283539701.issue1359@psf.upfronthosting.co.za> Guido van Rossum added the comment: Thanks!! The patch as given doesn't quite work -- it gives an error message on string literals like '\s'. By reverting some of your code and only keeping the bounds checks for the octal escape code I got it to work though. See my checkin. Committed revision 58707. This needs to be backported too; it seems a pure coincidence it didn't trigger before! ---------- assignee: -> gvanrossum resolution: -> accepted status: open -> closed __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Oct 29 22:50:49 2007 From: report at bugs.python.org (andres) Date: Mon, 29 Oct 2007 21:50:49 -0000 Subject: [issue1358] Compile error on OS X 10.5 In-Reply-To: <1193688053.98.0.705650347605.issue1358@psf.upfronthosting.co.za> Message-ID: <0043F4DD-7217-41A6-9141-5BC11355ED98@octopart.com> andres added the comment: I've attached a compressed config.log. Incidentally, we were able to get Python to compile by appending the following line to pyconfig.h: #define SETPGRP_HAVE_ARG -Andres On Oct 29, 2007, at 1:00 PM, Martin v. L?wis wrote: > > Martin v. L?wis added the comment: > > Can you please also attach config.log (perhaps compressed)? > > ---------- > nosy: +loewis > > __________________________________ > Tracker > > __________________________________ Added file: http://bugs.python.org/file8659/unnamed Added file: http://bugs.python.org/file8660/config.log.gz Added file: http://bugs.python.org/file8661/unnamed __________________________________ Tracker __________________________________ -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: unnamed Url: http://mail.python.org/pipermail/python-bugs-list/attachments/20071029/a7c06766/attachment-0002.txt -------------- next part -------------- A non-text attachment was scrubbed... Name: config.log.gz Type: application/x-gzip Size: 22415 bytes Desc: not available Url : http://mail.python.org/pipermail/python-bugs-list/attachments/20071029/a7c06766/attachment-0001.bin -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: unnamed Url: http://mail.python.org/pipermail/python-bugs-list/attachments/20071029/a7c06766/attachment-0003.txt From report at bugs.python.org Mon Oct 29 22:58:39 2007 From: report at bugs.python.org (Guido van Rossum) Date: Mon, 29 Oct 2007 21:58:39 -0000 Subject: [issue1359] py3k: out of bounds read in PyUnicode_DecodeUnicodeEscape Message-ID: <1193695119.73.0.852409514841.issue1359@psf.upfronthosting.co.za> Guido van Rossum added the comment: (Hold on, the assert I added triggers in debug mode.) ---------- status: closed -> open __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Oct 29 23:01:58 2007 From: report at bugs.python.org (Amaury Forgeot d'Arc) Date: Mon, 29 Oct 2007 22:01:58 -0000 Subject: [issue1359] py3k: out of bounds read in PyUnicode_DecodeUnicodeEscape Message-ID: <1193695318.17.0.927279727342.issue1359@psf.upfronthosting.co.za> Amaury Forgeot d'Arc added the comment: I don't like this assert either: this function is part of the public API, and should not crash the interpreter just because of a trailing \. To test easily: import ctypes decode = ctypes.pythonapi.PyUnicodeUCS2_DecodeUnicodeEscape decode.restype = ctypes.py_object decode(b'\\1', 1, None) This should gently raise a UnicodeDecodeError IMO. __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Oct 29 23:08:51 2007 From: report at bugs.python.org (Guido van Rossum) Date: Mon, 29 Oct 2007 22:08:51 -0000 Subject: [issue1359] py3k: out of bounds read in PyUnicode_DecodeUnicodeEscape Message-ID: <1193695731.75.0.181761484904.issue1359@psf.upfronthosting.co.za> Guido van Rossum added the comment: Better fix: Committed revision 58708. __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Oct 30 00:08:29 2007 From: report at bugs.python.org (Bill Janssen) Date: Mon, 29 Oct 2007 23:08:29 -0000 Subject: [issue1349] more uses of ord() in plat-mac/ic.py In-Reply-To: <1193680737.61.0.911885182828.issue1349@psf.upfronthosting.co.za> Message-ID: <4b3e516a0710291608m67adee75q8f45891ac740ae2a@mail.gmail.com> Bill Janssen added the comment: I've been testing it over the weekend. Will do. Bill On 10/29/07, Guido van Rossum wrote: > > Guido van Rossum added the comment: > > Looks good, though I can't find anything that would test this. > > Can you check this in yourself? > > ---------- > assignee: nnorwitz -> janssen > nosy: +gvanrossum > > __________________________________ > Tracker > > __________________________________ > __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Oct 30 00:08:48 2007 From: report at bugs.python.org (Bill Janssen) Date: Mon, 29 Oct 2007 23:08:48 -0000 Subject: [issue1347] BaseHTTPServer writing strings to bytes interface In-Reply-To: <1193680474.51.0.40010722096.issue1347@psf.upfronthosting.co.za> Message-ID: <4b3e516a0710291608o7ab84f6dwb5e230a4a91b5eca@mail.gmail.com> Bill Janssen added the comment: Will do. On 10/29/07, Guido van Rossum wrote: > > Guido van Rossum added the comment: > > Looks good. You can check this in yourself right? > > ---------- > assignee: -> janssen > nosy: +gvanrossum > resolution: -> accepted > > __________________________________ > Tracker > > __________________________________ > __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Oct 30 01:06:30 2007 From: report at bugs.python.org (Daniele Varrazzo) Date: Tue, 30 Oct 2007 00:06:30 -0000 Subject: [issue1360] Queue.get() can't be interrupted with Ctrl-C unless timed out Message-ID: <1193702790.06.0.592600873674.issue1360@psf.upfronthosting.co.za> New submission from Daniele Varrazzo: This issue probably depends on #1167930 When waiting on a queue in blocking mode, in no timeout is set, ctrl-C doesn't raise KeyboardInterrupt:: q = Queue() q.get(True) # ctrl-c doesn't work here If any timeout is set, ctrl-c works as expected:: q = Queue() ONEYEAR = 365 * 24 * 60 * 60 q.get(True, ONEYEAR) # ctrl-c works here Traceback (most recent call last): File "queuebug.py", line 6, in q.get(True, ONEYEAR) File "/usr/lib/python2.5/Queue.py", line 174, in get self.not_empty.wait(remaining) File "/usr/lib/python2.5/threading.py", line 233, in wait _sleep(delay) KeyboardInterrupt ---------- components: Library (Lib) messages: 56942 nosy: piro severity: normal status: open title: Queue.get() can't be interrupted with Ctrl-C unless timed out type: behavior versions: Python 2.5 __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Oct 30 01:29:36 2007 From: report at bugs.python.org (Guido van Rossum) Date: Tue, 30 Oct 2007 00:29:36 -0000 Subject: [issue1352] Preliminary stderr patch Message-ID: <1193704176.56.0.899417191845.issue1352@psf.upfronthosting.co.za> Guido van Rossum added the comment: Good idea. Are there any places where PyBytes or PyString are written to stderr? Or can you get away with just supporting PyUnicode? It's "dumb", not "dump". I wouldn't explicitly remove the old stderr printer -- it will be deleted automatically by the PyDict_SetItemString() call in PySys_SetObject(). That way you'll still have it when the PyFile_FromFd() call fails... This patch doesn't commute with your 'closefd' patch... __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Oct 30 01:29:54 2007 From: report at bugs.python.org (Guido van Rossum) Date: Tue, 30 Oct 2007 00:29:54 -0000 Subject: [issue1359] py3k: out of bounds read in PyUnicode_DecodeUnicodeEscape Message-ID: <1193704194.79.0.684561434661.issue1359@psf.upfronthosting.co.za> Changes by Guido van Rossum: ---------- status: open -> closed __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Oct 30 01:42:26 2007 From: report at bugs.python.org (Guido van Rossum) Date: Tue, 30 Oct 2007 00:42:26 -0000 Subject: [issue1329] Different 3.0a1 exit behavior Message-ID: <1193704946.42.0.939603638817.issue1329@psf.upfronthosting.co.za> Guido van Rossum added the comment: Thanks!! Code review: Shouldn't closefd be passed as 1 in import.c? I don't see the point of distinguishing between -1 and +1. The block "if (closefd < 0) { closefd = 1; }" looks rather silly. In io.py, you should document that closefd must not be False when a filename is given. I think in _fileio.c, you can insist that the closefd argument is an int (a bool will work anyway, as bool is a subclass of int). I don't think we should warn when trying to close an unclosable fd; it should really just be a no-op. Also, if you are going to call PyErr_WarnEx(), you should test its return value (it can raise an exception!). Please don't add trailing whitespace. ---------- priority: -> high __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Oct 30 01:53:11 2007 From: report at bugs.python.org (Guido van Rossum) Date: Tue, 30 Oct 2007 00:53:11 -0000 Subject: [issue1360] Queue.get() can't be interrupted with Ctrl-C unless timed out Message-ID: <1193705591.8.0.209959692839.issue1360@psf.upfronthosting.co.za> Guido van Rossum added the comment: This (and the other issue you mention) is because the regular acquire() method on a basic lock cannot be interrupted. That's unlikely to go away, so you'll just have to live with this. As you've discovered, specifying a timeout solves the issue. Since code running in threads doesn't receive signals anyway (in Python), it would be fairly pointless to slow down lock acquisition in order to support keyboard interrupts. ---------- nosy: +gvanrossum resolution: -> wont fix status: open -> closed __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Oct 30 01:56:13 2007 From: report at bugs.python.org (Eric Hopper) Date: Tue, 30 Oct 2007 00:56:13 -0000 Subject: [issue1361] hashlib uses OpenSSL which is much slower than Aaron Gifford Message-ID: <1193705773.8.0.670166527886.issue1361@psf.upfronthosting.co.za> New submission from Eric Hopper: Aaron Gifford's implementation of SHA-{256,384,512} is nearly twice as fast as OpenSSLs. ---------- components: Extension Modules messages: 56946 nosy: Omnifarious severity: normal status: open title: hashlib uses OpenSSL which is much slower than Aaron Gifford type: resource usage versions: Python 2.5 __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Oct 30 01:56:32 2007 From: report at bugs.python.org (Guido van Rossum) Date: Tue, 30 Oct 2007 00:56:32 -0000 Subject: [issue1167930] threading.Thread.join() cannot be interrupted by a Ctrl-C Message-ID: <1193705792.79.0.0747611821723.issue1167930@psf.upfronthosting.co.za> Guido van Rossum added the comment: This is because the regular acquire() method on a basic lock cannot be interrupted. That's unlikely to go away, so you'll just have to live with this. As you've discovered, specifying a timeout solves the issue (sort of). ---------- nosy: +gvanrossum resolution: -> wont fix status: open -> closed _____________________________________ Tracker _____________________________________ From report at bugs.python.org Tue Oct 30 01:56:54 2007 From: report at bugs.python.org (Dan M) Date: Tue, 30 Oct 2007 00:56:54 -0000 Subject: [issue1362] Simple mistake in http://docs.python.org/tut/node6.html Message-ID: <1193705814.05.0.19491362552.issue1362@psf.upfronthosting.co.za> New submission from Dan M: In section 4.6 it says: Writing the value None is normally suppressed by the interpreter if it would be the only value written. When it should say: Writing the value None is normally displayed by the interpreter if it would be the only value written. Or less wordy: The value None is (normally) displayed by the interpreter when it would be the only value written. ---------- components: Documentation messages: 56948 nosy: dmazz severity: minor status: open title: Simple mistake in http://docs.python.org/tut/node6.html __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Oct 30 02:33:49 2007 From: report at bugs.python.org (Eric Hopper) Date: Tue, 30 Oct 2007 01:33:49 -0000 Subject: [issue1361] hashlib uses OpenSSL which is much slower than Aaron Gifford Message-ID: <1193708029.89.0.900278546348.issue1361@psf.upfronthosting.co.za> Eric Hopper added the comment: My testing methodology was faulty, this is not actually true. Oops. __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Oct 30 02:34:47 2007 From: report at bugs.python.org (Eric Hopper) Date: Tue, 30 Oct 2007 01:34:47 -0000 Subject: [issue1361] please close: hashlib uses OpenSSL which is much slower than Aaron Gifford Message-ID: <1193708088.0.0.902803808376.issue1361@psf.upfronthosting.co.za> Changes by Eric Hopper: ---------- title: hashlib uses OpenSSL which is much slower than Aaron Gifford -> please close: hashlib uses OpenSSL which is much slower than Aaron Gifford __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Oct 30 02:38:35 2007 From: report at bugs.python.org (Daniele Varrazzo) Date: Tue, 30 Oct 2007 01:38:35 -0000 Subject: [issue1360] Queue.get() can't be interrupted with Ctrl-C unless timed out Message-ID: <1193708315.09.0.661390924957.issue1360@psf.upfronthosting.co.za> Daniele Varrazzo added the comment: Because the easy workaround, we can live with the issue. Anyway, because the workaround is not trivial to find, and because the behavior is supposed to remain unchanged, maybe the issue should be mentioned in the docs. Thank you for the explanation :) __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Oct 30 03:16:25 2007 From: report at bugs.python.org (Facundo Batista) Date: Tue, 30 Oct 2007 02:16:25 -0000 Subject: [issue1361] please close: hashlib uses OpenSSL which is much slower than Aaron Gifford Message-ID: <1193710585.47.0.84833020846.issue1361@psf.upfronthosting.co.za> Facundo Batista added the comment: The OP changed his mind, :) ---------- nosy: +facundobatista resolution: -> invalid status: open -> closed __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Oct 30 03:48:16 2007 From: report at bugs.python.org (Kurt B. Kaiser) Date: Tue, 30 Oct 2007 02:48:16 -0000 Subject: [issue1612746] Enhanced tabbed pane widget Message-ID: <1193712496.83.0.524004899059.issue1612746@psf.upfronthosting.co.za> Kurt B. Kaiser added the comment: Prior to the 13:17:41 update: r58710. Minor formatting changes. I figured you might have an update :-) It's good to let these new modules age a bit :-) Well, maybe not that long... renamed tabbedPages.py -> tabbedpages.py to conform to PEP 8. Nicely done, thanks for the patch! One comment: when multiple rows are created, the row order in the test widget, counting from the top, is 2341. I expected 1234. ---------- resolution: out of date -> accepted _____________________________________ Tracker _____________________________________ From report at bugs.python.org Tue Oct 30 03:49:28 2007 From: report at bugs.python.org (Kurt B. Kaiser) Date: Tue, 30 Oct 2007 02:49:28 -0000 Subject: [issue1612746] Enhanced tabbed pane widget Message-ID: <1193712568.82.0.490718401668.issue1612746@psf.upfronthosting.co.za> Kurt B. Kaiser added the comment: Well, I already checked it in. Please synch to svn and send me an update against that. Note that I renamed tabbedPages.py. _____________________________________ Tracker _____________________________________ From report at bugs.python.org Tue Oct 30 04:55:36 2007 From: report at bugs.python.org (Senthil) Date: Tue, 30 Oct 2007 03:55:36 -0000 Subject: [issue1333] merge urllib and urlparse functionality Message-ID: <1193716536.61.0.331578160124.issue1333@psf.upfronthosting.co.za> Senthil added the comment: I have started this work at http://svn.python.org/projects/sandbox/trunk/urilib/ as a part of G-SoC, yes taking it to web-sig would be appropriate and I shall do so. techtonik, you might want to review it urilib and we can discuss it further. Thanks, ---------- nosy: +orsenthil __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Oct 30 06:51:57 2007 From: report at bugs.python.org (Christian Heimes) Date: Tue, 30 Oct 2007 05:51:57 -0000 Subject: [issue1352] Preliminary stderr patch In-Reply-To: <1193704176.56.0.899417191845.issue1352@psf.upfronthosting.co.za> Message-ID: <4726C676.1060906@cheimes.de> Christian Heimes added the comment: Guido van Rossum wrote: > Are there any places where PyBytes or PyString are written to stderr? > Or can you get away with just supporting PyUnicode? I could have simple copied the write method from _fileio.c and letting the argument parser do its job instead of fighting with the API for 20 minutes. : > It's "dumb", not "dump". I need an IDE with a context aware spell checker :] > I wouldn't explicitly remove the old stderr printer -- it will be > deleted automatically by the PyDict_SetItemString() call in > PySys_SetObject(). That way you'll still have it when the > PyFile_FromFd() call fails... I didn't know that. I'll keep it in place. __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Oct 30 07:21:09 2007 From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=) Date: Tue, 30 Oct 2007 06:21:09 -0000 Subject: [issue1362] Simple mistake in http://docs.python.org/tut/node6.html Message-ID: <1193725269.92.0.74544992443.issue1362@psf.upfronthosting.co.za> Martin v. L?wis added the comment: I fail to see the bug. The documentation is correct as it stands, ie. None is *not* displayed normally. IOW, writing is normally suppressed. ---------- nosy: +loewis resolution: -> invalid status: open -> closed __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Oct 30 07:33:20 2007 From: report at bugs.python.org (Christian Heimes) Date: Tue, 30 Oct 2007 06:33:20 -0000 Subject: [issue1329] Different 3.0a1 exit behavior In-Reply-To: <1193704946.42.0.939603638817.issue1329@psf.upfronthosting.co.za> Message-ID: <4726D028.3080506@cheimes.de> Christian Heimes added the comment: Guido van Rossum wrote: > Shouldn't closefd be passed as 1 in import.c? > > I don't see the point of distinguishing between -1 and +1. The block > "if (closefd < 0) { closefd = 1; }" looks rather silly. I used -1 as default to keep it consistent with buffer=-1. I figured out that I can go with "closefd != 0 means close it". > In io.py, you should document that closefd must not be False when a > filename is given. Done > I think in _fileio.c, you can insist that the closefd argument is an int > (a bool will work anyway, as bool is a subclass of int). Thanks, it makes the code a bit easier. > I don't think we should warn when trying to close an unclosable fd; it > should really just be a no-op. Also, if you are going to call > PyErr_WarnEx(), you should test its return value (it can raise an > exception!). I think we should keep the warning. The warning made me aware of a minor bug in quopri. > Please don't add trailing whitespace. I've reconfigured my editor to remove trailing spaces. I've attached a combined patch for closefd and preliminary stderr. Christian Added file: http://bugs.python.org/file8662/py3k_combined_preliminary_closefd.patch __________________________________ Tracker __________________________________ -------------- next part -------------- A non-text attachment was scrubbed... Name: py3k_combined_preliminary_closefd.patch Type: text/x-patch Size: 13242 bytes Desc: not available Url : http://mail.python.org/pipermail/python-bugs-list/attachments/20071030/ca99d724/attachment-0001.bin From report at bugs.python.org Tue Oct 30 13:03:56 2007 From: report at bugs.python.org (Christian Heimes) Date: Tue, 30 Oct 2007 12:03:56 -0000 Subject: [issue1322] platform.dist() has unpredictable result under Linux In-Reply-To: <1193741374.29.0.884447620757.issue1322@psf.upfronthosting.co.za> Message-ID: <47271DA8.4090004@cheimes.de> Christian Heimes added the comment: Yann Cointepas wrote: > I joined a modified version of platform.py. Here is a summary of the > modification: > - replaced '/etc' by global variable _etc_dir > - removed supported_dists parameter of dist() > - each element of dist() result is searched in the following places > (the first value found is kept): > 1) First line of /etc/-release > 2) Contents of /etc/lsb-release > 3) Extract from /etc/-release Here is an updated patch against Python 2.5 (your file was based on Python 2.5's platform.py, wasn't it?). CHANGES: * Added unit tests * Add Lib/test/platform directory for unit tests * removed usage of string * minor cleanups Now for the funny part. You have to port the patch to the svn trunk. The file can't be altered in the 2.5 release cycle. The changes are too great. Unfortunately the patch doesn't apply cleanly. Please add more test data to the platform/ directory and test_platform.py In order to build the trunk: svn co http://svn.python.org/projects/python/trunk cd trunk ./configure make patch -p0 < patchfile ./python Lib/test/test_platform.py svn diff > patchfile Christian __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Oct 30 13:04:49 2007 From: report at bugs.python.org (Christian Heimes) Date: Tue, 30 Oct 2007 12:04:49 -0000 Subject: [issue1322] platform.dist() has unpredictable result under Linux Message-ID: <1193745889.08.0.0272864809777.issue1322@psf.upfronthosting.co.za> Changes by Christian Heimes: ---------- components: +Library (Lib), Tests versions: +Python 2.6 -Python 2.5 Added file: http://bugs.python.org/file8664/platform_py25.patch __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Oct 30 13:18:13 2007 From: report at bugs.python.org (Christian Heimes) Date: Tue, 30 Oct 2007 12:18:13 -0000 Subject: [issue1345] Fix for test_netrc on Windows In-Reply-To: <1193680310.07.0.198103455549.issue1345@psf.upfronthosting.co.za> Message-ID: <47272102.4060906@cheimes.de> Christian Heimes added the comment: Guido van Rossum wrote: > Are you sure this is the proper fix? Why does netrc.py insist on not > having \r\n line endings? It opens the file in text mode so I don't > quite understand your patch. I don't quite understand why it fails. :/ I've to take more time to debug it. Christian __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Oct 30 14:07:17 2007 From: report at bugs.python.org (Dan M) Date: Tue, 30 Oct 2007 13:07:17 -0000 Subject: [issue1362] Simple mistake in http://docs.python.org/tut/node6.html Message-ID: <1193749637.31.0.429282943009.issue1362@psf.upfronthosting.co.za> Dan M added the comment: Yes, it is normally suppressed. The problem is the condition when it is suppressed. The documentation states that it's suppressed when it's the only value to be written. It is suppressed when it's *not* the only value to be written. -or- (removing the double negative of suppressed(not displayed) and not) It is displayed when it would be the only value written. The example immediately following this mistake is correct, which makes the actual behavior obvious even if this particular statement is wrong. __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Oct 30 15:40:24 2007 From: report at bugs.python.org (Guido van Rossum) Date: Tue, 30 Oct 2007 14:40:24 -0000 Subject: [issue1358] Compile error on OS X 10.5 Message-ID: <1193755224.0.0.161178255623.issue1358@psf.upfronthosting.co.za> Guido van Rossum added the comment: Thanks for testing on Leopard! I haven't gotten that yet. Assigning to Neal since this ought to be fixed before 2.5.2 is released. (But someone needs to come up with a proper patch.) ---------- assignee: -> nnorwitz nosy: +gvanrossum, nnorwitz priority: -> immediate __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Oct 30 18:19:02 2007 From: report at bugs.python.org (Guido van Rossum) Date: Tue, 30 Oct 2007 17:19:02 -0000 Subject: [issue1329] Different 3.0a1 exit behavior Message-ID: <1193764742.0.0.831603326624.issue1329@psf.upfronthosting.co.za> Guido van Rossum added the comment: OK, thanks. The closefd part is good, but the stderrprinter part has a problem. On Linux, in a non-debug build, this has the odd side effect of subtracting one from sys.maxunicode. In a debug build, it dies like this: $ ./python -S python: Modules/gcmodule.c:336: visit_reachable: Assertion `gc_refs > 0 || gc_refs == (-3) || gc_refs == (-2)' failed. Aborted $ If I comment out the PySys_SetObject() call everything seems fine, but I suspect that the problem is actually in the creation of the stdprinter object. __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Oct 30 18:28:37 2007 From: report at bugs.python.org (Guido van Rossum) Date: Tue, 30 Oct 2007 17:28:37 -0000 Subject: [issue1329] Different 3.0a1 exit behavior Message-ID: <1193765317.22.0.537522867929.issue1329@psf.upfronthosting.co.za> Guido van Rossum added the comment: I've checked the closefd patch (which minor changes) into the py3k branch. Committed revision 58711. Please take the stdprinter patch to the original issue (bug 1352). ---------- resolution: -> accepted status: open -> closed __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Oct 30 18:38:28 2007 From: report at bugs.python.org (Bill Fenner) Date: Tue, 30 Oct 2007 17:38:28 -0000 Subject: [issue1339] smtplib starttls() should ehlo() if it needs to Message-ID: <1193765908.85.0.635981154634.issue1339@psf.upfronthosting.co.za> Bill Fenner added the comment: I've attached a patch against 2.4.3. The patch does the following: - Factor out the duplication of EHLO/HELO in login() and sendmail() to a new function, ehlo_or_helo_if_needed(). - Use ehlo_or_helo_if_needed() in starttls() - Check for the starttls exception in starttls() in the same way as login() checks for the auth extension. Added file: http://bugs.python.org/file8665/smtplib-startls-ehlo.diff __________________________________ Tracker __________________________________ -------------- next part -------------- A non-text attachment was scrubbed... Name: smtplib-startls-ehlo.diff Type: application/octet-stream Size: 2986 bytes Desc: not available Url : http://mail.python.org/pipermail/python-bugs-list/attachments/20071030/aa4b4ff8/attachment.obj From report at bugs.python.org Tue Oct 30 18:52:43 2007 From: report at bugs.python.org (Jonathan Amsterdam) Date: Tue, 30 Oct 2007 17:52:43 -0000 Subject: [issue1336] subprocess.Popen hangs when child writes to stderr In-Reply-To: <1193421647.43.0.624297760555.issue1336@psf.upfronthosting.co.za> Message-ID: <31c6fe8f0710301052v5ba5ff9o8c60de7834a2ae0e@mail.gmail.com> Jonathan Amsterdam added the comment: It's an honor to hear from you, BDFL. I'm just a Python user, not a developer, so the time it would take me to check out, compile, test, etc. would dwarf the change itself (removing two lines from file_dealloc). There is another solution, following Java: file_dealloc could raise an exception. Then the error would appear in normal contexts, but (assuming the GC ignores exceptions in finalization) would be ignored in GC. There is also a simpler, less invasive change you could consider: disabling GC in the child inside subprocess.Popen. On 10/26/07, Guido van Rossum wrote: > > Guido van Rossum added the comment: > > I don't think we can prevent GC from occurring between fork and exec -- > it's legal to just call os.fork() and execute Python code in the > subprocess forever. I think the right solution might be to ignore > errors in file_close(). Can you try to whip up a patch for that and > test it? > > ---------- > nosy: +gvanrossum > > __________________________________ > Tracker > > __________________________________ > __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Oct 30 18:53:43 2007 From: report at bugs.python.org (Bill Fenner) Date: Tue, 30 Oct 2007 17:53:43 -0000 Subject: [issue829951] Fixes smtplib starttls HELO errors Message-ID: <1193766823.91.0.341890513632.issue829951@psf.upfronthosting.co.za> Bill Fenner added the comment: I've attached an updated diff, against the 2.4.3 smtplib.py, which forgets all of the relevant pieces of information. The line numbers are offset from the standard lib because the original file has my patch for issue 1339 applied, but there is no overlap so this patch should apply cleanly. Added file: http://bugs.python.org/file8666/smtplib-startls-discard-knowledge.diff ____________________________________ Tracker ____________________________________ -------------- next part -------------- A non-text attachment was scrubbed... Name: smtplib-startls-discard-knowledge.diff Type: application/octet-stream Size: 768 bytes Desc: not available Url : http://mail.python.org/pipermail/python-bugs-list/attachments/20071030/c9284a67/attachment-0001.obj From report at bugs.python.org Tue Oct 30 18:58:14 2007 From: report at bugs.python.org (Georg Brandl) Date: Tue, 30 Oct 2007 17:58:14 -0000 Subject: [issue1362] Simple mistake in http://docs.python.org/tut/node6.html Message-ID: <1193767094.75.0.7238229974.issue1362@psf.upfronthosting.co.za> Georg Brandl added the comment: No, the text is correct, but the example is misleading -- I now changed it to >>> fib(0) >>> print fib(0) None which should make the difference between using and not using print clearer. ---------- nosy: +georg.brandl __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Oct 30 19:06:44 2007 From: report at bugs.python.org (Christian Heimes) Date: Tue, 30 Oct 2007 18:06:44 -0000 Subject: [issue1329] Different 3.0a1 exit behavior In-Reply-To: <1193764742.0.0.831603326624.issue1329@psf.upfronthosting.co.za> Message-ID: <472772AF.7030006@cheimes.de> Christian Heimes added the comment: Guido van Rossum wrote: > Guido van Rossum added the comment: > > OK, thanks. The closefd part is good, but the stderrprinter part has a > problem. On Linux, in a non-debug build, this has the odd side effect > of subtracting one from sys.maxunicode. In a debug build, it dies like > this: > > $ ./python -S > python: Modules/gcmodule.c:336: visit_reachable: Assertion `gc_refs > 0 > || gc_refs == (-3) || gc_refs == (-2)' failed. > Aborted > $ > > If I comment out the PySys_SetObject() call everything seems fine, but I > suspect that the problem is actually in the creation of the stdprinter > object. I may have found the problem. I forgot th remove Py_TPFLAGS_HAVE_GC from tp_flags. It's a relict from my first implementation. $ ./python Fatal Python error: Py_Initialize: can't initialize sys standard streams Traceback (most recent call last): File "/home/heimes/dev/python/py3k/Lib/io.py", line 22, in test NameError: name 'test' is not defined Aborted $ vi Lib/io.py $ ./python -S Python 3.0a1+ (py3k:58715M, Oct 30 2007, 19:02:47) [GCC 4.1.3 20070929 (prerelease) (Ubuntu 4.1.2-16ubuntu2)] on linux2 >>> import sys [33116 refs] >>> sys.maxunicode 1114111 [33127 refs] >>> [33128 refs] [23233 refs] $ python2.5 -c "import sys; print sys.maxunicode" 1114111 __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Oct 30 19:10:01 2007 From: report at bugs.python.org (Christian Heimes) Date: Tue, 30 Oct 2007 18:10:01 -0000 Subject: [issue1329] Different 3.0a1 exit behavior Message-ID: <1193767801.3.0.607104939002.issue1329@psf.upfronthosting.co.za> Changes by Christian Heimes: Added file: http://bugs.python.org/file8667/py3k_preliminary_stderr3.patch __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Oct 30 19:15:00 2007 From: report at bugs.python.org (Bill Janssen) Date: Tue, 30 Oct 2007 18:15:00 -0000 Subject: [issue1347] BaseHTTPServer writing strings to bytes interface Message-ID: <1193768100.39.0.78500946912.issue1347@psf.upfronthosting.co.za> Bill Janssen added the comment: Fixed in rev 58718 ---------- keywords: +py3k resolution: accepted -> fixed status: open -> closed __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Oct 30 19:16:28 2007 From: report at bugs.python.org (Bill Janssen) Date: Tue, 30 Oct 2007 18:16:28 -0000 Subject: [issue1349] more uses of ord() in plat-mac/ic.py Message-ID: <1193768188.08.0.00535746956431.issue1349@psf.upfronthosting.co.za> Bill Janssen added the comment: Fixed in r58717 ---------- resolution: -> fixed status: open -> closed __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Oct 30 19:18:10 2007 From: report at bugs.python.org (Paul) Date: Tue, 30 Oct 2007 18:18:10 -0000 Subject: [issue1363] python 2.4.4 fails on solaris (sun4u sparc SUNW, Sun-Fire-880) Message-ID: <1193768290.81.0.981284051139.issue1363@psf.upfronthosting.co.za> New submission from Paul: Trying to compile Plone (3.0.2) on a Sun V880 (SunOS genome 5.10 Generic_125100-05 sun4u sparc SUNW,Sun-Fire-880). Plone is a web application which runs on the Zope framework. What fails is the python (2.4.4) which is distributed with Zope. During the configure step of the build, I receive the following warning: *****BEGIN Snippet***** configure: WARNING: sys/wait.h: present but cannot be compiled configure: WARNING: sys/wait.h: check for missing prerequisite headers? configure: WARNING: sys/wait.h: see the Autoconf documentation configure: WARNING: sys/wait.h: section "Present But Cannot Be Compiled" configure: WARNING: sys/wait.h: proceeding with the preprocessor's result configure: WARNING: sys/wait.h: in the future, the compiler will take precedence configure: WARNING: ## ------------------------------------------------ ## configure: WARNING: ## Report this to http://www.python.org/python-bugs ## configure: WARNING: ## ------------------------------------------------ ## *****END Snippet***** Then this nasty error breaks the entire config: ******BEGIN Snippet checking size of int... configure: error: cannot compute sizeof (int), 77 See `config.log' for more details. ******END Snippet ---------- components: Build messages: 56972 nosy: theoryno3 severity: normal status: open title: python 2.4.4 fails on solaris (sun4u sparc SUNW,Sun-Fire-880) versions: Python 2.4 __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Oct 30 19:18:27 2007 From: report at bugs.python.org (Paul) Date: Tue, 30 Oct 2007 18:18:27 -0000 Subject: [issue1363] python 2.4.4 fails on solaris (sun4u sparc SUNW, Sun-Fire-880) Message-ID: <1193768307.75.0.27232416343.issue1363@psf.upfronthosting.co.za> Paul added the comment: Trying to compile Plone (3.0.2) on a Sun V880 (SunOS genome 5.10 Generic_125100-05 sun4u sparc SUNW,Sun-Fire-880). Plone is a web application which runs on the Zope framework. What fails is the python (2.4.4) which is distributed with Zope. During the configure step of the build, I receive the following warning: *****BEGIN Snippet***** configure: WARNING: sys/wait.h: present but cannot be compiled configure: WARNING: sys/wait.h: check for missing prerequisite headers? configure: WARNING: sys/wait.h: see the Autoconf documentation configure: WARNING: sys/wait.h: section "Present But Cannot Be Compiled" configure: WARNING: sys/wait.h: proceeding with the preprocessor's result configure: WARNING: sys/wait.h: in the future, the compiler will take precedence configure: WARNING: ## ------------------------------------------------ ## configure: WARNING: ## Report this to http://www.python.org/python-bugs ## configure: WARNING: ## ------------------------------------------------ ## *****END Snippet***** Then this nasty error breaks the entire config: ******BEGIN Snippet checking size of int... configure: error: cannot compute sizeof (int), 77 See `config.log' for more details. ******END Snippet ---------- severity: normal -> critical type: -> compile error __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Oct 30 19:35:10 2007 From: report at bugs.python.org (Guido van Rossum) Date: Tue, 30 Oct 2007 18:35:10 -0000 Subject: [issue1352] Preliminary stderr patch Message-ID: <1193769310.62.0.159293100824.issue1352@psf.upfronthosting.co.za> Guido van Rossum added the comment: I've checked in the patch you added to issue 1329, with one mod: where you wrote "int fd : 1;" I removed the ": 1" since a field width of one bit makes no sense here. ---------- resolution: -> accepted status: open -> closed __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Oct 30 19:37:53 2007 From: report at bugs.python.org (Guido van Rossum) Date: Tue, 30 Oct 2007 18:37:53 -0000 Subject: [issue1329] Different 3.0a1 exit behavior Message-ID: <1193769473.29.0.602754939518.issue1329@psf.upfronthosting.co.za> Guido van Rossum added the comment: Thanks, I've closed issue 1352 too now. __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Oct 30 19:43:34 2007 From: report at bugs.python.org (Guido van Rossum) Date: Tue, 30 Oct 2007 18:43:34 -0000 Subject: [issue1336] subprocess.Popen hangs when child writes to stderr In-Reply-To: <31c6fe8f0710301052v5ba5ff9o8c60de7834a2ae0e@mail.gmail.com> Message-ID: Guido van Rossum added the comment: In Python, you can't raise an exception from file_dealloc. (Note how it is a void function -- there's no way to return an error status.) Disabling gc however makes sense. I'll think about that. Since you seem to have the only reproducible occurrence of this bug, try this: right after the "# Child" comment add a call to gc.disable(). You should import gc at the top of the module with the rest of the imports. __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Oct 30 19:49:46 2007 From: report at bugs.python.org (Christian Heimes) Date: Tue, 30 Oct 2007 18:49:46 -0000 Subject: [issue1352] Preliminary stderr patch In-Reply-To: <1193769310.62.0.159293100824.issue1352@psf.upfronthosting.co.za> Message-ID: <47277CC6.3090108@cheimes.de> Christian Heimes added the comment: Guido van Rossum wrote: > I've checked in the patch you added to issue 1329, with one mod: where > you wrote "int fd : 1;" I removed the ": 1" since a field width of one > bit makes no sense here. Can you close http://bugs.python.org/issue1771260, too? Christian __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Oct 30 19:56:38 2007 From: report at bugs.python.org (Guido van Rossum) Date: Tue, 30 Oct 2007 18:56:38 -0000 Subject: [issue1771260] Errors in site.py not reported properly Message-ID: <1193770598.23.0.841639596607.issue1771260@psf.upfronthosting.co.za> Guido van Rossum added the comment: Fixed by Christian Heimes's patch, see issue 1352 and issue 1329. ---------- nosy: +gvanrossum resolution: -> fixed status: open -> closed _____________________________________ Tracker _____________________________________ From report at bugs.python.org Tue Oct 30 20:00:57 2007 From: report at bugs.python.org (Christian Heimes) Date: Tue, 30 Oct 2007 19:00:57 -0000 Subject: [issue1342] Crash on Windows if Python runs from a directory with umlauts Message-ID: <1193770857.21.0.0606363989402.issue1342@psf.upfronthosting.co.za> Christian Heimes added the comment: Hi Martin! Thomas Wouters said on #python that you have the Windows Fu to fix the problem. Parts of the Python API for file paths, sys.path and os.environ have to be reimplemented using the wide char API. ---------- nosy: +loewis __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Oct 30 22:00:40 2007 From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=) Date: Tue, 30 Oct 2007 21:00:40 -0000 Subject: [issue1358] Compile error on OS X 10.5 Message-ID: <1193778039.95.0.644110902215.issue1358@psf.upfronthosting.co.za> Martin v. L?wis added the comment: There is an autoconf test that tries to compile | #include | int | main () | { | setpgrp(0,0); | ; | return 0; | } (with many additional defines - see config.log.gz). This file compiles with the error message conftest.c:185: error: too many arguments to function 'setpgrp' hence configure concludes that SETPGRP_HAVE_ARG should *not* be defined - yet you say it works when it is defined. Can somebody with access to the system resolve this mystery? Studying the header file that has the setpgrp declaration is probably necessary. __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Oct 30 22:03:32 2007 From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=) Date: Tue, 30 Oct 2007 21:03:32 -0000 Subject: [issue1363] python 2.4.4 fails on solaris (sun4u sparc SUNW, Sun-Fire-880) Message-ID: <1193778212.04.0.120184520649.issue1363@psf.upfronthosting.co.za> Martin v. L?wis added the comment: What compiler did you use? Can you please attach the compressed config.log? ---------- nosy: +loewis __________________________________ Tracker __________________________________ From report at bugs.python.org Wed Oct 31 04:11:12 2007 From: report at bugs.python.org (billiejoex) Date: Wed, 31 Oct 2007 03:11:12 -0000 Subject: [issue1364] os.lstat documentation error Message-ID: <1193800272.82.0.918454638792.issue1364@psf.upfronthosting.co.za> New submission from billiejoex: os module documentation says about lstat(): > lstat( path) > > Like stat(), but do not follow symbolic links. > Availability: Macintosh, Unix. This is not true since os.lstat() is also available under Windows (tested under Win XP sp, Python 2.5). Moreover, wouldn't it be better having os.lstat() available on all platforms and turn it into an alias of os.stat on those platforms which do not support symbolic links? ---------- components: Documentation messages: 56982 nosy: billiejoex severity: normal status: open title: os.lstat documentation error versions: Python 2.5 __________________________________ Tracker __________________________________ From report at bugs.python.org Wed Oct 31 04:14:31 2007 From: report at bugs.python.org (billiejoex) Date: Wed, 31 Oct 2007 03:14:31 -0000 Subject: [issue1345] Fix for test_netrc on Windows Message-ID: <1193800471.0.0.919622802698.issue1345@psf.upfronthosting.co.za> Changes by billiejoex: __________________________________ Tracker __________________________________ From report at bugs.python.org Wed Oct 31 05:22:02 2007 From: report at bugs.python.org (Neal Norwitz) Date: Wed, 31 Oct 2007 04:22:02 -0000 Subject: [issue1631171] implement warnings module in C Message-ID: <1193804522.18.0.136691235685.issue1631171@psf.upfronthosting.co.za> Neal Norwitz added the comment: I think Brett summarized the issues well. I can't think of anything else that seems to need doing. _____________________________________ Tracker _____________________________________ From report at bugs.python.org Wed Oct 31 06:00:51 2007 From: report at bugs.python.org (Kurt B. Kaiser) Date: Wed, 31 Oct 2007 05:00:51 -0000 Subject: [issue1252] IDLE - patch Delegator to support callables Message-ID: <1193806851.02.0.0709031123906.issue1252@psf.upfronthosting.co.za> Kurt B. Kaiser added the comment: Further response to your 27Oct: > That's it. There is more. The Delegator mixin exposes its delegate attribute. Without that, it would not be possible to pass e.g. insert() down the chain because (in the case of the Text percolator) insert() is found in each filter and blocks 'transparent' access. I agree with your two use cases, but repeat that transparent access is dangerous in that the class in which the attribute is being looked up changes for each link on the chain. You could get unexpected results. IMO you are giving up stability for convenience. "Explicit is better than implicit." > (Caching is just an implementation detail, whose only purpose is to > facilitate changing a Delegator's delegate.) Don't believe everything you read. While that comment in the code is true, it's not the whole truth. If 'transparent' access is made to an attribute further down the chain, that attribute will be actually cached, i.e. be set as an attribute, in each DelegatorNode. I imagine this was done for performance reasons. The Delegator.__cache is used to determine which attributes to delete if a delegate is changed. I'll defer the Percolator comments until later. > Now, it seems to me that you aren't looking at Delegators and > Peroclators as transparent proxies at all. Not so. That's my 2. in my msg56862 27Oct. But I see filters as having two modes of operation. In the first, they take an action like insert() and share it explicitly along a chain of authority. Each link takes specific action, and passes insert() along. They also provide transparent access to attributes down the chain, as you note. But once an attribute is found it will not propagate unless explicitly passed along, and that requires the self.delegate attribute. __________________________________ Tracker __________________________________ From report at bugs.python.org Wed Oct 31 06:04:01 2007 From: report at bugs.python.org (Neal Norwitz) Date: Wed, 31 Oct 2007 05:04:01 -0000 Subject: [issue1358] Compile error on OS X 10.5 Message-ID: <1193807041.66.0.0623903021733.issue1358@psf.upfronthosting.co.za> Neal Norwitz added the comment: I don't have access to a 10.5 machine. My guess is that the difference is between configure not setting _XOPEN_SOURCE and/or _XOPEN_SOURCE_EXTENDED and it being set in pyconfig.h. At least those are both defined on 10.4. This page talks about needing to include unistd.h, but doesn't give enough info: http://developer.apple.com/documentation/Darwin/Reference/Manpages/man2/setpgid.2.html Hopefully someone else with access to 10.5 can confirm if this is the case and we can resolve this. __________________________________ Tracker __________________________________ From report at bugs.python.org Wed Oct 31 06:06:58 2007 From: report at bugs.python.org (Neal Norwitz) Date: Wed, 31 Oct 2007 05:06:58 -0000 Subject: [issue1574217] isinstance swallows exceptions Message-ID: <1193807218.03.0.636753658651.issue1574217@psf.upfronthosting.co.za> Neal Norwitz added the comment: Yeah, this seems like a bug and the patch seems correct. The patch also needs a test and add a space between if (. _____________________________________ Tracker _____________________________________ From report at bugs.python.org Wed Oct 31 06:18:16 2007 From: report at bugs.python.org (Kurt B. Kaiser) Date: Wed, 31 Oct 2007 05:18:16 -0000 Subject: [issue1252] IDLE - patch Delegator to support callables Message-ID: <1193807896.2.0.80210956861.issue1252@psf.upfronthosting.co.za> Kurt B. Kaiser added the comment: > 1) Should Delegator delegate calls to callables No, I agree they should. The question is whether it's necessary to add a __call__() method to the Delegator class. I claim you can do what you want to do without it. It serves only one purpose that I can see: you want to delegate to a callable by calling the instance at the top of the chain, and one of the chain members isn't callable. I don't see a use case for that, YAGNI. I'll defer the Percolator discussion for now. There is more to it than just the inheritance issue. I found your example1.py to be confusing. Please stop using the word 'delegator', it's too overloaded in this discussion! I marked up example1.py as example1a.py, changing some names and adding some comments. I also worked up example2.py which seems to cover the possible combinations of proxying functions, callables, and methods. It works without adding __call__() to Delegator. Please check it out, what more do you need? I'll be away until Sunday, so I can't respond further until then. __________________________________ Tracker __________________________________ From report at bugs.python.org Wed Oct 31 06:21:29 2007 From: report at bugs.python.org (Kurt B. Kaiser) Date: Wed, 31 Oct 2007 05:21:29 -0000 Subject: [issue1252] IDLE - patch Delegator to support callables Message-ID: <1193808089.38.0.0542327485541.issue1252@psf.upfronthosting.co.za> Changes by Kurt B. Kaiser: Added file: http://bugs.python.org/file8668/example1a.py __________________________________ Tracker __________________________________ From report at bugs.python.org Wed Oct 31 06:21:58 2007 From: report at bugs.python.org (Kurt B. Kaiser) Date: Wed, 31 Oct 2007 05:21:58 -0000 Subject: [issue1252] IDLE - patch Delegator to support callables Message-ID: <1193808118.08.0.302410147509.issue1252@psf.upfronthosting.co.za> Changes by Kurt B. Kaiser: Added file: http://bugs.python.org/file8669/example2.py __________________________________ Tracker __________________________________ From report at bugs.python.org Wed Oct 31 07:03:45 2007 From: report at bugs.python.org (Neal Norwitz) Date: Wed, 31 Oct 2007 06:03:45 -0000 Subject: [issue1490190] add os.chflags() and os.lchflags() where available Message-ID: <1193810625.39.0.455250289463.issue1490190@psf.upfronthosting.co.za> Neal Norwitz added the comment: Martin's patch from 2007-03-21 fixed the problem with test_posix. It now passes all the tests (test_posix and rest of test suite). The tests/interpreter do not exit prematurely. I think it is good to apply this patch. ---------- assignee: nnorwitz -> loewis _____________________________________ Tracker _____________________________________ From report at bugs.python.org Wed Oct 31 07:16:38 2007 From: report at bugs.python.org (Neal Norwitz) Date: Wed, 31 Oct 2007 06:16:38 -0000 Subject: [issue1346] Error using >>> from OpenGL.GLUT import * Message-ID: <1193811398.15.0.430884087344.issue1346@psf.upfronthosting.co.za> Neal Norwitz added the comment: As gagenellina said, this problem appears to be with OpenGL, not python. OpenGL is not maintained here. You'll have to open a bug report with them. ---------- nosy: +nnorwitz resolution: -> rejected status: open -> closed __________________________________ Tracker __________________________________ From report at bugs.python.org Wed Oct 31 10:50:11 2007 From: report at bugs.python.org (Christian Heimes) Date: Wed, 31 Oct 2007 09:50:11 -0000 Subject: [issue1365] bytes() constructor Message-ID: <1193824211.16.0.246660638775.issue1365@psf.upfronthosting.co.za> New submission from Christian Heimes: Hey Guido! During my testing and local modifications of the PEP 3137 branch I found a bunch of unit tests that were choking on bytes(1) where bytes is PyString. The PEP doesn't list bytes() as a valid constructor, only buffer(). I don't see a reason why bytes() shouldn't accept an int when b'1' still creates a byte sequence with 3 elements. Here is a patch ---------- components: Interpreter Core messages: 56990 nosy: gvanrossum, tiran severity: normal status: open title: bytes() constructor type: rfe versions: Python 3.0 __________________________________ Tracker __________________________________ From report at bugs.python.org Wed Oct 31 10:59:43 2007 From: report at bugs.python.org (=?utf-8?q?Patrick_M=C3=A9zard?=) Date: Wed, 31 Oct 2007 09:59:43 -0000 Subject: [issue1366] popen spawned process may not write to stdout under windows Message-ID: <1193824783.73.0.865697244253.issue1366@psf.upfronthosting.co.za> New submission from Patrick M?zard: Let child.py be: """ import sys sys.stdout.write('1:stdout\n') sys.stdout.flush() sys.stderr.write('2:stderr\n') sys.stderr.flush() sys.stdout.write('3:stdout\n') sys.stdout.flush() """ and parent.py: """ import os cmd = 'python child.py' for l in os.popen(cmd): print l, """ Then running it: """ >python parent.py 1:stdout >python Python 2.5.1 (r251:54863, Apr 18 2007, 08:51:08) [MSC v.1310 32 bit (Intel)] on win32 """ I would have expected at least: """ 1:stdout 3:stdout """ to be output, which actually happens if the stderr is nullified like "python child.py 2>nul" in parent.py call. Am I wrong ? ---------- components: Windows messages: 56991 nosy: pmezard severity: normal status: open title: popen spawned process may not write to stdout under windows type: behavior versions: Python 2.5 __________________________________ Tracker __________________________________ From report at bugs.python.org Wed Oct 31 13:43:32 2007 From: report at bugs.python.org (anonyprog) Date: Wed, 31 Oct 2007 12:43:32 -0000 Subject: [issue1367] mkdir+chdir problem in multiple threads Message-ID: <1193834612.62.0.192544402104.issue1367@psf.upfronthosting.co.za> New submission from anonyprog: Under certain circumstances, creating a directory using os.mkdir then immediately changing to it using os.chdir fails with a file not found exception. Here is some code to demonstrate that. Using the following program with a parameter of 1 works fine. But anything greater than that and exceptions occur in the first os.chdir until only one thread is left to run completely. Tested on Python 2.5.1 for Windows and Python 2.3.5 for Linux. # mkdirtest.py # # usage: mkdirtest import os, threading, sys x = int(sys.argv[1]) class MkdirTest(threading.Thread): def __init__(self, t): threading.Thread.__init__(self) self.t = t print "new thread "+str(t) def run(self): for i in range(0,50): s = str(self.t)+"_"+str(i) print "mkdir "+s os.mkdir(s) os.chdir(s) os.chdir("..") print "end thread "+str(t) for t in range(0,x): print t a = MkdirTest(t) a.start() ---------- components: None messages: 56992 nosy: anonyprog severity: normal status: open title: mkdir+chdir problem in multiple threads type: behavior versions: Python 2.5 __________________________________ Tracker __________________________________ From report at bugs.python.org Wed Oct 31 13:44:03 2007 From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=) Date: Wed, 31 Oct 2007 12:44:03 -0000 Subject: [issue1365] bytes() constructor Message-ID: <1193834643.93.0.17673542593.issue1365@psf.upfronthosting.co.za> Martin v. L?wis added the comment: Where is the patch? ---------- nosy: +loewis __________________________________ Tracker __________________________________ From report at bugs.python.org Wed Oct 31 13:49:00 2007 From: report at bugs.python.org (Christian Heimes) Date: Wed, 31 Oct 2007 12:49:00 -0000 Subject: [issue1365] bytes() constructor Message-ID: <1193834940.5.0.64567510685.issue1365@psf.upfronthosting.co.za> Christian Heimes added the comment: Here it is. patch + unit test Added file: http://bugs.python.org/file8670/py3k_pystring_ssize.patch __________________________________ Tracker __________________________________ -------------- next part -------------- A non-text attachment was scrubbed... Name: py3k_pystring_ssize.patch Type: text/x-diff Size: 1514 bytes Desc: not available Url : http://mail.python.org/pipermail/python-bugs-list/attachments/20071031/48689095/attachment.patch From report at bugs.python.org Wed Oct 31 13:50:16 2007 From: report at bugs.python.org (Simon) Date: Wed, 31 Oct 2007 12:50:16 -0000 Subject: [issue1651995] sgmllib _convert_ref UnicodeDecodeError exception, new in 2. Message-ID: <1193835016.57.0.0795643903221.issue1651995@psf.upfronthosting.co.za> Changes by Simon: ---------- nosy: +bind _____________________________________ Tracker _____________________________________ From report at bugs.python.org Wed Oct 31 16:01:07 2007 From: report at bugs.python.org (Jean-Paul Calderone) Date: Wed, 31 Oct 2007 15:01:07 -0000 Subject: [issue1367] mkdir+chdir problem in multiple threads Message-ID: <1193842867.61.0.569850472083.issue1367@psf.upfronthosting.co.za> Jean-Paul Calderone added the comment: This isn't a bug in Python. Working directory, which os.chdir modifies, is process-global. One of your threads makes a directory, then gets suspended while another one makes a different directory and changes into it, then the first tries to change into its directory and fails. ---------- nosy: +exarkun __________________________________ Tracker __________________________________ From report at bugs.python.org Wed Oct 31 16:35:23 2007 From: report at bugs.python.org (anonyprog) Date: Wed, 31 Oct 2007 15:35:23 -0000 Subject: [issue1367] mkdir+chdir problem in multiple threads Message-ID: <1193844923.2.0.101237222454.issue1367@psf.upfronthosting.co.za> anonyprog added the comment: Sorry for filing this as a bug, I am a fool. I should have read the documentation for each operating systems' mkdir call more carefully. __________________________________ Tracker __________________________________ From report at bugs.python.org Wed Oct 31 17:41:43 2007 From: report at bugs.python.org (Guido van Rossum) Date: Wed, 31 Oct 2007 16:41:43 -0000 Subject: [issue1365] bytes() constructor Message-ID: <1193848903.79.0.406600363097.issue1365@psf.upfronthosting.co.za> Guido van Rossum added the comment: Committed revision 58730. Thanks! PS. Christian, please work with Neal or Martin to get developer privileges... ---------- resolution: -> accepted status: open -> closed __________________________________ Tracker __________________________________ From report at bugs.python.org Wed Oct 31 20:27:51 2007 From: report at bugs.python.org (Mike Klaas) Date: Wed, 31 Oct 2007 19:27:51 -0000 Subject: [issue1516330] Module uuid: functions for retrieving MAC addres Message-ID: <1193858871.28.0.540504439697.issue1516330@psf.upfronthosting.co.za> Mike Klaas added the comment: Is this meant to be inserted into uuid.py? It seems more like a snippet from unrelated code: code coventions do not follow PEP 8; there are no tests; code does not run as-is (references non-existent variable '_os'-- why no 'import os'?); etc. ---------- nosy: +klaas _____________________________________ Tracker _____________________________________ From report at bugs.python.org Wed Oct 31 20:42:24 2007 From: report at bugs.python.org (Mike Klaas) Date: Wed, 31 Oct 2007 19:42:24 -0000 Subject: [issue1516327] Module uuid: reduce pickle footprint Message-ID: <1193859744.4.0.649254054266.issue1516327@psf.upfronthosting.co.za> Mike Klaas added the comment: Is the footprint of UUID an issue? Note that changing the pickle format of UUID will require code that can unpickle both versions, for compatibility. I don't really see the need. Also, no real patch provided. ---------- nosy: +klaas _____________________________________ Tracker _____________________________________ From report at bugs.python.org Wed Oct 31 20:59:15 2007 From: report at bugs.python.org (Thomas Heller) Date: Wed, 31 Oct 2007 19:59:15 -0000 Subject: [issue1292] libffi needs an update to support mips64, arm and armeabi on linux Message-ID: <1193860755.0.0.403949992645.issue1292@psf.upfronthosting.co.za> Thomas Heller added the comment: In the branches_ctypes-branch I hacked setup.py to always use an installed libffi if one is found. Then I triggered the trunk buildbots which failed or crashed before in some c_longdouble tests; the tests worked ok on them (ppc Debian unstable, and S-390 Debian). __________________________________ Tracker __________________________________ From report at bugs.python.org Wed Oct 31 21:00:13 2007 From: report at bugs.python.org (Thomas Heller) Date: Wed, 31 Oct 2007 20:00:13 -0000 Subject: [issue1292] libffi needs an update to support mips64, arm and armeabi on linux Message-ID: <1193860813.22.0.241974768037.issue1292@psf.upfronthosting.co.za> Thomas Heller added the comment: I meant branches/ctypes_branch, of course. __________________________________ Tracker __________________________________ From report at bugs.python.org Wed Oct 31 21:26:22 2007 From: report at bugs.python.org (Mike Klaas) Date: Wed, 31 Oct 2007 20:26:22 -0000 Subject: [issue1705170] contextmanager eats StopIteration Message-ID: <1193862382.17.0.585425136201.issue1705170@psf.upfronthosting.co.za> Mike Klaas added the comment: Verified on 2.5.0. The problem stems from contextmanager.__exit__: def __exit__(self, type, value, traceback): if type is None: try: self.gen.next() except StopIteration: return else: raise RuntimeError("generator didn't stop") else: try: self.gen.throw(type, value, traceback) raise RuntimeError("generator didn't stop after throw ()") except StopIteration, exc: # Suppress the exception *unless* it's the same exception that # was passed to throw(). This prevents a StopIteration # raised inside the "with" statement from being suppressed return exc is not value except: # only re-raise if it's *not* the exception that was # passed to throw(), because __exit__() must not raise # an exception unless __exit__() itself failed. But throw() # has to raise the exception to signal propagation, so this # fixes the impedance mismatch between the throw() protocol # and the __exit__() protocol. # if sys.exc_info()[1] is not value: raise Conjecture: internal StopIteration exceptions are always the same instance (PyExc_StopIteration) when propagated to python, invalidating the return exc is not value check. ---------- nosy: +klaas _____________________________________ Tracker _____________________________________ From report at bugs.python.org Wed Oct 31 22:19:07 2007 From: report at bugs.python.org (Mike Klaas) Date: Wed, 31 Oct 2007 21:19:07 -0000 Subject: [issue1773632] Remove references to _xmlrpclib from xmlrpclib.py Message-ID: <1193865547.04.0.764977466869.issue1773632@psf.upfronthosting.co.za> Mike Klaas added the comment: Patch applies to 2.5 cleanly, test_xmlrpc passes. ---------- nosy: +klaas _____________________________________ Tracker _____________________________________ From report at bugs.python.org Wed Oct 31 22:23:26 2007 From: report at bugs.python.org (Mike Klaas) Date: Wed, 31 Oct 2007 21:23:26 -0000 Subject: [issue738948] Logic Variable Thread Synchronization Message-ID: <1193865806.64.0.969237867196.issue738948@psf.upfronthosting.co.za> Mike Klaas added the comment: PEPs should be proposed on python-list and python-dev. This is a four- year-old idea that seems quite profound in the changes proposed. Recommend closing. ---------- nosy: +klaas ____________________________________ Tracker ____________________________________ From report at bugs.python.org Wed Oct 31 22:26:26 2007 From: report at bugs.python.org (Matthias Klose) Date: Wed, 31 Oct 2007 21:26:26 -0000 Subject: [issue1292] libffi needs an update to support mips64, arm and armeabi on linux Message-ID: <1193865986.53.0.870735160257.issue1292@psf.upfronthosting.co.za> Matthias Klose added the comment: oops, did the same for arm* on trunk, but in configure.in __________________________________ Tracker __________________________________