From report at bugs.python.org Thu Nov 1 00:30:20 2007 From: report at bugs.python.org (Guido van Rossum) Date: Wed, 31 Oct 2007 23:30:20 -0000 Subject: [issue1247] PEP 3137 patch (repr, names, parser) Message-ID: <1193873420.77.0.0578646756249.issue1247@psf.upfronthosting.co.za> Guido van Rossum added the comment: I've submitted the 'harmless' patch (and much, much more) in r58741. I'm closing this now, the rest probably has been implemented one way or another as well. If you see something I missed, please open a new issue with a patch for just that issue. ---------- resolution: -> accepted status: open -> closed __________________________________ Tracker __________________________________ From report at bugs.python.org Thu Nov 1 11:51:53 2007 From: report at bugs.python.org (Tal Einat) Date: Thu, 01 Nov 2007 10:51:53 -0000 Subject: [issue1612746] Enhanced tabbed pane widget Message-ID: <1193914313.69.0.320266540688.issue1612746@psf.upfronthosting.co.za> Tal Einat added the comment: Updated patch as requested. Most of the changes are cosmetic, except one minor bug (kw -> **kw). I added a few comments and doc-strings as well. Consider removing tabpage.py, which is no longer used... Added file: http://bugs.python.org/file8671/IDLE_tabbedpages.071101.patch _____________________________________ Tracker _____________________________________ -------------- next part -------------- A non-text attachment was scrubbed... Name: IDLE_tabbedpages.071101.patch Type: application/octet-stream Size: 7926 bytes Desc: not available Url : http://mail.python.org/pipermail/python-bugs-list/attachments/20071101/773e1555/attachment.obj From report at bugs.python.org Thu Nov 1 15:03:40 2007 From: report at bugs.python.org (Guido van Rossum) Date: Thu, 01 Nov 2007 14:03:40 -0000 Subject: [issue1367] mkdir+chdir problem in multiple threads Message-ID: <1193925820.5.0.154734451618.issue1367@psf.upfronthosting.co.za> Changes by Guido van Rossum: ---------- resolution: -> invalid status: open -> closed __________________________________ Tracker __________________________________ From report at bugs.python.org Thu Nov 1 16:24:57 2007 From: report at bugs.python.org (Kai) Date: Thu, 01 Nov 2007 15:24:57 -0000 Subject: [issue1368] Bug tracker link in about tutorial page is wrong Message-ID: <1193930697.14.0.0930864012953.issue1368@psf.upfronthosting.co.za> New submission from Kai: http://docs.python.org/tut/about.html has instructions for submitting a bug doc, but it points to the SourceForge tracker. Change the link to point to http://bugs.pythong.org ---------- components: Documentation messages: 57008 nosy: ksjohnson severity: minor status: open title: Bug tracker link in about tutorial page is wrong type: resource usage versions: Python 2.5 __________________________________ Tracker __________________________________ From report at bugs.python.org Thu Nov 1 16:26:35 2007 From: report at bugs.python.org (Kai) Date: Thu, 01 Nov 2007 15:26:35 -0000 Subject: [issue1369] Reference to Python24 path in Python 2.5 doc Message-ID: <1193930795.47.0.130226414395.issue1369@psf.upfronthosting.co.za> New submission from Kai: In the second paragraph under 2.1 Invoking the Interpreter, it says on Windows Python defaults to C:\Python24 . This should be C:\Python25 for the 2.5 guide. The set path= command also needs to be changed to C:\Python25. http://docs.python.org/tut/node4.html ---------- components: Documentation messages: 57009 nosy: ksjohnson severity: minor status: open title: Reference to Python24 path in Python 2.5 doc versions: Python 2.5 __________________________________ Tracker __________________________________ From report at bugs.python.org Thu Nov 1 18:07:16 2007 From: report at bugs.python.org (Georg Brandl) Date: Thu, 01 Nov 2007 17:07:16 -0000 Subject: [issue1368] Bug tracker link in about tutorial page is wrong Message-ID: <1193936836.09.0.241188819236.issue1368@psf.upfronthosting.co.za> Georg Brandl added the comment: Thanks, this is already fixed in SVN and will be live after a rebuild of the 2.5 docs (which will happen with the pending release of 2.5.2...) ---------- nosy: +georg.brandl resolution: -> out of date status: open -> closed __________________________________ Tracker __________________________________ From report at bugs.python.org Thu Nov 1 18:07:54 2007 From: report at bugs.python.org (Georg Brandl) Date: Thu, 01 Nov 2007 17:07:54 -0000 Subject: [issue1369] Reference to Python24 path in Python 2.5 doc Message-ID: <1193936874.4.0.793487144659.issue1369@psf.upfronthosting.co.za> Georg Brandl added the comment: Thanks, this is already fixed in SVN and will be live after a rebuild of the 2.5 docs (which will happen with the pending release of 2.5.2...) ---------- nosy: +georg.brandl resolution: -> out of date status: open -> closed __________________________________ Tracker __________________________________ From report at bugs.python.org Thu Nov 1 18:12:27 2007 From: report at bugs.python.org (Georg Brandl) Date: Thu, 01 Nov 2007 17:12:27 -0000 Subject: [issue738948] Logic Variable Thread Synchronization Message-ID: <1193937147.05.0.339800569933.issue738948@psf.upfronthosting.co.za> Georg Brandl added the comment: Agreed. ---------- nosy: +georg.brandl resolution: -> rejected status: open -> closed ____________________________________ Tracker ____________________________________ From report at bugs.python.org Thu Nov 1 18:13:52 2007 From: report at bugs.python.org (Georg Brandl) Date: Thu, 01 Nov 2007 17:13:52 -0000 Subject: [issue1773632] Remove references to _xmlrpclib from xmlrpclib.py Message-ID: <1193937232.0.0.086064081533.issue1773632@psf.upfronthosting.co.za> Changes by Georg Brandl: ---------- assignee: -> effbot nosy: +effbot _____________________________________ Tracker _____________________________________ From report at bugs.python.org Thu Nov 1 18:14:59 2007 From: report at bugs.python.org (Georg Brandl) Date: Thu, 01 Nov 2007 17:14:59 -0000 Subject: [issue1516330] Module uuid: functions for retrieving MAC addres Message-ID: <1193937299.25.0.303628532309.issue1516330@psf.upfronthosting.co.za> Georg Brandl added the comment: Agreed, this is unusable in its current form. ---------- nosy: +georg.brandl resolution: -> rejected status: open -> pending _____________________________________ Tracker _____________________________________ From report at bugs.python.org Thu Nov 1 18:15:59 2007 From: report at bugs.python.org (Georg Brandl) Date: Thu, 01 Nov 2007 17:15:59 -0000 Subject: [issue1651995] sgmllib _convert_ref UnicodeDecodeError exception, new in 2.5 Message-ID: <1193937359.2.0.980330759799.issue1651995@psf.upfronthosting.co.za> Georg Brandl added the comment: Restore bug title. ---------- nosy: +georg.brandl title: sgmllib _convert_ref UnicodeDecodeError exception, new in 2. -> sgmllib _convert_ref UnicodeDecodeError exception, new in 2.5 _____________________________________ Tracker _____________________________________ From report at bugs.python.org Thu Nov 1 18:19:47 2007 From: report at bugs.python.org (Georg Brandl) Date: Thu, 01 Nov 2007 17:19:47 -0000 Subject: [issue1364] os.lstat documentation error Message-ID: <1193937587.5.0.875492197046.issue1364@psf.upfronthosting.co.za> Georg Brandl added the comment: os.lstat is in fact an alias for os.stat on Windows. Corrected the docs in r58745, r58746 (2.5). ---------- nosy: +georg.brandl resolution: -> fixed status: open -> closed __________________________________ Tracker __________________________________ From report at bugs.python.org Thu Nov 1 18:21:38 2007 From: report at bugs.python.org (Georg Brandl) Date: Thu, 01 Nov 2007 17:21:38 -0000 Subject: [issue1355] xml.dom refers to PyXML, which is no longer maintained Message-ID: <1193937698.66.0.68085440466.issue1355@psf.upfronthosting.co.za> Changes by Georg Brandl: ---------- nosy: +georg.brandl __________________________________ Tracker __________________________________ From report at bugs.python.org Thu Nov 1 18:37:45 2007 From: report at bugs.python.org (Ali Polatel) Date: Thu, 01 Nov 2007 17:37:45 -0000 Subject: [issue1651995] sgmllib _convert_ref UnicodeDecodeError exception, new in 2.5 Message-ID: <1193938665.69.0.528221734679.issue1651995@psf.upfronthosting.co.za> Changes by Ali Polatel: ---------- nosy: +hawking _____________________________________ Tracker _____________________________________ From report at bugs.python.org Thu Nov 1 18:39:17 2007 From: report at bugs.python.org (Guido van Rossum) Date: Thu, 01 Nov 2007 17:39:17 -0000 Subject: [issue1663329] subprocess/popen close_fds perform poor if SC_OPEN_MAX is hi Message-ID: <1193938757.13.0.896267177345.issue1663329@psf.upfronthosting.co.za> Guido van Rossum added the comment: Looks good to me. ---------- nosy: +gvanrossum _____________________________________ Tracker _____________________________________ From report at bugs.python.org Thu Nov 1 18:40:49 2007 From: report at bugs.python.org (Guido van Rossum) Date: Thu, 01 Nov 2007 17:40:49 -0000 Subject: [issue1516330] Module uuid: functions for retrieving MAC addres Message-ID: <1193938849.34.0.425708920587.issue1516330@psf.upfronthosting.co.za> Guido van Rossum added the comment: This makes more sense as a 3rd party library. ---------- nosy: +gvanrossum status: pending -> closed _____________________________________ Tracker _____________________________________ From report at bugs.python.org Thu Nov 1 18:41:42 2007 From: report at bugs.python.org (Guido van Rossum) Date: Thu, 01 Nov 2007 17:41:42 -0000 Subject: [issue1516327] Module uuid: reduce pickle footprint Message-ID: <1193938902.83.0.583293374872.issue1516327@psf.upfronthosting.co.za> Guido van Rossum added the comment: No clear problem, no patch. ---------- nosy: +gvanrossum resolution: -> wont fix status: open -> closed _____________________________________ Tracker _____________________________________ From report at bugs.python.org Thu Nov 1 18:44:20 2007 From: report at bugs.python.org (Georg Brandl) Date: Thu, 01 Nov 2007 17:44:20 -0000 Subject: [issue1352] Preliminary stderr patch Message-ID: <1193939060.41.0.222552600619.issue1352@psf.upfronthosting.co.za> Georg Brandl added the comment: You should be able to close it yourself now :) ---------- nosy: +georg.brandl __________________________________ Tracker __________________________________ From report at bugs.python.org Thu Nov 1 18:50:13 2007 From: report at bugs.python.org (billiejoex) Date: Thu, 01 Nov 2007 17:50:13 -0000 Subject: [issue1364] os.lstat documentation error Message-ID: <1193939413.65.0.228922123059.issue1364@psf.upfronthosting.co.za> billiejoex added the comment: What about other platforms? I think it should be an alias for all platforms which does not support symbolic links, not only Windows. __________________________________ Tracker __________________________________ From report at bugs.python.org Thu Nov 1 18:52:34 2007 From: report at bugs.python.org (Georg Brandl) Date: Thu, 01 Nov 2007 17:52:34 -0000 Subject: [issue1364] os.lstat documentation error Message-ID: <1193939554.15.0.889007068287.issue1364@psf.upfronthosting.co.za> Georg Brandl added the comment: It is, and this is also documented that way now. __________________________________ Tracker __________________________________ From report at bugs.python.org Thu Nov 1 18:55:31 2007 From: report at bugs.python.org (Simon) Date: Thu, 01 Nov 2007 17:55:31 -0000 Subject: [issue1651995] sgmllib _convert_ref UnicodeDecodeError exception, new in 2.5 Message-ID: <1193939731.23.0.842766425112.issue1651995@psf.upfronthosting.co.za> Simon added the comment: The 255 -> 127 change works for me. Let me know if I can help with unit tests or whatever to get this patched. _____________________________________ Tracker _____________________________________ From report at bugs.python.org Thu Nov 1 18:58:32 2007 From: report at bugs.python.org (billiejoex) Date: Thu, 01 Nov 2007 17:58:32 -0000 Subject: [issue1364] os.lstat documentation error Message-ID: <1193939912.28.0.0971982119032.issue1364@psf.upfronthosting.co.za> billiejoex added the comment: Thanks. __________________________________ Tracker __________________________________ From report at bugs.python.org Thu Nov 1 19:08:48 2007 From: report at bugs.python.org (Facundo Batista) Date: Thu, 01 Nov 2007 18:08:48 -0000 Subject: [issue1259] string find and rfind methods give a TypeError that is misleading Message-ID: <1193940528.89.0.409747721709.issue1259@psf.upfronthosting.co.za> Facundo Batista added the comment: Created the patch, also send a mail to python-dev to see if somebody wants to review it before me applying it. ---------- assignee: -> facundobatista Added file: http://bugs.python.org/file8672/string_find.patch __________________________________ Tracker __________________________________ -------------- next part -------------- A non-text attachment was scrubbed... Name: string_find.patch Type: text/x-diff Size: 7976 bytes Desc: not available Url : http://mail.python.org/pipermail/python-bugs-list/attachments/20071101/ac51dbd9/attachment.patch From report at bugs.python.org Thu Nov 1 19:36:41 2007 From: report at bugs.python.org (Facundo Batista) Date: Thu, 01 Nov 2007 18:36:41 -0000 Subject: [issue1293] Trailing slash in sys.path cause import failure Message-ID: <1193942201.29.0.706016099684.issue1293@psf.upfronthosting.co.za> Facundo Batista added the comment: Only in win32, in Linux it behaves ok (I put a /tmp/w.py that prints 'w'): 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 sys >>> sys.path.append("/tmp/") >>> import w w >>> ---------- nosy: +facundobatista __________________________________ Tracker __________________________________ From report at bugs.python.org Thu Nov 1 19:49:59 2007 From: report at bugs.python.org (Guido van Rossum) Date: Thu, 01 Nov 2007 18:49:59 -0000 Subject: [issue1352] Preliminary stderr patch In-Reply-To: <1193939060.41.0.222552600619.issue1352@psf.upfronthosting.co.za> Message-ID: Guido van Rossum added the comment: Georg, could you explain somewhere in the tracker docs linked from the tracker side bar what the options are? I looked into giving Christian more tracker privileges before, but I didn't know what to type in the Roles box. IOW I don't know what the allowable roles are, what they mean, or where to find a list that describes them. On 11/1/07, Georg Brandl wrote: > > Georg Brandl added the comment: > > You should be able to close it yourself now :) __________________________________ Tracker __________________________________ From report at bugs.python.org Thu Nov 1 20:06:01 2007 From: report at bugs.python.org (Facundo Batista) Date: Thu, 01 Nov 2007 19:06:01 -0000 Subject: [issue1755179] Deadlocks with fork() and multithreading Message-ID: <1193943961.86.0.91753683482.issue1755179@psf.upfronthosting.co.za> Facundo Batista added the comment: I followed the link you provided. All the discussion there ends asking for a realiable way to test the problem (otherwise, we could be making more mistakes than solving the problem in the different platforms). Please provide a test case, so we include it in the regression tests and know that this won't be broken again. You should provide the smallest code that causes a deadlock for you. ---------- assignee: facundobatista -> _____________________________________ Tracker _____________________________________ From report at bugs.python.org Thu Nov 1 20:07:38 2007 From: report at bugs.python.org (Adam Olsen) Date: Thu, 01 Nov 2007 19:07:38 -0000 Subject: [issue1328] feature request: force BOM option Message-ID: <1193944058.05.0.212980178301.issue1328@psf.upfronthosting.co.za> Adam Olsen added the comment: The problem with "being tolerate" as you suggest is you lose the ability to round-trip. Read in a file using the UTF-8 signature, write it back out, and suddenly nothing else can open it. Conceptually, these signatures shouldn't even be part of the encoding; they're a prefix in the file indicating which encoding to use. Note that the BOM signature (ZWNBSP) is a valid code point. Although it seems unlikely for a file to start with ZWNBSP, if were to chop a file up into smaller chunks and decode them individually you'd be more likely to run into it. (However, it seems general use of ZWNBSP is being discouraged precisely due to this potential for confusion[1]). In summary, guessing the encoding should never be the default. Although it may be appropriate in some contexts, we must ensure we emit the right encoding for those contexts as well. [2] [1] http://unicode.org/faq/utf_bom.html#38 [2] http://unicode.org/faq/utf_bom.html#28 ---------- nosy: +rhamphoryncus __________________________________ Tracker __________________________________ From report at bugs.python.org Thu Nov 1 20:49:32 2007 From: report at bugs.python.org (Christian Heimes) Date: Thu, 01 Nov 2007 19:49:32 -0000 Subject: [issue1293] Trailing slash in sys.path cause import failure Message-ID: <1193946572.59.0.260675656745.issue1293@psf.upfronthosting.co.za> Christian Heimes added the comment: I was able to reproduce the bug on Windows with Python 2.6 and 3.0. I've added an unit test to both versions. ---------- nosy: +tiran priority: -> low resolution: -> accepted versions: +Python 2.6, Python 3.0 __________________________________ Tracker __________________________________ From report at bugs.python.org Thu Nov 1 20:51:09 2007 From: report at bugs.python.org (Guido van Rossum) Date: Thu, 01 Nov 2007 19:51:09 -0000 Subject: [issue1371] Two bsddb tests temporarily commented out in py3k branch Message-ID: <1193946669.52.0.205865214576.issue1371@psf.upfronthosting.co.za> New submission from Guido van Rossum: In Lib/bsddb/test/test_misc.py in the py3k branch I had to disable two test in order to make progress on a mega-merge from the trunk. The tests are test01_badpointer and test04_double_free_make_key_dbt. I commented them out by inserting "## " in front of each line. Can you please re-enable these tests and fix the code that currently breaks then? ---------- assignee: gregory.p.smith messages: 57031 nosy: gregory.p.smith, gvanrossum priority: urgent severity: urgent status: open title: Two bsddb tests temporarily commented out in py3k branch __________________________________ Tracker __________________________________ From report at bugs.python.org Thu Nov 1 20:51:17 2007 From: report at bugs.python.org (Guido van Rossum) Date: Thu, 01 Nov 2007 19:51:17 -0000 Subject: [issue1371] Two bsddb tests temporarily commented out in py3k branch Message-ID: <1193946677.09.0.01197664424.issue1371@psf.upfronthosting.co.za> Changes by Guido van Rossum: ---------- type: -> crash __________________________________ Tracker __________________________________ From report at bugs.python.org Thu Nov 1 20:51:46 2007 From: report at bugs.python.org (Guido van Rossum) Date: Thu, 01 Nov 2007 19:51:46 -0000 Subject: [issue1370] Doc changes left over after mega-merge from trunk Message-ID: <1193946706.15.0.409687132231.issue1370@psf.upfronthosting.co.za> Changes by Guido van Rossum: ---------- severity: normal -> major __________________________________ Tracker __________________________________ From report at bugs.python.org Thu Nov 1 20:54:04 2007 From: report at bugs.python.org (Georg Brandl) Date: Thu, 01 Nov 2007 19:54:04 -0000 Subject: [issue1370] Doc changes left over after mega-merge from trunk Message-ID: <1193946844.6.0.160599998837.issue1370@psf.upfronthosting.co.za> Georg Brandl added the comment: I saw the merge commit and that it missed Doc/, and I feared this. :D But, having caused most of this mess, I'll sort it out right now. __________________________________ Tracker __________________________________ From report at bugs.python.org Thu Nov 1 20:56:30 2007 From: report at bugs.python.org (James G. sack (jim)) Date: Thu, 01 Nov 2007 19:56:30 -0000 Subject: [issue1328] feature request: force BOM option In-Reply-To: <1193944058.05.0.212980178301.issue1328@psf.upfronthosting.co.za> Message-ID: <472A2F3C.7020205@san.rr.com> James G. sack (jim) added the comment: Adam Olsen wrote: > Adam Olsen added the comment: > > The problem with "being tolerate" as you suggest is you lose the ability > to round-trip. Read in a file using the UTF-8 signature, write it back > out, and suddenly nothing else can open it. I'm sorry, I don't see the round-trip problem you describe. If codec utf_8 or utf_8_sig were to accept input with or without the 3-byte BOM, and write it as currently specified without/with the BOM respectively, then _I_ can reread again with either utf_8 or utf_8_sig. No round trip problem _for me_. Now If I need to exchange with some else, that's a different matter. One way or another I need to know what format they need and create the output they require for their input. Am I missing something in your statement of a problem? > Conceptually, these signatures shouldn't even be part of the encoding; > they're a prefix in the file indicating which encoding to use. Yes, I'm aware of that, but you can't predict what you may find in dusty archives, or what someone may give to you. IMO, that's the basis of being tolerant in what you accept, is it not? > Note that the BOM signature (ZWNBSP) is a valid code point. Although it > seems unlikely for a file to start with ZWNBSP, if were to chop a file > up into smaller chunks and decode them individually you'd be more likely > to run into it. (However, it seems general use of ZWNBSP is being > discouraged precisely due to this potential for confusion[1]). I understand that throwing away a ZWNBSP at the beginning of a file does risk discarding data rather than metadata. I also believe the standards people recognized that and deliberately picked a BOM character that is a calculated low risk. I'm willing to accept that risk. > In summary, guessing the encoding should never be the default. Although > it may be appropriate in some contexts, we must ensure we emit the right > encoding for those contexts as well. [2] > > [1] http://unicode.org/faq/utf_bom.html#38 > [2] http://unicode.org/faq/utf_bom.html#28 >From my point of view, I don't see that being tolerant in what _I_ (or my applications) accept violates any guidelines. Please explain where I am wrong. Regards, ..jim __________________________________ Tracker __________________________________ From report at bugs.python.org Thu Nov 1 21:33:07 2007 From: report at bugs.python.org (Georg Brandl) Date: Thu, 01 Nov 2007 20:33:07 -0000 Subject: [issue1370] Doc changes left over after mega-merge from trunk Message-ID: <1193949187.07.0.68586869734.issue1370@psf.upfronthosting.co.za> Georg Brandl added the comment: Okay, resolved and committed in r58752. ---------- resolution: -> fixed status: open -> closed __________________________________ Tracker __________________________________ From report at bugs.python.org Thu Nov 1 21:58:20 2007 From: report at bugs.python.org (Guido van Rossum) Date: Thu, 01 Nov 2007 20:58:20 -0000 Subject: [issue1370] Doc changes left over after mega-merge from trunk Message-ID: <1193950700.54.0.863823174499.issue1370@psf.upfronthosting.co.za> Guido van Rossum added the comment: Hm, what happened to Doc/using? Should that perhaps also be submitted? __________________________________ Tracker __________________________________ From report at bugs.python.org Thu Nov 1 22:00:34 2007 From: report at bugs.python.org (Georg Brandl) Date: Thu, 01 Nov 2007 21:00:34 -0000 Subject: [issue1370] Doc changes left over after mega-merge from trunk Message-ID: <1193950834.15.0.291797791158.issue1370@psf.upfronthosting.co.za> Georg Brandl added the comment: I noted that too, should be in the repos now. __________________________________ Tracker __________________________________ From report at bugs.python.org Thu Nov 1 22:02:00 2007 From: report at bugs.python.org (Guido van Rossum) Date: Thu, 01 Nov 2007 21:02:00 -0000 Subject: [issue1370] Doc changes left over after mega-merge from trunk In-Reply-To: <1193950834.15.0.291797791158.issue1370@psf.upfronthosting.co.za> Message-ID: Guido van Rossum added the comment: On 11/1/07, Georg Brandl wrote: > > Georg Brandl added the comment: > > I noted that too, should be in the repos now. Thanks! And thanks for fixing up my mess so quickly!! __________________________________ Tracker __________________________________ From report at bugs.python.org Thu Nov 1 22:12:36 2007 From: report at bugs.python.org (Christian Heimes) Date: Thu, 01 Nov 2007 21:12:36 -0000 Subject: [issue1293] Trailing slash in sys.path cause import failure Message-ID: <1193951556.89.0.972231352273.issue1293@psf.upfronthosting.co.za> Christian Heimes added the comment: Here is a patch that solves the problem. However the patch is against the py3k sources and I like somebody to review and test it. I don't have enough disk space in my VMWare box to test it against the trunk or 2.5. Reason for the problem: Windows' stat doesn't like trailing slashes. ---------- keywords: +patch nosy: +georg.brandl Added file: http://bugs.python.org/file8674/trailing_slash.patch __________________________________ Tracker __________________________________ -------------- next part -------------- A non-text attachment was scrubbed... Name: trailing_slash.patch Type: text/x-diff Size: 925 bytes Desc: not available Url : http://mail.python.org/pipermail/python-bugs-list/attachments/20071101/4438c802/attachment.patch From report at bugs.python.org Thu Nov 1 22:53:38 2007 From: report at bugs.python.org (Christian Heimes) Date: Thu, 01 Nov 2007 21:53:38 -0000 Subject: [issue1293] Trailing slash in sys.path cause import failure Message-ID: <1193954018.91.0.135000629854.issue1293@psf.upfronthosting.co.za> Christian Heimes added the comment: Fixed patch. Georg pointed out that PyArg_ParseTuple("s") returns a reference to the internal data of the PyString object. The new version copies the path to a fixed width buffer before it mangles the trailing slashes. The new patch applies against the trunk. Brett, you are the import master. Can you review the patch, please? ---------- assignee: -> brett.cannon nosy: +brett.cannon Added file: http://bugs.python.org/file8675/trailing_slash2.patch __________________________________ Tracker __________________________________ -------------- next part -------------- A non-text attachment was scrubbed... Name: trailing_slash2.patch Type: text/x-diff Size: 1304 bytes Desc: not available Url : http://mail.python.org/pipermail/python-bugs-list/attachments/20071101/2764684d/attachment.patch From report at bugs.python.org Thu Nov 1 22:55:46 2007 From: report at bugs.python.org (Gregory P. Smith) Date: Thu, 01 Nov 2007 21:55:46 -0000 Subject: [issue1371] Two bsddb tests temporarily commented out in py3k branch Message-ID: <1193954146.79.0.812281254139.issue1371@psf.upfronthosting.co.za> Gregory P. Smith added the comment: This should be fixed in py3k revision 58761. ---------- keywords: +py3k resolution: -> fixed status: open -> closed __________________________________ Tracker __________________________________ From report at bugs.python.org Thu Nov 1 23:21:34 2007 From: report at bugs.python.org (Adam Olsen) Date: Thu, 01 Nov 2007 22:21:34 -0000 Subject: [issue1328] feature request: force BOM option In-Reply-To: <472A2F3C.7020205@san.rr.com> Message-ID: Adam Olsen added the comment: On 11/1/07, James G. sack (jim) wrote: > > James G. sack (jim) added the comment: > > Adam Olsen wrote: > > Adam Olsen added the comment: > > > > The problem with "being tolerate" as you suggest is you lose the ability > > to round-trip. Read in a file using the UTF-8 signature, write it back > > out, and suddenly nothing else can open it. > > I'm sorry, I don't see the round-trip problem you describe. > > If codec utf_8 or utf_8_sig were to accept input with or without the > 3-byte BOM, and write it as currently specified without/with the BOM > respectively, then _I_ can reread again with either utf_8 or utf_8_sig. > > No round trip problem _for me_. > > Now If I need to exchange with some else, that's a different matter. One > way or another I need to know what format they need and create the > output they require for their input. > > Am I missing something in your statement of a problem? You don't seem to think it's important to interact with other programs. If you're importing with no intent to write out to a common format, then yes, autodetecting the BOM is just fine. Python needs a more general default though, and not guessing is part of that. > > Conceptually, these signatures shouldn't even be part of the encoding; > > they're a prefix in the file indicating which encoding to use. > > Yes, I'm aware of that, but you can't predict what you may find in dusty > archives, or what someone may give to you. IMO, that's the basis of > being tolerant in what you accept, is it not? Garbage in, garbage out. There's a lot of protocols with whitespace, capitalization, etc that you can fudge around while retaining the same contents; character set encodings aren't one of them. __________________________________ Tracker __________________________________ From report at bugs.python.org Thu Nov 1 23:29:05 2007 From: report at bugs.python.org (Travis Oliphant) Date: Thu, 01 Nov 2007 22:29:05 -0000 Subject: [issue1742669] "%d" format handling for long values Message-ID: <1193956145.96.0.631396387437.issue1742669@psf.upfronthosting.co.za> Travis Oliphant added the comment: I have two issues with this patch: 1) I'm not sure it's that bad to need to use '%d' % long(obj) to ensure conversion to a long integer. 2) If this kind of auto-conversion is deemed useful, then the patch itself is rather complicated. I would re-factor so that the same code is not repeated once in the PyNumber_Check and again in the original PyLong_Check and else clauses. Simply check for PyNumber. Then, if not already an int or a long, convert to int first and then long if that creates an error. Then, excecute the two segments of code for int and long objects. ---------- nosy: +teoliphant _____________________________________ Tracker _____________________________________ From report at bugs.python.org Fri Nov 2 02:09:09 2007 From: report at bugs.python.org (Barry A. Warsaw) Date: Fri, 02 Nov 2007 01:09:09 -0000 Subject: [issue1259] string find and rfind methods give a TypeError that is misleading Message-ID: <1193965749.37.0.733914093433.issue1259@psf.upfronthosting.co.za> Barry A. Warsaw added the comment: facundo, robert and i looked at this patch and it seems okay. suggestions: document the reference count semantics of _ParseTupleFinds() and include a definition of that function in a .h file. since its non-public, maybe find.h is the right place to put it? there also some random addition of trailing whitespace in the last hunk of stringobject.c __________________________________ Tracker __________________________________ From report at bugs.python.org Fri Nov 2 02:45:38 2007 From: report at bugs.python.org (Brett Cannon) Date: Fri, 02 Nov 2007 01:45:38 -0000 Subject: [issue1293] Trailing slash in sys.path cause import failure Message-ID: <1193967938.68.0.852903779089.issue1293@psf.upfronthosting.co.za> Brett Cannon added the comment: I will have a look when I can. __________________________________ Tracker __________________________________ From report at bugs.python.org Fri Nov 2 10:45:18 2007 From: report at bugs.python.org (Nick Coghlan) Date: Fri, 02 Nov 2007 09:45:18 -0000 Subject: [issue1705170] contextmanager eats StopIteration Message-ID: <1193996718.45.0.539014502189.issue1705170@psf.upfronthosting.co.za> Nick Coghlan added the comment: Close, but not quite. The problem is that the 'value' argument may be None if instantiation of the exception hasn't been forced before __exit__ gets called. >>> class TestWith(object): ... def __enter__(self): ... pass ... def __exit__(self, exc_type, exc_value, exc_tb): ... print exc_type, exc_value, exc_tb ... >>> from __future__ import with_statement >>> with TestWith(): iter([]).next() ... None Traceback (most recent call last): File "", line 1, in StopIteration That 'None' in the middle there is the problem - contextmanager.__exit__ needs to be detecting that and instantiating the passed in exception if it isn't already instantiated. Something like the following at the start of the else clause should do the trick: if value is None: value = type() ---------- nosy: +ncoghlan _____________________________________ Tracker _____________________________________ From report at bugs.python.org Fri Nov 2 11:13:39 2007 From: report at bugs.python.org (Nick Coghlan) Date: Fri, 02 Nov 2007 10:13:39 -0000 Subject: [issue1705170] contextmanager eats StopIteration Message-ID: <1193998419.22.0.133704761311.issue1705170@psf.upfronthosting.co.za> Nick Coghlan added the comment: Fixed for 2.6 in rev 58766. I'm not sure if it will be possible to get this into 2.5.2. Leaving open against 2.5 until it is checked in on the maintenance branch. ---------- components: +Library (Lib) -None resolution: -> accepted versions: +Python 2.5 _____________________________________ Tracker _____________________________________ From report at bugs.python.org Fri Nov 2 11:14:05 2007 From: report at bugs.python.org (Nick Coghlan) Date: Fri, 02 Nov 2007 10:14:05 -0000 Subject: [issue1705170] contextmanager eats StopIteration Message-ID: <1193998445.17.0.128232162924.issue1705170@psf.upfronthosting.co.za> Changes by Nick Coghlan: ---------- assignee: -> ncoghlan _____________________________________ Tracker _____________________________________ From report at bugs.python.org Fri Nov 2 11:39:31 2007 From: report at bugs.python.org (Peter Weseloh) Date: Fri, 02 Nov 2007 10:39:31 -0000 Subject: [issue1372] zlibmodule.c: int overflow in PyZlib_decompress Message-ID: <1193999971.29.0.358180724062.issue1372@psf.upfronthosting.co.za> New submission from Peter Weseloh: When I use zlib.decompress to decompress a string where the result would be >1 GB I get SystemError: Objects/stringobject.c:4089: bad argument to internal function I tracked that down to an int overflow of r_strlen in PyZlib_decompress. Using Py_ssize_t instead of int solved this for me (on 64bit Linux). The patch is against python/trunk/Modules/zlibmodule.c Revision: 56476 Kind regards, Peter ---------- components: Extension Modules files: int_overflow.diff messages: 57047 nosy: PeterW severity: normal status: open title: zlibmodule.c: int overflow in PyZlib_decompress type: crash versions: Python 2.5 Added file: http://bugs.python.org/file8676/int_overflow.diff __________________________________ Tracker __________________________________ -------------- next part -------------- A non-text attachment was scrubbed... Name: int_overflow.diff Type: application/octet-stream Size: 386 bytes Desc: not available Url : http://mail.python.org/pipermail/python-bugs-list/attachments/20071102/0c946def/attachment-0001.obj From report at bugs.python.org Fri Nov 2 13:46:28 2007 From: report at bugs.python.org (Adam Hupp) Date: Fri, 02 Nov 2007 12:46:28 -0000 Subject: [issue1373] turn off socket timeout in test_xmlrpc Message-ID: <1194007588.59.0.396140192089.issue1373@psf.upfronthosting.co.za> New submission from Adam Hupp: The attached patch resolves the intermittent test_xmlrpc failures reported by Neal Norwitz[0]. test_xmlrpc starts the XMLRPC server with a socket timeout. This puts the socket into non-blocking mode which is incompatible with the use of socket.makefile as used by SocketServer. To work around this the test was specifically ignoring temporary read errors but the ignore was no longer working. The patch resolves this by removing the call to socket.settimeout and the code to ignore temporary read errors. I also had to change the `numrequests' parameter in FailingServerTestCase from 2->1. This test case only makes a single request per test (like the others) so numrequests=2 caused the test to hang. [0]http://mail.python.org/pipermail/python-3000/2007-October/011073.html ---------- components: Tests files: xmlrpc_nonblock.patch messages: 57048 nosy: hupp severity: normal status: open title: turn off socket timeout in test_xmlrpc versions: Python 3.0 Added file: http://bugs.python.org/file8677/xmlrpc_nonblock.patch __________________________________ Tracker __________________________________ -------------- next part -------------- A non-text attachment was scrubbed... Name: xmlrpc_nonblock.patch Type: application/octet-stream Size: 7567 bytes Desc: not available Url : http://mail.python.org/pipermail/python-bugs-list/attachments/20071102/64f78236/attachment.obj From report at bugs.python.org Fri Nov 2 14:24:23 2007 From: report at bugs.python.org (Christian Heimes) Date: Fri, 02 Nov 2007 13:24:23 -0000 Subject: [issue1372] zlibmodule.c: int overflow in PyZlib_decompress Message-ID: <1194009863.18.0.868575184012.issue1372@psf.upfronthosting.co.za> Changes by Christian Heimes: ---------- keywords: +patch priority: -> high resolution: -> accepted versions: +Python 2.6, Python 3.0 __________________________________ Tracker __________________________________ From report at bugs.python.org Fri Nov 2 14:27:43 2007 From: report at bugs.python.org (Christian Heimes) Date: Fri, 02 Nov 2007 13:27:43 -0000 Subject: [issue1265] pdb bug with "with" statement Message-ID: <1194010063.26.0.643285228226.issue1265@psf.upfronthosting.co.za> Christian Heimes added the comment: The bug makes debugging a crux :( ---------- priority: -> high resolution: -> accepted type: -> behavior __________________________________ Tracker __________________________________ From report at bugs.python.org Fri Nov 2 15:00:07 2007 From: report at bugs.python.org (Christian Heimes) Date: Fri, 02 Nov 2007 14:00:07 -0000 Subject: [issue1373] turn off socket timeout in test_xmlrpc Message-ID: <1194012007.74.0.178418208291.issue1373@psf.upfronthosting.co.za> Changes by Christian Heimes: ---------- keywords: +patch, py3k __________________________________ Tracker __________________________________ From report at bugs.python.org Fri Nov 2 16:02:16 2007 From: report at bugs.python.org (Tom Lazar) Date: Fri, 02 Nov 2007 15:02:16 -0000 Subject: [issue1673409] datetime module missing some important methods Message-ID: <1194015736.17.0.312325739544.issue1673409@psf.upfronthosting.co.za> Tom Lazar added the comment: unless I'm missing something important this will do the trick quite nicely: >>> from datetime import datetime >>> datetime(2007, 12, 24, 20, 0).strftime("%s") '1198522800' For most imaginable use cases, where an epoch style time stamp is required this should be enough. HTH, Tom ---------- nosy: +tomster _____________________________________ Tracker _____________________________________ From report at bugs.python.org Fri Nov 2 16:42:34 2007 From: report at bugs.python.org (Skip Montanaro) Date: Fri, 02 Nov 2007 15:42:34 -0000 Subject: [issue1673409] datetime module missing some important methods In-Reply-To: <1194015736.17.0.312325739544.issue1673409@psf.upfronthosting.co.za> Message-ID: <18219.17732.240439.613048@montanaro.dyndns.org> Skip Montanaro added the comment: Tom> unless I'm missing something important this will do the trick quite Tom> nicely: >>>> from datetime import datetime >>>> datetime(2007, 12, 24, 20, 0).strftime("%s") Tom> '1198522800' Tom> For most imaginable use cases, where an epoch style time stamp is Tom> required this should be enough. No fractions of a second... Skip _____________________________________ Tracker _____________________________________ From report at bugs.python.org Fri Nov 2 16:51:36 2007 From: report at bugs.python.org (Jon Ribbens) Date: Fri, 02 Nov 2007 15:51:36 -0000 Subject: [issue1673409] datetime module missing some important methods Message-ID: <1194018696.59.0.4301690798.issue1673409@psf.upfronthosting.co.za> Jon Ribbens added the comment: > No fractions of a second... If we're expecting floating-point, then everything you said earlier about the limitations of ints was a bit redundant ;-) _____________________________________ Tracker _____________________________________ From report at bugs.python.org Fri Nov 2 17:10:16 2007 From: report at bugs.python.org (Guido van Rossum) Date: Fri, 02 Nov 2007 16:10:16 -0000 Subject: [issue1373] turn off socket timeout in test_xmlrpc Message-ID: <1194019816.21.0.465944772947.issue1373@psf.upfronthosting.co.za> Guido van Rossum added the comment: Committed revision 58774. Thanks!!! ---------- nosy: +gvanrossum resolution: -> accepted status: open -> closed __________________________________ Tracker __________________________________ From report at bugs.python.org Fri Nov 2 17:21:25 2007 From: report at bugs.python.org (Guido van Rossum) Date: Fri, 02 Nov 2007 16:21:25 -0000 Subject: [issue1372] zlibmodule.c: int overflow in PyZlib_decompress Message-ID: <1194020485.72.0.453753027728.issue1372@psf.upfronthosting.co.za> Guido van Rossum added the comment: I trust that there's a problem, but this can't be right -- the address of r_strlen is passed to PyArg_ParseTuple corresponding to an 'i' format letter. That will never do. ---------- assignee: -> nnorwitz nosy: +gvanrossum, nnorwitz __________________________________ Tracker __________________________________ From report at bugs.python.org Fri Nov 2 17:30:19 2007 From: report at bugs.python.org (Ralf Schmitt) Date: Fri, 02 Nov 2007 16:30:19 -0000 Subject: [issue1068268] subprocess is not EINTR-safe Message-ID: <1194021018.99.0.869095776166.issue1068268@psf.upfronthosting.co.za> Ralf Schmitt added the comment: In normal application code that signal.alarm is called for a reason. And the caller most probably expects it to interrupt the read calls. So I think the proposed patch is wrong. What was the signal interrupting the read calls? maybe SIGPIPE? ---------- nosy: +schmir _____________________________________ Tracker _____________________________________ From report at bugs.python.org Fri Nov 2 17:51:27 2007 From: report at bugs.python.org (Ralf Schmitt) Date: Fri, 02 Nov 2007 16:51:27 -0000 Subject: [issue846388] Check for signals during regular expression matches Message-ID: <1194022287.72.0.288747929498.issue846388@psf.upfronthosting.co.za> Ralf Schmitt added the comment: here is an example (from http://swtch.com/~rsc/regexp/regexp1.html) python -c 'import re; num=25; r=re.compile("a?"*num+"a"*num); r.match("a"*num)' At work I have seen a real world case of a regular expression which ran for minutes rendering the application unresponsive. We would have been glad to be able to interrupt the regular expression engine and getting a traceback. ---------- nosy: +schmir ____________________________________ Tracker ____________________________________ From report at bugs.python.org Fri Nov 2 17:55:24 2007 From: report at bugs.python.org (Skip Montanaro) Date: Fri, 02 Nov 2007 16:55:24 -0000 Subject: [issue1673409] datetime module missing some important methods In-Reply-To: <1194018696.59.0.4301690798.issue1673409@psf.upfronthosting.co.za> Message-ID: <18219.22105.588043.636156@montanaro.dyndns.org> Skip Montanaro added the comment: >> No fractions of a second... Jon> If we're expecting floating-point, then everything you said earlier Jon> about the limitations of ints was a bit redundant ;-) Yes, sorry. I responded to the mail without going back and reviewing the entire thread. (It's been a couple months.) Note however that my example to_timestamp() function converts the microseconds field to seconds and include them in the result. So, are we concluding that nothing needs to be added to the datetime module? Skip _____________________________________ Tracker _____________________________________ From report at bugs.python.org Fri Nov 2 18:00:00 2007 From: report at bugs.python.org (Skip Montanaro) Date: Fri, 02 Nov 2007 17:00:00 -0000 Subject: [issue1673409] datetime module missing some important methods Message-ID: <1194022800.62.0.587680934475.issue1673409@psf.upfronthosting.co.za> Skip Montanaro added the comment: One other thing worth noting is that %s is not universally available. Solaris, for example, lacks it in its strftime() implementation. (It has a bazillion other non-standard format strings but not %s.) Skip _____________________________________ Tracker _____________________________________ From report at bugs.python.org Fri Nov 2 19:18:39 2007 From: report at bugs.python.org (Jon Ribbens) Date: Fri, 02 Nov 2007 18:18:39 -0000 Subject: [issue1673409] datetime module missing some important methods Message-ID: <1194027519.76.0.285005809015.issue1673409@psf.upfronthosting.co.za> Jon Ribbens added the comment: Well, I still think that a convert-to-time_t function is essential, and I don't buy any of the counter-arguments so far. The only argument I can see is "should it return float or integer?" - floats are inaccurate and integers can't represent partial seconds. _____________________________________ Tracker _____________________________________ From report at bugs.python.org Fri Nov 2 19:27:42 2007 From: report at bugs.python.org (Tal Einat) Date: Fri, 02 Nov 2007 18:27:42 -0000 Subject: [issue1374] IDLE - minor FormatParagraph bug fix Message-ID: <1194028062.43.0.247471106942.issue1374@psf.upfronthosting.co.za> New submission from Tal Einat: The format_paragraph_event method was not returning "break", causing unwanted side effects when called via a key binding. ---------- components: IDLE files: IDLE_FormatParagraph.071102.patch messages: 57060 nosy: kbk, taleinat severity: normal status: open title: IDLE - minor FormatParagraph bug fix versions: Python 2.5, Python 2.6, Python 3.0 Added file: http://bugs.python.org/file8678/IDLE_FormatParagraph.071102.patch __________________________________ Tracker __________________________________ -------------- next part -------------- A non-text attachment was scrubbed... Name: IDLE_FormatParagraph.071102.patch Type: application/octet-stream Size: 385 bytes Desc: not available Url : http://mail.python.org/pipermail/python-bugs-list/attachments/20071102/d6d07374/attachment.obj From report at bugs.python.org Fri Nov 2 19:33:55 2007 From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=) Date: Fri, 02 Nov 2007 18:33:55 -0000 Subject: [issue1374] IDLE - minor FormatParagraph bug fix Message-ID: <1194028435.82.0.692917446992.issue1374@psf.upfronthosting.co.za> Changes by Martin v. L?wis: ---------- keywords: +patch __________________________________ Tracker __________________________________ From report at bugs.python.org Fri Nov 2 20:17:02 2007 From: report at bugs.python.org (Ruben Reifenberg) Date: Fri, 02 Nov 2007 19:17:02 -0000 Subject: [issue1375] hotshot IndexError when loading stats Message-ID: <1194031021.72.0.351195403989.issue1375@psf.upfronthosting.co.za> New submission from Ruben Reifenberg: Python 2.4.4 - 64 Bit This code reproduceably fails with IndexError: pop from empty list def start(x): x.start() if __name__ == "__main__": import hotshot prof = hotshot.Profile("test3_stats") start(prof) #prof.start() prof.stop() prof.close() from hotshot import stats s = stats.load("test3_stats") Note1: This issue may be identical with Issue1019882 (another situation but same Error.) Note2: Workaround exists: Replace the line "start(prof)" with "prof.start()". In this case, the resulting stats (binary) file is 1 Byte shorter, and no error happens. ---------- components: Library (Lib) messages: 57061 nosy: ratsberg severity: minor status: open title: hotshot IndexError when loading stats type: crash versions: Python 2.4 __________________________________ Tracker __________________________________ From report at bugs.python.org Fri Nov 2 20:38:05 2007 From: report at bugs.python.org (Georg Brandl) Date: Fri, 02 Nov 2007 19:38:05 -0000 Subject: [issue1352] Preliminary stderr patch Message-ID: <1194032285.08.0.00713316921755.issue1352@psf.upfronthosting.co.za> Georg Brandl added the comment: I've submitted a new bug in the meta tracker. __________________________________ Tracker __________________________________ From report at bugs.python.org Fri Nov 2 20:51:11 2007 From: report at bugs.python.org (Thomas Heller) Date: Fri, 02 Nov 2007 19:51:11 -0000 Subject: [issue1292] libffi needs an update to support mips64, arm and armeabi on linux Message-ID: <1194033071.84.0.727724680021.issue1292@psf.upfronthosting.co.za> Thomas Heller added the comment: I have now made --with-system-ffi default to "yes" for Linux/alpha*, Linux/arm*, Linux/ppc*, and Linux/s390* machines. If you think it is needed for mips machines also please add this - there's no buildbot where I can check the result. __________________________________ Tracker __________________________________ From report at bugs.python.org Fri Nov 2 21:59:47 2007 From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=) Date: Fri, 02 Nov 2007 20:59:47 -0000 Subject: [issue1352] Preliminary stderr patch Message-ID: <1194037187.13.0.419696717679.issue1352@psf.upfronthosting.co.za> Martin v. L?wis added the comment: I just created http://wiki.python.org/moin/TrackerAccessControl which specifies all permissions in the tracker in detail. ---------- nosy: +loewis __________________________________ Tracker __________________________________ From report at bugs.python.org Fri Nov 2 22:04:35 2007 From: report at bugs.python.org (Guido van Rossum) Date: Fri, 02 Nov 2007 21:04:35 -0000 Subject: [issue1352] Preliminary stderr patch In-Reply-To: <1194037187.13.0.419696717679.issue1352@psf.upfronthosting.co.za> Message-ID: Guido van Rossum added the comment: > http://wiki.python.org/moin/TrackerAccessControl > > which specifies all permissions in the tracker in detail. Is it so that Anonymous < User < Developer < Coordinator? If so, the role field could just be a dropdown instead of a list of roles... __________________________________ Tracker __________________________________ From report at bugs.python.org Fri Nov 2 22:14:26 2007 From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=) Date: Fri, 02 Nov 2007 21:14:26 -0000 Subject: [issue1352] Preliminary stderr patch In-Reply-To: Message-ID: <472B932F.8070403@v.loewis.de> Martin v. L?wis added the comment: > Guido van Rossum added the comment: > >> http://wiki.python.org/moin/TrackerAccessControl >> >> which specifies all permissions in the tracker in detail. > > Is it so that Anonymous < User < Developer < Coordinator? Not in roundup per se, no. It is so in this installation. > If so, the role field could just be a > dropdown instead of a list of roles... I believe a lot of these permissions are redundant. People holding the Developer role typically also hold the User role. It might be possible to drop the User role from the developers, and the User and Developer roles from the Coordinators, without loss of permissions - but there is a chance that doing so would break things in case some permission was forgotten. Regards, Martin __________________________________ Tracker __________________________________ From report at bugs.python.org Fri Nov 2 22:35:40 2007 From: report at bugs.python.org (Ralf Schmitt) Date: Fri, 02 Nov 2007 21:35:40 -0000 Subject: [issue846388] Check for signals during regular expression matches Message-ID: <1194039340.83.0.909027746066.issue846388@psf.upfronthosting.co.za> Ralf Schmitt added the comment: I'm attaching a working patch against 2.5.1 and a short test program. #! /usr/bin/env python import signal import re import time def main(): num=28 # need more than 60s on a 2.4Ghz core 2 r=re.compile("a?"*num+"a"*num) signal.signal(signal.SIGALRM, signal.default_int_handler) signal.alarm(1) stime = time.time() try: r.match("a"*num) except KeyboardInterrupt: assert time.time()-stime<3 else: raise RuntimeError("no keyboard interrupt") if __name__=='__main__': main() Added file: http://bugs.python.org/file8679/patch ____________________________________ Tracker ____________________________________ -------------- next part -------------- A non-text attachment was scrubbed... Name: patch Type: application/octet-stream Size: 1044 bytes Desc: not available Url : http://mail.python.org/pipermail/python-bugs-list/attachments/20071102/0dd1d420/attachment.obj From report at bugs.python.org Fri Nov 2 23:04:29 2007 From: report at bugs.python.org (Ralf Schmitt) Date: Fri, 02 Nov 2007 22:04:29 -0000 Subject: [issue846388] Check for signals during regular expression matches Message-ID: <1194041069.02.0.586963197716.issue846388@psf.upfronthosting.co.za> Ralf Schmitt added the comment: hm. just noticed that calling PyErr_CheckSignals slows down regular expression matching considerably (50%). I'm adding another patch, which only checks every 4096th iteration for signals. Added file: http://bugs.python.org/file8680/patch.speedup ____________________________________ Tracker ____________________________________ -------------- next part -------------- A non-text attachment was scrubbed... Name: patch.speedup Type: application/octet-stream Size: 1405 bytes Desc: not available Url : http://mail.python.org/pipermail/python-bugs-list/attachments/20071102/8a03fae2/attachment.obj From report at bugs.python.org Fri Nov 2 23:21:08 2007 From: report at bugs.python.org (Georg Brandl) Date: Fri, 02 Nov 2007 22:21:08 -0000 Subject: [issue1184] test fixes for immutable bytes change Message-ID: <1194042068.26.0.409087305843.issue1184@psf.upfronthosting.co.za> Changes by Georg Brandl: ---------- assignee: -> gvanrossum nosy: +gvanrossum __________________________________ Tracker __________________________________ From report at bugs.python.org Fri Nov 2 23:23:49 2007 From: report at bugs.python.org (Georg Brandl) Date: Fri, 02 Nov 2007 22:23:49 -0000 Subject: [issue1098] decode_unicode doesn't nul-terminate Message-ID: <1194042229.44.0.0530108295827.issue1098@psf.upfronthosting.co.za> Georg Brandl added the comment: Guido, didn't you fix something about 0-termination in a DecodeUnicode function recently? I can't seem to find the commit now though... ---------- assignee: loewis -> gvanrossum nosy: +gvanrossum __________________________________ Tracker __________________________________ From report at bugs.python.org Fri Nov 2 23:29:27 2007 From: report at bugs.python.org (Georg Brandl) Date: Fri, 02 Nov 2007 22:29:27 -0000 Subject: [issue1752184] PyHeapTypeObject fix Message-ID: <1194042567.01.0.383691113647.issue1752184@psf.upfronthosting.co.za> Georg Brandl added the comment: The patch's changes to typeobject.c are already in the PEP3137 branch (but without the "this is buggy" comment), the others are not. ---------- nosy: +georg.brandl _____________________________________ Tracker _____________________________________ From report at bugs.python.org Fri Nov 2 23:35:52 2007 From: report at bugs.python.org (Guido van Rossum) Date: Fri, 02 Nov 2007 22:35:52 -0000 Subject: [issue1098] decode_unicode doesn't nul-terminate Message-ID: <1194042952.84.0.55309339003.issue1098@psf.upfronthosting.co.za> Guido van Rossum added the comment: Yes I did, in r58709, in the trunk. Please backport to 2.5.2. ---------- assignee: gvanrossum -> __________________________________ Tracker __________________________________ From report at bugs.python.org Fri Nov 2 23:38:39 2007 From: report at bugs.python.org (Guido van Rossum) Date: Fri, 02 Nov 2007 22:38:39 -0000 Subject: [issue1098] decode_unicode doesn't nul-terminate Message-ID: <1194043119.32.0.154917071863.issue1098@psf.upfronthosting.co.za> Guido van Rossum added the comment: Also r58708 and r58707 in the py3k-pep3137 branch. See also bug 1359. __________________________________ Tracker __________________________________ From report at bugs.python.org Fri Nov 2 23:46:15 2007 From: report at bugs.python.org (Guido van Rossum) Date: Fri, 02 Nov 2007 22:46:15 -0000 Subject: [issue1752184] PyHeapTypeObject fix Message-ID: <1194043575.49.0.392816935902.issue1752184@psf.upfronthosting.co.za> Guido van Rossum added the comment: And in the py3k branch as well (r57504). I'll work on the others and on a fix for the "this is buggy" thing. _____________________________________ Tracker _____________________________________ From report at bugs.python.org Fri Nov 2 23:46:47 2007 From: report at bugs.python.org (Georg Brandl) Date: Fri, 02 Nov 2007 22:46:47 -0000 Subject: [issue1098] decode_unicode doesn't nul-terminate Message-ID: <1194043607.77.0.592606617303.issue1098@psf.upfronthosting.co.za> Georg Brandl added the comment: Committed r58814. ---------- resolution: -> fixed status: open -> closed __________________________________ Tracker __________________________________ From report at bugs.python.org Fri Nov 2 23:58:50 2007 From: report at bugs.python.org (Guido van Rossum) Date: Fri, 02 Nov 2007 22:58:50 -0000 Subject: [issue1184] test fixes for immutable bytes change Message-ID: <1194044330.46.0.745193350488.issue1184@psf.upfronthosting.co.za> Guido van Rossum added the comment: This has been superseded by PEP 3137 and the work I've done in the py3k-pep3137 branch. ---------- resolution: -> out of date status: open -> closed __________________________________ Tracker __________________________________ From report at bugs.python.org Sat Nov 3 00:08:01 2007 From: report at bugs.python.org (Guido van Rossum) Date: Fri, 02 Nov 2007 23:08:01 -0000 Subject: [issue1752184] PyHeapTypeObject fix Message-ID: <1194044881.37.0.947572050551.issue1752184@psf.upfronthosting.co.za> Guido van Rossum added the comment: Fix for all issues committed as revision 58815 (in the py3k branch). The strlen() check is replaced by something saner. Thanks for reminding me! ---------- resolution: -> fixed status: open -> closed _____________________________________ Tracker _____________________________________ From report at bugs.python.org Sat Nov 3 00:13:53 2007 From: report at bugs.python.org (billiejoex) Date: Fri, 02 Nov 2007 23:13:53 -0000 Subject: [issue1376] uu module catches a wrong exception type Message-ID: <1194045233.33.0.855077145409.issue1376@psf.upfronthosting.co.za> New submission from billiejoex: uu module on line 53 erroneously tries to catch an AttributeError exception type. try: mode = os.stat(in_file).st_mode except AttributeError: pass This is not correct since os.stat(), as far as I know, should raise OSError exceptions only. This would turn in an error in case we pass a "broken" symlink as in_file argument. ---------- components: Library (Lib) messages: 57077 nosy: billiejoex severity: normal status: open title: uu module catches a wrong exception type type: behavior versions: Python 2.5 __________________________________ Tracker __________________________________ From report at bugs.python.org Sat Nov 3 00:41:00 2007 From: report at bugs.python.org (Brett Cannon) Date: Fri, 02 Nov 2007 23:41:00 -0000 Subject: [issue1673409] datetime module missing some important methods Message-ID: <1194046860.21.0.562862729289.issue1673409@psf.upfronthosting.co.za> Brett Cannon added the comment: This is not going to go anywhere without someone offering a patch to implement this. Plus I suspect this has a much greater use in the C API than in the Python API for datetime. ---------- nosy: +brett.cannon _____________________________________ Tracker _____________________________________ From report at bugs.python.org Sat Nov 3 00:45:03 2007 From: report at bugs.python.org (Guido van Rossum) Date: Fri, 02 Nov 2007 23:45:03 -0000 Subject: [issue1377] test_import breaks on Linux Message-ID: <1194047103.5.0.8046180758.issue1377@psf.upfronthosting.co.za> New submission from Guido van Rossum: Error output: test_import at test/test????test test_import failed -- Traceback (most recent call last): File "/usr/local/google/home/guido/python/py3k-main/Lib/test/test_import.py", line 184, in test_sys_path_with_unicode mod = __import__("testimport%i" % i)ImportError: No module named testimport1 ---------- assignee: tiran messages: 57079 nosy: gvanrossum, tiran severity: normal status: open title: test_import breaks on Linux versions: Python 3.0 __________________________________ Tracker __________________________________ From report at bugs.python.org Sat Nov 3 01:08:58 2007 From: report at bugs.python.org (Jon Ribbens) Date: Sat, 03 Nov 2007 00:08:58 -0000 Subject: [issue1673409] datetime module missing some important methods Message-ID: <1194048538.6.0.0228409278962.issue1673409@psf.upfronthosting.co.za> Jon Ribbens added the comment: Skip has already provided what amounts to a patch. It just needs to be decided whether to (a) not include it, (b) include it with the floating point part, or (c) include it without the floating point part. I couldn't comment as to how many people need it. I can say that I need it, and anyone else who's used to manipulating dates and times either "in a unixy sort of way" or with libraries that are expecting time_t's will need it. _____________________________________ Tracker _____________________________________ From report at bugs.python.org Sat Nov 3 01:24:44 2007 From: report at bugs.python.org (Guido van Rossum) Date: Sat, 03 Nov 2007 00:24:44 -0000 Subject: [issue1171] allow subclassing of bytes type Message-ID: <1194049484.14.0.223069930552.issue1171@psf.upfronthosting.co.za> Guido van Rossum added the comment: Committed revision 58819. ---------- resolution: -> accepted status: open -> closed __________________________________ Tracker __________________________________ From report at bugs.python.org Sat Nov 3 15:02:34 2007 From: report at bugs.python.org (Peter Weseloh) Date: Sat, 03 Nov 2007 14:02:34 -0000 Subject: [issue1372] zlibmodule.c: int overflow in PyZlib_decompress In-Reply-To: <1194020485.72.0.453753027728.issue1372@psf.upfronthosting.co.za> Message-ID: <4db3b0200711030702g140cec65w968542735bc84728@mail.gmail.com> Peter Weseloh added the comment: You are right. The format should be 'l'. I overlooked that. In my case the optional 'buf_size' parameter of 'decompress' is not used anyhow. Shall I change the patch accordingly? It work well for me and I now checked the code of PyArg_ParseTuple (Python/getargs.c) to see what happens. As far as I understand, the given pointer is casted to a pointer to int if the format is 'i' (line 630) . On a 64 bit machine this leads to a downcast from a (64 bit) long to a (32 bit) int, which is OK AFAIK, but I could be wrong. Thanks for pointing that out, Peter 2007/11/2, Guido van Rossum : > > > Guido van Rossum added the comment: > > I trust that there's a problem, but this can't be right -- the address > of r_strlen is passed to PyArg_ParseTuple corresponding to an 'i' format > letter. That will never do. > > ---------- > assignee: -> nnorwitz > nosy: +gvanrossum, nnorwitz > > __________________________________ > Tracker > > __________________________________ > Added file: http://bugs.python.org/file8681/unnamed __________________________________ Tracker __________________________________ -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: unnamed Url: http://mail.python.org/pipermail/python-bugs-list/attachments/20071103/84140cff/attachment.txt From report at bugs.python.org Sat Nov 3 16:17:45 2007 From: report at bugs.python.org (Guido van Rossum) Date: Sat, 03 Nov 2007 15:17:45 -0000 Subject: [issue1376] uu module catches a wrong exception type Message-ID: <1194103065.82.0.350185727152.issue1376@psf.upfronthosting.co.za> Guido van Rossum added the comment: You misunderstand. The try/except is there in case os.stat isn't defined or its result doesn't have a st_mode attribute. If the stat operation fails due to a problem with the file, there's not much point in proceeding since the subsequent open() call would fail the same way. ---------- nosy: +gvanrossum resolution: -> invalid status: open -> closed __________________________________ Tracker __________________________________ From report at bugs.python.org Sat Nov 3 16:24:15 2007 From: report at bugs.python.org (roudkerk) Date: Sat, 03 Nov 2007 15:24:15 -0000 Subject: [issue1378] fromfd() and dup() for _socket on WIndows Message-ID: <1194103455.44.0.390687208828.issue1378@psf.upfronthosting.co.za> New submission from roudkerk: The patch adds support for _socket.fromfd() and _socket.socket.dup() on Windows. It uses the Win32 DuplicateHandle() function. The patch is to socketmodule.c an test_socket.py. ---------- files: socket_fromfd.patch messages: 57084 nosy: roudkerk severity: normal status: open title: fromfd() and dup() for _socket on WIndows type: behavior versions: Python 2.5 Added file: http://bugs.python.org/file8682/socket_fromfd.patch __________________________________ Tracker __________________________________ -------------- next part -------------- A non-text attachment was scrubbed... Name: socket_fromfd.patch Type: application/octet-stream Size: 3915 bytes Desc: not available Url : http://mail.python.org/pipermail/python-bugs-list/attachments/20071103/58236311/attachment.obj From report at bugs.python.org Sat Nov 3 16:42:11 2007 From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=) Date: Sat, 03 Nov 2007 15:42:11 -0000 Subject: [issue1378] fromfd() and dup() for _socket on WIndows Message-ID: <1194104532.0.0.186207846913.issue1378@psf.upfronthosting.co.za> Changes by Martin v. L?wis: ---------- keywords: +patch __________________________________ Tracker __________________________________ From report at bugs.python.org Sat Nov 3 17:51:43 2007 From: report at bugs.python.org (Paul Pogonyshev) Date: Sat, 03 Nov 2007 16:51:43 -0000 Subject: [issue1379] reloading imported modules sometimes fail with 'parent not in sys.modules' error Message-ID: <1194108703.22.0.307056079238.issue1379@psf.upfronthosting.co.za> New submission from Paul Pogonyshev: This is apparently because sys.modules contains Unicode (str) keys, while 'parentname' is an old-style string. Attached patch seems to fix it, but I have no idea if it is correct in principle ---------- components: Interpreter Core files: reloading-fix.diff messages: 57085 nosy: Paul Pogonyshev severity: normal status: open title: reloading imported modules sometimes fail with 'parent not in sys.modules' error versions: Python 3.0 Added file: http://bugs.python.org/file8683/reloading-fix.diff __________________________________ Tracker __________________________________ -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: reloading-fix.diff Url: http://mail.python.org/pipermail/python-bugs-list/attachments/20071103/6726e63a/attachment.txt From report at bugs.python.org Sat Nov 3 18:30:39 2007 From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=) Date: Sat, 03 Nov 2007 17:30:39 -0000 Subject: [issue1379] reloading imported modules sometimes fail with 'parent not in sys.modules' error Message-ID: <1194111039.76.0.148388918263.issue1379@psf.upfronthosting.co.za> Changes by Martin v. L?wis: ---------- keywords: +patch __________________________________ Tracker __________________________________ From report at bugs.python.org Sat Nov 3 19:06:42 2007 From: report at bugs.python.org (Adam Hupp) Date: Sat, 03 Nov 2007 18:06:42 -0000 Subject: [issue1380] fix for test_asynchat and test_asyncore on pep3137 branch Message-ID: <1194113202.87.0.167615791843.issue1380@psf.upfronthosting.co.za> New submission from Adam Hupp: The attached patch resolves test failues in test_asynchat and test_asyncore. The asynchat failure was due to interpolating a byte string into a unicode string using %s. This resulted in a b'' byte representation in the final string. The fix is to use string constants instead of byte constants. The result is encoded to bytes later on. The asyncore failure was due to an explicit isinstance(data, bytes) check on the result of recv. The actual type in this case was buffer. I've removed the check since the next line calls data.replace(b'\n', b'') This all should fail for anything thats not a buffer or bytes. ---------- components: Library (Lib), Tests files: pep3137-asynfix.patch messages: 57086 nosy: hupp severity: normal status: open title: fix for test_asynchat and test_asyncore on pep3137 branch type: behavior versions: Python 3.0 Added file: http://bugs.python.org/file8684/pep3137-asynfix.patch __________________________________ Tracker __________________________________ -------------- next part -------------- A non-text attachment was scrubbed... Name: pep3137-asynfix.patch Type: application/octet-stream Size: 1469 bytes Desc: not available Url : http://mail.python.org/pipermail/python-bugs-list/attachments/20071103/724dd10b/attachment.obj From report at bugs.python.org Sat Nov 3 19:30:55 2007 From: report at bugs.python.org (Christian Heimes) Date: Sat, 03 Nov 2007 18:30:55 -0000 Subject: [issue1380] fix for test_asynchat and test_asyncore on pep3137 branch Message-ID: <1194114655.68.0.0471190184282.issue1380@psf.upfronthosting.co.za> Christian Heimes added the comment: Applied in r58831 Thanks! ---------- keywords: +patch, py3k nosy: +tiran resolution: -> fixed status: open -> closed __________________________________ Tracker __________________________________ From report at bugs.python.org Sat Nov 3 19:58:58 2007 From: report at bugs.python.org (Andreas Kloeckner) Date: Sat, 03 Nov 2007 18:58:58 -0000 Subject: [issue1381] cmath is numerically unsound Message-ID: <1194116338.25.0.15025018351.issue1381@psf.upfronthosting.co.za> New submission from Andreas Kloeckner: This here basically says it all: >>> import cmath;[cmath.asinh(i*1e-17).real for i in range(0,20)] [4.4408920985006257e-16, 4.4408920985006257e-16, 4.4408920985006257e-16, 4.4408920985006257e-16, 4.4408920985006257e-16, 4.4408920985006257e-16, 4.4408920985006257e-16, 4.4408920985006257e-16, 4.4408920985006257e-16, 4.4408920985006257e-16, 4.4408920985006257e-16, 4.4408920985006257e-16, 4.4408920985006257e-16, 4.4408920985006257e-16, 4.4408920985006257e-16, 4.4408920985006257e-16, 4.4408920985006257e-16, 4.4408920985006257e-16, 4.4408920985006257e-16, 4.4408920985006257e-16] The boost.math toolkit at [2] is an implementation that does better in the above (real-only) aspect. [2] http://freespace.virgin.net/boost.regex/toolkit/html/index.html Tim Peters remarks in [1] that basically all of cmath is unsound. http://mail.python.org/pipermail/python-bugs-list/2001-February/004126.html I just wanted to make sure that this issue remains on the radar. ---------- components: Library (Lib) messages: 57088 nosy: inducer severity: normal status: open title: cmath is numerically unsound type: behavior versions: Python 2.5 __________________________________ Tracker __________________________________ From report at bugs.python.org Sat Nov 3 20:17:37 2007 From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=) Date: Sat, 03 Nov 2007 19:17:37 -0000 Subject: [issue1381] cmath is numerically unsound Message-ID: <1194117457.47.0.761476267246.issue1381@psf.upfronthosting.co.za> Martin v. L?wis added the comment: Can you propose a patch? ---------- nosy: +loewis __________________________________ Tracker __________________________________ From report at bugs.python.org Sat Nov 3 20:42:43 2007 From: report at bugs.python.org (Andreas Kloeckner) Date: Sat, 03 Nov 2007 19:42:43 -0000 Subject: [issue1381] cmath is numerically unsound In-Reply-To: <1194117457.47.0.761476267246.issue1381@psf.upfronthosting.co.za> Message-ID: <200711031542.38325.inform@tiker.net> Andreas Kloeckner added the comment: On Samstag 03 November 2007, Martin v. L?wis wrote: > Martin v. L?wis added the comment: > > Can you propose a patch? Other than point at how boost.math does things, I don't have the time to work on this right now, sorry. Andreas __________________________________ Tracker __________________________________ From report at bugs.python.org Sun Nov 4 04:36:42 2007 From: report at bugs.python.org (Guido van Rossum) Date: Sun, 04 Nov 2007 03:36:42 -0000 Subject: [issue1372] zlibmodule.c: int overflow in PyZlib_decompress Message-ID: <1194147402.38.0.412510760033.issue1372@psf.upfronthosting.co.za> Changes by Guido van Rossum: Removed file: http://bugs.python.org/file8681/unnamed __________________________________ Tracker __________________________________ From report at bugs.python.org Sun Nov 4 04:38:42 2007 From: report at bugs.python.org (Guido van Rossum) Date: Sun, 04 Nov 2007 03:38:42 -0000 Subject: [issue1372] zlibmodule.c: int overflow in PyZlib_decompress Message-ID: <1194147522.45.0.756610901785.issue1372@psf.upfronthosting.co.za> Guido van Rossum added the comment: The correct format for a Py_ssize_t is 'n' (at least in the trunk, I don't have the 2.5 branch handy but I imagine it's the same). We can figure out the patch from here. __________________________________ Tracker __________________________________ From report at bugs.python.org Sun Nov 4 06:46:53 2007 From: report at bugs.python.org (Alan McIntyre) Date: Sun, 04 Nov 2007 05:46:53 -0000 Subject: [issue1381] cmath is numerically unsound Message-ID: <1194155213.52.0.238702919538.issue1381@psf.upfronthosting.co.za> Alan McIntyre added the comment: I have to review a few complex math topics for some of my current course work, so I wouldn't mind taking a look into this. I can't promise I'll have the time required to make all of cmath correct (assuming it's as unsound as claimed), but I'll do what I can. ---------- nosy: +alanmcintyre __________________________________ Tracker __________________________________ From report at bugs.python.org Sun Nov 4 12:20:15 2007 From: report at bugs.python.org (Christian Heimes) Date: Sun, 04 Nov 2007 11:20:15 -0000 Subject: [issue1377] test_import breaks on Linux Message-ID: <1194175215.01.0.260995479809.issue1377@psf.upfronthosting.co.za> Christian Heimes added the comment: I'm going to disable the test for now. ---------- keywords: +py3k resolution: -> accepted superseder: -> Crash on Windows if Python runs from a directory with umlauts __________________________________ Tracker __________________________________ From report at bugs.python.org Sun Nov 4 12:51:55 2007 From: report at bugs.python.org (Christian Heimes) Date: Sun, 04 Nov 2007 11:51:55 -0000 Subject: [issue1342] Crash on Windows if Python runs from a directory with umlauts Message-ID: <1194177115.01.0.940511917474.issue1342@psf.upfronthosting.co.za> Christian Heimes added the comment: I've checked in part of the patch in r58837. It doesn't solve the problem but at least it prevents Python from seg faulting on Windows. ---------- keywords: +py3k, rfe priority: -> high resolution: -> accepted __________________________________ Tracker __________________________________ From report at bugs.python.org Sun Nov 4 13:10:35 2007 From: report at bugs.python.org (Christian Heimes) Date: Sun, 04 Nov 2007 12:10:35 -0000 Subject: [issue1379] reloading imported modules sometimes fail with 'parent not in sys.modules' error Message-ID: <1194178235.14.0.698585551084.issue1379@psf.upfronthosting.co.za> Christian Heimes added the comment: Why are you using PyUnicode_AsUTF32String(parentname)? PyUnicode_AsString() is the correct method (although it's not yet in the docs). The rest looks fine. PyModule_GetName() returns a char* from PyUnicode_AsString(). Fixed in r58838. ---------- keywords: +py3k nosy: +tiran resolution: -> fixed status: open -> closed __________________________________ Tracker __________________________________ From report at bugs.python.org Sun Nov 4 13:30:48 2007 From: report at bugs.python.org (Paul Pogonyshev) Date: Sun, 04 Nov 2007 12:30:48 -0000 Subject: [issue1379] reloading imported modules sometimes fail with 'parent not in sys.modules' error Message-ID: <1194179448.68.0.868850720439.issue1379@psf.upfronthosting.co.za> Paul Pogonyshev added the comment: Thank you for the commit. I just had a problem with my package, and since I was not sure if it was a bug in Py3k or the package, I went to debugging the former and found this. I just didn't know how to work with Unicode strings properly. __________________________________ Tracker __________________________________ From report at bugs.python.org Sun Nov 4 14:09:41 2007 From: report at bugs.python.org (Grzegorz Makarewicz) Date: Sun, 04 Nov 2007 13:09:41 -0000 Subject: [issue1772916] xmlrpclib crash when PyXML installed - sgmlop is available Message-ID: <1194181781.67.0.229859307766.issue1772916@psf.upfronthosting.co.za> Grzegorz Makarewicz added the comment: Minimalistic test crash (python 2.5 cvs, sgmlop cvs(pyxml)) - compiled with msvc 2005, where after 10 loops ms-debugger is invoked: data='''\ mws.ScannerLogout 7 ''' import xmlrpclib def main(): i = 1 while 1: print i params, method = xmlrpclib.loads(data) i+=1 main() ---------- components: +Extension Modules -Library (Lib) nosy: +mak -alanmcintyre, effbot, ldeller, loewis title: xmlrpclib crash when PyXML installed -> xmlrpclib crash when PyXML installed - sgmlop is available versions: +3rd party -Python 2.5 _____________________________________ Tracker _____________________________________ From report at bugs.python.org Sun Nov 4 14:12:11 2007 From: report at bugs.python.org (roudkerk) Date: Sun, 04 Nov 2007 13:12:11 -0000 Subject: [issue1378] fromfd() and dup() for _socket on WIndows Message-ID: <1194181931.21.0.875265518186.issue1378@psf.upfronthosting.co.za> Changes by roudkerk: ---------- versions: +Python 2.6 -Python 2.5 __________________________________ Tracker __________________________________ From report at bugs.python.org Sun Nov 4 14:49:32 2007 From: report at bugs.python.org (Christian Heimes) Date: Sun, 04 Nov 2007 13:49:32 -0000 Subject: [issue1210] imaplib does not run under Python 3 Message-ID: <1194184172.08.0.254538491001.issue1210@psf.upfronthosting.co.za> Changes by Christian Heimes: ---------- keywords: +py3k priority: -> normal resolution: -> accepted __________________________________ Tracker __________________________________ From report at bugs.python.org Sun Nov 4 16:16:23 2007 From: report at bugs.python.org (Mark Dickinson) Date: Sun, 04 Nov 2007 15:16:23 -0000 Subject: [issue1381] cmath is numerically unsound Message-ID: <1194189383.11.0.0300801460306.issue1381@psf.upfronthosting.co.za> Mark Dickinson added the comment: I took a look at this a while back, and got as far as writing a pure Python drop-in replacement for cmath, based on Kahan's "branch cuts for elementary functions" paper. This fixes a variety of problems in cmath, including the buggy branch cuts for asinh. File attached, in case it's of any use. As Tim Peters pointed out, the real problem here is a lack of decent unit tests for these functions. I have tests for the file above, but they assume IEEE754 floats, which is probably not an acceptable assumption in general. ---------- nosy: +marketdickinson Added file: http://bugs.python.org/file8685/cmath_py.py __________________________________ Tracker __________________________________ -------------- next part -------------- A non-text attachment was scrubbed... Name: cmath_py.py Type: text/x-python-script Size: 23575 bytes Desc: not available Url : http://mail.python.org/pipermail/python-bugs-list/attachments/20071104/1fdc58f7/attachment-0001.bin From report at bugs.python.org Sun Nov 4 16:49:45 2007 From: report at bugs.python.org (Amaury Forgeot d'Arc) Date: Sun, 04 Nov 2007 15:49:45 -0000 Subject: [issue1382] py3k-pep3137: patch for test_ctypes Message-ID: <1194191385.34.0.481652970532.issue1382@psf.upfronthosting.co.za> New submission from Amaury Forgeot d'Arc: This patch corrects test_ctypes in the py3k-pep3137 branch. Replacing PyBytes_* by PyString_* was 99% of the task. Also had to modify binascii, which used to return buffers instead of bytes strings. Tested on winXP. ---------- components: Tests files: ctypes3.diff messages: 57099 nosy: amaury.forgeotdarc, gvanrossum, tiran severity: normal status: open title: py3k-pep3137: patch for test_ctypes versions: Python 3.0 Added file: http://bugs.python.org/file8686/ctypes3.diff __________________________________ Tracker __________________________________ -------------- next part -------------- A non-text attachment was scrubbed... Name: ctypes3.diff Type: application/octet-stream Size: 15409 bytes Desc: not available Url : http://mail.python.org/pipermail/python-bugs-list/attachments/20071104/546b5895/attachment.obj From report at bugs.python.org Sun Nov 4 16:59:26 2007 From: report at bugs.python.org (Skip Montanaro) Date: Sun, 04 Nov 2007 15:59:26 -0000 Subject: [issue1744580] cvs.get_dialect() return a class object Message-ID: <1194191966.51.0.422677055478.issue1744580@psf.upfronthosting.co.za> Skip Montanaro added the comment: I changed the documentation for 2.5 and 2.6 to reflect the change in semantics. r58840 and r58841. Have a look and let me know if that looks reasonable. ---------- status: open -> pending title: cvs.get_dialect() return a class object -> cvs.get_dialect() return a class object _____________________________________ Tracker _____________________________________ From report at bugs.python.org Sun Nov 4 17:19:49 2007 From: report at bugs.python.org (Skip Montanaro) Date: Sun, 04 Nov 2007 16:19:49 -0000 Subject: [issue1431091] CSV Sniffer fails to report mismatch of column counts Message-ID: <1194193189.91.0.388937801971.issue1431091@psf.upfronthosting.co.za> Skip Montanaro added the comment: This appears to work better in 2.5 and 2.6 (it doesn't crash, though it gets the delimiter wrong) but does indeed fail in 2.4. ---------- nosy: +skip.montanaro _____________________________________ Tracker _____________________________________ From report at bugs.python.org Sun Nov 4 17:59:58 2007 From: report at bugs.python.org (Christian Heimes) Date: Sun, 04 Nov 2007 16:59:58 -0000 Subject: [issue1382] py3k-pep3137: patch for test_ctypes Message-ID: <1194195598.45.0.655315018729.issue1382@psf.upfronthosting.co.za> Christian Heimes added the comment: Applied in r58843. Thank you very much! ---------- keywords: +patch, py3k resolution: -> fixed status: open -> closed __________________________________ Tracker __________________________________ From report at bugs.python.org Sun Nov 4 19:01:18 2007 From: report at bugs.python.org (Guido van Rossum) Date: Sun, 04 Nov 2007 18:01:18 -0000 Subject: [issue1378] fromfd() and dup() for _socket on WIndows Message-ID: <1194199278.25.0.704155895047.issue1378@psf.upfronthosting.co.za> Changes by Guido van Rossum: ---------- nosy: +gvanrossum __________________________________ Tracker __________________________________ From report at bugs.python.org Sun Nov 4 19:38:37 2007 From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=) Date: Sun, 04 Nov 2007 18:38:37 -0000 Subject: [issue1381] cmath is numerically unsound Message-ID: <1194201517.3.0.761948461639.issue1381@psf.upfronthosting.co.za> Martin v. L?wis added the comment: It would be ok if a test is only run on a system with IEEE floats, and skipped elsewhere. For all practical purposes, Python assumes that all systems have IEEE float. __________________________________ Tracker __________________________________ From report at bugs.python.org Sun Nov 4 19:44:56 2007 From: report at bugs.python.org (Christian Heimes) Date: Sun, 04 Nov 2007 18:44:56 -0000 Subject: [issue1384] Windows fix for inspect tests Message-ID: <1194201895.98.0.637065940329.issue1384@psf.upfronthosting.co.za> New submission from Christian Heimes: The patch lower()s the file names on Windows. The tests break on my system because C:\\... != c:\\... ---------- files: py3k_inspect.patch keywords: patch, py3k messages: 57105 nosy: tiran severity: normal status: open title: Windows fix for inspect tests versions: Python 3.0 Added file: http://bugs.python.org/file8688/py3k_inspect.patch __________________________________ Tracker __________________________________ -------------- next part -------------- A non-text attachment was scrubbed... Name: py3k_inspect.patch Type: text/x-diff Size: 2769 bytes Desc: not available Url : http://mail.python.org/pipermail/python-bugs-list/attachments/20071104/919c0601/attachment.patch From report at bugs.python.org Sun Nov 4 19:52:00 2007 From: report at bugs.python.org (Joachim Wagner) Date: Sun, 04 Nov 2007 18:52:00 -0000 Subject: [issue1385] hmac module violates RFC for some hash functions, e.g. sha512 Message-ID: <1194202320.65.0.260919187967.issue1385@psf.upfronthosting.co.za> New submission from Joachim Wagner: (First time submitting a patch to this system.) The hmac module uses a fixed blocksize of 64 bytes. This is fine for many hash functions like md5, sha1 and sha256, but not for sha512 or in the general case. The RFC referenced in the python documentation specifies that the blocksize has to match the hash function. The attached patch is the first of three proposed solutions: 1. use the undocumented block_size attribute of the hashing objects provided in the hashlib modules and fallback to 64 bytes if the attribute is missing (maybe a depreciated warning would be better); in this case it would be a good idea to document to block_size attribute (not included in the patch attached); performance could be improved by making block_size a class attribute 2. document that the blocksize is 64 and that the RFC is only correctly implemented if the hash function also has a blocksize of 64 bytes; optionally include the workaround to subclass hmac.HMAC and overwrite the blocksize (this is documented in the source code, but unfortunately not in the python docu) 3. make the blocksize a keyword argument to the constructor and document that it has to match the hash function's blocksize for full RFC compliance Regards, Joachim ---------- components: None files: hmac_1.patch messages: 57106 nosy: jowagner severity: normal status: open title: hmac module violates RFC for some hash functions, e.g. sha512 type: behavior versions: Python 3.0 Added file: http://bugs.python.org/file8689/hmac_1.patch __________________________________ Tracker __________________________________ -------------- next part -------------- A non-text attachment was scrubbed... Name: hmac_1.patch Type: text/x-diff Size: 652 bytes Desc: not available Url : http://mail.python.org/pipermail/python-bugs-list/attachments/20071104/d0875516/attachment.patch From report at bugs.python.org Sun Nov 4 20:43:40 2007 From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=) Date: Sun, 04 Nov 2007 19:43:40 -0000 Subject: [issue1383] Backport abcoll to 2.6 Message-ID: <1194205420.03.0.879303414883.issue1383@psf.upfronthosting.co.za> Changes by Martin v. L?wis: ---------- keywords: +patch __________________________________ Tracker __________________________________ From report at bugs.python.org Sun Nov 4 20:44:10 2007 From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=) Date: Sun, 04 Nov 2007 19:44:10 -0000 Subject: [issue1385] hmac module violates RFC for some hash functions, e.g. sha512 Message-ID: <1194205450.72.0.550770254952.issue1385@psf.upfronthosting.co.za> Changes by Martin v. L?wis: ---------- keywords: +patch __________________________________ Tracker __________________________________ From report at bugs.python.org Sun Nov 4 20:56:58 2007 From: report at bugs.python.org (Georg Brandl) Date: Sun, 04 Nov 2007 19:56:58 -0000 Subject: [issue1383] Backport abcoll to 2.6 Message-ID: <1194206218.12.0.383443933959.issue1383@psf.upfronthosting.co.za> Georg Brandl added the comment: Is this a successor or a companion to #1026? ---------- nosy: +georg.brandl __________________________________ Tracker __________________________________ From report at bugs.python.org Sun Nov 4 22:22:37 2007 From: report at bugs.python.org (Benjamin Aranguren) Date: Sun, 04 Nov 2007 21:22:37 -0000 Subject: [issue1383] Backport abcoll to 2.6 In-Reply-To: <1194206218.12.0.383443933959.issue1383@psf.upfronthosting.co.za> Message-ID: Benjamin Aranguren added the comment: This is a companion to #1026. On 11/4/07, Georg Brandl wrote: > > Georg Brandl added the comment: > > Is this a successor or a companion to #1026? > > ---------- > nosy: +georg.brandl > > __________________________________ > Tracker > > __________________________________ > __________________________________ Tracker __________________________________ From report at bugs.python.org Sun Nov 4 23:08:37 2007 From: report at bugs.python.org (Amaury Forgeot d'Arc) Date: Sun, 04 Nov 2007 22:08:37 -0000 Subject: [issue1386] py3k-pep3137: patch to ensure that all codecs return bytes Message-ID: <1194214117.31.0.466476826392.issue1386@psf.upfronthosting.co.za> New submission from Amaury Forgeot d'Arc: Most codecs return buffer objects, when the rule is now to return bytes. This patch adds a test, and corrects failing codecs. (more PyBytes_* -> PyString_* replacements) ---------- components: Unicode files: codecs.diff messages: 57109 nosy: amaury.forgeotdarc, tiran severity: normal status: open title: py3k-pep3137: patch to ensure that all codecs return bytes versions: Python 3.0 Added file: http://bugs.python.org/file8690/codecs.diff __________________________________ Tracker __________________________________ -------------- next part -------------- A non-text attachment was scrubbed... Name: codecs.diff Type: application/octet-stream Size: 6692 bytes Desc: not available Url : http://mail.python.org/pipermail/python-bugs-list/attachments/20071104/813be2d3/attachment-0001.obj From report at bugs.python.org Sun Nov 4 23:12:53 2007 From: report at bugs.python.org (Amaury Forgeot d'Arc) Date: Sun, 04 Nov 2007 22:12:53 -0000 Subject: [issue1387] py3k-pep3137: patch for hashlib on Windows Message-ID: <1194214373.18.0.782991994946.issue1387@psf.upfronthosting.co.za> New submission from Amaury Forgeot d'Arc: On Windows, openssl is not always available, in this case python uses its own implementation of md5, sha1 &co. This patch correct the failing tests (test_hashlib and test_uuid), by returning bytes instead of buffers. ---------- components: Windows files: hashlib.diff messages: 57110 nosy: amaury.forgeotdarc, tiran severity: normal status: open title: py3k-pep3137: patch for hashlib on Windows versions: Python 3.0 Added file: http://bugs.python.org/file8691/hashlib.diff __________________________________ Tracker __________________________________ -------------- next part -------------- A non-text attachment was scrubbed... Name: hashlib.diff Type: application/octet-stream Size: 1870 bytes Desc: not available Url : http://mail.python.org/pipermail/python-bugs-list/attachments/20071104/3ce05671/attachment.obj From report at bugs.python.org Mon Nov 5 00:21:05 2007 From: report at bugs.python.org (Christian Heimes) Date: Sun, 04 Nov 2007 23:21:05 -0000 Subject: [issue1386] py3k-pep3137: patch to ensure that all codecs return bytes Message-ID: <1194218465.4.0.710248153229.issue1386@psf.upfronthosting.co.za> Christian Heimes added the comment: Applied in r58848. Thanks for removing the annoying warnings! A small request: Please use self.assert_() and its friends instead of assert() in unit tests. ---------- keywords: +patch, py3k resolution: -> fixed status: open -> closed __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Nov 5 00:21:23 2007 From: report at bugs.python.org (Christian Heimes) Date: Sun, 04 Nov 2007 23:21:23 -0000 Subject: [issue1387] py3k-pep3137: patch for hashlib on Windows Message-ID: <1194218483.3.0.34431937881.issue1387@psf.upfronthosting.co.za> Christian Heimes added the comment: Thanks! Applied in r58847. ---------- keywords: +patch, py3k resolution: -> fixed status: open -> closed __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Nov 5 01:01:26 2007 From: report at bugs.python.org (Christian Heimes) Date: Mon, 05 Nov 2007 00:01:26 -0000 Subject: [issue1388] py3k-pep3137: possible ref leak in ctypes Message-ID: <1194220886.12.0.81605317037.issue1388@psf.upfronthosting.co.za> New submission from Christian Heimes: ~/dev/python/py3k-pep3137$ ./python Lib/test/regrtest.py -R 3:5 test_ctypes test_ctypes beginning 8 repetitions 12345678 ........ test_ctypes leaked [39, -31, 33, -33, 0] references, sum=8 1 test OK. [101762 refs] ---------- assignee: theller components: Library (Lib) keywords: py3k messages: 57113 nosy: theller, tiran priority: normal severity: normal status: open title: py3k-pep3137: possible ref leak in ctypes type: behavior versions: Python 3.0 __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Nov 5 01:16:54 2007 From: report at bugs.python.org (Christian Heimes) Date: Mon, 05 Nov 2007 00:16:54 -0000 Subject: [issue1389] py3k-pep3137: struct module is leaking references Message-ID: <1194221814.03.0.457201446889.issue1389@psf.upfronthosting.co.za> New submission from Christian Heimes: ~/dev/python/py3k-pep3137$ ./python Lib/test/regrtest.py -R 2:4 test_struct test_struct beginning 6 repetitions 123456 ...... test_struct leaked [12, 7, 20, 10] references, sum=49 1 test OK. [65353 refs] ---------- components: Extension Modules keywords: py3k messages: 57114 nosy: tiran priority: normal severity: normal status: open title: py3k-pep3137: struct module is leaking references type: behavior versions: Python 3.0 __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Nov 5 01:58:05 2007 From: report at bugs.python.org (Thomas Conway) Date: Mon, 05 Nov 2007 00:58:05 -0000 Subject: [issue1390] toxml generates output that is not well formed Message-ID: <1194224285.7.0.825321790392.issue1390@psf.upfronthosting.co.za> Changes by Thomas Conway: ---------- components: Library (Lib) nosy: drtomc severity: normal status: open title: toxml generates output that is not well formed type: behavior versions: Python 2.5 __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Nov 5 02:01:04 2007 From: report at bugs.python.org (Thomas Conway) Date: Mon, 05 Nov 2007 01:01:04 -0000 Subject: [issue1390] toxml generates output that is not well formed Message-ID: <1194224464.02.0.498094570041.issue1390@psf.upfronthosting.co.za> New submission from Thomas Conway: The attached script yields a non-well-formed xml document. Added file: http://bugs.python.org/file8692/bug.py __________________________________ Tracker __________________________________ -------------- next part -------------- A non-text attachment was scrubbed... Name: bug.py Type: text/x-python Size: 149 bytes Desc: not available Url : http://mail.python.org/pipermail/python-bugs-list/attachments/20071105/674d768d/attachment.py From report at bugs.python.org Mon Nov 5 02:49:58 2007 From: report at bugs.python.org (Gregory P. Smith) Date: Mon, 05 Nov 2007 01:49:58 -0000 Subject: [issue1391] Adds the .compact() method to bsddb db.DB objects Message-ID: <1194227398.84.0.43254190344.issue1391@psf.upfronthosting.co.za> New submission from Gregory P. Smith: I'm attaching the patch to add this method here just as a place to track it for now. It compiles and it looks right, but it causes a crash within BerkeleyDB when the test case runs using BerkeleyDB 4.6.21. It passes as expected when using 4.4.20 or 4.5.20. I won't commit this until the 4.6 crash issue is resolved. python bindings for the compact method were requested here: http://sourceforge.net/tracker/index.php?func=detail&aid=1724985&group_id=13900&atid=363900 ---------- assignee: gregory.p.smith components: Extension Modules files: add-bsddb-db_compact-gps01.patch.txt keywords: patch, rfe messages: 57116 nosy: gregory.p.smith severity: normal status: open title: Adds the .compact() method to bsddb db.DB objects versions: Python 2.6 Added file: http://bugs.python.org/file8693/add-bsddb-db_compact-gps01.patch.txt __________________________________ Tracker __________________________________ -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: add-bsddb-db_compact-gps01.patch.txt Url: http://mail.python.org/pipermail/python-bugs-list/attachments/20071105/d5278b78/attachment.txt From report at bugs.python.org Mon Nov 5 03:47:28 2007 From: report at bugs.python.org (Andrew McNamara) Date: Mon, 05 Nov 2007 02:47:28 -0000 Subject: [issue1744580] cvs.get_dialect() return a class object Message-ID: <1194230848.48.0.49956519454.issue1744580@psf.upfronthosting.co.za> Andrew McNamara added the comment: Seems okay to me. I had a quick look at the examples section, and it shows a use like the one I mention, but I wonder if the section on dialects should quote the specific examples I mention? _____________________________________ Tracker _____________________________________ From report at bugs.python.org Mon Nov 5 06:31:13 2007 From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=) Date: Mon, 05 Nov 2007 05:31:13 -0000 Subject: [issue1390] toxml generates output that is not well formed Message-ID: <1194240673.6.0.519180604579.issue1390@psf.upfronthosting.co.za> Martin v. L?wis added the comment: That's not a bug in Python, but in your script. You should not pass such a string to createComment. ---------- nosy: +loewis __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Nov 5 06:55:42 2007 From: report at bugs.python.org (Thomas Conway) Date: Mon, 05 Nov 2007 05:55:42 -0000 Subject: [issue1390] toxml generates output that is not well formed Message-ID: <1194242142.55.0.34387182832.issue1390@psf.upfronthosting.co.za> Thomas Conway added the comment: Either it is a bug in the DOM implementation, which should reject comments containing -->, a bug in toxml() which should refuse to serialize unserializable documents, or it is a bug in the documentation. cheers, Tom __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Nov 5 07:07:10 2007 From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=) Date: Mon, 05 Nov 2007 06:07:10 -0000 Subject: [issue1390] toxml generates output that is not well formed Message-ID: <1194242830.44.0.273029041022.issue1390@psf.upfronthosting.co.za> Martin v. L?wis added the comment: It's not a bug in the DOM implementation, as createCommment does not specify an exception in this case. It may be a bug in the W3 DOM specification; please report that to the W3 consortium. It's not a bug in toxml, which should always serialize the DOM tree if possible. As for a bug in the documentation: can you propose a change to the documentation that would make you happy? __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Nov 5 14:17:00 2007 From: report at bugs.python.org (Christian Heimes) Date: Mon, 05 Nov 2007 13:17:00 -0000 Subject: [issue1193] os.system() encoding bug on Windows Message-ID: <1194268620.77.0.838951294591.issue1193@psf.upfronthosting.co.za> Christian Heimes added the comment: Python 3.0 has many more problems at its boundaries to the system on Windows. Large parts of the API that deals with Windows system calls have to be rewritten in order to use the wide char API. ---------- keywords: +py3k nosy: +tiran priority: normal -> high resolution: -> accepted __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Nov 5 14:39:46 2007 From: report at bugs.python.org (Thomas Heller) Date: Mon, 05 Nov 2007 13:39:46 -0000 Subject: [issue1388] py3k-pep3137: possible ref leak in ctypes Message-ID: <1194269986.86.0.307084598845.issue1388@psf.upfronthosting.co.za> Thomas Heller added the comment: ./python Lib/test/regrtest.py -R:: test_ctypes does not report a leak, so I think there is no leak. __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Nov 5 14:53:43 2007 From: report at bugs.python.org (Christian Heimes) Date: Mon, 05 Nov 2007 13:53:43 -0000 Subject: [issue1388] py3k-pep3137: possible ref leak in ctypes In-Reply-To: <1194269986.86.0.307084598845.issue1388@psf.upfronthosting.co.za> Message-ID: <472F2065.2070200@cheimes.de> Christian Heimes added the comment: Thomas Heller wrote: > Thomas Heller added the comment: > > ./python Lib/test/regrtest.py -R:: test_ctypes does not report a leak, > so I think there is no leak. I'm getting $ ./python Lib/test/regrtest.py -R:: test_ctypes test_ctypes beginning 9 repetitions 123456789 ......... test_ctypes leaked [-33, 0, 0, 0] references, sum=-33 1 test OK. [101762 refs] Is that ok? Christian __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Nov 5 15:22:51 2007 From: report at bugs.python.org (Christian Heimes) Date: Mon, 05 Nov 2007 14:22:51 -0000 Subject: [issue1392] py3k-pep3137: str(bytes()) and str(buffer()) should raise TypeError patch Message-ID: <1194272571.2.0.948157868786.issue1392@psf.upfronthosting.co.za> New submission from Christian Heimes: str(bytes()) == repr(bytes()) and str(buffer()) == repr(buffer()) is causing a bunch bugs which are extremely hard to understand. On several occasions I didn't understand the problem until I removed a str() call or made str(bytes()) and str(buffer()) raise an exception. ---------- assignee: gvanrossum components: Interpreter Core files: py3k-pep3137_remove_str_bytes.patch keywords: patch, py3k messages: 57124 nosy: gvanrossum, tiran priority: high severity: normal status: open title: py3k-pep3137: str(bytes()) and str(buffer()) should raise TypeError patch type: behavior versions: Python 3.0 Added file: http://bugs.python.org/file8694/py3k-pep3137_remove_str_bytes.patch __________________________________ Tracker __________________________________ -------------- next part -------------- A non-text attachment was scrubbed... Name: py3k-pep3137_remove_str_bytes.patch Type: text/x-diff Size: 3719 bytes Desc: not available Url : http://mail.python.org/pipermail/python-bugs-list/attachments/20071105/2c8d55c7/attachment.patch From report at bugs.python.org Mon Nov 5 15:31:08 2007 From: report at bugs.python.org (Christian Heimes) Date: Mon, 05 Nov 2007 14:31:08 -0000 Subject: [issue1392] py3k-pep3137: str(bytes()) and str(buffer()) should raise TypeError patch Message-ID: <1194273068.33.0.109493117052.issue1392@psf.upfronthosting.co.za> Christian Heimes added the comment: Err, please remove the (reprfunc) cast and check the language of the error messages, too :) __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Nov 5 16:17:25 2007 From: report at bugs.python.org (Christian Heimes) Date: Mon, 05 Nov 2007 15:17:25 -0000 Subject: [issue1392] py3k-pep3137: str(bytes()) and str(buffer()) should raise TypeError patch Message-ID: <1194275845.09.0.000652683356157.issue1392@psf.upfronthosting.co.za> Christian Heimes added the comment: Here is an updated patch that fixes an error in httplib that was causing the xmlrpc test suite to block. Added file: http://bugs.python.org/file8695/py3k-pep3137_remove_str_bytes2.patch __________________________________ Tracker __________________________________ -------------- next part -------------- A non-text attachment was scrubbed... Name: py3k-pep3137_remove_str_bytes2.patch Type: text/x-diff Size: 5142 bytes Desc: not available Url : http://mail.python.org/pipermail/python-bugs-list/attachments/20071105/8185cd9c/attachment.patch From report at bugs.python.org Mon Nov 5 16:51:31 2007 From: report at bugs.python.org (Guido van Rossum) Date: Mon, 05 Nov 2007 15:51:31 -0000 Subject: [issue1392] py3k-pep3137: str(bytes()) and str(buffer()) should raise TypeError patch Message-ID: <1194277891.77.0.208229875188.issue1392@psf.upfronthosting.co.za> Guido van Rossum added the comment: I'll look at the patches later, but we've gone over this before on the list. str() of *any* object needs to return *something*. Yes, it's unfortunate that this masks bugs in the transitional period, but it really is the best thing in the long run. We had other exceptional treatement for str vs. bytes (e.g. the comparison was raising TypeError for a while) and we had to kill that too. __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Nov 5 16:59:55 2007 From: report at bugs.python.org (Christian Heimes) Date: Mon, 05 Nov 2007 15:59:55 -0000 Subject: [issue1392] py3k-pep3137: str(bytes()) and str(buffer()) should raise TypeError patch In-Reply-To: <1194277891.77.0.208229875188.issue1392@psf.upfronthosting.co.za> Message-ID: <472F3DF9.7070905@cheimes.de> Christian Heimes added the comment: Guido van Rossum wrote: > I'll look at the patches later, but we've gone over this before on the > list. str() of *any* object needs to return *something*. Yes, it's > unfortunate that this masks bugs in the transitional period, but it > really is the best thing in the long run. We had other exceptional > treatement for str vs. bytes (e.g. the comparison was raising TypeError > for a while) and we had to kill that too. Can we agree to a compromise and make str(bytes()) return bytes().decode("ascii")? I think it's a sensible default behavior and catches the errors in the code I've seen so far. Christian __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Nov 5 17:27:04 2007 From: report at bugs.python.org (Christian Heimes) Date: Mon, 05 Nov 2007 16:27:04 -0000 Subject: [issue1392] py3k-pep3137: str(bytes()) and str(buffer()) should raise TypeError patch Message-ID: <1194280024.8.0.33383179622.issue1392@psf.upfronthosting.co.za> Christian Heimes added the comment: New patch: static PyObject * string_str(PyObject *op) { return PyObject_CallMethod(op, "decode", "s", "ascii"); } Added file: http://bugs.python.org/file8696/py3k-pep3137_str_bytes_ascii.patch __________________________________ Tracker __________________________________ -------------- next part -------------- A non-text attachment was scrubbed... Name: py3k-pep3137_str_bytes_ascii.patch Type: text/x-diff Size: 4035 bytes Desc: not available Url : http://mail.python.org/pipermail/python-bugs-list/attachments/20071105/e15e5337/attachment.patch From report at bugs.python.org Mon Nov 5 18:18:28 2007 From: report at bugs.python.org (Thomas Heller) Date: Mon, 05 Nov 2007 17:18:28 -0000 Subject: [issue1388] py3k-pep3137: possible ref leak in ctypes In-Reply-To: <472F2065.2070200@cheimes.de> Message-ID: <472F5060.9050005@ctypes.org> Thomas Heller added the comment: > $ ./python Lib/test/regrtest.py -R:: test_ctypes > test_ctypes > beginning 9 repetitions > 123456789 > ......... > test_ctypes leaked [-33, 0, 0, 0] references, sum=-33 > 1 test OK. > [101762 refs] Yes, I think this is ok. __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Nov 5 18:21:11 2007 From: report at bugs.python.org (Christian Heimes) Date: Mon, 05 Nov 2007 17:21:11 -0000 Subject: [issue1388] py3k-pep3137: possible ref leak in ctypes Message-ID: <1194283271.65.0.413072867652.issue1388@psf.upfronthosting.co.za> Changes by Christian Heimes: ---------- resolution: -> invalid status: open -> closed __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Nov 5 18:39:08 2007 From: report at bugs.python.org (Guido van Rossum) Date: Mon, 05 Nov 2007 17:39:08 -0000 Subject: [issue1392] py3k-pep3137: str(bytes()) and str(buffer()) should raise TypeError patch Message-ID: <1194284348.24.0.642527657304.issue1392@psf.upfronthosting.co.za> Guido van Rossum added the comment: No -- making str(b) return b.decode("ascii") brings back the same issues we had with mindlessly mixing PyString and PyUnicode in 2.x. That was a major disaster. ---------- status: open -> __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Nov 5 19:10:14 2007 From: report at bugs.python.org (Guido van Rossum) Date: Mon, 05 Nov 2007 18:10:14 -0000 Subject: [issue1392] py3k-pep3137: str(bytes()) and str(buffer()) should raise TypeError patch Message-ID: <1194286214.46.0.485152138048.issue1392@psf.upfronthosting.co.za> Guido van Rossum added the comment: A compromise I could live with: add a command line option that makes it a warning. __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Nov 5 20:25:48 2007 From: report at bugs.python.org (Christian Heimes) Date: Mon, 05 Nov 2007 19:25:48 -0000 Subject: [issue1392] py3k-pep3137: str(bytes()) and str(buffer()) should raise TypeError patch In-Reply-To: <1194286214.46.0.485152138048.issue1392@psf.upfronthosting.co.za> Message-ID: <472F6E38.7080007@cheimes.de> Christian Heimes added the comment: Guido van Rossum wrote: > Guido van Rossum added the comment: > > A compromise I could live with: add a command line option that makes it > a warning. Good idea. I can live with it, too. :) How do you like -b: issue warnings about str(bytes_instance) and str(buffer_instance) (-bb: issue errors) Christian __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Nov 5 20:46:51 2007 From: report at bugs.python.org (Christian Heimes) Date: Mon, 05 Nov 2007 19:46:51 -0000 Subject: [issue1392] py3k-pep3137: str(bytes()) and str(buffer()) should raise TypeError patch Message-ID: <1194292011.23.0.924551016046.issue1392@psf.upfronthosting.co.za> Christian Heimes added the comment: I've made a patch with -b -> warning and -bb > type error. I'm not happy with the warning message. Maybe you've a better idea for it. Added file: http://bugs.python.org/file8697/py3k-pep3137_str_bytes_warning.patch __________________________________ Tracker __________________________________ -------------- next part -------------- A non-text attachment was scrubbed... Name: py3k-pep3137_str_bytes_warning.patch Type: text/x-diff Size: 5992 bytes Desc: not available Url : http://mail.python.org/pipermail/python-bugs-list/attachments/20071105/502b5afe/attachment-0001.patch From report at bugs.python.org Mon Nov 5 21:40:45 2007 From: report at bugs.python.org (Paul Pogonyshev) Date: Mon, 05 Nov 2007 20:40:45 -0000 Subject: [issue1393] function comparing lacks NotImplemented error Message-ID: <1194295245.65.0.45134369314.issue1393@psf.upfronthosting.co.za> New submission from Paul Pogonyshev: I believe attached script demonstrates a bug in Python 3000. As far as I can tell, it should print four times 'True'. ---------- components: Interpreter Core files: test.py messages: 57135 nosy: Paul Pogonyshev severity: normal status: open title: function comparing lacks NotImplemented error versions: Python 3.0 Added file: http://bugs.python.org/file8698/test.py __________________________________ Tracker __________________________________ -------------- next part -------------- A non-text attachment was scrubbed... Name: test.py Type: text/x-python Size: 241 bytes Desc: not available Url : http://mail.python.org/pipermail/python-bugs-list/attachments/20071105/36b93137/attachment.py From report at bugs.python.org Mon Nov 5 21:44:23 2007 From: report at bugs.python.org (Guido van Rossum) Date: Mon, 05 Nov 2007 20:44:23 -0000 Subject: [issue1392] py3k-pep3137: str(bytes()) and str(buffer()) should raise TypeError patch In-Reply-To: <1194292011.23.0.924551016046.issue1392@psf.upfronthosting.co.za> Message-ID: Guido van Rossum added the comment: The error message is fine, though you could drop the word "Calling" without loss of information. ;-) Also, most warnings don't seem to use a trailing period. Perhaps you could expand this to also add a trap in the comparison function when Py{String,Bytes} is compared to PyUnicode. __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Nov 5 22:00:30 2007 From: report at bugs.python.org (Christian Heimes) Date: Mon, 05 Nov 2007 21:00:30 -0000 Subject: [issue1392] py3k-pep3137: str(bytes()) and str(buffer()) should raise TypeError patch In-Reply-To: Message-ID: <472F846C.2090200@cheimes.de> Christian Heimes added the comment: Guido van Rossum wrote: > The error message is fine, though you could drop the word "Calling" > without loss of information. ;-) Also, most warnings don't seem to use > a trailing period. > > Perhaps you could expand this to also add a trap in the comparison > function when Py{String,Bytes} is compared to PyUnicode. It's sounds like a reasonable idea. But first I'm going to hit the down with my gf and meet some friends. Cu later! PS: In my humble opinion Amaury Forgeot d'Arc deserves an entry in the Misc/ACKS list for his patches. __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Nov 5 22:04:00 2007 From: report at bugs.python.org (Guido van Rossum) Date: Mon, 05 Nov 2007 21:04:00 -0000 Subject: [issue1392] py3k-pep3137: str(bytes()) and str(buffer()) should raise TypeError patch In-Reply-To: <472F846C.2090200@cheimes.de> Message-ID: Guido van Rossum added the comment: > It's sounds like a reasonable idea. But first I'm going to hit the down > with my gf and meet some friends. Cu later! No! You're not allowed to have a life! :-) (And no hacking drunk, either. :-) > PS: In my humble opinion Amaury Forgeot d'Arc deserves an entry in the > Misc/ACKS list for his patches. Agreed -- done! __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Nov 5 22:36:20 2007 From: report at bugs.python.org (Guido van Rossum) Date: Mon, 05 Nov 2007 21:36:20 -0000 Subject: [issue1384] Windows fix for inspect tests Message-ID: <1194298580.47.0.953446928038.issue1384@psf.upfronthosting.co.za> Guido van Rossum added the comment: Shouldn't this use os.path.normcase() instead of testing for nt and using lower()? ---------- nosy: +gvanrossum __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Nov 5 22:36:50 2007 From: report at bugs.python.org (Thomas Conway) Date: Mon, 05 Nov 2007 21:36:50 -0000 Subject: [issue1390] toxml generates output that is not well formed Message-ID: <1194298610.77.0.967785275262.issue1390@psf.upfronthosting.co.za> Thomas Conway added the comment: Hi Martin, You write: It's not a bug in toxml, which should always serialize the DOM tree if possible. Right! In this case it is *not* possible. The generated serialization is not a well formed XML document. Having just consulted the DOM technical reports, I see that createComment is specified as not generating any exceptions, so although it would be quite a sensible place to check that one was not creating an insane document, probably one should not do the check there. I think you're right that this *is* a bug in DOM, and I will report it there. Having said that, I still think that toxml should throw an exception. In general, if toxml succeeds, I would expect to be able to parse the result. I can propose a doco change, but I think such would only be a partial solution. Something like the following addition to the description for createComment Note that comments containing the string C{-->} may make the document unserializable. cheers, Tom __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Nov 5 22:37:06 2007 From: report at bugs.python.org (Guido van Rossum) Date: Mon, 05 Nov 2007 21:37:06 -0000 Subject: [issue1385] hmac module violates RFC for some hash functions, e.g. sha512 Message-ID: <1194298626.33.0.108914428595.issue1385@psf.upfronthosting.co.za> Changes by Guido van Rossum: ---------- assignee: -> gregory.p.smith nosy: +gregory.p.smith __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Nov 5 23:09:01 2007 From: report at bugs.python.org (Paul Pogonyshev) Date: Mon, 05 Nov 2007 22:09:01 -0000 Subject: [issue1394] simple patch, improving unreachable bytecode removing Message-ID: <1194300541.67.0.109986222934.issue1394@psf.upfronthosting.co.za> New submission from Paul Pogonyshev: This patch improves bytecode output, by removing unreachable code. It doesn't target special cases, as now, but provides a generic implementation. ---------- components: Interpreter Core files: unreachable-code.diff messages: 57141 nosy: Paul Pogonyshev severity: minor status: open title: simple patch, improving unreachable bytecode removing versions: Python 2.6 Added file: http://bugs.python.org/file8699/unreachable-code.diff __________________________________ Tracker __________________________________ -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: unreachable-code.diff Url: http://mail.python.org/pipermail/python-bugs-list/attachments/20071105/fc6bed03/attachment.txt From report at bugs.python.org Mon Nov 5 23:12:58 2007 From: report at bugs.python.org (Gregory P. Smith) Date: Mon, 05 Nov 2007 22:12:58 -0000 Subject: [issue1385] hmac module violates RFC for some hash functions, e.g. sha512 Message-ID: <1194300778.18.0.852860564908.issue1385@psf.upfronthosting.co.za> Gregory P. Smith added the comment: option 1 sounds best. i'll take care of this. thanks for noticing this and providing suggestions and a patch. __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Nov 5 23:14:20 2007 From: report at bugs.python.org (Gregory P. Smith) Date: Mon, 05 Nov 2007 22:14:20 -0000 Subject: [issue1385] hmac module violates RFC for some hash functions, e.g. sha512 Message-ID: <1194300860.95.0.5422187612.issue1385@psf.upfronthosting.co.za> Changes by Gregory P. Smith: ---------- components: +Library (Lib) -None versions: +Python 2.5, Python 2.6 __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Nov 5 23:18:24 2007 From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=) Date: Mon, 05 Nov 2007 22:18:24 -0000 Subject: [issue1390] toxml generates output that is not well formed Message-ID: <1194301104.13.0.872979530887.issue1390@psf.upfronthosting.co.za> Martin v. L?wis added the comment: I'm not willing to change minidom unless there is precedence of how to deal with this case. So can you find DOM implementations in other languages that meet the DOM spec an still reject your code? __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Nov 5 23:38:31 2007 From: report at bugs.python.org (Thomas Conway) Date: Mon, 05 Nov 2007 22:38:31 -0000 Subject: [issue1390] toxml generates output that is not well formed Message-ID: <1194302311.54.0.123589101596.issue1390@psf.upfronthosting.co.za> Thomas Conway added the comment: Hi Martin, toxml() is not part of the DOM, so it could be changed to throw an exception. However, I suggest doing nothing, for the moment - I've posted to the dom mailing list at w3, so I'll see what wisdom we get from its members. cheers, Tom __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Nov 6 00:12:04 2007 From: report at bugs.python.org (Amaury Forgeot d'Arc) Date: Mon, 05 Nov 2007 23:12:04 -0000 Subject: [issue1384] Windows fix for inspect tests Message-ID: <1194304324.06.0.626284684529.issue1384@psf.upfronthosting.co.za> Amaury Forgeot d'Arc added the comment: A slightly modified patch, which uses os.path.normcase before comparing file names. ---------- nosy: +amaury.forgeotdarc Added file: http://bugs.python.org/file8700/py3k_inspect_2.diff __________________________________ Tracker __________________________________ -------------- next part -------------- A non-text attachment was scrubbed... Name: py3k_inspect_2.diff Type: application/octet-stream Size: 2896 bytes Desc: not available Url : http://mail.python.org/pipermail/python-bugs-list/attachments/20071105/bb9baf4c/attachment.obj From report at bugs.python.org Tue Nov 6 01:17:42 2007 From: report at bugs.python.org (Christian Heimes) Date: Tue, 06 Nov 2007 00:17:42 -0000 Subject: [issue1384] Windows fix for inspect tests Message-ID: <1194308262.27.0.522558699593.issue1384@psf.upfronthosting.co.za> Christian Heimes added the comment: Ah, os.path has a method for the job. I should have checked the module before reinventing the wheel ... For some unknown and mysterious reasons the inspect tests are passing again on my machine. I've purged the pyc files before I run the unpatched test suite. Should I apply the patch anyway? __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Nov 6 01:21:36 2007 From: report at bugs.python.org (Amaury Forgeot d'Arc) Date: Tue, 06 Nov 2007 00:21:36 -0000 Subject: [issue1395] py3k: duplicated line endings when using read(1) Message-ID: <1194308496.75.0.337158380504.issue1395@psf.upfronthosting.co.za> New submission from Amaury Forgeot d'Arc: When reading a Windows text file one byte at a time, \r\n get split into two function calls, and the user receives two \n. The following test fails (put it somewhere in test_io.py, inside TextIOWrapperTest for example) def testReadOneByOne(self): txt = io.TextIOWrapper(io.BytesIO(b"AA\r\nBB")) reads = "" while True: c = txt.read(1) if not c: break reads += c self.assertEquals(reads, "AA\nBB") # AssertionError: 'AA\n\nBB' != 'AA\nBB' Note that replacing read(1) by read(2) gives the correct result. This problem is why test_netrc fails on Windows. It may also be the root cause for issue 1142 (when \r\n position is just a multiple of the _CHUNK_SIZE). It also possible that the correction to this problem will have good effects on test_mailbox, which uses tell() and seek() intensively. ---------- messages: 57147 nosy: amaury.forgeotdarc, gvanrossum, tiran severity: normal status: open title: py3k: duplicated line endings when using read(1) versions: Python 3.0 __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Nov 6 01:21:40 2007 From: report at bugs.python.org (Gregory P. Smith) Date: Tue, 06 Nov 2007 00:21:40 -0000 Subject: [issue1385] hmac module violates RFC for some hash functions, e.g. sha512 Message-ID: <1194308500.87.0.841528359675.issue1385@psf.upfronthosting.co.za> Gregory P. Smith added the comment: Fixed in trunk (2.6) svn revision 58868 with rfc 4231 unit tests and tests for the new warnings. The fix parts of that diff should be backported to 2.5. I'm leaving the Python 2.5 flag on the bug until that happens. I'm leaving Python 3.0 and py3k tags on this bug for now until someone merges it into that tree. ---------- keywords: +py3k -patch versions: -Python 2.6 __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Nov 6 01:32:41 2007 From: report at bugs.python.org (Gregory P. Smith) Date: Tue, 06 Nov 2007 00:32:41 -0000 Subject: [issue1385] hmac module violates RFC for some hash functions, e.g. sha512 Message-ID: <1194309161.59.0.237298935386.issue1385@psf.upfronthosting.co.za> Gregory P. Smith added the comment: Fixed in release25-maint branch in svn r58870. ---------- versions: -Python 2.5 __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Nov 6 01:39:57 2007 From: report at bugs.python.org (Amaury Forgeot d'Arc) Date: Tue, 06 Nov 2007 00:39:57 -0000 Subject: [issue1384] Windows fix for inspect tests Message-ID: <1194309597.69.0.788229485502.issue1384@psf.upfronthosting.co.za> Amaury Forgeot d'Arc added the comment: Yes, the patch is needed. The problem arises when you run the python executable in different ways WITHOUT deleting the .pyc files. Example on my machine: Note that the exact path to run python is not the same: >cd C:\dev\python\py3k\PCbuild8 >del /s ..\*.pyc >c:\dev\python\py3k\PCbuild8\win32debug\python_d.exe -E -tt ../lib/test/regrtest.py -v test_inspect [test OK] >C:\dev\python\py3k\PCbuild8\win32debug\python_d.exe -E -tt ../lib/test/regrtest.py -v test_inspect [test FAILED] If I always use the same path the tests succeed. __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Nov 6 01:43:12 2007 From: report at bugs.python.org (Guido van Rossum) Date: Tue, 06 Nov 2007 00:43:12 -0000 Subject: [issue1389] py3k-pep3137: struct module is leaking references Message-ID: <1194309792.54.0.199901810955.issue1389@psf.upfronthosting.co.za> Guido van Rossum added the comment: Committed revision 58871. Finding this took me half a day. It was not a real leak; it was just filling the character cache in stringobject.c slowly with random data. ---------- nosy: +gvanrossum resolution: -> fixed status: open -> closed __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Nov 6 01:46:20 2007 From: report at bugs.python.org (Guido van Rossum) Date: Tue, 06 Nov 2007 00:46:20 -0000 Subject: [issue1395] py3k: duplicated line endings when using read(1) Message-ID: <1194309980.47.0.132640322593.issue1395@psf.upfronthosting.co.za> Guido van Rossum added the comment: Wow, thanks! This is not just a bug on Windows -- it is a bug in the TextIOWrapper code that is just more likely on Windows. It is easily reproduced on Linux too: >>> f = open("@", "wb")>>> f.write(b"a\r\n") 6 >>> f.close() >>> f = open("@", "r") >>> f.read(1) 'a' >>> f.read(1) '\n' >>> ---------- priority: -> high __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Nov 6 03:16:12 2007 From: report at bugs.python.org (Christian Heimes) Date: Tue, 06 Nov 2007 02:16:12 -0000 Subject: [issue1392] py3k-pep3137: str(bytes()) and str(buffer()) should raise TypeError patch Message-ID: <1194315372.6.0.341994801739.issue1392@psf.upfronthosting.co.za> Christian Heimes added the comment: Pfff! I've written my best code after having one or two beers :) Updates: * Added class BytesWarning(Warning) * Added -b/-bb command line args and Py_BytesWarningFlag * issue PyErr_WarnEx(PyExc_BytesWarning) when Py_BytesWarningFlag is set. * Added warning filter for BytesWarning that raises an exception if Py_BytesWarningFlag > 1 Open questions: * the warning filter isn't set when the initializer cannot load the warning module (e.g. frozen apps). W/o the warning module Python is screwed anyway and frozen apps would never add the -b argument. * the warnings are only enabled with -b. They can't be enabled by modifying the warnings.filters. Is this fine with you? Added file: http://bugs.python.org/file8701/py3k-pep3137_str_bytes_warning2.patch __________________________________ Tracker __________________________________ -------------- next part -------------- A non-text attachment was scrubbed... Name: py3k-pep3137_str_bytes_warning2.patch Type: text/x-diff Size: 12992 bytes Desc: not available Url : http://mail.python.org/pipermail/python-bugs-list/attachments/20071106/3dee02bf/attachment-0001.patch From report at bugs.python.org Tue Nov 6 03:18:37 2007 From: report at bugs.python.org (Christian Heimes) Date: Tue, 06 Nov 2007 02:18:37 -0000 Subject: [issue1345] Fix for test_netrc on Windows Message-ID: <1194315517.93.0.0158785975852.issue1345@psf.upfronthosting.co.za> Changes by Christian Heimes: ---------- keywords: +py3k resolution: -> invalid status: open -> closed superseder: -> py3k: duplicated line endings when using read(1) __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Nov 6 04:44:21 2007 From: report at bugs.python.org (Guido van Rossum) Date: Tue, 06 Nov 2007 03:44:21 -0000 Subject: [issue1392] py3k-pep3137: str(bytes()) and str(buffer()) should raise TypeError patch In-Reply-To: <1194315372.6.0.341994801739.issue1392@psf.upfronthosting.co.za> Message-ID: Guido van Rossum added the comment: > Updates: > * Added class BytesWarning(Warning) > * Added -b/-bb command line args and Py_BytesWarningFlag > * issue PyErr_WarnEx(PyExc_BytesWarning) when Py_BytesWarningFlag is set. > * Added warning filter for BytesWarning that raises an exception if > Py_BytesWarningFlag > 1 > > Open questions: > * the warning filter isn't set when the initializer cannot load the > warning module (e.g. frozen apps). W/o the warning module Python is > screwed anyway and frozen apps would never add the -b argument. > * the warnings are only enabled with -b. They can't be enabled by > modifying the warnings.filters. Is this fine with you? Yes, this is is all fine with me. Feel free to submit overnight. __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Nov 6 05:36:32 2007 From: report at bugs.python.org (Raghuram Devarakonda) Date: Tue, 06 Nov 2007 04:36:32 -0000 Subject: [issue1395] py3k: duplicated line endings when using read(1) Message-ID: <1194323792.55.0.580361470916.issue1395@psf.upfronthosting.co.za> Raghuram Devarakonda added the comment: I think the solution is to do the translation on a bigger chunk than on the string being returned in each read call. For example, the following patch correctly returns "a" and "\n" (instead of "a" and two "\n"s). Index: Lib/io.py =================================================================== --- Lib/io.py (revision 58874) +++ Lib/io.py (working copy) @@ -1253,8 +1253,9 @@ res += pending if not readahead: break + res = self._replacenl(res) self._pending = res[n:] - return self._replacenl(res[:n]) + return res[:n] def __next__(self): self._telling = False ----------------- Of course, we need to take care of the case when the last character in "res" is "\r" to be followed by "\n" in the next read. I just wanted to see if I am on the right track and if so, I can spend more time on this. ---------- nosy: +draghuram __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Nov 6 05:50:44 2007 From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=) Date: Tue, 06 Nov 2007 04:50:44 -0000 Subject: [issue1394] simple patch, improving unreachable bytecode removing Message-ID: <1194324644.51.0.389788766233.issue1394@psf.upfronthosting.co.za> Changes by Martin v. L?wis: ---------- keywords: +patch __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Nov 6 08:32:12 2007 From: report at bugs.python.org (Georg Brandl) Date: Tue, 06 Nov 2007 07:32:12 -0000 Subject: [issue1385] hmac module violates RFC for some hash functions, e.g. sha512 Message-ID: <1194334332.32.0.964568381778.issue1385@psf.upfronthosting.co.za> Changes by Georg Brandl: ---------- resolution: -> fixed status: open -> closed __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Nov 6 09:11:58 2007 From: report at bugs.python.org (Amaury Forgeot d'Arc) Date: Tue, 06 Nov 2007 08:11:58 -0000 Subject: [issue1395] py3k: duplicated line endings when using read(1) Message-ID: <1194336718.28.0.668207079599.issue1395@psf.upfronthosting.co.za> Amaury Forgeot d'Arc added the comment: Some thoughts: - is it ok to call replacenl multiple times on the same string? \r\r\n and other combinations like this. - I wonder if it is possible to correctly handle \r\n at the CHUNK_SIZE limit without an incremental decoder. it seems that we need at least a flag saying "\r was previously read, ignore the next \n" __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Nov 6 12:17:10 2007 From: report at bugs.python.org (Joachim Wagner) Date: Tue, 06 Nov 2007 11:17:10 -0000 Subject: [issue1385] hmac module violates RFC for some hash functions, e.g. sha512 Message-ID: <1194347830.71.0.767968928347.issue1385@psf.upfronthosting.co.za> Joachim Wagner added the comment: Thanks. Looks great! Also thanks for the hint to rfc 4321. This answers the questions how my application can identify whether the right python version is running. JJ __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Nov 6 12:37:59 2007 From: report at bugs.python.org (Christian Heimes) Date: Tue, 06 Nov 2007 11:37:59 -0000 Subject: [issue1396] py3k-pep3137: patch for mailbox Message-ID: <1194349078.97.0.791611531221.issue1396@psf.upfronthosting.co.za> New submission from Christian Heimes: Hi Yhg1s! svn praise shows your name for Lib/mailbox.py more often then other names. Can you look at my patch and see if it's correct? It fixes most of the errors in test_mailbox.py and all tests in test_old_mailbox. I'm unsure about the patch. Crys ---------- assignee: twouters components: Library (Lib) files: py3k-pep3137_fix_mailbox.patch keywords: patch, py3k messages: 57158 nosy: tiran, twouters priority: normal severity: normal status: open title: py3k-pep3137: patch for mailbox type: behavior versions: Python 3.0 Added file: http://bugs.python.org/file8702/py3k-pep3137_fix_mailbox.patch __________________________________ Tracker __________________________________ -------------- next part -------------- A non-text attachment was scrubbed... Name: py3k-pep3137_fix_mailbox.patch Type: text/x-diff Size: 1603 bytes Desc: not available Url : http://mail.python.org/pipermail/python-bugs-list/attachments/20071106/31ebcd8e/attachment.patch From report at bugs.python.org Tue Nov 6 12:45:36 2007 From: report at bugs.python.org (Christian Heimes) Date: Tue, 06 Nov 2007 11:45:36 -0000 Subject: [issue1384] Windows fix for inspect tests Message-ID: <1194349536.77.0.991940609866.issue1384@psf.upfronthosting.co.za> Christian Heimes added the comment: Applied to py3k in r58875. I'm doing a svnmerge later. Thanks again for your help, pal! ---------- components: +Windows resolution: -> fixed status: open -> closed __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Nov 6 12:53:53 2007 From: report at bugs.python.org (Christian Heimes) Date: Tue, 06 Nov 2007 11:53:53 -0000 Subject: [issue1392] py3k-pep3137: issue warnings / errors on str(bytes()) and similar operations Message-ID: <1194350033.76.0.193001061128.issue1392@psf.upfronthosting.co.za> Christian Heimes added the comment: Applied to py3k-pep3137 in r 58876 ---------- resolution: -> fixed status: -> closed title: py3k-pep3137: str(bytes()) and str(buffer()) should raise TypeError patch -> py3k-pep3137: issue warnings / errors on str(bytes()) and similar operations __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Nov 6 13:29:25 2007 From: report at bugs.python.org (Christian Heimes) Date: Tue, 06 Nov 2007 12:29:25 -0000 Subject: [issue1397] py3k-pep3137: failing unit test test_bsddb Message-ID: <1194352164.91.0.707733802252.issue1397@psf.upfronthosting.co.za> New submission from Christian Heimes: Exception in thread writer 2: Traceback (most recent call last): File "/home/heimes/dev/python/py3k-pep3137/Lib/threading.py", line 485, in _bootstrap_inner self.run() File "/home/heimes/dev/python/py3k-pep3137/Lib/threading.py", line 445, in run self._target(*self._args, **self._kwargs) File "/home/heimes/dev/python/py3k-pep3137/Lib/bsddb/test/test_thread.py", line 80, in writerThread self._writerThread(*args, **kwargs) File "/home/heimes/dev/python/py3k-pep3137/Lib/bsddb/test/test_thread.py", line 254, in _writerThread self.assertEqual(data, self.makeData(key)) File "/home/heimes/dev/python/py3k-pep3137/Lib/unittest.py", line 325, in failUnlessEqual raise self.failureException(msg or '%r != %r' % (first, second)) AssertionError: None != b'2226-2226-2226-2226-2226' Exception in thread writer 1: Traceback (most recent call last): File "/home/heimes/dev/python/py3k-pep3137/Lib/threading.py", line 485, in _bootstrap_inner self.run() File "/home/heimes/dev/python/py3k-pep3137/Lib/threading.py", line 445, in run self._target(*self._args, **self._kwargs) File "/home/heimes/dev/python/py3k-pep3137/Lib/bsddb/test/test_thread.py", line 80, in writerThread self._writerThread(*args, **kwargs) File "/home/heimes/dev/python/py3k-pep3137/Lib/bsddb/test/test_thread.py", line 269, in _writerThread self.assertEqual(data, self.makeData(key)) File "/home/heimes/dev/python/py3k-pep3137/Lib/unittest.py", line 325, in failUnlessEqual raise self.failureException(msg or '%r != %r' % (first, second)) AssertionError: None != b'1007-1007-1007-1007-1007' Exception in thread writer 0: Traceback (most recent call last): File "/home/heimes/dev/python/py3k-pep3137/Lib/threading.py", line 485, in _bootstrap_inner self.run() File "/home/heimes/dev/python/py3k-pep3137/Lib/threading.py", line 445, in run self._target(*self._args, **self._kwargs) File "/home/heimes/dev/python/py3k-pep3137/Lib/bsddb/test/test_thread.py", line 80, in writerThread self._writerThread(*args, **kwargs) File "/home/heimes/dev/python/py3k-pep3137/Lib/bsddb/test/test_thread.py", line 269, in _writerThread self.assertEqual(data, self.makeData(key)) File "/home/heimes/dev/python/py3k-pep3137/Lib/unittest.py", line 325, in failUnlessEqual raise self.failureException(msg or '%r != %r' % (first, second)) AssertionError: None != b'0004-0004-0004-0004-0004' Ubuntu Linux 7.10, i386, db 4.4.20 ---------- components: Tests keywords: py3k messages: 57161 nosy: gvanrossum, tiran priority: normal severity: normal status: open title: py3k-pep3137: failing unit test test_bsddb versions: Python 3.0 __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Nov 6 13:49:08 2007 From: report at bugs.python.org (Christian Heimes) Date: Tue, 06 Nov 2007 12:49:08 -0000 Subject: [issue1397] py3k-pep3137: failing unit test test_bsddb Message-ID: <1194353348.7.0.729460162219.issue1397@psf.upfronthosting.co.za> Christian Heimes added the comment: Correction: The unit test isn't marked as failing but the failing assertion don't look good. __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Nov 6 17:12:19 2007 From: report at bugs.python.org (Raghuram Devarakonda) Date: Tue, 06 Nov 2007 16:12:19 -0000 Subject: [issue1395] py3k: duplicated line endings when using read(1) Message-ID: <1194365539.01.0.471765788664.issue1395@psf.upfronthosting.co.za> Raghuram Devarakonda added the comment: I am attaching the patch io.diff that does the following: - If a chunk ends in "\r", read the next chunk to check if it starts with "\n". This is obviously a very simplified solution that can be optimized. - invoke _replacenl on the complete string read instead of what is being returned in each read call. I also incorporated the test case by Amaury and added one more. With this patch in place, the following tests failed (on SuSE 10.1): test_doctest test_mailbox test_nis test_old_mailbox test_pickletools test_pty test_sys The failures (other than known test_mailbox and test_old_mailbox) didn't look like they are caused by this fix. Added file: http://bugs.python.org/file8703/io.diff __________________________________ Tracker __________________________________ -------------- next part -------------- A non-text attachment was scrubbed... Name: io.diff Type: text/x-patch Size: 1965 bytes Desc: not available Url : http://mail.python.org/pipermail/python-bugs-list/attachments/20071106/3c8772c1/attachment.bin From report at bugs.python.org Tue Nov 6 17:51:50 2007 From: report at bugs.python.org (Amaury Forgeot d'Arc) Date: Tue, 06 Nov 2007 16:51:50 -0000 Subject: [issue1395] py3k: duplicated line endings when using read(1) Message-ID: <1194367910.86.0.84550784944.issue1395@psf.upfronthosting.co.za> Amaury Forgeot d'Arc added the comment: This patch goes in the right direction, but has several problems IMO: - it reads a complete chunk for just one more byte - the re-read should be disabled when lineends are not translated these two are minor annoyance and can be easily corrected, but: - there is no limit to the re-read; it can exhaust the memory if the source is a big file with many \r (like a Mac text file) - How does this behave if the underlying stream has not yet available data (a socket, a terminal, or an opened file): will the re-read block at the 129th byte until more data is available? If so, it is annoying for a simple call to read(1). I will try to write these test cases if you want. __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Nov 6 18:37:59 2007 From: report at bugs.python.org (Guido van Rossum) Date: Tue, 06 Nov 2007 17:37:59 -0000 Subject: [issue1393] function comparing lacks NotImplemented error Message-ID: <1194370679.92.0.607107344057.issue1393@psf.upfronthosting.co.za> Guido van Rossum added the comment: Odd. I'll look into it. ---------- assignee: -> gvanrossum nosy: +gvanrossum priority: -> normal __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Nov 6 18:40:44 2007 From: report at bugs.python.org (Guido van Rossum) Date: Tue, 06 Nov 2007 17:40:44 -0000 Subject: [issue1394] simple patch, improving unreachable bytecode removing Message-ID: <1194370844.26.0.482188142702.issue1394@psf.upfronthosting.co.za> Changes by Guido van Rossum: ---------- nosy: +gvanrossum __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Nov 6 18:43:35 2007 From: report at bugs.python.org (Guido van Rossum) Date: Tue, 06 Nov 2007 17:43:35 -0000 Subject: [issue1395] py3k: duplicated line endings when using read(1) Message-ID: <1194371015.45.0.540723310693.issue1395@psf.upfronthosting.co.za> Guido van Rossum added the comment: IMO you shouldn't read another chunk when the last character you've seen is \r; instead, you should set a flag so that on the next read, you'll ignore an initial \n. The flag should be made of the tell/seek state as well. (The problem with reading another character is that in interactive input mode, this might force the user to type an entire second line.) __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Nov 6 18:48:52 2007 From: report at bugs.python.org (Guido van Rossum) Date: Tue, 06 Nov 2007 17:48:52 -0000 Subject: [issue1397] py3k-pep3137: failing unit test test_bsddb Message-ID: <1194371332.66.0.432043579181.issue1397@psf.upfronthosting.co.za> Guido van Rossum added the comment: I've seen this too occasionally. Greg, can you look at this? ---------- assignee: -> gregory.p.smith nosy: +gregory.p.smith __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Nov 6 18:51:45 2007 From: report at bugs.python.org (Guido van Rossum) Date: Tue, 06 Nov 2007 17:51:45 -0000 Subject: [issue1396] py3k-pep3137: patch for mailbox Message-ID: <1194371505.14.0.625280447212.issue1396@psf.upfronthosting.co.za> Guido van Rossum added the comment: If Yhgls is twouters, I think he's on vacation. Possibly Thomas appears on the blame list because he did some big integrations. Is he on the blame list for the trunk as well? Anyway I want this over with so I'll look into it. ---------- nosy: +gvanrossum __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Nov 6 18:52:23 2007 From: report at bugs.python.org (Raghuram Devarakonda) Date: Tue, 06 Nov 2007 17:52:23 -0000 Subject: [issue1395] py3k: duplicated line endings when using read(1) In-Reply-To: <1194367910.86.0.84550784944.issue1395@psf.upfronthosting.co.za> Message-ID: <2c51ecee0711060952i68c7f354r814c51af7897bf29@mail.gmail.com> Raghuram Devarakonda added the comment: On 11/6/07, Amaury Forgeot d'Arc wrote: > - it reads a complete chunk for just one more byte > - the re-read should be disabled when lineends are not translated > these two are minor annoyance and can be easily corrected, but: > > - there is no limit to the re-read; it can exhaust the memory if the > source is a big file with many \r (like a Mac text file) Yes. reading another chunk is not an optimal solution but after seeing Guido's comment, I now agree that I shouldn't try to read at all. I will work on modifications. > I will try to write these test cases if you want. That will definitely be useful. __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Nov 6 19:15:32 2007 From: report at bugs.python.org (Christian Heimes) Date: Tue, 06 Nov 2007 18:15:32 -0000 Subject: [issue1396] py3k-pep3137: patch for mailbox Message-ID: <1194372932.38.0.277638688927.issue1396@psf.upfronthosting.co.za> Christian Heimes added the comment: Yes, Yhg1s is Thomas nick on #python. On the trunk svn annotate shows Andrew as the author of most lines. Maybe he can shed some light on the problem. I'm not familiar with the details of the mailbox format. ---------- assignee: twouters -> akuchling nosy: +akuchling __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Nov 6 19:21:09 2007 From: report at bugs.python.org (Christian Heimes) Date: Tue, 06 Nov 2007 18:21:09 -0000 Subject: [issue1395] py3k: duplicated line endings when using read(1) In-Reply-To: <1194371015.45.0.540723310693.issue1395@psf.upfronthosting.co.za> Message-ID: <4730B093.2020804@cheimes.de> Christian Heimes added the comment: Guido van Rossum wrote: > IMO you shouldn't read another chunk when the last character you've seen > is \r; instead, you should set a flag so that on the next read, you'll > ignore an initial \n. The flag should be made of the tell/seek state as > well. In my opinion the check for \r should only happen when os.linesep or newline starts with \r. On Unix with standard newline the \r should be treated as every other char. Christian __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Nov 6 19:34:04 2007 From: report at bugs.python.org (A.M. Kuchling) Date: Tue, 06 Nov 2007 18:34:04 -0000 Subject: [issue1396] py3k-pep3137: patch for mailbox Message-ID: <1194374044.52.0.789700574871.issue1396@psf.upfronthosting.co.za> A.M. Kuchling added the comment: I'm not following Py3K development at all, but the patch is pretty short and seems reasonable. I think mailboxes should be 7-bit clean in theory, but have no idea if things are that tidy in practice. __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Nov 6 19:34:30 2007 From: report at bugs.python.org (Mike Verdone) Date: Tue, 06 Nov 2007 18:34:30 -0000 Subject: [issue737648] Error on handling nan Message-ID: <1194374070.69.0.680152515736.issue737648@psf.upfronthosting.co.za> Mike Verdone added the comment: For the benefit of those who stumble here through Google, here's a workaround I've discovered for NaN testing. This is BAD: value == float('NaN') But this seems to work ok: str(value) == str(float('NaN')) ---------- nosy: +mike.verdone title: Error on handling nan -> Error on handling nan ____________________________________ Tracker ____________________________________ From report at bugs.python.org Tue Nov 6 19:47:10 2007 From: report at bugs.python.org (Christian Heimes) Date: Tue, 06 Nov 2007 18:47:10 -0000 Subject: [issue1396] py3k-pep3137: patch for mailbox Message-ID: <1194374830.75.0.973250587353.issue1396@psf.upfronthosting.co.za> Christian Heimes added the comment: Thanks for your insight, Andrew! Applied in r58881. I agree with you but I'm not able to test it with real data. I've no longer access to our old server at my old dormitory. I had a Qmail system with maildir there. Two tests are still failing with the same error: ====================================================================== FAIL: test_get (test.test_mailbox.TestMaildir) ---------------------------------------------------------------------- Traceback (most recent call last): File "/home/heimes/dev/python/py3k-pep3137/Lib/test/test_mailbox.py", line 138, in test_get self.assertEqual(msg.fp.read(), '1') AssertionError: '\n\n1' != '1' ---------- resolution: -> fixed status: open -> closed __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Nov 6 19:57:58 2007 From: report at bugs.python.org (Guido van Rossum) Date: Tue, 06 Nov 2007 18:57:58 -0000 Subject: [issue1396] py3k-pep3137: patch for mailbox Message-ID: <1194375478.57.0.395399266734.issue1396@psf.upfronthosting.co.za> Guido van Rossum added the comment: I fixed the remaining two errors in r58882. __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Nov 6 19:59:14 2007 From: report at bugs.python.org (Guido van Rossum) Date: Tue, 06 Nov 2007 18:59:14 -0000 Subject: [issue1395] py3k: duplicated line endings when using read(1) In-Reply-To: <4730B093.2020804@cheimes.de> Message-ID: Guido van Rossum added the comment: > In my opinion the check for \r should only happen when os.linesep or > newline starts with \r. On Unix with standard newline the \r should be > treated as every other char. No: it is not dependent on os.linesep but on the newline parameter passed to open(). It's perfectly valid to want to read a file with CRLF endings on Unix (Amaury's patches end up in my /tmp directory like that.) __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Nov 6 20:10:04 2007 From: report at bugs.python.org (Guido van Rossum) Date: Tue, 06 Nov 2007 19:10:04 -0000 Subject: [issue1293] Trailing slash in sys.path cause import failure Message-ID: <1194376204.36.0.627339998478.issue1293@psf.upfronthosting.co.za> Guido van Rossum added the comment: I see several problems with this, but there's light at the end of the tunnel. (1) Don't use s#; it will allow null bytes in the string, which we don't want. (2) Put the entire trailing slash removal inside #ifdef MS_WINDOWS. (3) Careful! It seems the code you wrote would transform "C:/" into "C:" which isn't the same thing (the latter refers to the current directory on the C drive, while the former is the root of the C drive). ---------- nosy: +gvanrossum __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Nov 6 20:10:10 2007 From: report at bugs.python.org (Guido van Rossum) Date: Tue, 06 Nov 2007 19:10:10 -0000 Subject: [issue1293] Trailing slash in sys.path cause import failure Message-ID: <1194376210.31.0.80333502469.issue1293@psf.upfronthosting.co.za> Changes by Guido van Rossum: ---------- resolution: accepted -> __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Nov 6 21:07:55 2007 From: report at bugs.python.org (Christian Heimes) Date: Tue, 06 Nov 2007 20:07:55 -0000 Subject: [issue1293] Trailing slash in sys.path cause import failure In-Reply-To: <1194376204.36.0.627339998478.issue1293@psf.upfronthosting.co.za> Message-ID: <4730C99A.9080205@cheimes.de> Christian Heimes added the comment: Guido van Rossum wrote: > (1) Don't use s#; it will allow null bytes in the string, which we don't > want. > > (2) Put the entire trailing slash removal inside #ifdef MS_WINDOWS. Done aand done > (3) Careful! It seems the code you wrote would transform "C:/" into > "C:" which isn't the same thing (the latter refers to the current > directory on the C drive, while the former is the root of the C drive). Oh, good catch! I haven't thought of C:/ How do you like #ifdef MS_WINDOWS /* Remove trailing / and \ - Windows' stat doesn't like them - but * keep the trailing slash of C:/ */ Py_ssize_t i; char mangled[MAXPATHLEN+1]; if (pathlen > MAXPATHLEN) { PyErr_SetString(PyExc_OverflowError, "path is too long"); return -1; } strcpy(mangled, path); for (i = pathlen-1; i > 3; i--) { if (mangled[i] != '/' && mangled[i] != '\\') { break; } mangled[i] = '\0'; } rv = stat(mangled, &statbuf); #else rv = stat(path, &statbuf); #endif i > 3 should take care of C:/ and C:\ Christian __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Nov 6 21:19:38 2007 From: report at bugs.python.org (Guido van Rossum) Date: Tue, 06 Nov 2007 20:19:38 -0000 Subject: [issue1293] Trailing slash in sys.path cause import failure In-Reply-To: <4730C99A.9080205@cheimes.de> Message-ID: Guido van Rossum added the comment: > How do you like > #ifdef MS_WINDOWS > /* Remove trailing / and \ - Windows' stat doesn't like them - but > * keep the trailing slash of C:/ > */ > > Py_ssize_t i; > char mangled[MAXPATHLEN+1]; > > if (pathlen > MAXPATHLEN) { > PyErr_SetString(PyExc_OverflowError, > "path is too long"); > return -1; > } > strcpy(mangled, path); > > for (i = pathlen-1; i > 3; i--) { > if (mangled[i] != '/' && mangled[i] != '\\') { > break; > } > mangled[i] = '\0'; > } > rv = stat(mangled, &statbuf); > #else > rv = stat(path, &statbuf); > #endif > > i > 3 should take care of C:/ and C:\ But the C: is optional. You will need to do more parsing. Some more examples (all with slashes; but backslashes work the same): //share/ -> //share/ //share/x/ -> //share/x /x/ -> /x / -> / // -> // (probably illegal but doesn't matter) C:/ -> C:/ x/ -> x C:x/ -> C:x Isn't it easier to handle this at the Python level? There probably already is code for parsing Windows paths. (Hm, maybe we have it in C too somewhere?) __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Nov 6 22:11:54 2007 From: report at bugs.python.org (Gregory P. Smith) Date: Tue, 06 Nov 2007 21:11:54 -0000 Subject: [issue1397] py3k-pep3137: failing unit test test_bsddb Message-ID: <1194383514.63.0.547552839914.issue1397@psf.upfronthosting.co.za> Gregory P. Smith added the comment: yeah i've seen this at random times as well. I don't believe its related to py3k or the pep3137 branch at all, i believe seen it on trunk but its rare. For reference, what platform (OS) and BerkeleyDB version did you build python with when this happened? The reason the test doesn't fail is that these exceptions occur in worker threads. The bsddb thread tests could clearly use some work. __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Nov 6 22:16:02 2007 From: report at bugs.python.org (Christian Heimes) Date: Tue, 06 Nov 2007 21:16:02 -0000 Subject: [issue1397] py3k-pep3137: failing unit test test_bsddb Message-ID: <1194383762.72.0.829423341666.issue1397@psf.upfronthosting.co.za> Christian Heimes added the comment: I've mentioned the platform and db version in the last line. You surely have missed it: Ubuntu Linux 7.10, i386, db 4.4.20 __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Nov 6 22:49:30 2007 From: report at bugs.python.org (Christian Heimes) Date: Tue, 06 Nov 2007 21:49:30 -0000 Subject: [issue1293] Trailing slash in sys.path cause import failure Message-ID: <1194385770.91.0.0405330974089.issue1293@psf.upfronthosting.co.za> Christian Heimes added the comment: Another patch that uses os.path.normpath. Added file: http://bugs.python.org/file8704/trailing_slash3.patch __________________________________ Tracker __________________________________ -------------- next part -------------- A non-text attachment was scrubbed... Name: trailing_slash3.patch Type: text/x-diff Size: 1285 bytes Desc: not available Url : http://mail.python.org/pipermail/python-bugs-list/attachments/20071106/7710c63a/attachment.patch From report at bugs.python.org Tue Nov 6 23:23:27 2007 From: report at bugs.python.org (Guido van Rossum) Date: Tue, 06 Nov 2007 22:23:27 -0000 Subject: [issue1293] Trailing slash in sys.path cause import failure In-Reply-To: <1194385770.91.0.0405330974089.issue1293@psf.upfronthosting.co.za> Message-ID: Guido van Rossum added the comment: > Another patch that uses os.path.normpath. Sorry, I really don't like to be importing os.path in order to be able to process the path used for an import. __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Nov 6 23:36:36 2007 From: report at bugs.python.org (Guido van Rossum) Date: Tue, 06 Nov 2007 22:36:36 -0000 Subject: [issue1372] zlibmodule.c: int overflow in PyZlib_decompress Message-ID: <1194388596.12.0.612061901787.issue1372@psf.upfronthosting.co.za> Changes by Guido van Rossum: ---------- keywords: +64bit resolution: accepted -> __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Nov 6 23:37:46 2007 From: report at bugs.python.org (Thomas Conway) Date: Tue, 06 Nov 2007 22:37:46 -0000 Subject: [issue1390] toxml generates output that is not well formed Message-ID: <1194388666.44.0.426841273228.issue1390@psf.upfronthosting.co.za> Thomas Conway added the comment: The W3 guys had some information that helps. The DOM3 Core specification contains the following No lexical check is done on the content of a comment and it is therefore possible to have the character sequence "--" (double-hyphen) in the content, which is illegal in a comment per section 2.5 of [XML 1.0]. The presence of this character sequence must generate a fatal error during serialization. This suggest that toxml is does not comply with DOM3 at any rate. cheers, Tom __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Nov 6 23:42:46 2007 From: report at bugs.python.org (Brett Cannon) Date: Tue, 06 Nov 2007 22:42:46 -0000 Subject: [issue1293] Trailing slash in sys.path cause import failure In-Reply-To: Message-ID: Brett Cannon added the comment: On 11/6/07, Guido van Rossum wrote: > > Guido van Rossum added the comment: > > > Another patch that uses os.path.normpath. > > Sorry, I really don't like to be importing os.path in order to be able > to process the path used for an import. Modules/getpath.c:joinpath() I think does what you want in C. __________________________________ Tracker __________________________________ From report at bugs.python.org Wed Nov 7 00:01:39 2007 From: report at bugs.python.org (Facundo Batista) Date: Tue, 06 Nov 2007 23:01:39 -0000 Subject: [issue1742669] "%d" format handling for long values Message-ID: <1194390099.26.0.0260637173857.issue1742669@psf.upfronthosting.co.za> Facundo Batista added the comment: I'm positive that this shouldn't happen. There should NOT be any difference between longs and ints in nowadays Python, so you never should say to an user to call that long() before the %d. And, you have some strange behaviours... for example: >>> "%d" % 9e8 '900000000' >>> "%d" % 9e9 Traceback (most recent call last): File "", line 1, in TypeError: int argument required Why the first is ok and in the second you should have called it through long()? Gabriel, could you please take a look to the recommendations that Travis is doing? Maybe the patch could be simpler... In any case, please confirm if yes or no, :) _____________________________________ Tracker _____________________________________ From report at bugs.python.org Wed Nov 7 01:31:03 2007 From: report at bugs.python.org (Paul Pogonyshev) Date: Wed, 07 Nov 2007 00:31:03 -0000 Subject: [issue1390] toxml generates output that is not well formed Message-ID: <1194395463.33.0.759323512832.issue1390@psf.upfronthosting.co.za> Paul Pogonyshev added the comment: Looks like bad design on W3 part: postponing an error happening, though it wouldn't be difficult to check right in createComment(). But I guess minidom should still be changed to conform to standard. ---------- nosy: +_doublep __________________________________ Tracker __________________________________ From report at bugs.python.org Wed Nov 7 01:37:18 2007 From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=) Date: Wed, 07 Nov 2007 00:37:18 -0000 Subject: [issue1390] toxml generates output that is not well formed Message-ID: <1194395838.44.0.95167014086.issue1390@psf.upfronthosting.co.za> Martin v. L?wis added the comment: Would anybody want to provide a patch, then? __________________________________ Tracker __________________________________ From report at bugs.python.org Wed Nov 7 01:56:10 2007 From: report at bugs.python.org (Thomas Conway) Date: Wed, 07 Nov 2007 00:56:10 -0000 Subject: [issue1390] toxml generates output that is not well formed Message-ID: <1194396970.3.0.395837016994.issue1390@psf.upfronthosting.co.za> Thomas Conway added the comment: FWIW, the DOM guys considered mandating a check in createComment, but decided that the performance penalty was too great. I'm not sure I agree with them, but there you have it. Here are links to my query about the issue: http://lists.w3.org/Archives/Public/www-dom/2007OctDec/0017.html http://lists.w3.org/Archives/Public/www-dom/2007OctDec/0018.html __________________________________ Tracker __________________________________ From report at bugs.python.org Wed Nov 7 02:08:23 2007 From: report at bugs.python.org (Paul Pogonyshev) Date: Wed, 07 Nov 2007 01:08:23 -0000 Subject: [issue1390] toxml generates output that is not well formed Message-ID: <1194397703.7.0.223777629093.issue1390@psf.upfronthosting.co.za> Paul Pogonyshev added the comment: Well, it seems that allows createComment() in minidom to raise something implementation/language specific. I personally would prefer this (e.g. a ValueError) instead of raising on serialization step, as I prefer early error checks, when these checks obviously relate to some place in the code. In any way, I think that either createComment() should raise or toxml(), but generating non-well formed output is a bug. __________________________________ Tracker __________________________________ From report at bugs.python.org Wed Nov 7 07:26:38 2007 From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=) Date: Wed, 07 Nov 2007 06:26:38 -0000 Subject: [issue1390] toxml generates output that is not well formed Message-ID: <1194416798.92.0.164209664059.issue1390@psf.upfronthosting.co.za> Martin v. L?wis added the comment: It may the intention that these functions may raise exceptions in other cases as well - but can you also support that possibility from the text of the DOM spec itself? Adding an exception there may break existing applications, which already have except clauses to deal with all "possible" exceptions; now they break if additional exceptions become possible. __________________________________ Tracker __________________________________ From report at bugs.python.org Wed Nov 7 08:00:38 2007 From: report at bugs.python.org (Thomas Conway) Date: Wed, 07 Nov 2007 07:00:38 -0000 Subject: [issue1390] toxml generates output that is not well formed Message-ID: <1194418838.67.0.14002087602.issue1390@psf.upfronthosting.co.za> Thomas Conway added the comment: I think the specification is reasonably clear: createComment may not throw an exception. The serializer must throw an exception. (Personally, I think they have it round the wrong way - every time you write a serializer you have to write code to do the check; if it was in createComment, you'd only have to do it once. Never mind!) The problem of compatibility is, as always, a nasty one: whether or not to potentially break code that previously worked. In this case, I think modifying toxml (and the other serializing functions in the same library) to throw an exception is pretty unlikely to break existing code. The *only* way to trigger the error is if you call createComment with bad text. Moreover, the programs which "succeeded" before which now fail were almost certainly producing wrong output before, which if it did not break downstream processing, would at least produce strange bits of extra character data. If the library is changed to throw an exception, at least it will alert the author/maintainer to the problem. I would estimate the expected number of programs to be broken by such a change to be about 0. :-) This is certainly not the first time in the history of software development the break or not to break issue has come up. Is there a precedent in the python libraries for how to deal with this kind of issue? Can we add a quickAndBuggy = True default parameter to toxml, then in a couple of releases make it mandatory, then in a couple of further releases remove it and the old behaviour? cheers, Tom __________________________________ Tracker __________________________________ From report at bugs.python.org Wed Nov 7 08:21:41 2007 From: report at bugs.python.org (Neal Norwitz) Date: Wed, 07 Nov 2007 07:21:41 -0000 Subject: [issue1705170] contextmanager eats StopIteration Message-ID: <1194420101.54.0.328220747915.issue1705170@psf.upfronthosting.co.za> Neal Norwitz added the comment: Nick, can you backport this and add a NEWS entry? Thanks. ---------- nosy: +nnorwitz _____________________________________ Tracker _____________________________________ From report at bugs.python.org Wed Nov 7 09:53:52 2007 From: report at bugs.python.org (=?utf-8?q?S=C3=A9bastien_Sabl=C3=A9?=) Date: Wed, 07 Nov 2007 08:53:52 -0000 Subject: [issue1234] semaphore errors on AIX 5.2 Message-ID: <1194425632.71.0.301263441911.issue1234@psf.upfronthosting.co.za> S?bastien Sabl? added the comment: The bug is still present in Python 2.5.1. The same patch applies. The patch is rather trivival, could someone please integrate it in trunk? Thanks in advance __________________________________ Tracker __________________________________ From report at bugs.python.org Wed Nov 7 09:55:32 2007 From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=) Date: Wed, 07 Nov 2007 08:55:32 -0000 Subject: [issue1390] toxml generates output that is not well formed Message-ID: <1194425732.39.0.745287372085.issue1390@psf.upfronthosting.co.za> Martin v. L?wis added the comment: The standard procedure for an incompatible change would be to add such a parameter to 2.6, and then change the default behavior in 2.7 (or rather 3.1). Of course, people will not notice the change in 2.6, and then be surprised as much about the default change in 2.7, assuming this problem arises in some application (and this issue is proof that the problem does arise in real life - unless drtomc brought up an artificial problem). __________________________________ Tracker __________________________________ From report at bugs.python.org Wed Nov 7 13:25:03 2007 From: report at bugs.python.org (Nick Coghlan) Date: Wed, 07 Nov 2007 12:25:03 -0000 Subject: [issue1291] test_resource fails on recent linux systems ( Message-ID: <1194438303.3.0.814192763015.issue1291@psf.upfronthosting.co.za> Nick Coghlan added the comment: I just hit this as well when rerunning the 2.5 tests before checking something else in. The test itself appears to be fine, but the call to f.close() outside the try/except block attempting to flush the file to disk and raising an IOError. Didn't something like this get fixed recently? Did the new IO module in py3k have a similar problem? (assigning to Neal to make a call on the importance for 2.5.2) ---------- assignee: -> nnorwitz components: +Interpreter Core -Extension Modules nosy: +ncoghlan, nnorwitz priority: -> high resolution: -> accepted __________________________________ Tracker __________________________________ From report at bugs.python.org Wed Nov 7 13:27:18 2007 From: report at bugs.python.org (Nick Coghlan) Date: Wed, 07 Nov 2007 12:27:18 -0000 Subject: [issue1705170] contextmanager eats StopIteration Message-ID: <1194438438.74.0.322733727778.issue1705170@psf.upfronthosting.co.za> Nick Coghlan added the comment: Done in rev 58901 ---------- resolution: accepted -> fixed status: open -> closed _____________________________________ Tracker _____________________________________ From report at bugs.python.org Wed Nov 7 13:42:17 2007 From: report at bugs.python.org (Nick Coghlan) Date: Wed, 07 Nov 2007 12:42:17 -0000 Subject: [issue1291] test_resource fails on recent linux systems ( Message-ID: <1194439337.87.0.803523620903.issue1291@psf.upfronthosting.co.za> Nick Coghlan added the comment: I just compared the 2.5 test_resource with the trunk test_resource - the latter has been modified to remove the file size limitation before it attempts to close the file, eliminating the test failure without changing the underlying behaviour of f.close. __________________________________ Tracker __________________________________ From report at bugs.python.org Wed Nov 7 15:08:02 2007 From: report at bugs.python.org (Christian Heimes) Date: Wed, 07 Nov 2007 14:08:02 -0000 Subject: [issue1293] Trailing slash in sys.path cause import failure In-Reply-To: Message-ID: <4731C6BB.3010305@cheimes.de> Christian Heimes added the comment: Brett Cannon wrote: > Modules/getpath.c:joinpath() I think does what you want in C. I don't see how it is going to help us. I've a final offer before I declare the bug as SEP (someone else's problem): pseudo code #ifdef MS_WINDOWS rv = stat(...) if (rv == error) check for *one* trailign / or \ and remove it rv = stat(...) if (rv == error) give up #endif It should fix the case when somebody adds a directory with a trailing / or \ on Windows. More complex cases are still broken but that's really not my concern. ;) Christian __________________________________ Tracker __________________________________ From report at bugs.python.org Wed Nov 7 16:27:30 2007 From: report at bugs.python.org (Daniel) Date: Wed, 07 Nov 2007 15:27:30 -0000 Subject: [issue1398] Can't pickle partial functions Message-ID: <1194449250.48.0.936565568427.issue1398@psf.upfronthosting.co.za> New submission from Daniel: Creating a function using functools.partial results in a function which cannot be pickled. Attached is a small testcase. ---------- components: Library (Lib) files: partial_bug.py messages: 57200 nosy: danhs severity: normal status: open title: Can't pickle partial functions type: behavior versions: Python 2.5 Added file: http://bugs.python.org/file8705/partial_bug.py __________________________________ Tracker __________________________________ -------------- next part -------------- A non-text attachment was scrubbed... Name: partial_bug.py Type: text/x-python Size: 141 bytes Desc: not available Url : http://mail.python.org/pipermail/python-bugs-list/attachments/20071107/6c59084a/attachment.py From report at bugs.python.org Wed Nov 7 16:48:51 2007 From: report at bugs.python.org (Gabriel Genellina) Date: Wed, 07 Nov 2007 15:48:51 -0000 Subject: [issue1366] popen spawned process may not write to stdout under windows Message-ID: <1194450531.49.0.208562179266.issue1366@psf.upfronthosting.co.za> Gabriel Genellina added the comment: (I think the title you meant was "popen spawned process may not write to stderr under windows") The child is dying with IOError: [Errno 22] Invalid argument at the sys.stderr.flush() call. Neither the docs for os.popen nor the Linux man page for popen(3) say that stderr is redirected, so one would expect the handle to be inherited; the IOError looks like a bug. Try using os.popen4 or popen2.popen4 or -the recommended choice- the subprocess module. Using the latter, this is the modified parent.py: """ import subprocess cmd = 'python child.py' p = subprocess.Popen(cmd, stdout=subprocess.PIPE) for line in p.stdout: print ">>>", line, print p.wait() """ and this is the output, as expected: """ 2:stderr >>> 1:stdout >>> 3:stdout 0 """ Note the 2:stderr line lacking the >>>, because it was printed directly by the child process onto the stderr handle inherited from its parent. ---------- nosy: +gagenellina __________________________________ Tracker __________________________________ From report at bugs.python.org Wed Nov 7 16:56:55 2007 From: report at bugs.python.org (Gabriel Genellina) Date: Wed, 07 Nov 2007 15:56:55 -0000 Subject: [issue1343] XMLGenerator: nice elements Message-ID: <1194451015.75.0.294785545707.issue1343@psf.upfronthosting.co.za> Gabriel Genellina added the comment: Some (ugly) parsers insist on when the element is not declared to be empty, so this should be optional (the default being generate ) ---------- nosy: +gagenellina __________________________________ Tracker __________________________________ From report at bugs.python.org Wed Nov 7 17:00:30 2007 From: report at bugs.python.org (Guido van Rossum) Date: Wed, 07 Nov 2007 16:00:30 -0000 Subject: [issue1293] Trailing slash in sys.path cause import failure In-Reply-To: <4731C6BB.3010305@cheimes.de> Message-ID: Guido van Rossum added the comment: Works for me! On Nov 7, 2007 6:08 AM, Christian Heimes wrote: > > Christian Heimes added the comment: > > Brett Cannon wrote: > > Modules/getpath.c:joinpath() I think does what you want in C. > > I don't see how it is going to help us. > > I've a final offer before I declare the bug as SEP (someone else's problem): > > pseudo code > > #ifdef MS_WINDOWS > rv = stat(...) > if (rv == error) > check for *one* trailign / or \ and remove it > rv = stat(...) > if (rv == error) > give up > #endif > > It should fix the case when somebody adds a directory with a trailing / > or \ on Windows. More complex cases are still broken but that's really > not my concern. ;) > > Christian > > > __________________________________ > Tracker > > __________________________________ > __________________________________ Tracker __________________________________ From report at bugs.python.org Wed Nov 7 18:08:57 2007 From: report at bugs.python.org (Raghuram Devarakonda) Date: Wed, 07 Nov 2007 17:08:57 -0000 Subject: [issue1395] py3k: duplicated line endings when using read(1) Message-ID: <1194455337.8.0.268769343343.issue1395@psf.upfronthosting.co.za> Raghuram Devarakonda added the comment: I am attaching another patch (io2.diff). Please review. I am not sure whether _adjust_chunk() should also adjust "readahead". BTW, PEP 3116 says: "If universal newlines without translation are requested on input (i.e. newline=''), if a system read operation returns a buffer ending in '\r', another system read operation is done to determine whether it is followed by '\n' or not. In universal newlines mode with translation, the second system read operation may be postponed until the next read request, and if the following system read operation returns a buffer starting with '\n', that character is simply discarded." I suppose this issue is mainly talking about the latter (newline is None). I don't understand what is meant by "enabling universal new line mode without translation". Isn't the purpose of enabling universal new line mode is to translate line endings? I may be missing something basic, of course. Added file: http://bugs.python.org/file8706/io2.diff __________________________________ Tracker __________________________________ -------------- next part -------------- A non-text attachment was scrubbed... Name: io2.diff Type: text/x-patch Size: 4790 bytes Desc: not available Url : http://mail.python.org/pipermail/python-bugs-list/attachments/20071107/70289176/attachment-0001.bin From report at bugs.python.org Wed Nov 7 18:20:30 2007 From: report at bugs.python.org (Christian Heimes) Date: Wed, 07 Nov 2007 17:20:30 -0000 Subject: [issue1395] py3k: duplicated line endings when using read(1) Message-ID: <1194456030.59.0.351657682002.issue1395@psf.upfronthosting.co.za> Christian Heimes added the comment: The new patch fixes test_netrc for me but test_csv and test_mailbox are still broken. ---------- components: +Library (Lib), Windows keywords: +py3k __________________________________ Tracker __________________________________ From report at bugs.python.org Wed Nov 7 18:28:32 2007 From: report at bugs.python.org (Christian Heimes) Date: Wed, 07 Nov 2007 17:28:32 -0000 Subject: [issue1293] Trailing slash in sys.path cause import failure Message-ID: <1194456512.46.0.470461381823.issue1293@psf.upfronthosting.co.za> Christian Heimes added the comment: I've checked in a fix in r58903 (py3k branch). __________________________________ Tracker __________________________________ From report at bugs.python.org Wed Nov 7 18:28:33 2007 From: report at bugs.python.org (Raghuram Devarakonda) Date: Wed, 07 Nov 2007 17:28:33 -0000 Subject: [issue1395] py3k: duplicated line endings when using read(1) In-Reply-To: <1194456030.59.0.351657682002.issue1395@psf.upfronthosting.co.za> Message-ID: <2c51ecee0711070928j7f623062h697286237d369af9@mail.gmail.com> Raghuram Devarakonda added the comment: > The new patch fixes test_netrc for me but test_csv and test_mailbox are > still broken. Unfortunately, I am not able to build python on windows so I can not test there. Can you post the exact errors? You can send me private email as well if you think the test output would clutter this issue. __________________________________ Tracker __________________________________ From report at bugs.python.org Wed Nov 7 18:41:31 2007 From: report at bugs.python.org (Guido van Rossum) Date: Wed, 07 Nov 2007 17:41:31 -0000 Subject: [issue1395] py3k: duplicated line endings when using read(1) Message-ID: <1194457291.72.0.380930781186.issue1395@psf.upfronthosting.co.za> Guido van Rossum added the comment: This looks promising, but my head hurts when I try to understand the code that's already there and think about whether your patch will always do the right thing... I'll look more later. Regarding "universal newlines without translation:" that means that \r\n and \r are recognized as line endings (as is \n) and that readline() will return whatever line end it sees. Compare this to setting newline="\n"; then \r is not treated as a line ending at all (and if the input is a\rb\n, the next readline call would return that entire string). __________________________________ Tracker __________________________________ From report at bugs.python.org Wed Nov 7 18:46:51 2007 From: report at bugs.python.org (Guido van Rossum) Date: Wed, 07 Nov 2007 17:46:51 -0000 Subject: [issue1293] Trailing slash in sys.path cause import failure Message-ID: <1194457611.02.0.950220696492.issue1293@psf.upfronthosting.co.za> Changes by Guido van Rossum: ---------- resolution: -> fixed status: open -> closed __________________________________ Tracker __________________________________ From report at bugs.python.org Wed Nov 7 18:47:22 2007 From: report at bugs.python.org (Amaury Forgeot d'Arc) Date: Wed, 07 Nov 2007 17:47:22 -0000 Subject: [issue1395] py3k: duplicated line endings when using read(1) Message-ID: <1194457642.21.0.20408346155.issue1395@psf.upfronthosting.co.za> Amaury Forgeot d'Arc added the comment: > The new patch fixes test_netrc for me but test_csv and test_mailbox are > still broken. For test_mailbox at least, I think I have a clue: the _pending member now contains translated newlines. But in tell(), we use its length and compare it with the length of a previous "pending" value stored in self._snapshot... Can we try to somehow move the replacenl() call inside the _get_chunk function? Not sure it will work. This gets more and more obscure... __________________________________ Tracker __________________________________ From report at bugs.python.org Wed Nov 7 18:49:33 2007 From: report at bugs.python.org (Guido van Rossum) Date: Wed, 07 Nov 2007 17:49:33 -0000 Subject: [issue1395] py3k: duplicated line endings when using read(1) In-Reply-To: <1194457642.21.0.20408346155.issue1395@psf.upfronthosting.co.za> Message-ID: Guido van Rossum added the comment: Somebody needs to reverse-engineer the invariants applying to the various instance variables and add comments explaining them, and showing how they are maintained by each call. __________________________________ Tracker __________________________________ From report at bugs.python.org Wed Nov 7 18:52:33 2007 From: report at bugs.python.org (Guido van Rossum) Date: Wed, 07 Nov 2007 17:52:33 -0000 Subject: [issue1291] test_resource fails on recent linux systems ( Message-ID: <1194457953.76.0.9414367468.issue1291@psf.upfronthosting.co.za> Guido van Rossum added the comment: It's fine to fix this in 2.5.2, as it is just a test. (IMO you can just copy the 2.6 test_resource.py into 2.5.2, assuming that works.) __________________________________ Tracker __________________________________ From report at bugs.python.org Wed Nov 7 18:53:57 2007 From: report at bugs.python.org (Guido van Rossum) Date: Wed, 07 Nov 2007 17:53:57 -0000 Subject: [issue1399] XML codec Message-ID: <1194458037.92.0.0845222978917.issue1399@psf.upfronthosting.co.za> Guido van Rossum added the comment: I think it's good to add this; I don't have time to review though. ---------- nosy: +gvanrossum __________________________________ Tracker __________________________________ From report at bugs.python.org Wed Nov 7 19:34:59 2007 From: report at bugs.python.org (Christian Heimes) Date: Wed, 07 Nov 2007 18:34:59 -0000 Subject: [issue1395] py3k: duplicated line endings when using read(1) In-Reply-To: Message-ID: <47320553.9090402@cheimes.de> Christian Heimes added the comment: By the way what happened to the SoC project related to Python's new IO subsystem? IIRC somebody was working on a C optimization of the io lib. __________________________________ Tracker __________________________________ From report at bugs.python.org Wed Nov 7 19:36:11 2007 From: report at bugs.python.org (Wojciech Walczak) Date: Wed, 07 Nov 2007 18:36:11 -0000 Subject: [issue1400] Py3k's print() flushing problem Message-ID: <1194460571.16.0.187401389382.issue1400@psf.upfronthosting.co.za> New submission from Wojciech Walczak: py3k's print() is not flushing when the string's length is 1 byte long and 'end' parameter is set to ''. Example: >>> print('x',end='') # it should print 'x' but it does nothing >>> print('') # we have to call second print() to get buffers flushed x >>> The same thing happens when the string is empty and end's length is 1: >>> print('',end='x') # it should print 'x' but it does nothing >>> print('') # we have to call second print() to get buffers flushed x >>> When there is more characters than one, print() is flushing allright (despite of lack of a newline in the interpreter): >>> print('x',end='y') xy>>> print('xx',end='') xx>>> print('',end='yy') yy>>> The same thing happens in scripts. Try this one as script: ----------------- import time print('xx',end='') time.sleep(3) print('x',end='') time.sleep(3) ----------------- First print() will flush immediately even though there is no newline and flush is not called, while second print() will flush after second sleep (because python is flushing buffers at the end of the script). The conclusion is that print() is not flushing immediately when string is 1 byte long, but when it is longer - then print() is flushing even when there is no newline or flush was not called by the programmer. I guess print() should act in the same way for every string > 0 bytes long instead of for every string > 1 byte long. Any ideas where is the bug? You can find Python-3000's mail list discussion about that bug here: http://mail.python.org/pipermail/python-3000/2007-November/011191.html Wojtek Walczak ---------- components: Build messages: 57215 nosy: wojtekwalczak severity: normal status: open title: Py3k's print() flushing problem type: behavior versions: Python 3.0 __________________________________ Tracker __________________________________ From report at bugs.python.org Wed Nov 7 19:52:59 2007 From: report at bugs.python.org (Guido van Rossum) Date: Wed, 07 Nov 2007 18:52:59 -0000 Subject: [issue1704621] interpreter crash when multiplying large lists Message-ID: <1194461579.09.0.256061848423.issue1704621@psf.upfronthosting.co.za> Guido van Rossum added the comment: Shouldn't this be fixed before 2.5.2 goes out? ---------- assignee: -> nnorwitz nosy: +gvanrossum priority: normal -> high _____________________________________ Tracker _____________________________________ From report at bugs.python.org Wed Nov 7 20:03:08 2007 From: report at bugs.python.org (Guido van Rossum) Date: Wed, 07 Nov 2007 19:03:08 -0000 Subject: [issue1395] py3k: duplicated line endings when using read(1) In-Reply-To: <47320553.9090402@cheimes.de> Message-ID: Guido van Rossum added the comment: On 11/7/07, Christian Heimes wrote: > > Christian Heimes added the comment: > > By the way what happened to the SoC project related to Python's new IO > subsystem? IIRC somebody was working on a C optimization of the io lib. > > __________________________________ > Tracker > > __________________________________ I think it was Alexandre Vassalotti. Is that right, Alexandre? Or am I mixing you up? (If you ca, please respond to the bug.) __________________________________ Tracker __________________________________ From report at bugs.python.org Wed Nov 7 20:06:05 2007 From: report at bugs.python.org (Raghuram Devarakonda) Date: Wed, 07 Nov 2007 19:06:05 -0000 Subject: [issue1395] py3k: duplicated line endings when using read(1) Message-ID: <1194462365.14.0.324410567581.issue1395@psf.upfronthosting.co.za> Raghuram Devarakonda added the comment: Hi Amaury and Christian, io3.diff does replacenl() in adjust_chunk() (trying Amaury's suggestion). Can you see if it fixes test_mailbox failures? Added file: http://bugs.python.org/file8708/io3.diff __________________________________ Tracker __________________________________ -------------- next part -------------- A non-text attachment was scrubbed... Name: io3.diff Type: text/x-patch Size: 2718 bytes Desc: not available Url : http://mail.python.org/pipermail/python-bugs-list/attachments/20071107/86a5d24f/attachment.bin From report at bugs.python.org Wed Nov 7 20:06:36 2007 From: report at bugs.python.org (Christian Heimes) Date: Wed, 07 Nov 2007 19:06:36 -0000 Subject: [issue1395] py3k: duplicated line endings when using read(1) Message-ID: <1194462396.41.0.28293235966.issue1395@psf.upfronthosting.co.za> Changes by Christian Heimes: __________________________________ Tracker __________________________________ From report at bugs.python.org Wed Nov 7 20:07:05 2007 From: report at bugs.python.org (Christian Heimes) Date: Wed, 07 Nov 2007 19:07:05 -0000 Subject: [issue1395] py3k: duplicated line endings when using read(1) Message-ID: <1194462425.6.0.11253246735.issue1395@psf.upfronthosting.co.za> Changes by Christian Heimes: ---------- nosy: +alexandre.vassalotti __________________________________ Tracker __________________________________ From report at bugs.python.org Wed Nov 7 20:10:59 2007 From: report at bugs.python.org (Christian Heimes) Date: Wed, 07 Nov 2007 19:10:59 -0000 Subject: [issue1395] py3k: duplicated line endings when using read(1) Message-ID: <1194462659.35.0.587993881497.issue1395@psf.upfronthosting.co.za> Christian Heimes added the comment: Good work! The tests for mailbox, netrc and csv are passing with your test. I'm going to run the entire suite now. __________________________________ Tracker __________________________________ From report at bugs.python.org Wed Nov 7 20:14:56 2007 From: report at bugs.python.org (Christian Heimes) Date: Wed, 07 Nov 2007 19:14:56 -0000 Subject: [issue1395] py3k: duplicated line endings when using read(1) Message-ID: <1194462896.18.0.891944132109.issue1395@psf.upfronthosting.co.za> Christian Heimes added the comment: I take it back. I accidentally run the unit tests on the trunk instead of the py3k branch. mailbox and csv are still breaking with your test, netrc is doing fine. Added file: http://bugs.python.org/file8709/py3k_windows.log.gz __________________________________ Tracker __________________________________ -------------- next part -------------- A non-text attachment was scrubbed... Name: py3k_windows.log.gz Type: application/x-gzip Size: 5995 bytes Desc: not available Url : http://mail.python.org/pipermail/python-bugs-list/attachments/20071107/e70e15fa/attachment.bin From report at bugs.python.org Wed Nov 7 20:43:06 2007 From: report at bugs.python.org (Marc-Andre Lemburg) Date: Wed, 07 Nov 2007 19:43:06 -0000 Subject: [issue1399] XML codec Message-ID: <1194464586.68.0.00643379611909.issue1399@psf.upfronthosting.co.za> Marc-Andre Lemburg added the comment: Nice codec ! The only nit I have is the name: "xml" isn't intuitive enough. I had to read the code to figure out what the codec actually does. "xml" used a encoding usually refers to having Unicode text converted to ASCII with XML entity escapes for all non-ASCII characters. How about "xml-auto-detect" or something along those lines ?! ---------- nosy: +lemburg __________________________________ Tracker __________________________________ From report at bugs.python.org Wed Nov 7 22:42:20 2007 From: report at bugs.python.org (=?utf-8?q?Walter_D=C3=B6rwald?=) Date: Wed, 07 Nov 2007 21:42:20 -0000 Subject: [issue1399] XML codec Message-ID: <1194471740.69.0.748741469939.issue1399@psf.upfronthosting.co.za> Walter D?rwald added the comment: "xml-auto-detect" sounds OK to me, it even makes sense for the encoder, because it normally detects the encoding to use for writing from the XML declaration. We could put "xml-auto-detect" into the alias mapping and keep xml as the module name. But I noticed I have to rewrap a lot of lines, before I check it in. __________________________________ Tracker __________________________________ From report at bugs.python.org Wed Nov 7 22:42:59 2007 From: report at bugs.python.org (Andres Riancho) Date: Wed, 07 Nov 2007 21:42:59 -0000 Subject: [issue1401] urllib 302 POST Message-ID: <1194471779.09.0.301126280852.issue1401@psf.upfronthosting.co.za> New submission from Andres Riancho: There is an error in urllib2 when doing a POST request to a URI that responds with a 302 redirection. The problem is in urllib2.py:536, where the HTTPRedirectHandler creates the new Request based on the original one: newurl = newurl.replace(' ', '%20') return Request(newurl, headers=req.headers, origin_req_host=req.get_origin_req_host(), unverifiable=True) The issue is that when it creates the new request, it uses the old headers (which contain a content-length header, remember that we originally sent a POST!) but doesn't use the same post-data from the original request (in fact it doesn't use any post-data). So, when the new request is sent, urllib2 sends something like: ====START Request===== GET http://f00/1.php HTTP/1.1 Content-length: 63 Accept-encoding: identity Accept: */* User-agent: w3af.sourceforge.net Host: f00 Content-type: application/x-www-form-urlencoded ==== END REQUEST === The server waits some time for the post-data that is advertised in "Content-length: 63" but it never arrives, so the connection is closed and urllib2 timeouts. There are two different solutions to this issue, implementing one is enough to solve it: 1) when creating the new request, remove the content length header 2) when creating the new request, add the post-data of the old request I think that the solution 1) is the most RFC-compliant solution. I coded a small patch for urllib2.py of python2.5 that solves this issue, the patch simply adds a line that removes the cl header: newurl = newurl.replace(' ', '%20') req.headers.pop('content-length') return Request(newurl, headers=req.headers, origin_req_host=req.get_origin_req_host(), unverifiable=True) ---------- components: None messages: 57223 nosy: andresriancho severity: minor status: open title: urllib 302 POST type: behavior versions: Python 2.5 __________________________________ Tracker __________________________________ From report at bugs.python.org Wed Nov 7 22:44:35 2007 From: report at bugs.python.org (Andres Riancho) Date: Wed, 07 Nov 2007 21:44:35 -0000 Subject: [issue1401] urllib2 302 POST Message-ID: <1194471875.17.0.832648280653.issue1401@psf.upfronthosting.co.za> Changes by Andres Riancho: ---------- title: urllib 302 POST -> urllib2 302 POST __________________________________ Tracker __________________________________ From report at bugs.python.org Wed Nov 7 22:54:18 2007 From: report at bugs.python.org (Marc-Andre Lemburg) Date: Wed, 07 Nov 2007 21:54:18 -0000 Subject: [issue1399] XML codec Message-ID: <1194472458.47.0.359233232745.issue1399@psf.upfronthosting.co.za> Marc-Andre Lemburg added the comment: Leaving the module name as "xml" would remove that name from the namespace of possible encodings. "xml" as encoding name is problematic, as many people regard writing data in XML as "encoding the data in XML". I'd simply not use it at all, not even for a codec that converts between Unicode and ASCII+XML entities. __________________________________ Tracker __________________________________ From report at bugs.python.org Wed Nov 7 22:59:56 2007 From: report at bugs.python.org (Guido van Rossum) Date: Wed, 07 Nov 2007 21:59:56 -0000 Subject: [issue1399] XML codec Message-ID: <1194472796.55.0.95924303862.issue1399@psf.upfronthosting.co.za> Changes by Guido van Rossum: ---------- nosy: -gvanrossum __________________________________ Tracker __________________________________ From report at bugs.python.org Wed Nov 7 23:05:52 2007 From: report at bugs.python.org (Ronald Oussoren) Date: Wed, 07 Nov 2007 22:05:52 -0000 Subject: [issue1402] Interpreter cleanup: order of _PyGILState_Fini and PyInterpreterState_Clear Message-ID: <1194473152.44.0.739478133219.issue1402@psf.upfronthosting.co.za> New submission from Ronald Oussoren: Py_Finalize cleans up the thread state by first calling _PyGILState_Fini and then calling PyInterpreterState_Clear. The latter can cause user code to run, which could use the GILState API and this then causes a crash. The attached file 'threads.py' causes a crash on OSX leopard because of this issue. The script causes an exception to be set that has an attribute that uses the GILState API in its dealloc slot. ---------- components: Interpreter Core files: threads.py messages: 57225 nosy: ronaldoussoren priority: normal severity: normal status: open title: Interpreter cleanup: order of _PyGILState_Fini and PyInterpreterState_Clear type: crash versions: Python 2.5 Added file: http://bugs.python.org/file8710/threads.py __________________________________ Tracker __________________________________ -------------- next part -------------- A non-text attachment was scrubbed... Name: threads.py Type: text/x-python-script Size: 650 bytes Desc: not available Url : http://mail.python.org/pipermail/python-bugs-list/attachments/20071107/0f53cce9/attachment.bin From report at bugs.python.org Wed Nov 7 23:44:14 2007 From: report at bugs.python.org (Gabriel Genellina) Date: Wed, 07 Nov 2007 22:44:14 -0000 Subject: [issue1742669] "%d" format handling for long values Message-ID: <1194475454.97.0.120652079602.issue1742669@psf.upfronthosting.co.za> Gabriel Genellina added the comment: Yes, I can reformulate it. In fact my original version was quite different, but the resulting diff was hard to understand so I rewrote it trying to keep as much as the original code as possible. I'll submit a new patch next weekend. _____________________________________ Tracker _____________________________________ From report at bugs.python.org Wed Nov 7 23:54:30 2007 From: report at bugs.python.org (Facundo Batista) Date: Wed, 07 Nov 2007 22:54:30 -0000 Subject: [issue1401] urllib2 302 POST Message-ID: <1194476070.42.0.506355342003.issue1401@psf.upfronthosting.co.za> Facundo Batista added the comment: I don't understand why after receiving a redirection, and going to a new URL, you say to NOT send the POST data. Shouldn't the HTTP request be exactly like the original one, but to another URL destination? But you said that #2 solution was more RFC compliant... Could you please quote the RFC part that describes this behaviour? ---------- nosy: +facundobatista __________________________________ Tracker __________________________________ From report at bugs.python.org Thu Nov 8 00:55:40 2007 From: report at bugs.python.org (Alexandre Vassalotti) Date: Wed, 07 Nov 2007 23:55:40 -0000 Subject: [issue1395] py3k: duplicated line endings when using read(1) In-Reply-To: Message-ID: Alexandre Vassalotti added the comment: On 11/7/07, Guido van Rossum wrote: > On 11/7/07, Christian Heimes wrote: > > > > Christian Heimes added the comment: > > > > By the way what happened to the SoC project related to Python's new IO > > subsystem? IIRC somebody was working on a C optimization of the io lib. > > > > I think it was Alexandre Vassalotti. Is that right, Alexandre? Or am I > mixing you up? (If you ca, please respond to the bug.) I think so. My GSoC project was to merge the interface of cPickle/pickle and cStringIO/StringIO. I am still working on it, albeit slowly (my school homework is killing all my free time, right now). My work on StringIO and BytesIO is basically done; I just need to add newline translation and encoding support before it can be merged into the trunk. The cPickle/pickle merge is mostly done (i.e., all the current tests passes); I am right now in the bug-hunting phase. __________________________________ Tracker __________________________________ From report at bugs.python.org Thu Nov 8 01:11:54 2007 From: report at bugs.python.org (Guido van Rossum) Date: Thu, 08 Nov 2007 00:11:54 -0000 Subject: [issue1395] py3k: duplicated line endings when using read(1) In-Reply-To: Message-ID: Guido van Rossum added the comment: Cool. How hard do you think it would be to extend your work on StringIO into a translation of TextIOWrapper into C? On Nov 7, 2007 3:55 PM, Alexandre Vassalotti wrote: > On 11/7/07, Guido van Rossum wrote: > > On 11/7/07, Christian Heimes wrote: > > > > > > Christian Heimes added the comment: > > > > > > By the way what happened to the SoC project related to Python's new IO > > > subsystem? IIRC somebody was working on a C optimization of the io lib. > > > > > > > I think it was Alexandre Vassalotti. Is that right, Alexandre? Or am I > > mixing you up? (If you ca, please respond to the bug.) > > I think so. My GSoC project was to merge the interface of > cPickle/pickle and cStringIO/StringIO. I am still working on it, > albeit slowly (my school homework is killing all my free time, right > now). My work on StringIO and BytesIO is basically done; I just need > to add newline translation and encoding support before it can be > merged into the trunk. The cPickle/pickle merge is mostly done (i.e., > all the current tests passes); I am right now in the bug-hunting > phase. > __________________________________ Tracker __________________________________ From report at bugs.python.org Thu Nov 8 01:30:48 2007 From: report at bugs.python.org (Amaury Forgeot d'Arc) Date: Thu, 08 Nov 2007 00:30:48 -0000 Subject: [issue1395] py3k: duplicated line endings when using read(1) Message-ID: <1194481848.34.0.49603879707.issue1395@psf.upfronthosting.co.za> Amaury Forgeot d'Arc added the comment: > io3.diff does replacenl() in adjust_chunk() (trying Amaury's > suggestion). Can you see if it fixes test_mailbox failures? Unfortunately, it does not. And some tests now fail in test_io (correcting testTelling seems a good start point, since we just changed the tell() behaviour) __________________________________ Tracker __________________________________ From report at bugs.python.org Thu Nov 8 02:51:59 2007 From: report at bugs.python.org (Alexandre Vassalotti) Date: Thu, 08 Nov 2007 01:51:59 -0000 Subject: [issue1395] py3k: duplicated line endings when using read(1) In-Reply-To: Message-ID: Alexandre Vassalotti added the comment: On 11/7/07, Guido van Rossum wrote: > Cool. How hard do you think it would be to extend your work on > StringIO into a translation of TextIOWrapper into C? Well, StringIO and TextIOWrapper are quite different. The only part that I could reuse, from StringIO, would be the newline translation facilities. I think that a perfect translation to C of the current Python implementation of TextIOWrapper will be burdensome (due to things like function annotations) but not too hard to do. Nevertheless, that would be neat project for me. I could start to work it by mid-December, along with the other performance enhancements I have in mind. __________________________________ Tracker __________________________________ From report at bugs.python.org Thu Nov 8 03:48:15 2007 From: report at bugs.python.org (Raymond Hettinger) Date: Thu, 08 Nov 2007 02:48:15 -0000 Subject: [issue1165] Should itertools.count work for arbitrary integers? Message-ID: <1194490095.74.0.548587835363.issue1165@psf.upfronthosting.co.za> Changes by Raymond Hettinger: ---------- resolution: -> fixed status: open -> closed versions: +Python 2.6 -Python 3.0 __________________________________ Tracker __________________________________ From report at bugs.python.org Thu Nov 8 05:07:01 2007 From: report at bugs.python.org (Senthil) Date: Thu, 08 Nov 2007 04:07:01 -0000 Subject: [issue1401] urllib2 302 POST Message-ID: <1194494821.67.0.105898573576.issue1401@psf.upfronthosting.co.za> Senthil added the comment: I agree with facundobatista here. 1) I am not sure, if what you mention that doing POST in the 302 redirect url does not carry forward the POST data. Some examples would help to verify that and if this is case, IMO its a bug in urllib2. 2) You mention solution 1 as RFC compliant? Does RFC mention about changes to request headers for a redirection? Please quote the relevant section also I find in RFC2616 under 302 Found that: Note: RFC 1945 and RFC 2068 specify that the client is not allowedto change the method on the redirected request. However, most existing user agent implementations treat 302 as if it were a 303 response, performing a GET on the Location field-value regardless of the original request method. But could not find any references for behaviour with respect to POST on redirection. ---------- nosy: +orsenthil __________________________________ Tracker __________________________________ From report at bugs.python.org Thu Nov 8 13:52:18 2007 From: report at bugs.python.org (Andres Riancho) Date: Thu, 08 Nov 2007 12:52:18 -0000 Subject: [issue1401] urllib2 302 POST Message-ID: <1194526338.04.0.289626486842.issue1401@psf.upfronthosting.co.za> Andres Riancho added the comment: As mentioned in the RFC, and quoted by orsenthil, "however, most existing user agent implementations treat 302 as if it were a 303 response", which is true for urllib2.py too ( see line 585 ): http_error_301 = http_error_303 = http_error_307 = http_error_302 Which means: "all redirections are treated the same way". So, if we want to strictly respect the RFC, we should implement 4 different methods: - http_error_301 - http_error_303 - http_error_307 - http_error_302 But urllib2 is implementing the RFC "the easy way", this is: "threat all redirections the same, threat them as 303". 303 redirections perform a GET on the URI, which urllib2 does here: return Request(newurl, headers=req.headers, origin_req_host=req.get_origin_req_host(), unverifiable=True) These line does not clone the old request completely, it creates a GET request. If we create a GET request (handling 302 as 303) we should remove the content length header! __________________________________ Tracker __________________________________ From report at bugs.python.org Thu Nov 8 13:59:09 2007 From: report at bugs.python.org (Amaury Forgeot d'Arc) Date: Thu, 08 Nov 2007 12:59:09 -0000 Subject: [issue1395] py3k: duplicated line endings when using read(1) Message-ID: <1194526749.8.0.705105055834.issue1395@psf.upfronthosting.co.za> Amaury Forgeot d'Arc added the comment: OK, I have taken another approach which seems to work (see io4.diff): It uses an IncrementalNewlineDecoder, which wraps the initial (e.g. utf-8) decoder. All the tests in test_io pass on Windows, including those added by io.diff and io2.diff. This was not the case with the other proposed patches. While not completely finished, this approach seems much saner to me: it is simple, does not introduce obscure variables or functions, and is compatible with the (complex) code in tell() which reconstruct the file position. Next steps are: - move _seennl management inside this decoder, and remove _replacenl - make the decoder directly inherit from codecs.IncrementalDecoder; code may be easier to understand. - fix test_mailbox. About mailbox.py: it seems that the code cannot work: it uses statements like self._file.read(stop - self._file.tell()) where 'stop' was previously initialized with some other call to self._file.tell(). But read() counts characters, whereas tell() returns byte counts. The question is now: how does it work with python2.5? I'll try to add debug prints to see where the differences are. Added file: http://bugs.python.org/file8711/io4.diff __________________________________ Tracker __________________________________ -------------- next part -------------- A non-text attachment was scrubbed... Name: io4.diff Type: application/octet-stream Size: 6608 bytes Desc: not available Url : http://mail.python.org/pipermail/python-bugs-list/attachments/20071108/774563e0/attachment.obj From report at bugs.python.org Thu Nov 8 14:17:29 2007 From: report at bugs.python.org (Christian Heimes) Date: Thu, 08 Nov 2007 13:17:29 -0000 Subject: [issue1395] py3k: duplicated line endings when using read(1) Message-ID: <1194527849.91.0.0753287952318.issue1395@psf.upfronthosting.co.za> Christian Heimes added the comment: The patch doesn't apply $ patch -p0 < io4.diff (Stripping trailing CRs from patch.) patching file Lib/io.py patch: **** malformed patch at line 41: @@ -1133,7 +1160,10 @@ __________________________________ Tracker __________________________________ From report at bugs.python.org Thu Nov 8 14:23:36 2007 From: report at bugs.python.org (Amaury Forgeot d'Arc) Date: Thu, 08 Nov 2007 13:23:36 -0000 Subject: [issue1395] py3k: duplicated line endings when using read(1) Message-ID: <1194528216.04.0.927962815266.issue1395@psf.upfronthosting.co.za> Amaury Forgeot d'Arc added the comment: Sorry, I think I corrupted the file by hand. Here is another version Added file: http://bugs.python.org/file8712/io4.diff __________________________________ Tracker __________________________________ -------------- next part -------------- A non-text attachment was scrubbed... Name: io4.diff Type: application/octet-stream Size: 6608 bytes Desc: not available Url : http://mail.python.org/pipermail/python-bugs-list/attachments/20071108/2aed2803/attachment.obj From report at bugs.python.org Thu Nov 8 14:28:13 2007 From: report at bugs.python.org (Christian Heimes) Date: Thu, 08 Nov 2007 13:28:13 -0000 Subject: [issue1393] function comparing lacks NotImplemented error Message-ID: <1194528493.5.0.779027996968.issue1393@psf.upfronthosting.co.za> Christian Heimes added the comment: Additional prints make it easy to understand what happens here: >>> class Anything: ... def __eq__(self, other): ... print("eq") ... return True ... def __ne__(self, other): ... print("ne") ... return False ... >>> x = lambda: None >>> print(x == Anything()) False >>> print(Anything() == x) eq True >>> y = object() >>> print(y == Anything()) eq True >>> print(Anything() == y) eq True x == Anything() doesn't invoke Anything.__eq__(). It's using function.__eq__(). ---------- nosy: +tiran __________________________________ Tracker __________________________________ From report at bugs.python.org Thu Nov 8 14:30:48 2007 From: report at bugs.python.org (Amaury Forgeot d'Arc) Date: Thu, 08 Nov 2007 13:30:48 -0000 Subject: [issue1395] py3k: duplicated line endings when using read(1) Message-ID: <1194528648.91.0.0536631802099.issue1395@psf.upfronthosting.co.za> Amaury Forgeot d'Arc added the comment: > About mailbox.py: it seems that the code cannot work Of course: the file mode was recently changed from rb+ to r+ (revision 57809). This means that every occurrence of os.linesep has to disappear. Oh my. __________________________________ Tracker __________________________________ From report at bugs.python.org Thu Nov 8 14:32:29 2007 From: report at bugs.python.org (Christian Heimes) Date: Thu, 08 Nov 2007 13:32:29 -0000 Subject: [issue1377] test_import breaks on Linux Message-ID: <1194528749.17.0.923394483771.issue1377@psf.upfronthosting.co.za> Changes by Christian Heimes: ---------- resolution: accepted -> remind status: open -> closed __________________________________ Tracker __________________________________ From report at bugs.python.org Thu Nov 8 14:39:22 2007 From: report at bugs.python.org (Christian Heimes) Date: Thu, 08 Nov 2007 13:39:22 -0000 Subject: [issue1337] Tools/msi/msi.py does not work with PCBuild8 Message-ID: <1194529162.14.0.117564458685.issue1337@psf.upfronthosting.co.za> Christian Heimes added the comment: PCBuild is still the default compiler for Python but any patches are appreciated. You could start by writing a new or updating the old compiler command to support VS 2005. The old distutils.msvccompiler supports only MSVC 6 and 7 but not 8. ---------- nosy: +tiran priority: -> low resolution: -> later __________________________________ Tracker __________________________________ From report at bugs.python.org Thu Nov 8 14:43:25 2007 From: report at bugs.python.org (Christian Heimes) Date: Thu, 08 Nov 2007 13:43:25 -0000 Subject: [issue1283] PyBytes (buffer) .extend method needs to accept any iterable of ints Message-ID: <1194529405.23.0.915302115222.issue1283@psf.upfronthosting.co.za> Changes by Christian Heimes: ---------- components: +Interpreter Core priority: -> low resolution: -> accepted type: -> rfe __________________________________ Tracker __________________________________ From report at bugs.python.org Thu Nov 8 14:45:55 2007 From: report at bugs.python.org (Christian Heimes) Date: Thu, 08 Nov 2007 13:45:55 -0000 Subject: [issue1042] test_glob fails with UnicodeDecodeError Message-ID: <1194529555.58.0.48319394732.issue1042@psf.upfronthosting.co.za> Christian Heimes added the comment: I'm unable to reproduce the error and I haven't seen it for a long time. Closing ---------- keywords: +rfe resolution: -> out of date status: open -> closed type: -> behavior __________________________________ Tracker __________________________________ From report at bugs.python.org Thu Nov 8 14:49:43 2007 From: report at bugs.python.org (Christian Heimes) Date: Thu, 08 Nov 2007 13:49:43 -0000 Subject: [issue1127] No tests for inspect.getfullargspec() Message-ID: <1194529783.67.0.210657444814.issue1127@psf.upfronthosting.co.za> Christian Heimes added the comment: I've applied your patch in r58910. Thanks! Please open another bug if you have additional tests. ---------- nosy: +tiran resolution: -> fixed __________________________________ Tracker __________________________________ From report at bugs.python.org Thu Nov 8 14:53:28 2007 From: report at bugs.python.org (Christian Heimes) Date: Thu, 08 Nov 2007 13:53:28 -0000 Subject: [issue1210] imaplib does not run under Python 3 Message-ID: <1194530008.29.0.130790419679.issue1210@psf.upfronthosting.co.za> Christian Heimes added the comment: The transition is done. Can you work on a patch and maybe add some tests, too? It helps when you start Python with the -bb flag: $ ./python -bb -c 'import imaplib; imaplib.Debug=5; imaplib.IMAP4("mail.rtmq.infosathse.com")' 52:01.86 imaplib version 2.58 52:01.86 new IMAP4 connection, tag=PNFO Traceback (most recent call last): File "", line 1, in File "/home/heimes/dev/python/py3k/Lib/imaplib.py", line 184, in __init__ self.welcome = self._get_response() File "/home/heimes/dev/python/py3k/Lib/imaplib.py", line 907, in _get_response resp = self._get_line() File "/home/heimes/dev/python/py3k/Lib/imaplib.py", line 1009, in _get_line self._mesg('< %s' % line) File "/home/heimes/dev/python/py3k/Lib/warnings.py", line 62, in warn globals) File "/home/heimes/dev/python/py3k/Lib/warnings.py", line 102, in warn_explicit raise message BytesWarning: str() on a bytes instance ---------- nosy: +tiran __________________________________ Tracker __________________________________ From report at bugs.python.org Thu Nov 8 14:57:06 2007 From: report at bugs.python.org (Christian Heimes) Date: Thu, 08 Nov 2007 13:57:06 -0000 Subject: [issue1144] parsermodule validation out of sync with Grammar Message-ID: <1194530226.84.0.130074451337.issue1144@psf.upfronthosting.co.za> Christian Heimes added the comment: It's still breaking but Guido should know how to fix the parser. ---------- assignee: -> gvanrossum keywords: +patch nosy: +gvanrossum, tiran priority: normal -> low resolution: -> accepted __________________________________ Tracker __________________________________ From report at bugs.python.org Thu Nov 8 15:01:08 2007 From: report at bugs.python.org (Christian Heimes) Date: Thu, 08 Nov 2007 14:01:08 -0000 Subject: [issue1403] io or codecs bug in codecs.getincrementaldecoder Message-ID: <1194530468.74.0.0933952267806.issue1403@psf.upfronthosting.co.za> New submission from Christian Heimes: $ ./python Lib/compileall.py Listing /home/heimes/dev/python/py3k/Lib ... Compiling /home/heimes/dev/python/py3k/Lib/pydoc.py ... Traceback (most recent call last): File "Lib/compileall.py", line 162, in exit_status = int(not main()) File "Lib/compileall.py", line 155, in main success = compile_path() File "Lib/compileall.py", line 110, in compile_path force, quiet=quiet) File "Lib/compileall.py", line 65, in compile_dir ok = py_compile.compile(fullname, None, dfile, True) File "/home/heimes/dev/python/py3k/Lib/py_compile.py", line 137, in compile codestring = f.read() File "/home/heimes/dev/python/py3k/Lib/io.py", line 1243, in read decoder = self._decoder or self._get_decoder() File "/home/heimes/dev/python/py3k/Lib/io.py", line 1132, in _get_decoder make_decoder = codecs.getincrementaldecoder(self._encoding) File "/home/heimes/dev/python/py3k/Lib/codecs.py", line 951, in getincrementaldecoder decoder = lookup(encoding).incrementaldecoder LookupError: unknown encoding: b'Latin-1' ---------- components: Library (Lib) keywords: py3k messages: 57244 nosy: tiran priority: high severity: normal status: open title: io or codecs bug in codecs.getincrementaldecoder type: crash versions: Python 3.0 __________________________________ Tracker __________________________________ From report at bugs.python.org Thu Nov 8 15:02:42 2007 From: report at bugs.python.org (Christian Heimes) Date: Thu, 08 Nov 2007 14:02:42 -0000 Subject: [issue1404] warnings module bug: BytesWarning: str() on a bytes instance Message-ID: <1194530562.67.0.490755632259.issue1404@psf.upfronthosting.co.za> New submission from Christian Heimes: $ ./python -bb Lib/compileall.py Listing /home/heimes/dev/python/py3k/Lib ... Compiling /home/heimes/dev/python/py3k/Lib/pydoc.py ... Traceback (most recent call last): File "Lib/compileall.py", line 162, in exit_status = int(not main()) File "Lib/compileall.py", line 155, in main success = compile_path() File "Lib/compileall.py", line 110, in compile_path force, quiet=quiet) File "Lib/compileall.py", line 65, in compile_dir ok = py_compile.compile(fullname, None, dfile, True) File "/home/heimes/dev/python/py3k/Lib/py_compile.py", line 131, in compile encoding = read_encoding(file, "utf-8") File "/home/heimes/dev/python/py3k/Lib/py_compile.py", line 91, in read_encoding return str(m.group(1)) File "/home/heimes/dev/python/py3k/Lib/warnings.py", line 62, in warn globals) File "/home/heimes/dev/python/py3k/Lib/warnings.py", line 102, in warn_explicit raise message BytesWarning: str() on a bytes instance ---------- assignee: tiran components: Library (Lib) keywords: patch messages: 57245 nosy: tiran priority: high severity: normal status: open title: warnings module bug: BytesWarning: str() on a bytes instance type: behavior versions: Python 3.0 __________________________________ Tracker __________________________________ From report at bugs.python.org Thu Nov 8 15:06:58 2007 From: report at bugs.python.org (Christian Heimes) Date: Thu, 08 Nov 2007 14:06:58 -0000 Subject: [issue1110] Problems with the msi installer - python-3.0a1.msi Message-ID: <1194530818.69.0.297220935668.issue1110@psf.upfronthosting.co.za> Christian Heimes added the comment: I've validated a) and fixed b) two weeks ago. I'm closing this bug. It doesn't contain any additional problems for the bug. I expect the next alpha of Python 3.0 in about two weeks. Please test the next version, would you? The problems with your localization of Windows should be fixed as long as you don't install Python into a directory with non ASCII letters. ---------- nosy: +tiran superseder: -> io or codecs bug in codecs.getincrementaldecoder __________________________________ Tracker __________________________________ From report at bugs.python.org Thu Nov 8 15:07:03 2007 From: report at bugs.python.org (Quentin Gallet-Gilles) Date: Thu, 08 Nov 2007 14:07:03 -0000 Subject: [issue1127] No tests for inspect.getfullargspec() Message-ID: <1194530823.19.0.611360695013.issue1127@psf.upfronthosting.co.za> Quentin Gallet-Gilles added the comment: Alright, thanks! __________________________________ Tracker __________________________________ From report at bugs.python.org Thu Nov 8 15:07:23 2007 From: report at bugs.python.org (Christian Heimes) Date: Thu, 08 Nov 2007 14:07:23 -0000 Subject: [issue1110] Problems with the msi installer - python-3.0a1.msi Message-ID: <1194530843.41.0.261764584516.issue1110@psf.upfronthosting.co.za> Changes by Christian Heimes: ---------- resolution: -> duplicate status: open -> closed __________________________________ Tracker __________________________________ From report at bugs.python.org Thu Nov 8 15:08:18 2007 From: report at bugs.python.org (Christian Heimes) Date: Thu, 08 Nov 2007 14:08:18 -0000 Subject: [issue1086] test_email failed Message-ID: <1194530898.45.0.178225442689.issue1086@psf.upfronthosting.co.za> Christian Heimes added the comment: Fixed about two weeks ago ---------- keywords: +rfe nosy: +tiran resolution: -> fixed status: open -> closed __________________________________ Tracker __________________________________ From report at bugs.python.org Thu Nov 8 15:18:00 2007 From: report at bugs.python.org (Christian Heimes) Date: Thu, 08 Nov 2007 14:18:00 -0000 Subject: [issue1087] py3k os.popen result is not iterable, patch attached Message-ID: <1194531480.0.0.141906660951.issue1087@psf.upfronthosting.co.za> New submission from Christian Heimes: os.popen was reimplemented a while ago. It's using the subprocess. I've added a unit test to verify the existence of __iter__() in r58912. ---------- nosy: +tiran resolution: -> invalid status: open -> closed __________________________________ Tracker __________________________________ From report at bugs.python.org Thu Nov 8 15:20:18 2007 From: report at bugs.python.org (Christian Heimes) Date: Thu, 08 Nov 2007 14:20:18 -0000 Subject: [issue1720390] Remove backslash escapes from tokenize.c. Message-ID: <1194531618.91.0.451410495153.issue1720390@psf.upfronthosting.co.za> Christian Heimes added the comment: Can you create a new patch and verify that the problem still exists? norawescape3.diff doesn't apply cleanly any more. ---------- nosy: +tiran _____________________________________ Tracker _____________________________________ From report at bugs.python.org Thu Nov 8 15:28:39 2007 From: report at bugs.python.org (Christian Heimes) Date: Thu, 08 Nov 2007 14:28:39 -0000 Subject: [issue1020] pyexpat.XMParserType broken (was: pydoc doesn't work on pyexpat) Message-ID: <1194532119.06.0.477711523213.issue1020@psf.upfronthosting.co.za> Christian Heimes added the comment: It's not a problem with pydoc but a problem in the pyexpat module. I believe that the C code is broken. See for yourself: >>> dir(pyexpat.XMLParserType) ['__class__', '__delattr__', '__dir__', '__doc__', '__eq__', '__format__', '__ge__', '__getattribute__', '__gt__', '__hash__', '__init__', '__le__', '__lt__', '__ne__', '__new__', '__reduce__', '__reduce_ex__', '__repr__', '__setattr__', '__str__', 'xZK\x08'] There is an issue in the method list. Since most lines of pyexpat were written by fdrake I'm assigning the bug to him. ---------- assignee: -> fdrake keywords: +py3k nosy: +fdrake, tiran priority: low -> high resolution: -> accepted title: pydoc doesn't work on pyexpat -> pyexpat.XMParserType broken (was: pydoc doesn't work on pyexpat) __________________________________ Tracker __________________________________ From report at bugs.python.org Thu Nov 8 15:40:02 2007 From: report at bugs.python.org (Christian Heimes) Date: Thu, 08 Nov 2007 14:40:02 -0000 Subject: [issue1395] py3k: duplicated line endings when using read(1) Message-ID: <1194532802.67.0.133943510643.issue1395@psf.upfronthosting.co.za> Christian Heimes added the comment: The new io4.diff breaks test_io and test_univnewlines on Linux Added file: http://bugs.python.org/file8713/linux_test.log.gz __________________________________ Tracker __________________________________ -------------- next part -------------- A non-text attachment was scrubbed... Name: linux_test.log.gz Type: application/x-gzip Size: 295 bytes Desc: not available Url : http://mail.python.org/pipermail/python-bugs-list/attachments/20071108/e724b8b2/attachment.bin From report at bugs.python.org Thu Nov 8 15:52:51 2007 From: report at bugs.python.org (Christian Heimes) Date: Thu, 08 Nov 2007 14:52:51 -0000 Subject: [issue1282] re module needs to support bytes / memoryview well Message-ID: <1194533571.31.0.794277564046.issue1282@psf.upfronthosting.co.za> Changes by Christian Heimes: ---------- keywords: +py3k priority: -> normal resolution: -> accepted type: -> rfe __________________________________ Tracker __________________________________ From report at bugs.python.org Thu Nov 8 15:54:39 2007 From: report at bugs.python.org (Christian Heimes) Date: Thu, 08 Nov 2007 14:54:39 -0000 Subject: [issue1333] merge urllib and urlparse functionality Message-ID: <1194533679.58.0.508902397077.issue1333@psf.upfronthosting.co.za> Changes by Christian Heimes: ---------- keywords: +py3k priority: -> normal resolution: -> accepted __________________________________ Tracker __________________________________ From report at bugs.python.org Thu Nov 8 15:59:56 2007 From: report at bugs.python.org (Christian Heimes) Date: Thu, 08 Nov 2007 14:59:56 -0000 Subject: [issue1351] Add getsize() to io instances Message-ID: <1194533996.25.0.318061849639.issue1351@psf.upfronthosting.co.za> Christian Heimes added the comment: > (a) the SizeInfo class is overkill. getsize() should just return an int. But I like overkill :) > (b) getsize() should check self.seekable() first and raise the appropriate error if the file isn't seekable. That's easy to implement > (c) os.fstat() is much less likely to work than the tell-seek-tell-seek sequence, so why not use that everywhere? fstat doesn't have concurrency problems in multi threaded apps. I haven't profiled it but I would guess that fstat is also faster than tell seek. > (d) people will expect to use this on text files, but of course the outcome will be in bytes, hence useless. I could rename the method to getfssize, getbytesize, getsizeb ... to make clear that it doesn't return the amount of chars but the amount of used bytes. ---------- keywords: +patch, py3k priority: -> low __________________________________ Tracker __________________________________ From report at bugs.python.org Thu Nov 8 15:59:57 2007 From: report at bugs.python.org (Raghuram Devarakonda) Date: Thu, 08 Nov 2007 14:59:57 -0000 Subject: [issue1210] imaplib does not run under Python 3 Message-ID: <1194533997.61.0.229955858756.issue1210@psf.upfronthosting.co.za> Raghuram Devarakonda added the comment: I will see what I can do but it may take a while. __________________________________ Tracker __________________________________ From report at bugs.python.org Thu Nov 8 16:01:57 2007 From: report at bugs.python.org (Christian Heimes) Date: Thu, 08 Nov 2007 15:01:57 -0000 Subject: [issue1200] Allow array.array to be parsed by the t# format unit. Message-ID: <1194534117.33.0.872088903637.issue1200@psf.upfronthosting.co.za> Changes by Christian Heimes: ---------- keywords: +py3k priority: -> normal type: behavior -> rfe __________________________________ Tracker __________________________________ From report at bugs.python.org Thu Nov 8 16:03:12 2007 From: report at bugs.python.org (Christian Heimes) Date: Thu, 08 Nov 2007 15:03:12 -0000 Subject: [issue1400] Py3k's print() flushing problem Message-ID: <1194534192.87.0.113050915328.issue1400@psf.upfronthosting.co.za> Changes by Christian Heimes: ---------- keywords: +py3k priority: -> high resolution: -> accepted __________________________________ Tracker __________________________________ From report at bugs.python.org Thu Nov 8 16:09:41 2007 From: report at bugs.python.org (Wojciech Walczak) Date: Thu, 08 Nov 2007 15:09:41 -0000 Subject: [issue1400] Py3k's print() flushing problem In-Reply-To: <1194534192.91.0.306296635773.issue1400@psf.upfronthosting.co.za> Message-ID: <2c3c21060711080709t7c1fed5er9559df02344da2b1@mail.gmail.com> Wojciech Walczak added the comment: 2007/11/8, admin : > ---------- > keywords: +py3k > priority: -> high > resolution: -> accepted Which resolution was accepted? Wojtek Walczak __________________________________ Tracker __________________________________ From report at bugs.python.org Thu Nov 8 17:31:30 2007 From: report at bugs.python.org (Stefan Sonnenberg-Carstens) Date: Thu, 08 Nov 2007 16:31:30 -0000 Subject: [issue1405] Garbage collection not working correctly in Python 2.3 Message-ID: <1194539490.65.0.919114363971.issue1405@psf.upfronthosting.co.za> New submission from Stefan Sonnenberg-Carstens: when running this script: aList = [] for i in xrange(5E5): aList += [[]] for j in xrange(10): aList[-1].append([]) del aList It does not give back the memory even a import gc gc.collect() afterwards does not do it. In Python 2.5 the memory is freed again correctly, at least under Windows. The problem came up, because I was parsing a CSV file of 50 MB which resulted in memory usage of more than 500 MB. ---------- components: Interpreter Core messages: 57256 nosy: pythonmeister severity: urgent status: open title: Garbage collection not working correctly in Python 2.3 type: resource usage versions: Python 2.3 __________________________________ Tracker __________________________________ From report at bugs.python.org Thu Nov 8 17:35:07 2007 From: report at bugs.python.org (Christian Heimes) Date: Thu, 08 Nov 2007 16:35:07 -0000 Subject: [issue1403] py_compile and compileall need unit tests Message-ID: <1194539707.23.0.692604531186.issue1403@psf.upfronthosting.co.za> Christian Heimes added the comment: I've fixed the bug in r58913. The modules need more unit tests. ---------- priority: high -> low resolution: -> accepted title: io or codecs bug in codecs.getincrementaldecoder -> py_compile and compileall need unit tests __________________________________ Tracker __________________________________ From report at bugs.python.org Thu Nov 8 17:36:07 2007 From: report at bugs.python.org (Christian Heimes) Date: Thu, 08 Nov 2007 16:36:07 -0000 Subject: [issue1404] warnings module bug: BytesWarning: str() on a bytes instance Message-ID: <1194539767.54.0.863889567318.issue1404@psf.upfronthosting.co.za> Christian Heimes added the comment: No bug at all ;) ---------- priority: high -> resolution: -> invalid status: open -> closed __________________________________ Tracker __________________________________ From report at bugs.python.org Thu Nov 8 17:38:46 2007 From: report at bugs.python.org (Stefan Sonnenberg-Carstens) Date: Thu, 08 Nov 2007 16:38:46 -0000 Subject: [issue1366] popen spawned process may not write to stdout under windows Message-ID: <1194539926.59.0.153105211326.issue1366@psf.upfronthosting.co.za> Stefan Sonnenberg-Carstens added the comment: the popen call does not redirect stderr. If you do something like 2>null (windows) or 2>/dev/null (*nix) it will _never_ get printed. If you want to have stderr & stdout getting in via popen and thus stdout, under *nix and windows you would do that: command 2>&1 It is not popen to blame. See this for reference: http://netbsd.gw.com/cgi-bin/man-cgi?popen++NetBSD-current ---------- nosy: +pythonmeister __________________________________ Tracker __________________________________ From report at bugs.python.org Thu Nov 8 17:49:26 2007 From: report at bugs.python.org (Stefan Sonnenberg-Carstens) Date: Thu, 08 Nov 2007 16:49:26 -0000 Subject: [issue1398] Can't pickle partial functions Message-ID: <1194540566.21.0.0154689977302.issue1398@psf.upfronthosting.co.za> Stefan Sonnenberg-Carstens added the comment: You are using an old protocol version pickle.dumps(partial_f,2) does the trick: >>> pickle.dumps(partial_f,2) '\x80\x02cfunctools\npartial\nq\x00)\x81q\x01}q\x02b.' ---------- nosy: +pythonmeister __________________________________ Tracker __________________________________ From report at bugs.python.org Thu Nov 8 18:14:30 2007 From: report at bugs.python.org (=?utf-8?q?Patrick_M=C3=A9zard?=) Date: Thu, 08 Nov 2007 17:14:30 -0000 Subject: [issue1366] popen spawned process may not write to stdout under windows Message-ID: <1194542070.72.0.633481965383.issue1366@psf.upfronthosting.co.za> Patrick M?zard added the comment: pythonmeister: I never expected stderr to be redirected, just *all stdout* to be captured. But... gagenellina: you are completely right about the failure. Still, this issue happened with a real world application written in C, and redirecting manually stderr to :NUL: solved it unexpectedly. I did not expect spawned process behaviour to differ when its stderr is being redirected. __________________________________ Tracker __________________________________ From report at bugs.python.org Thu Nov 8 18:24:23 2007 From: report at bugs.python.org (Christian Heimes) Date: Thu, 08 Nov 2007 17:24:23 -0000 Subject: [issue1127] No tests for inspect.getfullargspec() Message-ID: <1194542663.9.0.411023099521.issue1127@psf.upfronthosting.co.za> Changes by Christian Heimes: ---------- status: open -> closed __________________________________ Tracker __________________________________ From report at bugs.python.org Thu Nov 8 18:28:22 2007 From: report at bugs.python.org (Ron Adam) Date: Thu, 08 Nov 2007 17:28:22 -0000 Subject: [issue1720390] Remove backslash escapes from tokenize.c. Message-ID: <1194542902.33.0.170559091072.issue1720390@psf.upfronthosting.co.za> Ron Adam added the comment: Yes, I will update it. _____________________________________ Tracker _____________________________________ From report at bugs.python.org Thu Nov 8 18:30:00 2007 From: report at bugs.python.org (Christian Heimes) Date: Thu, 08 Nov 2007 17:30:00 -0000 Subject: [issue1405] Garbage collection not working correctly in Python 2.3 Message-ID: <1194543000.87.0.347380043997.issue1405@psf.upfronthosting.co.za> Christian Heimes added the comment: I'm sorry but Python 2.3 is long gone. Its maintenance cycle has ended over a year ago.Nobody is going to fix an outdated version when the new versions of Python are working fine. Can you update to a new version of Python? ---------- nosy: +tiran resolution: -> out of date status: open -> closed __________________________________ Tracker __________________________________ From report at bugs.python.org Thu Nov 8 18:34:55 2007 From: report at bugs.python.org (Christian Heimes) Date: Thu, 08 Nov 2007 17:34:55 -0000 Subject: [issue1398] Can't pickle partial functions Message-ID: <1194543295.79.0.37637567046.issue1398@psf.upfronthosting.co.za> Changes by Christian Heimes: ---------- resolution: -> invalid status: open -> closed __________________________________ Tracker __________________________________ From report at bugs.python.org Thu Nov 8 18:37:27 2007 From: report at bugs.python.org (Amaury Forgeot d'Arc) Date: Thu, 08 Nov 2007 17:37:27 -0000 Subject: [issue1395] py3k: duplicated line endings when using read(1) Message-ID: <1194543447.8.0.921735459822.issue1395@psf.upfronthosting.co.za> Amaury Forgeot d'Arc added the comment: > The new io4.diff breaks test_io and test_univnewlines on Linux oops, I missed this one. Here is a new version: io5.diff, which should handle the "seen newlines" better. Two more bug fixes found by test_univnewlines: - write() should return the number of characters written, but before they are newline-translated. - a problem in tell(), my decoder can return two characters even when you feed only one (example: decode(b'\r') holds the \r and returns nothing. then a decode(b'x') returns both chars "\rx") Added file: http://bugs.python.org/file8714/io5.diff __________________________________ Tracker __________________________________ -------------- next part -------------- A non-text attachment was scrubbed... Name: io5.diff Type: application/octet-stream Size: 14114 bytes Desc: not available Url : http://mail.python.org/pipermail/python-bugs-list/attachments/20071108/c0c18205/attachment-0001.obj From report at bugs.python.org Thu Nov 8 18:38:31 2007 From: report at bugs.python.org (Thomas Heller) Date: Thu, 08 Nov 2007 17:38:31 -0000 Subject: [issue1406] Use widechar api for os.environ Message-ID: <1194543511.82.0.106464214101.issue1406@psf.upfronthosting.co.za> New submission from Thomas Heller: This patch uses the windows widechar apis for os.environ. In this way, environment variables that use umlauts can be accessed. ---------- components: Interpreter Core, Windows files: posixmodule.c.diff keywords: patch, py3k messages: 57265 nosy: theller severity: normal status: open title: Use widechar api for os.environ type: behavior versions: Python 3.0 Added file: http://bugs.python.org/file8715/posixmodule.c.diff __________________________________ Tracker __________________________________ -------------- next part -------------- A non-text attachment was scrubbed... Name: posixmodule.c.diff Type: text/x-diff Size: 3033 bytes Desc: not available Url : http://mail.python.org/pipermail/python-bugs-list/attachments/20071108/545d8802/attachment.diff From report at bugs.python.org Thu Nov 8 18:39:45 2007 From: report at bugs.python.org (Christian Heimes) Date: Thu, 08 Nov 2007 17:39:45 -0000 Subject: [issue1677872] Efficient reverse line iterator Message-ID: <1194543584.98.0.378156778965.issue1677872@psf.upfronthosting.co.za> Christian Heimes added the comment: Some people like the feature, Guido isn't against the feature ... It looks as you have a good chance to get it into Python 3.0. :) Can you come up with a new patch and unit tests? The io module has changed a lot since your initial patch. ---------- nosy: +tiran _____________________________________ Tracker _____________________________________ From report at bugs.python.org Thu Nov 8 18:40:40 2007 From: report at bugs.python.org (Facundo Batista) Date: Thu, 08 Nov 2007 17:40:40 -0000 Subject: [issue1401] urllib2 302 POST Message-ID: <1194543640.32.0.26091364872.issue1401@psf.upfronthosting.co.za> Facundo Batista added the comment: So, for 302 error we should resend the request as POST (header with lenght and data), and for the others we need to keep current behaviour. Actually, we just need to code a new handling function for 302, and leave the existing one as is. What do you think? __________________________________ Tracker __________________________________ From report at bugs.python.org Thu Nov 8 18:56:11 2007 From: report at bugs.python.org (Andres Riancho) Date: Thu, 08 Nov 2007 17:56:11 -0000 Subject: [issue1401] urllib2 302 POST Message-ID: <1194544571.15.0.667039630893.issue1401@psf.upfronthosting.co.za> Andres Riancho added the comment: According to the RFC: If urllib2 gets a 302 in response to a request, it MUST send the *same* request to the URI specified in the Location header, without modifying the method, headers, or any data (urllib2 is not RFC compliant here) In urllib2, a 301 and a 307 message should be handled just like a 302. If urllib2 gets a 303 in response to a request, it MUST send a GET request to the URI specified in the Location header (urllib2 is "half" RFC compliant here, this only works if the original request WASN'T a POST request) I will code a complete patch to make urllib2 work as RFC Compliant as possible. Whenever it's ready i'll send it. __________________________________ Tracker __________________________________ From report at bugs.python.org Thu Nov 8 19:04:48 2007 From: report at bugs.python.org (Mark Russell) Date: Thu, 08 Nov 2007 18:04:48 -0000 Subject: [issue1677872] Efficient reverse line iterator Message-ID: <1194545088.23.0.523570389958.issue1677872@psf.upfronthosting.co.za> Mark Russell added the comment: Sure - I'll do an updated patch at the weekend. _____________________________________ Tracker _____________________________________ From report at bugs.python.org Thu Nov 8 19:05:05 2007 From: report at bugs.python.org (Christian Heimes) Date: Thu, 08 Nov 2007 18:05:05 -0000 Subject: [issue1081] file.seek allows float arguments Message-ID: <1194545105.18.0.65431682854.issue1081@psf.upfronthosting.co.za> Christian Heimes added the comment: Fixed in r58914 ---------- nosy: +tiran resolution: -> fixed status: open -> closed __________________________________ Tracker __________________________________ From report at bugs.python.org Thu Nov 8 19:10:57 2007 From: report at bugs.python.org (Christian Heimes) Date: Thu, 08 Nov 2007 18:10:57 -0000 Subject: [issue1406] Use widechar api for os.environ Message-ID: <1194545457.57.0.281109882829.issue1406@psf.upfronthosting.co.za> Christian Heimes added the comment: Great work! :) I've been waiting for a fix. Do you have time to rework PC/getpathp.c and other code related to sys.path? It's still using the ASCII api which causes bugs like http://bugs.python.org/issue1342 ---------- nosy: +tiran priority: -> high resolution: -> accepted __________________________________ Tracker __________________________________ From report at bugs.python.org Thu Nov 8 19:54:25 2007 From: report at bugs.python.org (Raghuram Devarakonda) Date: Thu, 08 Nov 2007 18:54:25 -0000 Subject: [issue1395] py3k: duplicated line endings when using read(1) Message-ID: <1194548065.14.0.942752491397.issue1395@psf.upfronthosting.co.za> Raghuram Devarakonda added the comment: Considering that test_csv is failing on windows even without any changes related to this issue, I looked at it and came up with this patch: ----------------- Index: Lib/test/test_csv.py =================================================================== --- Lib/test/test_csv.py (revision 58914) +++ Lib/test/test_csv.py (working copy) @@ -375,7 +375,7 @@ class TestCsvBase(unittest.TestCase): def readerAssertEqual(self, input, expected_result): - with TemporaryFile("w+") as fileobj: + with TemporaryFile("w+", newline='') as fileobj: fileobj.write(input) fileobj.seek(0) reader = csv.reader(fileobj, dialect = self.dialect) ----------------- Does this look ok? The tests pass on windows and Linux. __________________________________ Tracker __________________________________ From report at bugs.python.org Thu Nov 8 20:00:25 2007 From: report at bugs.python.org (Raghuram Devarakonda) Date: Thu, 08 Nov 2007 19:00:25 -0000 Subject: [issue1395] py3k: duplicated line endings when using read(1) In-Reply-To: <1194526749.8.0.705105055834.issue1395@psf.upfronthosting.co.za> Message-ID: <2c51ecee0711081059v720a0a69m5a7f1a334e87aae3@mail.gmail.com> Raghuram Devarakonda added the comment: On 11/8/07, Amaury Forgeot d'Arc wrote: > OK, I have taken another approach which seems to work (see io4.diff): > It uses an IncrementalNewlineDecoder, which wraps the initial (e.g. > utf-8) decoder. I like this approach even though I haven't looked at the patch in detail. __________________________________ Tracker __________________________________ From report at bugs.python.org Thu Nov 8 20:36:43 2007 From: report at bugs.python.org (Thomas Heller) Date: Thu, 08 Nov 2007 19:36:43 -0000 Subject: [issue1406] Use widechar api for os.environ Message-ID: <1194550603.07.0.206091992182.issue1406@psf.upfronthosting.co.za> Thomas Heller added the comment: Committed as rev 58916. The getpath.c, sys.path, and sys.argv issues is much more difficult to fix IMO. If you write a testcase for THIS issue (os.environ), I'll start thinking on them. No promises, though. ---------- assignee: -> theller resolution: accepted -> fixed status: open -> closed __________________________________ Tracker __________________________________ From report at bugs.python.org Thu Nov 8 21:30:33 2007 From: report at bugs.python.org (Wojciech Walczak) Date: Thu, 08 Nov 2007 20:30:33 -0000 Subject: [issue1407] [performance] Too many closed() checkings Message-ID: <1194553833.1.0.901439748582.issue1407@psf.upfronthosting.co.za> New submission from Wojciech Walczak: For debugging reasons I have added a simple line to PyObject_Call() function in Objects/abstract.c: printf("%s.%s\n", func->ob_type->tp_name, PyEval_GetFuncName(func)); Now, after compiling python and running interpreter with simple print() call I receive this: Python 3.0a1 (py3k, Nov 6 2007, 19:25:33) [GCC 4.1.2] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> print('!',end='') builtin_function_or_method.print method.write function.write function.closed function.closed builtin_function_or_method.ascii_encode function.closed function.closed !method.write # here it goes again for 'end' parameter function.write function.closed function.closed builtin_function_or_method.ascii_encode function.closed builtin_function_or_method.displayhook >>> Note that there can be something going on between one function.closed and the next one, because not every piece of code gets called by PyObject_Call(), but still - isn't it checking if stream is closed a bit too often? Regards, Wojtek Walczak ---------- components: Build messages: 57275 nosy: wojtekwalczak severity: minor status: open title: [performance] Too many closed() checkings type: resource usage versions: Python 3.0 __________________________________ Tracker __________________________________ From report at bugs.python.org Thu Nov 8 21:56:19 2007 From: report at bugs.python.org (Christian Heimes) Date: Thu, 08 Nov 2007 20:56:19 -0000 Subject: [issue1407] [performance] Too many closed() checkings Message-ID: <1194555378.99.0.422702018796.issue1407@psf.upfronthosting.co.za> Christian Heimes added the comment: The problem should be addressed after the last alpha during the optimization and cleanup phase. ---------- components: +Interpreter Core, Library (Lib) -Build keywords: +py3k nosy: +tiran priority: -> normal resolution: -> later __________________________________ Tracker __________________________________ From report at bugs.python.org Thu Nov 8 21:59:21 2007 From: report at bugs.python.org (beco) Date: Thu, 08 Nov 2007 20:59:21 -0000 Subject: [issue1408] Inconsistence in multiply list Message-ID: <1194555561.37.0.908448311381.issue1408@psf.upfronthosting.co.za> Changes by beco: ---------- components: Interpreter Core nosy: beco severity: major status: open title: Inconsistence in multiply list type: behavior versions: Python 2.5 __________________________________ Tracker __________________________________ From report at bugs.python.org Thu Nov 8 22:00:02 2007 From: report at bugs.python.org (Paul Pogonyshev) Date: Thu, 08 Nov 2007 21:00:02 -0000 Subject: [issue1409] new keyword-only function parameters interact badly with nested functions Message-ID: <1194555602.57.0.256813335387.issue1409@psf.upfronthosting.co.za> New submission from Paul Pogonyshev: Attached scripts fails with 'NameError: free variable 'a' referenced before assignment in enclosing scope'. If you remove '*' in function parameter list, it works. I think it is a bug. ---------- components: Interpreter Core files: test.py messages: 57277 nosy: _doublep severity: normal status: open title: new keyword-only function parameters interact badly with nested functions type: behavior versions: Python 3.0 Added file: http://bugs.python.org/file8716/test.py __________________________________ Tracker __________________________________ -------------- next part -------------- A non-text attachment was scrubbed... Name: test.py Type: text/x-python Size: 191 bytes Desc: not available Url : http://mail.python.org/pipermail/python-bugs-list/attachments/20071108/e102fc99/attachment.py From report at bugs.python.org Thu Nov 8 22:06:58 2007 From: report at bugs.python.org (Paul Pogonyshev) Date: Thu, 08 Nov 2007 21:06:58 -0000 Subject: [issue1390] toxml generates output that is not well formed Message-ID: <1194556018.45.0.839752051649.issue1390@psf.upfronthosting.co.za> Paul Pogonyshev added the comment: I think unexpected exception in toxml() is not worse than producing unreadable output. With createComment() it is different, since you can e.g. create a temporary DOM tree only to discard it later and never serialize. __________________________________ Tracker __________________________________ From report at bugs.python.org Thu Nov 8 22:14:08 2007 From: report at bugs.python.org (beco) Date: Thu, 08 Nov 2007 21:14:08 -0000 Subject: [issue1408] Inconsistence in multiply list Message-ID: <1194556448.46.0.361178031536.issue1408@psf.upfronthosting.co.za> New submission from beco: There is no way to create a big nested list without references using the multiplication operator. '*' is supposed to work like + ... + in this cases: >>> a=[0, 0] >>> b=[a[:]]+[a[:]] >>> b [[0, 0], [0, 0]] >>> b[0][0]=1 >>> b [[1, 0], [0, 0]] Ok! Copy here, not reference. Mainly because we use [:] explicitly expressing we want a copy. >>> c=[a[:]]*2 >>> c [[0, 0], [0, 0]] >>> c[0][0]=2 >>> c [[2, 0], [2, 0]] Inconsistence here. It is supposed to be clear and copy, not reference in between. Consequence: there is no clear way to create a nested list of, lets say, 60x60, using multiplications. Even when using this, we cannot deal with the problem: >>> import copy >>> d=[copy.deepcopy(a[:])]*2 >>> d [[0, 0], [0, 0]] >>> d[0][0]=3 >>> d [[3, 0], [3, 0]] Workaround: >>> from numpy import * >>> a=zeros((2,2),int) >>> a array([[0, 0], [0, 0]]) >>> b=a.tolist() >>> b [[0, 0], [0, 0]] >>> b[0][0]=4 >>> b [[4, 0], [0, 0]] And that is the expected behaviour. Thanks. __________________________________ Tracker __________________________________ From report at bugs.python.org Thu Nov 8 22:25:53 2007 From: report at bugs.python.org (=?utf-8?q?Walter_D=C3=B6rwald?=) Date: Thu, 08 Nov 2007 21:25:53 -0000 Subject: [issue1399] XML codec Message-ID: <1194557153.43.0.839111041592.issue1399@psf.upfronthosting.co.za> Walter D?rwald added the comment: OK, I've changed the name of the codec to xml_auto_detect and added support for EBCDIC. Added file: http://bugs.python.org/file8717/diff2.txt __________________________________ Tracker __________________________________ -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: diff2.txt Url: http://mail.python.org/pipermail/python-bugs-list/attachments/20071108/e048f7bd/attachment.txt From report at bugs.python.org Thu Nov 8 22:37:27 2007 From: report at bugs.python.org (Marc-Andre Lemburg) Date: Thu, 08 Nov 2007 21:37:27 -0000 Subject: [issue1399] XML codec Message-ID: <1194557847.7.0.615181018919.issue1399@psf.upfronthosting.co.za> Marc-Andre Lemburg added the comment: Thanks, Walter ! __________________________________ Tracker __________________________________ From report at bugs.python.org Thu Nov 8 23:22:08 2007 From: report at bugs.python.org (Christian Heimes) Date: Thu, 08 Nov 2007 22:22:08 -0000 Subject: [issue1409] new keyword-only function parameters interact badly with nested functions Message-ID: <1194560528.31.0.675689491868.issue1409@psf.upfronthosting.co.za> Changes by Christian Heimes: ---------- keywords: +py3k priority: -> normal resolution: -> accepted __________________________________ Tracker __________________________________ From report at bugs.python.org Fri Nov 9 00:13:40 2007 From: report at bugs.python.org (J. Peterson) Date: Thu, 08 Nov 2007 23:13:40 -0000 Subject: [issue1410] BaseHTTPServer cannot accept Unicode data Message-ID: <1194563620.66.0.0649109555228.issue1410@psf.upfronthosting.co.za> Changes by J. Peterson: ---------- components: Library (Lib) nosy: isonno severity: normal status: open title: BaseHTTPServer cannot accept Unicode data type: behavior versions: Python 2.5 __________________________________ Tracker __________________________________ From report at bugs.python.org Fri Nov 9 00:16:21 2007 From: report at bugs.python.org (J. Peterson) Date: Thu, 08 Nov 2007 23:16:21 -0000 Subject: [issue1410] BaseHTTPServer cannot accept Unicode data Message-ID: <1194563781.56.0.332937984797.issue1410@psf.upfronthosting.co.za> New submission from J. Peterson: Within a do_GET hander for a BaseHTTPServer.BaseHTTPRequestHandler, trying to write unicode data causes a UnicodeEncodeError exception. It should be possible to send Unicode data to the browser. The enclosed Python file demonstrates the issue. Added file: http://bugs.python.org/file8718/TestUnicodeHTTP.py __________________________________ Tracker __________________________________ -------------- next part -------------- A non-text attachment was scrubbed... Name: TestUnicodeHTTP.py Type: application/octet-stream Size: 859 bytes Desc: not available Url : http://mail.python.org/pipermail/python-bugs-list/attachments/20071108/0a14bb8d/attachment.obj From report at bugs.python.org Fri Nov 9 00:30:01 2007 From: report at bugs.python.org (Amaury Forgeot d'Arc) Date: Thu, 08 Nov 2007 23:30:01 -0000 Subject: [issue1395] py3k: duplicated line endings when using read(1) Message-ID: <1194564601.83.0.906212727755.issue1395@psf.upfronthosting.co.za> Amaury Forgeot d'Arc added the comment: Updated patch (io6.diff): - simplifications in readline - seennl is now completely handled by the NewlineDecoder Added file: http://bugs.python.org/file8719/io6.diff __________________________________ Tracker __________________________________ -------------- next part -------------- A non-text attachment was scrubbed... Name: io6.diff Type: application/octet-stream Size: 15381 bytes Desc: not available Url : http://mail.python.org/pipermail/python-bugs-list/attachments/20071108/fc9074dd/attachment.obj From report at bugs.python.org Fri Nov 9 00:52:54 2007 From: report at bugs.python.org (Brad Johnson) Date: Thu, 08 Nov 2007 23:52:54 -0000 Subject: [issue1720250] PyGILState_Ensure does not acquires GIL Message-ID: <1194565974.17.0.823220100057.issue1720250@psf.upfronthosting.co.za> Changes by Brad Johnson: ---------- nosy: +urBan_dK _____________________________________ Tracker _____________________________________ From report at bugs.python.org Fri Nov 9 01:03:17 2007 From: report at bugs.python.org (Guido van Rossum) Date: Fri, 09 Nov 2007 00:03:17 -0000 Subject: [issue1400] Py3k's print() flushing problem Message-ID: <1194566597.47.0.0293855173959.issue1400@psf.upfronthosting.co.za> Guido van Rossum added the comment: I don't think anything was accepted yet. ---------- nosy: +gvanrossum resolution: accepted -> __________________________________ Tracker __________________________________ From report at bugs.python.org Fri Nov 9 01:05:09 2007 From: report at bugs.python.org (Guido van Rossum) Date: Fri, 09 Nov 2007 00:05:09 -0000 Subject: [issue1402] Interpreter cleanup: order of _PyGILState_Fini and PyInterpreterState_Clear Message-ID: <1194566709.74.0.0112480633477.issue1402@psf.upfronthosting.co.za> Guido van Rossum added the comment: Do you have a patch? Then we could consider fixing this in 2.5.2. ---------- nosy: +gvanrossum __________________________________ Tracker __________________________________ From report at bugs.python.org Fri Nov 9 01:23:01 2007 From: report at bugs.python.org (Guido van Rossum) Date: Fri, 09 Nov 2007 00:23:01 -0000 Subject: [issue1393] function comparing lacks NotImplemented error Message-ID: <1194567781.3.0.213086975677.issue1393@psf.upfronthosting.co.za> Guido van Rossum added the comment: It's still odd though. Why does object() == Anything() pass control to the right hand side, while (lambda: None) == Anything() doesn't? There's no definition of equality in PyFunction_Type, so it would seem to fall back on the definition in PyBaseObject_Type, which I would expect to return False from the code in object_richcompare()... [...gdb...] OK, here's the solution of the mystery. do_richcompare() ends up taking the swapped code path for object() == Anything(), but not for function objects. This is because Anything() is a subclass of object, but not of . Perhaps the solution is to change object_richcompare() to return NotImplemented instead of returning False? Or perhaps even remove object_richcompare() altogether, since it doesn't do anything that do_richcompare() doesn't know how to do... __________________________________ Tracker __________________________________ From report at bugs.python.org Fri Nov 9 01:23:37 2007 From: report at bugs.python.org (Guido van Rossum) Date: Fri, 09 Nov 2007 00:23:37 -0000 Subject: [issue1377] test_import breaks on Linux Message-ID: <1194567817.67.0.00940107491798.issue1377@psf.upfronthosting.co.za> Guido van Rossum added the comment: I wouldn't close this until it's fixed. ---------- status: closed -> open __________________________________ Tracker __________________________________ From report at bugs.python.org Fri Nov 9 01:24:51 2007 From: report at bugs.python.org (Guido van Rossum) Date: Fri, 09 Nov 2007 00:24:51 -0000 Subject: [issue1144] parsermodule validation out of sync with Grammar Message-ID: <1194567891.88.0.381816905754.issue1144@psf.upfronthosting.co.za> Guido van Rossum added the comment: No, I didn't write the parser module (which isn't the parser, just a wrapper to make it accessible from Python). ---------- assignee: gvanrossum -> fdrake nosy: +fdrake __________________________________ Tracker __________________________________ From report at bugs.python.org Fri Nov 9 01:28:55 2007 From: report at bugs.python.org (Guido van Rossum) Date: Fri, 09 Nov 2007 00:28:55 -0000 Subject: [issue1351] Add getsize() to io instances Message-ID: <1194568135.43.0.933170128511.issue1351@psf.upfronthosting.co.za> Guido van Rossum added the comment: Sorry, I still don't like it. You'll have to come up with a darned good use case to justify this. __________________________________ Tracker __________________________________ From report at bugs.python.org Fri Nov 9 01:32:17 2007 From: report at bugs.python.org (Guido van Rossum) Date: Fri, 09 Nov 2007 00:32:17 -0000 Subject: [issue1720390] Remove backslash escapes from tokenize.c. Message-ID: <1194568337.48.0.564490237172.issue1720390@psf.upfronthosting.co.za> Guido van Rossum added the comment: FWIW, I'm +1 on the part of this patch that disables \u in raw strings. I just had a problem with a doctest that couldn't be run in verbose mode because \u was being interpreted in raw mode... But I'm still solidly -1 on allowing trailing \. _____________________________________ Tracker _____________________________________ From report at bugs.python.org Fri Nov 9 01:42:13 2007 From: report at bugs.python.org (Guido van Rossum) Date: Fri, 09 Nov 2007 00:42:13 -0000 Subject: [issue1395] py3k: duplicated line endings when using read(1) In-Reply-To: <1194548065.14.0.942752491397.issue1395@psf.upfronthosting.co.za> Message-ID: Guido van Rossum added the comment: > Considering that test_csv is failing on windows even without any changes > related to this issue, I looked at it and came up with this patch: > > ----------------- > Index: Lib/test/test_csv.py > =================================================================== > --- Lib/test/test_csv.py (revision 58914) > +++ Lib/test/test_csv.py (working copy) > @@ -375,7 +375,7 @@ > > class TestCsvBase(unittest.TestCase): > def readerAssertEqual(self, input, expected_result): > - with TemporaryFile("w+") as fileobj: > + with TemporaryFile("w+", newline='') as fileobj: > fileobj.write(input) > fileobj.seek(0) > reader = csv.reader(fileobj, dialect = self.dialect) > ----------------- > > Does this look ok? The tests pass on windows and Linux. Yes, especially since writerAssertEqual() already uses that. :-) I do think there is something iffy here -- the 2.x version of this test opens the files in binary mode. I wonder what end users are supposed to do. __________________________________ Tracker __________________________________ From report at bugs.python.org Fri Nov 9 02:29:56 2007 From: report at bugs.python.org (Christian Heimes) Date: Fri, 09 Nov 2007 01:29:56 -0000 Subject: [issue1157] test_urllib2net fails on test_ftp Message-ID: <1194571796.52.0.123246184192.issue1157@psf.upfronthosting.co.za> Christian Heimes added the comment: The test is passing for me on Ubuntu and Windows. ---------- keywords: +py3k nosy: +tiran resolution: -> works for me status: open -> closed __________________________________ Tracker __________________________________ From report at bugs.python.org Fri Nov 9 02:36:47 2007 From: report at bugs.python.org (Christian Heimes) Date: Fri, 09 Nov 2007 01:36:47 -0000 Subject: [issue1047] py3k: corrections for test_subprocess on windows Message-ID: <1194572207.53.0.611872582696.issue1047@psf.upfronthosting.co.za> Christian Heimes added the comment: The patch to _fileio was implemented in a different way and applied to the py3k branch a while ago. ---------- nosy: +tiran resolution: accepted -> fixed status: open -> closed __________________________________ Tracker __________________________________ From report at bugs.python.org Fri Nov 9 03:51:31 2007 From: report at bugs.python.org (J. Peterson) Date: Fri, 09 Nov 2007 02:51:31 -0000 Subject: [issue1410] BaseHTTPServer cannot accept Unicode data Message-ID: <1194576691.89.0.403010056791.issue1410@psf.upfronthosting.co.za> J. Peterson added the comment: The diagnostic printed is: File "C:\Apps\Python25\lib\socket.py", line 255, in write data = str(data) # XXX Should really reject non-string non-buffers The comment indicates the developer was aware of the bug. See also similar bug in writelines(), near line 267. __________________________________ Tracker __________________________________ From report at bugs.python.org Fri Nov 9 05:35:58 2007 From: report at bugs.python.org (Jeong-Min Lee) Date: Fri, 09 Nov 2007 04:35:58 -0000 Subject: [issue1411] A typo in tutorial Message-ID: <1194582958.24.0.143724736066.issue1411@psf.upfronthosting.co.za> New submission from Jeong-Min Lee: In the middle of "3.1.4 Lists", it reads as follow ----- >>> a [] The built-in function len() also applies to lists: >>> len(a) 8 ----- but it should be .. ----- >>> a [] The built-in function len() also applies to lists: >>> len(a) 0 ----- http://docs.python.org/tut/node5.html#SECTION005140000000000000000 ---------- components: Documentation messages: 57295 nosy: falsetru severity: urgent status: open title: A typo in tutorial versions: Python 2.5 __________________________________ Tracker __________________________________ From report at bugs.python.org Fri Nov 9 05:51:33 2007 From: report at bugs.python.org (Guido van Rossum) Date: Fri, 09 Nov 2007 04:51:33 -0000 Subject: [issue1409] new keyword-only function parameters interact badly with nested functions Message-ID: <1194583893.7.0.690034220868.issue1409@psf.upfronthosting.co.za> Guido van Rossum added the comment: I think I agree this is a bug. Who is setting all bugs to 'accepted'? ---------- nosy: +gvanrossum resolution: accepted -> __________________________________ Tracker __________________________________ From report at bugs.python.org Fri Nov 9 06:23:27 2007 From: report at bugs.python.org (Ronald Oussoren) Date: Fri, 09 Nov 2007 05:23:27 -0000 Subject: [issue1402] Interpreter cleanup: order of _PyGILState_Fini and PyInterpreterState_Clear Message-ID: <1194585807.04.0.300622536591.issue1402@psf.upfronthosting.co.za> Ronald Oussoren added the comment: I don't have a patch. I don't even know enough of the threading infrastructure to know if this really a bug or if it is a bug in my code. I'll work on a patch this weekend, if changing the order of calls to PyGILState_Fini and PyInterpreterState_Clear doesn't break unittests and fixes the problem I ran into I'll post about this issue on python-dev. __________________________________ Tracker __________________________________ From report at bugs.python.org Fri Nov 9 07:58:48 2007 From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=) Date: Fri, 09 Nov 2007 06:58:48 -0000 Subject: [issue1411] A typo in tutorial Message-ID: <1194591528.65.0.632801787087.issue1411@psf.upfronthosting.co.za> Changes by Martin v. L?wis: ---------- severity: urgent -> normal __________________________________ Tracker __________________________________ From report at bugs.python.org Fri Nov 9 08:54:34 2007 From: report at bugs.python.org (Peter Maxwell) Date: Fri, 09 Nov 2007 07:54:34 -0000 Subject: [issue1727780] 64/32-bit issue when unpickling random.Random Message-ID: <1194594874.75.0.3270150146.issue1727780@psf.upfronthosting.co.za> Peter Maxwell added the comment: For the record, and to prevent dilution of the count of times this bug has been encountered: this issue is a duplicate of issue1472695, which was later marked "won't fix" for no apparent reason. sligocki's patch is more thorough than mine was and I hope it has a better fate too. ---------- nosy: +pm67nz _____________________________________ Tracker _____________________________________ From report at bugs.python.org Fri Nov 9 14:15:42 2007 From: report at bugs.python.org (Georg Brandl) Date: Fri, 09 Nov 2007 13:15:42 -0000 Subject: [issue1411] A typo in tutorial Message-ID: <1194614142.17.0.823708364096.issue1411@psf.upfronthosting.co.za> Georg Brandl added the comment: Fixed in r58921. ---------- nosy: +georg.brandl resolution: -> fixed status: open -> closed __________________________________ Tracker __________________________________ From report at bugs.python.org Fri Nov 9 14:19:47 2007 From: report at bugs.python.org (Georg Brandl) Date: Fri, 09 Nov 2007 13:19:47 -0000 Subject: [issue1408] Inconsistence in multiply list Message-ID: <1194614387.05.0.822149561187.issue1408@psf.upfronthosting.co.za> Georg Brandl added the comment: I'm sorry, this is no bug. List multiplication works by referencing, there is no way to implement it differently in a straightforward way. Note that in >>> [a[:]] + [a[:]] the expression "a[:]" is evaluated twice, yielding two independent copies of a. In contrast, >>> [a[:]] * 2 evaluates "a[:]" only once, before the list multiplication is done. Because of the same reason, >>> [deepcopy(a)] * 2 doesn't work as you want. One way to do what you have in mind is >>> [a[:] for i in range(2)] which evaluates the "a[:]" once for each iteration of the list comprehension loop. ---------- nosy: +georg.brandl resolution: -> invalid status: open -> closed __________________________________ Tracker __________________________________ From report at bugs.python.org Fri Nov 9 14:30:50 2007 From: report at bugs.python.org (Denes Vadasz) Date: Fri, 09 Nov 2007 13:30:50 -0000 Subject: [issue1412] test_subprocess fails on SuSE 10 Message-ID: <1194615050.49.0.894512947633.issue1412@psf.upfronthosting.co.za> New submission from Denes Vadasz: I compiled Python 2.5.1 on SuSE 10 and ran "make test", which reported test_subprocess.py to fail on lines 537 and 579 with "permission denied". After a short investigation it looks the problem is that in SuSE 10 the shell (bash) rejects to execute scripts residing in the /tmp directory even if the file permissions would allow that. An easy way of fixing this could be to place the shell script statically in the same directory as test_subprocess.py instead of creating it on-the-fly in /tmp. ---------- components: Tests messages: 57301 nosy: dvadasz severity: normal status: open title: test_subprocess fails on SuSE 10 versions: Python 2.5 __________________________________ Tracker __________________________________ From report at bugs.python.org Fri Nov 9 14:50:39 2007 From: report at bugs.python.org (Christian Heimes) Date: Fri, 09 Nov 2007 13:50:39 -0000 Subject: [issue1409] new keyword-only function parameters interact badly with nested functions Message-ID: <1194616239.23.0.873565842179.issue1409@psf.upfronthosting.co.za> Christian Heimes added the comment: I set this bug to accepted because I was able to reproduce it yesterday. It's all in the history. Scroll down, pal! :) ---------- nosy: +tiran __________________________________ Tracker __________________________________ From report at bugs.python.org Fri Nov 9 15:22:27 2007 From: report at bugs.python.org (Georg Brandl) Date: Fri, 09 Nov 2007 14:22:27 -0000 Subject: [issue1409] new keyword-only function parameters interact badly with nested functions Message-ID: <1194618147.26.0.102445562438.issue1409@psf.upfronthosting.co.za> Georg Brandl added the comment: I think you misunderstood the meaning of "accepted" in our tracker - it may mean "I confirm that this is a bug" somewhere else, here it means "patch accepted". ---------- nosy: +georg.brandl __________________________________ Tracker __________________________________ From report at bugs.python.org Fri Nov 9 15:43:27 2007 From: report at bugs.python.org (=?utf-8?q?Michal_Bo=C5=BEo=C5=88?=) Date: Fri, 09 Nov 2007 14:43:27 -0000 Subject: [issue1413] int literal methods inaccessible Message-ID: <1194619407.27.0.40025808387.issue1413@psf.upfronthosting.co.za> New submission from Michal Bo?o?: It's impossible to call methods of int literals directly e.g. 1.__str__() (the same for oct literals). Even through it works for float, hex, literals, etc.. >>> 0x1.__str__() '1' >>> 1e0.__str__() '1.0' >>> 1..__str__() '1.0' >>> hasattr(1, '__str__') True >>> 1.__str__() File "", line 1 1.__str__() ^ SyntaxError: invalid syntax >>> 01.__str__() File "", line 1 01.__str__() ^ SyntaxError: invalid syntax ---------- messages: 57304 nosy: mykhal severity: normal status: open title: int literal methods inaccessible type: behavior versions: Python 2.5 __________________________________ Tracker __________________________________ From report at bugs.python.org Fri Nov 9 16:02:11 2007 From: report at bugs.python.org (Senthil) Date: Fri, 09 Nov 2007 15:02:11 -0000 Subject: [issue1401] urllib2 302 POST Message-ID: <1194620531.17.0.867245300088.issue1401@psf.upfronthosting.co.za> Senthil added the comment: Hello Andres, I think we are mixing up 2 or 3 things. Here are my comments. 1) urllib2 POST issue. - Discussion broke on this. No conclusion. 2) GET Request. >> If we create a GET request (handling 302 as 303) we should >> remove the content length header! I fail to find a reference for this statement in the RFC. Currently urllib2, gets the headers from the original request and passes the same headers to the redirected url. RFC mentions that we "should not change the headers". I quoted the section previously. 3) Handling 30* headers the same way. Yes, urllib2 handles them in the way stating most of the clients apparently handle it the same way. Most of us are okay with it. ("Practicality beats Purity"). But when we find that something can be improved, we just to add/extend the same. I am working on urilib (sandbox/trunk/urilib) which has some extensions like cached redirection for temporary redirections etc. And for this issue, we just have to find the supporting evidence for: >> If we create a GET request (handling 302 as 303) we should >> remove the content length header! If we don't find it,then it is not a bug. __________________________________ Tracker __________________________________ From report at bugs.python.org Fri Nov 9 16:10:07 2007 From: report at bugs.python.org (Andres Riancho) Date: Fri, 09 Nov 2007 15:10:07 -0000 Subject: [issue1401] urllib2 302 POST Message-ID: <1194621006.93.0.533198052732.issue1401@psf.upfronthosting.co.za> Andres Riancho added the comment: As I said in my original bug report, if you don't remove the content-length header or add the data, you are sending an invalid request: ====START Request===== GET http://f00/1.php HTTP/1.1 Content-length: 63 Accept-encoding: identity Accept: */* User-agent: w3af.sourceforge.net Host: f00 Content-type: application/x-www-form-urlencoded ==== END REQUEST === I opened this bug report because this is a bug, not because i'm a RFC purist. I I have time, I'll test the urllib2 patch I coded yesterday and submit it for revision. __________________________________ Tracker __________________________________ From report at bugs.python.org Fri Nov 9 16:11:03 2007 From: report at bugs.python.org (Christian Heimes) Date: Fri, 09 Nov 2007 15:11:03 -0000 Subject: [issue1409] new keyword-only function parameters interact badly with nested functions Message-ID: <1194621063.2.0.276432817176.issue1409@psf.upfronthosting.co.za> Christian Heimes added the comment: Oh, I misinterpreted the meaning of accepted. Can somebody please add a "confirmed" resolution? __________________________________ Tracker __________________________________ From report at bugs.python.org Fri Nov 9 16:15:08 2007 From: report at bugs.python.org (=?utf-8?q?Michal_Bo=C5=BEo=C5=88?=) Date: Fri, 09 Nov 2007 15:15:08 -0000 Subject: [issue1413] int literal methods inaccessible Message-ID: <1194621308.28.0.957817447103.issue1413@psf.upfronthosting.co.za> Michal Bo?o? added the comment: .. OK, now I see than (1).__str__() works.. however, could be the parser fixed to 1.__str__() work too ? __________________________________ Tracker __________________________________ From report at bugs.python.org Fri Nov 9 16:16:36 2007 From: report at bugs.python.org (Christian Heimes) Date: Fri, 09 Nov 2007 15:16:36 -0000 Subject: [issue1351] Add getsize() to io instances Message-ID: <1194621396.32.0.597796316657.issue1351@psf.upfronthosting.co.za> Christian Heimes added the comment: Does "it's convenient and I'm too lazy to address it in my code whenever the problem arises?" count as a darn good use case? No? Mh, I thought so :) __________________________________ Tracker __________________________________ From report at bugs.python.org Fri Nov 9 16:17:05 2007 From: report at bugs.python.org (Christian Heimes) Date: Fri, 09 Nov 2007 15:17:05 -0000 Subject: [issue1414] Fix for refleak tests Message-ID: <1194621425.79.0.958750228504.issue1414@psf.upfronthosting.co.za> Changes by Christian Heimes: ---------- assignee: gvanrossum keywords: patch, py3k nosy: gvanrossum, tiran priority: low severity: normal status: open title: Fix for refleak tests versions: Python 3.0 __________________________________ Tracker __________________________________ From report at bugs.python.org Fri Nov 9 16:18:06 2007 From: report at bugs.python.org (Christian Heimes) Date: Fri, 09 Nov 2007 15:18:06 -0000 Subject: [issue1414] Fix for refleak tests Message-ID: <1194621486.53.0.555770132546.issue1414@psf.upfronthosting.co.za> New submission from Christian Heimes: The patch prevents some tests from running multiple times in a test session. Added file: http://bugs.python.org/file8720/py3k_reftestfix.patch __________________________________ Tracker __________________________________ -------------- next part -------------- A non-text attachment was scrubbed... Name: py3k_reftestfix.patch Type: text/x-diff Size: 3510 bytes Desc: not available Url : http://mail.python.org/pipermail/python-bugs-list/attachments/20071109/fee9436f/attachment.patch From report at bugs.python.org Fri Nov 9 16:50:32 2007 From: report at bugs.python.org (Raghuram Devarakonda) Date: Fri, 09 Nov 2007 15:50:32 -0000 Subject: [issue1395] py3k: duplicated line endings when using read(1) In-Reply-To: Message-ID: <2c51ecee0711090750i1f29d000w3134172e7c685e60@mail.gmail.com> Raghuram Devarakonda added the comment: On 11/8/07, Guido van Rossum wrote: > I do think there is something iffy here -- the 2.x version of this > test opens the files in binary mode. I wonder what end users are > supposed to do. I think that requirement (need to open in binary mode) is no more present in 3.0. As per revision 56777 (#1767398), csv module seems to support unicode strings and as such I would expect that files *should not* be opened in binary mode (This requires doc change both in csv doc and "what's new in 3.0). The tests in test_csv are explicitly writing "\r\n" which seems to be a hangover from 2.x. We seem to have side-stepped the problem by passing "newline=''" at some places but the real fix may be changing "\r\n"s to "\n" now that the temp files are being opened in text mode. __________________________________ Tracker __________________________________ From report at bugs.python.org Fri Nov 9 16:57:34 2007 From: report at bugs.python.org (Christian Heimes) Date: Fri, 09 Nov 2007 15:57:34 -0000 Subject: [issue1410] BaseHTTPServer cannot accept Unicode data Message-ID: <1194623854.92.0.189430543334.issue1410@psf.upfronthosting.co.za> Christian Heimes added the comment: Due to its nature it is impossible to transmit unicode over the wire. Unicode must always be encoded to bytes before it can be stored on the hard disk or transmitted. Typically it's UTF-8 but in your case it depends on the client's browser and the Request header. The simple BaseHTTPServer isn't clever enough to encode your unicode data on the fly. You have to do it yourself. ---------- nosy: +tiran __________________________________ Tracker __________________________________ From report at bugs.python.org Fri Nov 9 17:25:51 2007 From: report at bugs.python.org (Georg Brandl) Date: Fri, 09 Nov 2007 16:25:51 -0000 Subject: [issue1409] new keyword-only function parameters interact badly with nested functions Message-ID: <1194625551.64.0.424544722771.issue1409@psf.upfronthosting.co.za> Georg Brandl added the comment: Please discuss that in the meta tracker (see the "report tracker problem" link in the sidebar). __________________________________ Tracker __________________________________ From report at bugs.python.org Fri Nov 9 18:04:15 2007 From: report at bugs.python.org (Christian Heimes) Date: Fri, 09 Nov 2007 17:04:15 -0000 Subject: [issue1409] new keyword-only function parameters interact badly with nested functions In-Reply-To: <1194625551.64.0.424544722771.issue1409@psf.upfronthosting.co.za> Message-ID: <4734930B.5090607@cheimes.de> Christian Heimes added the comment: > Please discuss that in the meta tracker (see the "report tracker > problem" link in the sidebar). Done http://psf.upfronthosting.co.za/roundup/meta/issue167 __________________________________ Tracker __________________________________ From report at bugs.python.org Fri Nov 9 19:44:35 2007 From: report at bugs.python.org (Guido van Rossum) Date: Fri, 09 Nov 2007 18:44:35 -0000 Subject: [issue1414] Fix for refleak tests In-Reply-To: <1194621486.53.0.555770132546.issue1414@psf.upfronthosting.co.za> Message-ID: Guido van Rossum added the comment: Hm, I was hoping more for patches to the C code that would make these initializations reentrant (e.g. by testing a flag in C that says "I'm already initialized"). __________________________________ Tracker __________________________________ From report at bugs.python.org Fri Nov 9 19:51:11 2007 From: report at bugs.python.org (Stefan Sonnenberg-Carstens) Date: Fri, 09 Nov 2007 18:51:11 -0000 Subject: [issue1405] Garbage collection not working correctly in Python 2.3 Message-ID: <1194634271.79.0.693106701409.issue1405@psf.upfronthosting.co.za> Stefan Sonnenberg-Carstens added the comment: No, I can't. As many Front Arena Developers on the 1.6/2.0/2.1/2.2 can't. Python 2.4 will be in Front Arena 4.0. Lightyears away from here. Same behaviour seen under Solaris 10 / Python 2.5.1 ---------- versions: +Python 2.5 __________________________________ Tracker __________________________________ From report at bugs.python.org Fri Nov 9 19:56:04 2007 From: report at bugs.python.org (Christian Heimes) Date: Fri, 09 Nov 2007 18:56:04 -0000 Subject: [issue1405] Garbage collection not working correctly in Python 2.3 Message-ID: <1194634564.29.0.39590989975.issue1405@psf.upfronthosting.co.za> Changes by Christian Heimes: ---------- resolution: out of date -> status: closed -> open __________________________________ Tracker __________________________________ From report at bugs.python.org Fri Nov 9 20:16:01 2007 From: report at bugs.python.org (Paul Pogonyshev) Date: Fri, 09 Nov 2007 19:16:01 -0000 Subject: [issue1405] Garbage collection not working correctly in Python 2.3 Message-ID: <1194635761.8.0.663883585688.issue1405@psf.upfronthosting.co.za> Paul Pogonyshev added the comment: See if gc.set_threshold (0, 0, 0) helps. ---------- nosy: +_doublep __________________________________ Tracker __________________________________ From report at bugs.python.org Fri Nov 9 20:23:21 2007 From: report at bugs.python.org (Guido van Rossum) Date: Fri, 09 Nov 2007 19:23:21 -0000 Subject: [issue1403] py_compile and compileall need unit tests Message-ID: <1194636201.38.0.825538712894.issue1403@psf.upfronthosting.co.za> Guido van Rossum added the comment: Why is it still open? ---------- nosy: +gvanrossum __________________________________ Tracker __________________________________ From report at bugs.python.org Fri Nov 9 20:29:22 2007 From: report at bugs.python.org (Guido van Rossum) Date: Fri, 09 Nov 2007 19:29:22 -0000 Subject: [issue1405] Garbage collection not working correctly in Python 2.3 Message-ID: <1194636562.36.0.58754832038.issue1405@psf.upfronthosting.co.za> Guido van Rossum added the comment: How do you know the memory isn't given back? It may be available for reallocation within Python, just not given back to the operating system. That's not necessarily a leak or a bug; that could just be heap fragmentation. There's nothing you can do about it. ---------- nosy: +gvanrossum __________________________________ Tracker __________________________________ From report at bugs.python.org Fri Nov 9 20:32:53 2007 From: report at bugs.python.org (Guido van Rossum) Date: Fri, 09 Nov 2007 19:32:53 -0000 Subject: [issue1407] [performance] Too many closed() checkings Message-ID: <1194636773.34.0.66303861149.issue1407@psf.upfronthosting.co.za> Guido van Rossum added the comment: To find out what really happens, use pdb to step through the example. This gives much better insight than adding a printf() call to PyObject_Call(). I've notice myself when stepping through I/O that there are a lot of checks for closed -- this may have to do with the stacking text -> buffer -> binary though. I've also noticed overridden isinstance checks in abc.py being called, which surprised me slightly. I haven't had time to look into this further though. ---------- nosy: +gvanrossum __________________________________ Tracker __________________________________ From report at bugs.python.org Fri Nov 9 20:34:30 2007 From: report at bugs.python.org (Guido van Rossum) Date: Fri, 09 Nov 2007 19:34:30 -0000 Subject: [issue1410] BaseHTTPServer cannot accept Unicode data Message-ID: <1194636870.69.0.284352493333.issue1410@psf.upfronthosting.co.za> Changes by Guido van Rossum: ---------- resolution: -> invalid status: open -> closed __________________________________ Tracker __________________________________ From report at bugs.python.org Fri Nov 9 20:45:21 2007 From: report at bugs.python.org (Christian Heimes) Date: Fri, 09 Nov 2007 19:45:21 -0000 Subject: [issue1414] Fix for refleak tests Message-ID: <1194637521.84.0.431684755763.issue1414@psf.upfronthosting.co.za> Christian Heimes added the comment: Here is a version of test_freeze that doesn't depend on stdout output on load. Added file: http://bugs.python.org/file8721/py3k_reftestfix2.patch __________________________________ Tracker __________________________________ -------------- next part -------------- A non-text attachment was scrubbed... Name: py3k_reftestfix2.patch Type: text/x-diff Size: 7029 bytes Desc: not available Url : http://mail.python.org/pipermail/python-bugs-list/attachments/20071109/26c6896d/attachment.patch From report at bugs.python.org Fri Nov 9 21:03:13 2007 From: report at bugs.python.org (Christian Heimes) Date: Fri, 09 Nov 2007 20:03:13 -0000 Subject: [issue1403] py_compile and compileall need unit tests Message-ID: <1194638592.99.0.913035012036.issue1403@psf.upfronthosting.co.za> Christian Heimes added the comment: I've left this bug open because no unit tests verifies that compileall can compile all files under Lib/. It has caused a problem with the Windows installer in 3.0a1 for some people. I like to add a compileall followed by a cleanup to make testall. I hope that's called before a release gets out. Index: Makefile.pre.in =================================================================== --- Makefile.pre.in (Revision 58923) +++ Makefile.pre.in (Arbeitskopie) @@ -610,7 +610,7 @@ TESTOPTS= -l $(EXTRATESTOPTS) TESTPROG= $(srcdir)/Lib/test/regrtest.py -TESTPYTHON= $(RUNSHARED) ./$(BUILDPYTHON) -E -tt +TESTPYTHON= $(RUNSHARED) ./$(BUILDPYTHON) -E -tt -bb test: all platform -find $(srcdir)/Lib -name '*.py[co]' -print | xargs rm -f -$(TESTPYTHON) $(TESTPROG) $(TESTOPTS) @@ -618,6 +618,8 @@ testall: all platform -find $(srcdir)/Lib -name '*.py[co]' -print | xargs rm -f + $(TESTPYTHON) Lib/compileall.py + -find $(srcdir)/Lib -name '*.py[co]' -print | xargs rm -f -$(TESTPYTHON) $(TESTPROG) $(TESTOPTS) -uall $(TESTPYTHON) $(TESTPROG) $(TESTOPTS) -uall Added file: http://bugs.python.org/file8722/makefile_compileall.patch __________________________________ Tracker __________________________________ -------------- next part -------------- A non-text attachment was scrubbed... Name: makefile_compileall.patch Type: text/x-diff Size: 785 bytes Desc: not available Url : http://mail.python.org/pipermail/python-bugs-list/attachments/20071109/adfef163/attachment.patch From report at bugs.python.org Fri Nov 9 21:12:01 2007 From: report at bugs.python.org (Christian Heimes) Date: Fri, 09 Nov 2007 20:12:01 -0000 Subject: [issue1413] int literal methods inaccessible Message-ID: <1194639121.37.0.956344921479.issue1413@psf.upfronthosting.co.za> Christian Heimes added the comment: It's a tricky problem because it's ambiguous: >>> 1.j What's going to happen here? Does it do getattr(1, 'j') or does it create the imaginary number 1j? ---------- nosy: +tiran __________________________________ Tracker __________________________________ From report at bugs.python.org Fri Nov 9 21:33:10 2007 From: report at bugs.python.org (=?utf-8?q?Michal_Bo=C5=BEo=C5=88?=) Date: Fri, 09 Nov 2007 20:33:10 -0000 Subject: [issue1413] int literal methods inaccessible Message-ID: <1194640390.16.0.239978675696.issue1413@psf.upfronthosting.co.za> Michal Bo?o? added the comment: I don't understand why 1.j is 1j .. because there's no int.j .. why then 1.L is not 1L ? __________________________________ Tracker __________________________________ From report at bugs.python.org Fri Nov 9 21:39:13 2007 From: report at bugs.python.org (=?utf-8?q?Michal_Bo=C5=BEo=C5=88?=) Date: Fri, 09 Nov 2007 20:39:13 -0000 Subject: [issue1413] int literal methods inaccessible Message-ID: <1194640753.89.0.51234048709.issue1413@psf.upfronthosting.co.za> Michal Bo?o? added the comment: .. however, fixing this is not necessary - because no one would probably use it, it's just a syntax inconsistency __________________________________ Tracker __________________________________ From report at bugs.python.org Fri Nov 9 21:41:41 2007 From: report at bugs.python.org (=?utf-8?q?Michal_Bo=C5=BEo=C5=88?=) Date: Fri, 09 Nov 2007 20:41:41 -0000 Subject: [issue1413] int literal methods inaccessible Message-ID: <1194640901.52.0.498144059861.issue1413@psf.upfronthosting.co.za> Michal Bo?o? added the comment: (finally now I get it.. I have forgotten that complex numbers can be float.. :) sorry ) __________________________________ Tracker __________________________________ From report at bugs.python.org Fri Nov 9 21:46:28 2007 From: report at bugs.python.org (Christian Heimes) Date: Fri, 09 Nov 2007 20:46:28 -0000 Subject: [issue1413] int literal methods inaccessible In-Reply-To: <1194640390.16.0.239978675696.issue1413@psf.upfronthosting.co.za> Message-ID: <4734C722.5010503@cheimes.de> Christian Heimes added the comment: > I don't understand why 1.j is 1j .. because there's no int.j .. why then > 1.L is not 1L ? Complex numbers from the number domain |C which supersets |R. Complex numbers are usually implemented and viewed as 2d vectors made from two floating numbers real and img. A long or long int however is from number domain |Z which doesn't allow fraction and hence no '.', too. It should explain why 1.L is illegal but 1.j is 1.0 * 1j. > .. however, fixing this is not necessary - because no one would > probably use it, it's just a syntax inconsistency I don't if it's possible to fix the problem with Python's parser. However the inconsistency should be documented. Is it explained in the docs and do the docs also mention the (1).__attr__ trick? I wasn't aware that it works. Christian __________________________________ Tracker __________________________________ From report at bugs.python.org Fri Nov 9 21:52:30 2007 From: report at bugs.python.org (=?utf-8?q?Michal_Bo=C5=BEo=C5=88?=) Date: Fri, 09 Nov 2007 20:52:30 -0000 Subject: [issue1413] int literal methods inaccessible Message-ID: <1194641550.33.0.819451979814.issue1413@psf.upfronthosting.co.za> Michal Bo?o? added the comment: I don't know it's in docs, it came into my mind, maybe logically (but later) to put 1 into parentheses __________________________________ Tracker __________________________________ From report at bugs.python.org Fri Nov 9 21:54:59 2007 From: report at bugs.python.org (=?utf-8?q?Michal_Bo=C5=BEo=C5=88?=) Date: Fri, 09 Nov 2007 20:54:59 -0000 Subject: [issue1413] int literal methods inaccessible Message-ID: <1194641699.41.0.127147161551.issue1413@psf.upfronthosting.co.za> Michal Bo?o? added the comment: .. I remember.. it came onto my mind when I tried also -1.__str__() and found out that the dot has higher priority than unary minus :) __________________________________ Tracker __________________________________ From report at bugs.python.org Fri Nov 9 22:03:23 2007 From: report at bugs.python.org (J. Peterson) Date: Fri, 09 Nov 2007 21:03:23 -0000 Subject: [issue1410] BaseHTTPServer cannot accept Unicode data Message-ID: <1194642203.27.0.348671161296.issue1410@psf.upfronthosting.co.za> J. Peterson added the comment: As implemented it's not even possible to send UTF-8, because the "data = str(data)" line only accepts seven bit ASCII with the default encoding. Since there's no easy way to change the encoding "str()" uses, some other mechanism should be available to do the encoding (as implied by the "XXX" comment). __________________________________ Tracker __________________________________ From report at bugs.python.org Fri Nov 9 22:08:46 2007 From: report at bugs.python.org (Christian Heimes) Date: Fri, 09 Nov 2007 21:08:46 -0000 Subject: [issue1410] BaseHTTPServer cannot accept Unicode data Message-ID: <1194642526.4.0.759233105293.issue1410@psf.upfronthosting.co.za> Christian Heimes added the comment: Yes, it's possible to send UTF-8 data: >>> data = u"testdata umlaut ???".encode("utf-8") >>> data 'testdata umlaut \xc3\xb6\xc3\xa4\xc3\xbc' >>> type(data) >>> data == str(data) True >>> data is str(data) True You have to encode your unicode string to a byte string. u''.encode(encoding) always returns a string. str() on a string doesn't alter a string. As you can clearly see it's a NOOP (no operation). __________________________________ Tracker __________________________________ From report at bugs.python.org Fri Nov 9 22:11:21 2007 From: report at bugs.python.org (Christian Heimes) Date: Fri, 09 Nov 2007 21:11:21 -0000 Subject: [issue1410] BaseHTTPServer cannot accept Unicode data Message-ID: <1194642681.2.0.0812556742987.issue1410@psf.upfronthosting.co.za> Christian Heimes added the comment: PS: http://www.joelonsoftware.com/articles/Unicode.html is a nice article about unicode and character sets. Joel is amazing when it comes to explaining complex problems in simple words. __________________________________ Tracker __________________________________ From report at bugs.python.org Fri Nov 9 22:20:05 2007 From: report at bugs.python.org (Christian Heimes) Date: Fri, 09 Nov 2007 21:20:05 -0000 Subject: [issue1234] semaphore errors on AIX 5.2 Message-ID: <1194643205.18.0.939784865641.issue1234@psf.upfronthosting.co.za> Christian Heimes added the comment: I'm setting the priority to high because it sounds important for AIX users and the patch is *really* simple, just two additional lines for configure.in ---------- keywords: +patch nosy: +tiran priority: -> high versions: +Python 2.5, Python 2.6, Python 3.0 __________________________________ Tracker __________________________________ From report at bugs.python.org Fri Nov 9 22:29:41 2007 From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=) Date: Fri, 09 Nov 2007 21:29:41 -0000 Subject: [issue1413] int literal methods inaccessible Message-ID: <1194643781.44.0.871889330021.issue1413@psf.upfronthosting.co.za> Martin v. L?wis added the comment: As now should be clear, there really is no bug here. Notice that you can also write 1 .__str__() ---------- nosy: +loewis resolution: -> invalid status: open -> closed __________________________________ Tracker __________________________________ From report at bugs.python.org Fri Nov 9 22:38:40 2007 From: report at bugs.python.org (=?utf-8?q?Michal_Bo=C5=BEo=C5=88?=) Date: Fri, 09 Nov 2007 21:38:40 -0000 Subject: [issue1413] int literal methods inaccessible Message-ID: <1194644320.32.0.786403577898.issue1413@psf.upfronthosting.co.za> Michal Bo?o? added the comment: interesting. I'm not sure I've read anywhere that it is allowed to place a whitespace between object and attributes. Thanks __________________________________ Tracker __________________________________ From report at bugs.python.org Fri Nov 9 22:40:49 2007 From: report at bugs.python.org (Christian Heimes) Date: Fri, 09 Nov 2007 21:40:49 -0000 Subject: [issue1378] fromfd() and dup() for _socket on WIndows Message-ID: <1194644449.88.0.460940028294.issue1378@psf.upfronthosting.co.za> Christian Heimes added the comment: I've created a clean patch and tested it. It works as promised, great work! Somebody with more Windows Fu than me should verify it before it's applied. ---------- nosy: +tiran Added file: http://bugs.python.org/file8723/trunk_socket_fromfd.patch __________________________________ Tracker __________________________________ -------------- next part -------------- A non-text attachment was scrubbed... Name: trunk_socket_fromfd.patch Type: text/x-diff Size: 4048 bytes Desc: not available Url : http://mail.python.org/pipermail/python-bugs-list/attachments/20071109/a88935d2/attachment.patch From report at bugs.python.org Fri Nov 9 22:46:30 2007 From: report at bugs.python.org (Christian Heimes) Date: Fri, 09 Nov 2007 21:46:30 -0000 Subject: [issue1631171] implement warnings module in C Message-ID: <1194644790.28.0.683990874595.issue1631171@psf.upfronthosting.co.za> Changes by Christian Heimes: ---------- nosy: +tiran _____________________________________ Tracker _____________________________________ From report at bugs.python.org Fri Nov 9 23:02:49 2007 From: report at bugs.python.org (Christian Heimes) Date: Fri, 09 Nov 2007 22:02:49 -0000 Subject: [issue718532] inspect, class instances and __getattr__ Message-ID: <1194645769.57.0.82470638083.issue718532@psf.upfronthosting.co.za> Changes by Christian Heimes: ---------- versions: +Python 2.5, Python 2.6, Python 3.0 ____________________________________ Tracker ____________________________________ From report at bugs.python.org Fri Nov 9 23:08:52 2007 From: report at bugs.python.org (Christian Heimes) Date: Fri, 09 Nov 2007 22:08:52 -0000 Subject: [issue1704621] interpreter crash when multiplying large lists Message-ID: <1194646132.7.0.719140098367.issue1704621@psf.upfronthosting.co.za> Christian Heimes added the comment: Python 2.5 still seg faults. Python 2.6 and 3.0 are raising a memory error. However I'm unsure if the memory error is also raised in a plain build. I've just Py_DEBUG builds of 2.6 and 3.0 around. ---------- nosy: +tiran versions: +Python 2.5, Python 2.6, Python 3.0 _____________________________________ Tracker _____________________________________ From report at bugs.python.org Fri Nov 9 23:14:34 2007 From: report at bugs.python.org (Christian Heimes) Date: Fri, 09 Nov 2007 22:14:34 -0000 Subject: [issue815646] thread unsafe file objects cause crash Message-ID: <1194646474.95.0.983763332778.issue815646@psf.upfronthosting.co.za> Christian Heimes added the comment: I'm still able to reproduce the bug in Python 2.5 (svn) and 2.6 (trunk). import thread f=open("tmp1", "w") def worker(): global f while 1: f.close() f=open("tmp1", "w") f.seek(0,0) thread.start_new_thread(worker, ()) thread.start_new_thread(worker, ()) Unhandled exception in thread started by Traceback (most recent call last): *** glibc detected *** ./python: malloc(): memory corruption: 0xb7efc008 *** ======= Backtrace: ========= /lib/tls/i686/cmov/libc.so.6[0xb7dbe636] /lib/tls/i686/cmov/libc.so.6(__libc_malloc+0x90)[0xb7dbffc0] /lib/tls/i686/cmov/libc.so.6[0xb7dad03f] /lib/tls/i686/cmov/libc.so.6(fopen64+0x2c)[0xb7daf61c] ./python(PyTraceBack_Print+0x1a4)[0x80ef0f4] ./python(PyErr_Display+0x76)[0x80e73a6] ./python[0x80ed80d] ./python(PyObject_Call+0x27)[0x805c927] ./python(PyEval_CallObjectWithKeywords+0x6c)[0x80c151c] ./python(PyErr_PrintEx+0xbe)[0x80e7e9e] ./python[0x80f37b1] /lib/tls/i686/cmov/libpthread.so.0[0xb7ed146b] /lib/tls/i686/cmov/libc.so.6(clone+0x5e)[0xb7e276de] ======= Memory map: ======== 08048000-0813d000 r-xp 00000000 fe:01 10586072 /home/heimes/dev/python/release25-maint/python 0813d000-08162000 rw-p 000f4000 fe:01 10586072 /home/heimes/dev/python/release25-maint/python 08162000-081fe000 rw-p 08162000 00:00 0 [heap] b6a00000-b6a21000 rw-p b6a00000 00:00 0 b6a21000-b6b00000 ---p b6a21000 00:00 0 b6bc1000-b6bc2000 ---p b6bc1000 00:00 0 b6bc2000-b73c2000 rw-p b6bc2000 00:00 0 b73c2000-b73c3000 ---p b73c2000 00:00 0 b73c3000-b7bc3000 rw-p b73c3000 00:00 0 b7bc3000-b7bff000 r-xp 00000000 08:05 325941 /lib/libncurses.so.5.6 b7bff000-b7c07000 rw-p 0003b000 08:05 325941 /lib/libncurses.so.5.6 b7c07000-b7c4e000 r-xp 00000000 08:05 325837 /lib/libncursesw.so.5.6 b7c4e000-b7c56000 rw-p 00046000 08:05 325837 /lib/libncursesw.so.5.6 b7c56000-b7c82000 r-xp 00000000 08:05 325955 /lib/libreadline.so.5.2 b7c82000-b7c86000 rw-p 0002c000 08:05 325955 /lib/libreadline.so.5.2 b7c86000-b7c87000 rw-p b7c86000 00:00 0 b7c87000-b7c8a000 r-xp 00000000 fe:01 10716611 /home/heimes/dev/python/release25-maint/build/lib.linux-i686-2.5/readline.so b7c8a000-b7c8b000 rw-p 00003000 fe:01 10716611 /home/heimes/dev/python/release25-maint/build/lib.linux-i686-2.5/readline.so b7c8b000-b7c92000 r--s 00000000 08:05 557857 /usr/lib/gconv/gconv-modules.cache b7c92000-b7cd1000 r--p 00000000 08:05 570306 /usr/lib/locale/de_DE.utf8/LC_CTYPE b7cd1000-b7d54000 rw-p b7cd1000 00:00 0 b7d54000-b7e98000 r-xp 00000000 08:05 326311 /lib/tls/i686/cmov/libc-2.6.1.so b7e98000-b7e99000 r--p 00143000 08:05 326311 /lib/tls/i686/cmov/libc-2.6.1.so b7e99000-b7e9b000 rw-p 00144000 08:05 326311 /lib/tls/i686/cmov/libc-2.6.1.so b7e9b000-b7e9e000 rw-p b7e9b000 00:00 0 b7e9e000-b7ec1000 r-xp 00000000 08:05 326315 /lib/tls/i686/cmov/libm-2.6.1.so b7ec1000-b7ec3000 rw-p 00023000 08:05 326315 /lib/tls/i686/cmov/libm-2.6.1.so b7ec3000-b7ec5000 r-xp 00000000 08:05 326330 /lib/tls/i686/cmov/libutil-2.6.1.so b7ec5000-b7ec7000 rw-p 00001000 08:05 326330 /lib/tls/i686/cmov/libutil-2.6.1.so b7ec7000-b7ec8000 rw-p b7ec7000 00:00 0 b7ec8000-b7eca000 r-xp 00000000 08:05 326314 /lib/tls/i686/cmov/libdl-2.6.1.so b7eca000-b7ecc000 rw-p 00001000 08:05 326314 /lib/tls/i686/cmov/libdl-2.6.1.so b7ecc000-b7ee0000 r-xp 00000000 08:05 326325 /lib/tls/i686/cmov/libpthread-2.6.1.so b7ee0000-b7ee2000 rw-p 00013000 08:05 326325 /lib/tls/i686/cmov/libpthread-2.6.1.so b7ee2000-b7ee4000 rw-p b7ee2000 00:00 0 b7ef1000-b7efb000 r-xp 00000000 08:05 325908 /lib/libgcc_s.so.1 b7efb000-b7efc000 rw-p 0000a000 08:05 325908 /lib/libgcc_s.so.1 b7efc000-b7f01000 rw-p b7efc000 00:00 0 b7f01000-b7f1b000 r-xp 00000000 08:05 326530 /lib/ld-2.6.1.so b7f1b000-b7f1d000 rw-p 00019000 08:05 326530 /lib/ld-2.6.1.so bfcd2000-bfcee000 rw-p bfcd2000 00:00 0 [stack] ffffe000-fffff000 r-xp 00000000 00:00 0 [vdso] However Python 3.0 doesn't crash: Unhandled exception in thread started by Traceback (most recent call last): File "", line 6, in worker File "/home/heimes/dev/python/py3k/Lib/io.py", line 1234, in seek self.buffer.seek(pos) File "/home/heimes/dev/python/py3k/Lib/io.py", line 877, in seek return self.raw.seek(pos, whence) IOError: [Errno 9] Bad file descriptor ---------- nosy: +tiran versions: +Python 2.5, Python 2.6 ____________________________________ Tracker ____________________________________ From report at bugs.python.org Fri Nov 9 23:24:51 2007 From: report at bugs.python.org (Christian Heimes) Date: Fri, 09 Nov 2007 22:24:51 -0000 Subject: [issue1678380] 0.0 and -0.0 identified, with surprising results Message-ID: <1194647091.55.0.366432041792.issue1678380@psf.upfronthosting.co.za> Christian Heimes added the comment: It's fixed in 2.6 but still broken in 2.5. ---------- nosy: +tiran versions: +Python 2.5 _____________________________________ Tracker _____________________________________ From report at bugs.python.org Sat Nov 10 00:28:37 2007 From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=) Date: Fri, 09 Nov 2007 23:28:37 -0000 Subject: [issue1413] int literal methods inaccessible Message-ID: <1194650917.78.0.187678121236.issue1413@psf.upfronthosting.co.za> Martin v. L?wis added the comment: See http://www.python.org/doc/2.5/ref/whitespace.html which says that you can put spaces between arbitrary tokens, and http://www.python.org/doc/2.5/ref/attribute-references.html which says that all of primary, ".", and identifier are separate tokens in an attributeref (not so in a literal, where the . is part of the floating point literal). __________________________________ Tracker __________________________________ From report at bugs.python.org Sat Nov 10 00:55:07 2007 From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=) Date: Fri, 09 Nov 2007 23:55:07 -0000 Subject: [issue1351] Add getsize() to io instances Message-ID: <1194652506.78.0.350440383145.issue1351@psf.upfronthosting.co.za> Martin v. L?wis added the comment: Ok, I'm rejecting it now based on the YAGNI argument Guido brought up, and based on my own concerns. ---------- resolution: -> rejected status: open -> closed __________________________________ Tracker __________________________________ From report at bugs.python.org Sat Nov 10 01:00:27 2007 From: report at bugs.python.org (Christian Heimes) Date: Sat, 10 Nov 2007 00:00:27 -0000 Subject: [issue1415] py3k: pythonw.exe fails to run Message-ID: <1194652827.19.0.0139976447149.issue1415@psf.upfronthosting.co.za> New submission from Christian Heimes: pythonw.exe fails to run with a runtime error. python.exe works as expected. While the bug itself isn't serious it should either be fixed or pythonw.exe be omitted from the next alpha release. ---------- components: Windows keywords: py3k messages: 57342 nosy: tiran priority: high severity: major status: open title: py3k: pythonw.exe fails to run type: crash versions: Python 3.0 __________________________________ Tracker __________________________________ From report at bugs.python.org Sat Nov 10 01:13:27 2007 From: report at bugs.python.org (Christian Heimes) Date: Sat, 10 Nov 2007 00:13:27 -0000 Subject: [issue1415] py3k: pythonw.exe fails to run Message-ID: <1194653607.05.0.428646411995.issue1415@psf.upfronthosting.co.za> Christian Heimes added the comment: Update: pythonw fails because the standard streams can't be initialized. fileno(stdin), fileno(stdout) and fileno(stderr) are returning -2. __________________________________ Tracker __________________________________ From report at bugs.python.org Sat Nov 10 02:20:32 2007 From: report at bugs.python.org (Christian Heimes) Date: Sat, 10 Nov 2007 01:20:32 -0000 Subject: [issue1415] py3k: pythonw.exe fails to run Message-ID: <1194657632.39.0.509274279222.issue1415@psf.upfronthosting.co.za> Christian Heimes added the comment: Python 2.6 (svn trunk) doesn't check the file handlers when it creates sys.stdin, stdout and stderr. write() operations to stdout and stderr don't fail although the data is written into nowhere land. stdin.read() fails with IOError: [Errno 9] Bad file descriptor. How should I address the problem in py3k? __________________________________ Tracker __________________________________ From report at bugs.python.org Sat Nov 10 06:58:10 2007 From: report at bugs.python.org (Guido van Rossum) Date: Sat, 10 Nov 2007 05:58:10 -0000 Subject: [issue1416] @prop.setter decorators Message-ID: <1194674290.8.0.853140061818.issue1416@psf.upfronthosting.co.za> New submission from Guido van Rossum: Here's an implementation of the idea I floated recently on python-dev (Subject: Declaring setters with getters). This implements the kind of syntax that I believe won over most folks in the end: @property def foo(self): ... @foo.setter def foo(self, value=None): ... There are also .getter and .deleter descriptors. This includes the hack that if you specify a setter but no deleter, the setter is called without a value argument when attempting to delete something. If the setter isn't ready for this, a TypeError will be raised, pretty much just as if no deleter was provided (just with a somewhat worse error message :-). I intend to check this into 2.6 and 3.0 unless there is a huge cry of dismay. Docs will be left to volunteers as always. ---------- assignee: gvanrossum files: propset.diff keywords: patch messages: 57345 nosy: gvanrossum priority: normal severity: normal status: open title: @prop.setter decorators versions: Python 2.6, Python 3.0 Added file: http://bugs.python.org/file8724/propset.diff __________________________________ Tracker __________________________________ -------------- next part -------------- A non-text attachment was scrubbed... Name: propset.diff Type: text/x-patch Size: 3094 bytes Desc: not available Url : http://mail.python.org/pipermail/python-bugs-list/attachments/20071110/39147308/attachment-0001.bin From report at bugs.python.org Sat Nov 10 12:12:16 2007 From: report at bugs.python.org (Michael Forbes) Date: Sat, 10 Nov 2007 11:12:16 -0000 Subject: [issue1689617] Intel icc build fails with optimizations -O2 Message-ID: <1194693136.21.0.71567080437.issue1689617@psf.upfronthosting.co.za> Michael Forbes added the comment: This appears to have been a bug with the intel compilers. With the latest version 10.1 20070913 everything seems to work. _____________________________________ Tracker _____________________________________ From report at bugs.python.org Sat Nov 10 12:21:44 2007 From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=) Date: Sat, 10 Nov 2007 11:21:44 -0000 Subject: [issue1689617] Intel icc build fails with optimizations -O2 Message-ID: <1194693704.37.0.460634338411.issue1689617@psf.upfronthosting.co.za> Martin v. L?wis added the comment: Ok. Closing it as third-party. ---------- resolution: -> invalid status: open -> closed versions: +3rd party -Python 2.5 _____________________________________ Tracker _____________________________________ From report at bugs.python.org Sat Nov 10 13:20:52 2007 From: report at bugs.python.org (MHOOO) Date: Sat, 10 Nov 2007 12:20:52 -0000 Subject: [issue1417] Weakref not working properly Message-ID: <1194697252.02.0.163162643165.issue1417@psf.upfronthosting.co.za> New submission from MHOOO: The following code is not working as expected: import weakref class cls1: def giveTo( self, to ): to.take( self.bla ) def bla(self ): pass class cls2: def take( self, what ): self.ref = weakref.ref(what) c1 = cls1() c2 = cls2() c1.giveTo( c2 ) print c1.bla print c2.ref It prints out: > Why is the weakref pointing to a dead object, when it's still alive? ---------- components: Library (Lib) files: test2.py messages: 57348 nosy: MHOOO severity: major status: open title: Weakref not working properly type: behavior versions: Python 2.5 Added file: http://bugs.python.org/file8725/test2.py __________________________________ Tracker __________________________________ -------------- next part -------------- A non-text attachment was scrubbed... Name: test2.py Type: text/x-python Size: 252 bytes Desc: not available Url : http://mail.python.org/pipermail/python-bugs-list/attachments/20071110/b0785c7f/attachment.py From report at bugs.python.org Sat Nov 10 15:44:46 2007 From: report at bugs.python.org (Christian Heimes) Date: Sat, 10 Nov 2007 14:44:46 -0000 Subject: [issue1415] py3k: pythonw.exe fails because std streams a missing Message-ID: <1194705886.17.0.746002796652.issue1415@psf.upfronthosting.co.za> Christian Heimes added the comment: Congratulations Amaury and welcome on board! :) I like to get your opinion on the problem. So far I've figured out that Windows doesn't create the std streams for Windows WinMain() programs. As first step towards the solution I like to separate the close check from the fd. Currently Module/_fileio.c:file_close() sets the fd to a negative value and open fails immediately with a negative fd. I want to add a closed flag to the struct and move the fd < 0 check to the read and write operations. That's going to fix stdin and stdout for non console based programs on Windows. For stderr I've to think about a better solution to avoid an infinite loop (stderr.write() -> exception -> stderr.write() ...). Maybe I could add some more methods to the dumb writer to make it more file like and use it? ---------- nosy: +amaury.forgeotdarc title: py3k: pythonw.exe fails to run -> py3k: pythonw.exe fails because std streams a missing __________________________________ Tracker __________________________________ From report at bugs.python.org Sat Nov 10 16:07:51 2007 From: report at bugs.python.org (Mark Dickinson) Date: Sat, 10 Nov 2007 15:07:51 -0000 Subject: [issue1418] Python/hypot.c is never used Message-ID: <1194707271.84.0.598290243888.issue1418@psf.upfronthosting.co.za> New submission from Mark Dickinson: With the current ./configure setup, it looks to me as though there are no circumstances under which the file Python/hypot.c is compliled. There's a line AC_REPLACE_FUNCS(hypot) in configure.in; which is supposed (if I understand correctly) to check for a system hypot(), and use the replacement file hypot.c if the system hypot() isn't found; but the mechanism for using the replacement file seems not to work: I tried the following: (1) replace all occurrences of hypot with myhypot in configure.in, pyport.h, complexobject.c, mathmodule.c and cmathmodule.c. (2) move Python/hypot.c to Python/myhypot.c, and rename the function contained within from hypot to myhypot (3) rerun autoconf and autoheader (4) ./configure && make The result: as expected, during configuration I got: checking for myhypot... no but building failed with: ar cr libpython2.6.a Objects/abstract.o Objects/boolobject.o Objects/ bufferobject.o Objects/cellobject.o Objects/classobject.o Objects/ cobject.o Objects/codeobject.o Objects/complexobject.o Objects/ descrobject.o Objects/enumobject.o Objects/exceptions.o Objects/ genobject.o Objects/fileobject.o Objects/floatobject.o Objects/ frameobject.o Objects/funcobject.o Objects/intobject.o Objects/ iterobject.o Objects/listobject.o Objects/longobject.o Objects/ dictobject.o Objects/methodobject.o Objects/moduleobject.o Objects/ object.o Objects/obmalloc.o Objects/rangeobject.o Objects/setobject.o Objects/sliceobject.o Objects/stringobject.o Objects/structseq.o Objects/tupleobject.o Objects/typeobject.o Objects/weakrefobject.o Objects/unicodeobject.o Objects/unicodectype.o ar cr libpython2.6.a Python/Python-ast.o Python/asdl.o Python/ast.o Python/bltinmodule.o Python/ceval.o Python/compile.o Python/codecs.o Python/errors.o Python/frozen.o Python/frozenmain.o Python/future.o Python/getargs.o Python/getcompiler.o Python/getcopyright.o Python/ getmtime.o Python/getplatform.o Python/getversion.o Python/graminit.o Python/import.o Python/importdl.o Python/marshal.o Python/modsupport.o Python/mystrtoul.o Python/mysnprintf.o Python/peephole.o Python/ pyarena.o Python/pyfpe.o Python/pystate.o Python/pythonrun.o Python/ structmember.o Python/symtable.o Python/sysmodule.o Python/traceback.o Python/getopt.o Python/pystrtod.o Python/dynload_shlib.o Python/ mactoolboxglue.o Python/thread.o ar cr libpython2.6.a Modules/config.o Modules/getpath.o Modules/main.o Modules/gcmodule.o ar cr libpython2.6.a Modules/threadmodule.o Modules/signalmodule.o Modules/posixmodule.o Modules/errnomodule.o Modules/pwdmodule.o Modules/_sre.o Modules/_codecsmodule.o Modules/zipimport.o Modules/ symtablemodule.o Modules/xxsubtype.o ranlib libpython2.6.a gcc -L/opt/local/lib -u _PyMac_Error -o python.exe \ Modules/python.o \ libpython2.6.a -ldl /usr/bin/ld: Undefined symbols: _myhypot (I'd like to know how to fix this: I've been working on fixing some of the numerical problems in the cmath module, and hoped to imitate the hypot setup for the functions log1p, asinh and copysign.) ---------- components: Build messages: 57350 nosy: marketdickinson severity: minor status: open title: Python/hypot.c is never used versions: Python 2.5, Python 2.6 __________________________________ Tracker __________________________________ From report at bugs.python.org Sat Nov 10 16:34:38 2007 From: report at bugs.python.org (Paul Pogonyshev) Date: Sat, 10 Nov 2007 15:34:38 -0000 Subject: [issue1405] Garbage collection not working correctly in Python 2.3 Message-ID: <1194708878.57.0.124593281108.issue1405@psf.upfronthosting.co.za> Paul Pogonyshev added the comment: Looks like the memory _is_ freed. As Guido said, "It may be available for reallocation within Python, just not given back to the operating system". I suggest closing this as invalid. paul at gonzo:~$ python Python 2.3.5 (#2, Oct 16 2006, 19:19:48) [GCC 3.3.5 (Debian 1:3.3.5-13)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> import gc >>> len ([object for object in gc.get_objects () if isinstance (object, list)]) 25 >>> aList = [] >>> for i in xrange(5E5): ... aList += [[]] ... for j in xrange(10): ... aList[-1].append([] ... ... KeyboardInterrupt >>> aList[-1].append([] KeyboardInterrupt >>> paul at gonzo:~/emacs$ python Python 2.3.5 (#2, Oct 16 2006, 19:19:48) [GCC 3.3.5 (Debian 1:3.3.5-13)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> import gc >>> len ([object for object in gc.get_objects () if isinstance (object, list)]) 25 >>> aList = [] >>> for i in xrange(5E5): ... aList += [[]] ... for j in xrange(10): ... aList[-1].append([]) ... __main__:1: DeprecationWarning: integer argument expected, got float >>> del aList >>> len ([object for object in gc.get_objects () if isinstance (object, list)]) 25 __________________________________ Tracker __________________________________ From report at bugs.python.org Sat Nov 10 16:35:38 2007 From: report at bugs.python.org (Paul Pogonyshev) Date: Sat, 10 Nov 2007 15:35:38 -0000 Subject: [issue1405] Garbage collection not working correctly in Python 2.3 Message-ID: <1194708938.68.0.368985222326.issue1405@psf.upfronthosting.co.za> Paul Pogonyshev added the comment: Meh, copied too much. Disregard first part, second shows it. __________________________________ Tracker __________________________________ From report at bugs.python.org Sat Nov 10 16:43:15 2007 From: report at bugs.python.org (Paul Pogonyshev) Date: Sat, 10 Nov 2007 15:43:15 -0000 Subject: [issue1417] Weakref not working properly Message-ID: <1194709395.33.0.64021854482.issue1417@psf.upfronthosting.co.za> Paul Pogonyshev added the comment: Because self.bla is a bound-method object, which is created and then instantly deleted as unreferenced. This is not a bug, it is expected. >>> class X: ... def foo (self): pass ... >>> x = X () >>> x.foo is x.foo False Note how the objects are different. ---------- nosy: +_doublep __________________________________ Tracker __________________________________ From report at bugs.python.org Sat Nov 10 16:45:40 2007 From: report at bugs.python.org (Paul Pogonyshev) Date: Sat, 10 Nov 2007 15:45:40 -0000 Subject: [issue1416] @prop.setter decorators Message-ID: <1194709540.64.0.902416848975.issue1416@psf.upfronthosting.co.za> Paul Pogonyshev added the comment: Looks great (regardless of how this is implemented). I always hated this def get_foo / def set_foo / foo = property (get_foo, set_foo). ---------- nosy: +_doublep __________________________________ Tracker __________________________________ From report at bugs.python.org Sat Nov 10 18:44:34 2007 From: report at bugs.python.org (Georg Brandl) Date: Sat, 10 Nov 2007 17:44:34 -0000 Subject: [issue1417] Weakref not working properly Message-ID: <1194716674.37.0.637453777226.issue1417@psf.upfronthosting.co.za> Georg Brandl added the comment: Closing as invalid. ---------- nosy: +georg.brandl resolution: -> invalid status: open -> closed __________________________________ Tracker __________________________________ From report at bugs.python.org Sat Nov 10 18:59:13 2007 From: report at bugs.python.org (Georg Brandl) Date: Sat, 10 Nov 2007 17:59:13 -0000 Subject: [issue1418] Python/hypot.c is never used Message-ID: <1194717553.17.0.245384272567.issue1418@psf.upfronthosting.co.za> Changes by Georg Brandl: ---------- assignee: -> loewis nosy: +loewis __________________________________ Tracker __________________________________ From report at bugs.python.org Sat Nov 10 19:23:40 2007 From: report at bugs.python.org (Guido van Rossum) Date: Sat, 10 Nov 2007 18:23:40 -0000 Subject: [issue1405] Garbage collection not working correctly in Python 2.3 Message-ID: <1194719020.75.0.817424819301.issue1405@psf.upfronthosting.co.za> Changes by Guido van Rossum: ---------- resolution: -> invalid status: open -> closed __________________________________ Tracker __________________________________ From report at bugs.python.org Sat Nov 10 19:29:04 2007 From: report at bugs.python.org (Guido van Rossum) Date: Sat, 10 Nov 2007 18:29:04 -0000 Subject: [issue1416] @prop.setter decorators Message-ID: <1194719343.79.0.346583143887.issue1416@psf.upfronthosting.co.za> Guido van Rossum added the comment: propset2.diff is a new version that improves upon the heuristic for making the deleter match the setter: when changing setters, if the old deleter is the same as the old setter, it will replace both the deleter and setter. This diff is relative to the 2.6 trunk; it applies to 3.0 too. Added file: http://bugs.python.org/file8726/propset2.diff __________________________________ Tracker __________________________________ -------------- next part -------------- A non-text attachment was scrubbed... Name: propset2.diff Type: text/x-patch Size: 4490 bytes Desc: not available Url : http://mail.python.org/pipermail/python-bugs-list/attachments/20071110/3a15cba5/attachment.bin From report at bugs.python.org Sat Nov 10 20:05:16 2007 From: report at bugs.python.org (Mark Dickinson) Date: Sat, 10 Nov 2007 19:05:16 -0000 Subject: [issue1418] Python/hypot.c is never used Message-ID: <1194721516.86.0.564276253389.issue1418@psf.upfronthosting.co.za> Mark Dickinson added the comment: hypot.patch contains a possible fix, together with a fix for the includes in hypot.c itself. (As it was, compilation of hypot.c would fail due to ssize_t being referenced before definition, in pyport.h.) Added file: http://bugs.python.org/file8727/hypot.patch __________________________________ Tracker __________________________________ -------------- next part -------------- A non-text attachment was scrubbed... Name: hypot.patch Type: application/octet-stream Size: 817 bytes Desc: not available Url : http://mail.python.org/pipermail/python-bugs-list/attachments/20071110/a44eb1dc/attachment.obj From report at bugs.python.org Sat Nov 10 22:16:57 2007 From: report at bugs.python.org (Guido van Rossum) Date: Sat, 10 Nov 2007 21:16:57 -0000 Subject: [issue1416] @prop.setter decorators Message-ID: <1194729417.28.0.553534669396.issue1416@psf.upfronthosting.co.za> Guido van Rossum added the comment: propset3.diff removes the hack that makes the deleter equal to the setter when no separate deleter has been specified. If you want a single method to be used as setter and deleter, write this: @foo.setter @foo.deleter def foo(self, value=None): ... Added file: http://bugs.python.org/file8728/propset3.diff __________________________________ Tracker __________________________________ -------------- next part -------------- A non-text attachment was scrubbed... Name: propset3.diff Type: text/x-patch Size: 3578 bytes Desc: not available Url : http://mail.python.org/pipermail/python-bugs-list/attachments/20071110/3d306ba9/attachment.bin From report at bugs.python.org Sat Nov 10 22:32:40 2007 From: report at bugs.python.org (Christian Heimes) Date: Sat, 10 Nov 2007 21:32:40 -0000 Subject: [issue1416] @prop.setter decorators Message-ID: <1194730360.05.0.177321631043.issue1416@psf.upfronthosting.co.za> Christian Heimes added the comment: Fixed a typo: +PyDoc_STRVAR(getter_doc, + "Descriptor to change the setter on a property."); ^^^ ---------- nosy: +tiran Added file: http://bugs.python.org/file8729/propset4.diff __________________________________ Tracker __________________________________ -------------- next part -------------- A non-text attachment was scrubbed... Name: propset4.diff Type: text/x-diff Size: 3578 bytes Desc: not available Url : http://mail.python.org/pipermail/python-bugs-list/attachments/20071110/9e334ed3/attachment.diff From report at bugs.python.org Sat Nov 10 23:05:24 2007 From: report at bugs.python.org (Christian Heimes) Date: Sat, 10 Nov 2007 22:05:24 -0000 Subject: [issue1412] test_subprocess fails on SuSE 10 Message-ID: <1194732324.39.0.938900236177.issue1412@psf.upfronthosting.co.za> Christian Heimes added the comment: Please try this: $ mkdir -p ~/tmp $ TMP=~/tmp make test ---------- nosy: +tiran __________________________________ Tracker __________________________________ From report at bugs.python.org Sat Nov 10 23:13:02 2007 From: report at bugs.python.org (Guido van Rossum) Date: Sat, 10 Nov 2007 22:13:02 -0000 Subject: [issue1416] @prop.setter decorators Message-ID: <1194732782.88.0.668258222945.issue1416@psf.upfronthosting.co.za> Guido van Rossum added the comment: Checked into trunk as revision 58929. ---------- resolution: -> accepted status: open -> closed __________________________________ Tracker __________________________________ From report at bugs.python.org Sat Nov 10 23:38:39 2007 From: report at bugs.python.org (Raymond Hettinger) Date: Sat, 10 Nov 2007 22:38:39 -0000 Subject: [issue1417] Weakref not working properly Message-ID: <1194734319.63.0.170336128314.issue1417@psf.upfronthosting.co.za> Raymond Hettinger added the comment: It's easier to see what is going on if you print the object ids. The id of self.bla is different than the subsequent c1.bla. The first is freed before the second gets created. ---------- nosy: +rhettinger __________________________________ Tracker __________________________________ From report at bugs.python.org Sun Nov 11 01:10:46 2007 From: report at bugs.python.org (Christian Heimes) Date: Sun, 11 Nov 2007 00:10:46 -0000 Subject: [issue1415] py3k: pythonw.exe fails because std streams a missing Message-ID: <1194739846.43.0.370235748888.issue1415@psf.upfronthosting.co.za> Christian Heimes added the comment: PATCH: * remove the analogy fd < 0 -> file is closed from _fileio.FileIO * added new flag closed to _fileio.FileIO * renamed closefd to close_fd to distinguish it from closed * make it impossible to instantiate another stdprinter * added repr and fileno methods to stdprinter Guido: Are you fine with the changes? The patch doesn't fix the problem (yet) but it's the first step towards a solution. ---------- nosy: +gvanrossum Added file: http://bugs.python.org/file8730/py3k_fileio_closed.patch __________________________________ Tracker __________________________________ -------------- next part -------------- A non-text attachment was scrubbed... Name: py3k_fileio_closed.patch Type: text/x-diff Size: 9510 bytes Desc: not available Url : http://mail.python.org/pipermail/python-bugs-list/attachments/20071111/b106c083/attachment.patch From report at bugs.python.org Sun Nov 11 03:31:59 2007 From: report at bugs.python.org (Viktor Ferenczi) Date: Sun, 11 Nov 2007 02:31:59 -0000 Subject: [issue1419] ssl module version 1.10 causes TypeError when accepting connection Message-ID: <1194748319.4.0.022602913069.issue1419@psf.upfronthosting.co.za> New submission from Viktor Ferenczi: The SSLSocket.accept() method passes arguments to SSLSocket's constructor in wrong order which causes TypeError later in the constructor. Proposed patch to ssl.__init__.py: @@ -257,7 +257,7 @@ SSL channel, and the address of the remote client.""" newsock, addr = socket.accept(self) - return (SSLSocket(newsock, True, self.keyfile, self.certfile, + return (SSLSocket(newsock, self.keyfile, self.certfile, True, self.cert_reqs, self.ssl_version, self.ca_certs, self.do_handshake_on_connect), addr) ---------- components: Library (Lib) messages: 57364 nosy: complex severity: critical status: open title: ssl module version 1.10 causes TypeError when accepting connection type: crash versions: Python 2.6 __________________________________ Tracker __________________________________ From report at bugs.python.org Sun Nov 11 03:55:35 2007 From: report at bugs.python.org (Christian Heimes) Date: Sun, 11 Nov 2007 02:55:35 -0000 Subject: [issue1415] py3k: pythonw.exe fails because std streams a missing Message-ID: <1194749735.18.0.752284510402.issue1415@psf.upfronthosting.co.za> Christian Heimes added the comment: The new patch fixes the startup problem with pythonw.exe on Windows. I still wonder if print(sometest) is raising an exception when stdout is not available. Added file: http://bugs.python.org/file8731/py3k_fileio_fixes.patch __________________________________ Tracker __________________________________ -------------- next part -------------- A non-text attachment was scrubbed... Name: py3k_fileio_fixes.patch Type: text/x-diff Size: 14759 bytes Desc: not available Url : http://mail.python.org/pipermail/python-bugs-list/attachments/20071111/d78b4727/attachment-0001.patch From report at bugs.python.org Sun Nov 11 15:32:56 2007 From: report at bugs.python.org (Ron Adam) Date: Sun, 11 Nov 2007 14:32:56 -0000 Subject: [issue1420] Unicode literals in tokenize.py and tests. Message-ID: <1194791576.59.0.681140086087.issue1420@psf.upfronthosting.co.za> New submission from Ron Adam: Replaced Unicode literals in tokenize.py and it's tests files with byte literals. Added a compile step to the test to make sure the text file used in the test are valid python code. This will catch changes that need to be done in to the text (gold file) for future python versions. ---------- components: Library (Lib) files: tokenize_patch.diff messages: 57366 nosy: ron_adam severity: normal status: open title: Unicode literals in tokenize.py and tests. versions: Python 3.0 Added file: http://bugs.python.org/file8732/tokenize_patch.diff __________________________________ Tracker __________________________________ -------------- next part -------------- A non-text attachment was scrubbed... Name: tokenize_patch.diff Type: text/x-patch Size: 7723 bytes Desc: not available Url : http://mail.python.org/pipermail/python-bugs-list/attachments/20071111/5c07bd3f/attachment.bin From report at bugs.python.org Sun Nov 11 15:37:08 2007 From: report at bugs.python.org (Christian Heimes) Date: Sun, 11 Nov 2007 14:37:08 -0000 Subject: [issue1421] python.org: outdated and false information Message-ID: <1194791828.05.0.091960180389.issue1421@psf.upfronthosting.co.za> New submission from Christian Heimes: Short of a bug tracker for errors on python.org I'm using this bug tracker to support some problems. http://www.python.org/dev/process/ "Documenting Python" still mentions LaTeX as the system for documentation of Python. http://www.python.org/dev/implementations/ "Python for .NET" is either describing a totally different project or the author of the chapter didn't understand the design goals of Python for .NET written by Brian Lloyd. It's a bridge between CPython and .NET/Mono that allows developers to use CPython code and C extensions in .NET or .NET assemblies in CPython. Compiling Python code to CLR / IL byte code is not the intention of the project. The project homepage is wrong (http://pythonnet.sourceforge.net/) and the project is still maintained. I myself has fixed several bugs this summer and ported it to Python 2.5, Python 2.6, UCS-4 builds of Python and Mono. ---------- components: Documentation messages: 57367 nosy: tiran priority: high severity: normal status: open title: python.org: outdated and false information __________________________________ Tracker __________________________________ From report at bugs.python.org Sun Nov 11 16:09:51 2007 From: report at bugs.python.org (Christian Heimes) Date: Sun, 11 Nov 2007 15:09:51 -0000 Subject: [issue1395] py3k: duplicated line endings when using read(1) Message-ID: <1194793791.03.0.357230980322.issue1395@psf.upfronthosting.co.za> Christian Heimes added the comment: By the way I've found the daily builds you were asking for, Raghuram. http://www.python.org/dev/daily-msi/ :) __________________________________ Tracker __________________________________ From report at bugs.python.org Sun Nov 11 16:18:26 2007 From: report at bugs.python.org (Georg Brandl) Date: Sun, 11 Nov 2007 15:18:26 -0000 Subject: [issue1421] python.org: outdated and false information Message-ID: <1194794306.01.0.562879759513.issue1421@psf.upfronthosting.co.za> Georg Brandl added the comment: Fixed in revisions 11114 and 11115 of the pydotorg repository. ---------- nosy: +georg.brandl resolution: -> fixed status: open -> closed __________________________________ Tracker __________________________________ From report at bugs.python.org Sun Nov 11 16:38:17 2007 From: report at bugs.python.org (Georg Brandl) Date: Sun, 11 Nov 2007 15:38:17 -0000 Subject: [issue1420] Unicode literals in tokenize.py and tests. Message-ID: <1194795497.76.0.744061682582.issue1420@psf.upfronthosting.co.za> Georg Brandl added the comment: I don't think you can have raw bytes (rb"..." etc.) literals. ---------- nosy: +georg.brandl __________________________________ Tracker __________________________________ From report at bugs.python.org Sun Nov 11 16:38:24 2007 From: report at bugs.python.org (Georg Brandl) Date: Sun, 11 Nov 2007 15:38:24 -0000 Subject: [issue1419] ssl module version 1.10 causes TypeError when accepting connection Message-ID: <1194795504.94.0.819335098084.issue1419@psf.upfronthosting.co.za> Changes by Georg Brandl: ---------- assignee: -> janssen nosy: +janssen __________________________________ Tracker __________________________________ From report at bugs.python.org Sun Nov 11 17:19:17 2007 From: report at bugs.python.org (Christian Heimes) Date: Sun, 11 Nov 2007 16:19:17 -0000 Subject: [issue1420] Unicode literals in tokenize.py and tests. Message-ID: <1194797957.9.0.631876193022.issue1420@psf.upfronthosting.co.za> Christian Heimes added the comment: Yes, raw byte strings are possible: >>> br"\x" b'\\x' ---------- keywords: +patch, py3k nosy: +tiran priority: -> normal __________________________________ Tracker __________________________________ From report at bugs.python.org Sun Nov 11 18:26:36 2007 From: report at bugs.python.org (Christian Heimes) Date: Sun, 11 Nov 2007 17:26:36 -0000 Subject: [issue1422] Writing to an invalid fd doesn't raise an exception Message-ID: <1194801996.44.0.296899248876.issue1422@psf.upfronthosting.co.za> New submission from Christian Heimes: The bug is related to http://bugs.python.org/issue1415 and occurs only with the latest patch from #1415. Writing to an invalid fd doesn't raise an exception: >>> f = open(100, 'w') >>> f.fileno() 100 >>> f.write("test") 4 However reading or opening an invalid fd for reading and writing raises an exception. >>> f = open(100, 'r') >>> f.read() Traceback (most recent call last): File "", line 1, in File "/home/heimes/dev/python/py3k/Lib/io.py", line 1253, in read res += decoder.decode(self.buffer.read(), True) File "/home/heimes/dev/python/py3k/Lib/io.py", line 756, in read current = self.raw.read(to_read) IOError: [Errno 9] Bad file descriptor >>> f = open(100, 'w+') Traceback (most recent call last): File "", line 1, in File "/home/heimes/dev/python/py3k/Lib/io.py", line 195, in __new__ return open(*args, **kwargs) File "/home/heimes/dev/python/py3k/Lib/io.py", line 169, in open buffer = BufferedRandom(raw, buffering) File "/home/heimes/dev/python/py3k/Lib/io.py", line 948, in __init__ raw._checkSeekable() File "/home/heimes/dev/python/py3k/Lib/io.py", line 301, in _checkSeekable if msg is None else msg) IOError: File or stream is not seekable. I expected that fileio_write() raises an exception when fd is invalid: n = write(self->fd, ptr, n); if (n < 0) { if (errno == EAGAIN) Py_RETURN_NONE; PyErr_SetFromErrno(PyExc_IOError); return NULL; } ---------- assignee: tiran components: Interpreter Core keywords: py3k messages: 57372 nosy: tiran priority: normal severity: normal status: open title: Writing to an invalid fd doesn't raise an exception type: behavior versions: Python 3.0 __________________________________ Tracker __________________________________ From report at bugs.python.org Sun Nov 11 18:37:58 2007 From: report at bugs.python.org (Guido van Rossum) Date: Sun, 11 Nov 2007 17:37:58 -0000 Subject: [issue1415] py3k: pythonw.exe fails because std streams a missing In-Reply-To: <1194749735.18.0.752284510402.issue1415@psf.upfronthosting.co.za> Message-ID: Guido van Rossum added the comment: Hmm... In internal_close() there's still a test for self->fd >= 0. I'm not sure if this is an oversight or intentional. Also, I don't understand under what circumstances fds < 0 can occur. I presume this is only on Windows. Can you point me to docs for this fact? __________________________________ Tracker __________________________________ From report at bugs.python.org Sun Nov 11 18:48:43 2007 From: report at bugs.python.org (Christian Heimes) Date: Sun, 11 Nov 2007 17:48:43 -0000 Subject: [issue1415] py3k: pythonw.exe fails because std streams a missing In-Reply-To: Message-ID: <47374074.7020901@cheimes.de> Christian Heimes added the comment: Guido van Rossum wrote: > Hmm... In internal_close() there's still a test for self->fd >= 0. I'm > not sure if this is an oversight or intentional. I'll check it later. The patch still contains some debugging code that redirects stdout and stderr to a file when PY_STDERR_FILE is defined. > Also, I don't understand under what circumstances fds < 0 can occur. I > presume this is only on Windows. Can you point me to docs for this > fact? It happens when a script is run with pythonw.exe (pyw extension). PythonW.exe isn't a console application but a GUI app which doesn't create a console window. However GUI apps don't have valid standard streams because stdin, stdout and stderr aren't connected. Here are some links that shed some light on the problem: http://mail.python.org/pipermail/python-dev/2001-January/011423.html http://www.halcyon.com/~ast/dload/guicon.htm http://msdn2.microsoft.com/en-us/library/3x292kth(VS.80).aspx The patch creates another problem: http://bugs.python.org/issue1422 Christian __________________________________ Tracker __________________________________ From report at bugs.python.org Sun Nov 11 20:18:18 2007 From: report at bugs.python.org (MHOOO) Date: Sun, 11 Nov 2007 19:18:18 -0000 Subject: [issue1417] Weakref not working properly Message-ID: <1194808698.88.0.404776029552.issue1417@psf.upfronthosting.co.za> MHOOO added the comment: Well, too bad. My workaround (to make weakrefs work) is attached as a file. Added file: http://bugs.python.org/file8733/myhacks.py __________________________________ Tracker __________________________________ -------------- next part -------------- A non-text attachment was scrubbed... Name: myhacks.py Type: text/x-python Size: 2165 bytes Desc: not available Url : http://mail.python.org/pipermail/python-bugs-list/attachments/20071111/fb11f941/attachment.py From report at bugs.python.org Sun Nov 11 20:49:58 2007 From: report at bugs.python.org (Christian Heimes) Date: Sun, 11 Nov 2007 19:49:58 -0000 Subject: [issue1422] Writing to an invalid fd doesn't raise an exception Message-ID: <1194810598.65.0.0259751927953.issue1422@psf.upfronthosting.co.za> Christian Heimes added the comment: Python 2.5 and probably 2.6 suffer from the same problem although it's harder to trigger it. Python 2.5.1 (r251:54863, Oct 5 2007, 13:36:32) [GCC 4.1.3 20070929 (prerelease) (Ubuntu 4.1.2-16ubuntu2)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> import os >>> f = open("/tmp/test", 'w') >>> f.fileno() 3 >>> os.close(f.fileno()) >>> f.write("test") >>> f.write("test") >>> close failed: [Errno 9] Bad file descriptor $ ls -la /tmp/test -rw-r----- 1 heimes heimes 0 2007-11-11 20:46 /tmp/test ---------- versions: +Python 2.5, Python 2.6 __________________________________ Tracker __________________________________ From report at bugs.python.org Sun Nov 11 21:15:28 2007 From: report at bugs.python.org (jeroen) Date: Sun, 11 Nov 2007 20:15:28 -0000 Subject: [issue1423] wave sunau aifc 16bit errors Message-ID: <1194812128.3.0.121145701122.issue1423@psf.upfronthosting.co.za> New submission from jeroen: When you write sound files wav sunau of aifc and you are using 16 bits samples. The number of frames in the files is incorrect. close function which updates the headers makes a mistake I assume. For the sunau type I had to double the number of frames in the close function to make it correct. If you do not correctg number of frames a 10 second file will play 5 seconds ---------- components: Library (Lib) messages: 57377 nosy: jeroen severity: normal status: open title: wave sunau aifc 16bit errors versions: Python 2.5 __________________________________ Tracker __________________________________ From report at bugs.python.org Sun Nov 11 21:54:45 2007 From: report at bugs.python.org (Christian Heimes) Date: Sun, 11 Nov 2007 20:54:45 -0000 Subject: [issue1424] py3k: readline and rlcompleter doesn't list choices Message-ID: <1194814485.68.0.898592111972.issue1424@psf.upfronthosting.co.za> New submission from Christian Heimes: Python 2.5: >>> import readline; import rlcompleter; readline.parse_and_bind("tab: complete") >>> import sys >>> sys.std sys.stderr sys.stdin sys.stdout Python 3.0: >>> import readline; import rlcompleter; readline.parse_and_bind("tab: complete") >>> import sys >>> import sys.std # nothing ---------- components: Extension Modules, Library (Lib) keywords: py3k messages: 57378 nosy: tiran priority: low severity: normal status: open title: py3k: readline and rlcompleter doesn't list choices versions: Python 3.0 __________________________________ Tracker __________________________________ From report at bugs.python.org Sun Nov 11 21:55:23 2007 From: report at bugs.python.org (Bill Janssen) Date: Sun, 11 Nov 2007 20:55:23 -0000 Subject: [issue1419] ssl module version 1.10 causes TypeError when accepting connection Message-ID: <1194814523.76.0.417345894346.issue1419@psf.upfronthosting.co.za> Bill Janssen added the comment: Good catch. I found this in the 3K branch, but hadn't backported it to the SSL PyPI module yet. ---------- resolution: -> accepted __________________________________ Tracker __________________________________ From report at bugs.python.org Sun Nov 11 22:30:00 2007 From: report at bugs.python.org (Bill Janssen) Date: Sun, 11 Nov 2007 21:30:00 -0000 Subject: [issue1419] ssl module version 1.10 causes TypeError when accepting connection Message-ID: <1194816600.76.0.172357431637.issue1419@psf.upfronthosting.co.za> Bill Janssen added the comment: I've uploaded a fixed ssl-1.12 to PyPI. ---------- resolution: accepted -> fixed status: open -> closed __________________________________ Tracker __________________________________ From report at bugs.python.org Sun Nov 11 23:36:43 2007 From: report at bugs.python.org (Christian Heimes) Date: Sun, 11 Nov 2007 22:36:43 -0000 Subject: [issue1425] readline: no display matches hook set Message-ID: <1194820603.07.0.458448795039.issue1425@psf.upfronthosting.co.za> New submission from Christian Heimes: In Python 2.6 and 3.0 the readline module has changed. A new hook to set a display matches was introduced but no default method is set thus rendering rlcompleter partly useless. ---------- components: Extension Modules, Library (Lib) keywords: py3k messages: 57381 nosy: tiran severity: normal status: open title: readline: no display matches hook set versions: Python 2.6, Python 3.0 __________________________________ Tracker __________________________________ From report at bugs.python.org Sun Nov 11 23:39:43 2007 From: report at bugs.python.org (Christian Heimes) Date: Sun, 11 Nov 2007 22:39:43 -0000 Subject: [issue1425] readline: no display matches hook set Message-ID: <1194820783.54.0.738332093483.issue1425@psf.upfronthosting.co.za> Christian Heimes added the comment: http://bugs.python.org/issue1388440 http://bugs.python.org/issue1424 ---------- assignee: -> loewis nosy: +loewis priority: -> normal superseder: -> py3k: readline and rlcompleter doesn't list choices __________________________________ Tracker __________________________________ From report at bugs.python.org Sun Nov 11 23:44:08 2007 From: report at bugs.python.org (Christian Heimes) Date: Sun, 11 Nov 2007 22:44:08 -0000 Subject: [issue1426] readline module needs a review Message-ID: <1194821048.12.0.233733442191.issue1426@psf.upfronthosting.co.za> New submission from Christian Heimes: The readline module needs a review and cleanup. Several functions don't do enough error checks and the indention is partly borked with mixes of tab and 2 space indention. ---------- keywords: py3k messages: 57383 nosy: tiran priority: high severity: normal status: open title: readline module needs a review versions: Python 2.6, Python 3.0 __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Nov 12 00:16:40 2007 From: report at bugs.python.org (Damjan Georgievski) Date: Sun, 11 Nov 2007 23:16:40 -0000 Subject: [issue1427] Error in standard module calendar Message-ID: <1194823000.48.0.0016595238228.issue1427@psf.upfronthosting.co.za> New submission from Damjan Georgievski: This is LocaleTextCalendar.__init__ def __init__(self, firstweekday=0, locale=None): TextCalendar.__init__(self, firstweekday) if locale is None: locale = locale.getdefaultlocale() self.locale = locale Which can not work, obviosly ... let me hilight the important part if locale is None: locale = locale.getdefaultlocale() ??? Attached is a patch that corrects this and keeps the signature of the method with the locale=None keyword. ---------- components: Extension Modules files: calendar.diff messages: 57384 nosy: gdamjan severity: normal status: open title: Error in standard module calendar type: behavior versions: Python 2.5 Added file: http://bugs.python.org/file8734/calendar.diff __________________________________ Tracker __________________________________ -------------- next part -------------- A non-text attachment was scrubbed... Name: calendar.diff Type: application/octet-stream Size: 620 bytes Desc: not available Url : http://mail.python.org/pipermail/python-bugs-list/attachments/20071111/9b337ed1/attachment.obj From report at bugs.python.org Mon Nov 12 00:23:43 2007 From: report at bugs.python.org (Christian Heimes) Date: Sun, 11 Nov 2007 23:23:43 -0000 Subject: [issue1428] Update to property.__doc__ Message-ID: <1194823423.41.0.514895809101.issue1428@psf.upfronthosting.co.za> New submission from Christian Heimes: The patch adds the new syntax to the doc string of property: Decorators makes defining new or modifying existing properties easy: class C(object): @property def x(self): return self.__x @x.setter def x(self, value): self.__x = value @x.deleter def x(self): del self.__x ---------- assignee: gvanrossum components: Interpreter Core files: property_docstring.patch keywords: patch messages: 57385 nosy: gvanrossum, tiran priority: low severity: normal status: open title: Update to property.__doc__ type: rfe versions: Python 2.6, Python 3.0 Added file: http://bugs.python.org/file8735/property_docstring.patch __________________________________ Tracker __________________________________ -------------- next part -------------- A non-text attachment was scrubbed... Name: property_docstring.patch Type: text/x-diff Size: 826 bytes Desc: not available Url : http://mail.python.org/pipermail/python-bugs-list/attachments/20071111/a0dc3d21/attachment.patch From report at bugs.python.org Mon Nov 12 00:48:11 2007 From: report at bugs.python.org (Christian Heimes) Date: Sun, 11 Nov 2007 23:48:11 -0000 Subject: [issue1427] Error in standard module calendar Message-ID: <1194824891.31.0.266239633827.issue1427@psf.upfronthosting.co.za> Christian Heimes added the comment: My patch uses "import locale as _locale" to avoid ambiguous variables. It also fixes some additional bugs. I still don't understand how prweek() should work. self.week is missing. ---------- keywords: +patch nosy: +tiran priority: -> normal versions: +Python 2.6, Python 3.0 Added file: http://bugs.python.org/file8736/calendar.diff __________________________________ Tracker __________________________________ -------------- next part -------------- A non-text attachment was scrubbed... Name: calendar.diff Type: text/x-diff Size: 620 bytes Desc: not available Url : http://mail.python.org/pipermail/python-bugs-list/attachments/20071111/c0c24fec/attachment.diff From report at bugs.python.org Mon Nov 12 00:48:28 2007 From: report at bugs.python.org (Christian Heimes) Date: Sun, 11 Nov 2007 23:48:28 -0000 Subject: [issue1427] Error in standard module calendar Message-ID: <1194824908.95.0.629646901914.issue1427@psf.upfronthosting.co.za> Changes by Christian Heimes: Removed file: http://bugs.python.org/file8736/calendar.diff __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Nov 12 00:48:44 2007 From: report at bugs.python.org (Christian Heimes) Date: Sun, 11 Nov 2007 23:48:44 -0000 Subject: [issue1427] Error in standard module calendar Message-ID: <1194824924.66.0.871916903678.issue1427@psf.upfronthosting.co.za> Christian Heimes added the comment: wrong file Added file: http://bugs.python.org/file8737/calendar_fix.patch __________________________________ Tracker __________________________________ -------------- next part -------------- A non-text attachment was scrubbed... Name: calendar_fix.patch Type: text/x-diff Size: 2414 bytes Desc: not available Url : http://mail.python.org/pipermail/python-bugs-list/attachments/20071111/34705305/attachment.patch From report at bugs.python.org Mon Nov 12 02:09:50 2007 From: report at bugs.python.org (Guido van Rossum) Date: Mon, 12 Nov 2007 01:09:50 -0000 Subject: [issue1428] Update to property.__doc__ In-Reply-To: <1194823423.41.0.514895809101.issue1428@psf.upfronthosting.co.za> Message-ID: Guido van Rossum added the comment: I would use _x instead of __x. Otherwise looks good. __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Nov 12 02:16:06 2007 From: report at bugs.python.org (Christian Heimes) Date: Mon, 12 Nov 2007 01:16:06 -0000 Subject: [issue1428] Update to property.__doc__ Message-ID: <1194830166.72.0.944728481687.issue1428@psf.upfronthosting.co.za> Christian Heimes added the comment: Applied in r58935 (trunk) ---------- resolution: -> fixed status: open -> closed __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Nov 12 02:28:24 2007 From: report at bugs.python.org (Christian Heimes) Date: Mon, 12 Nov 2007 01:28:24 -0000 Subject: [issue1427] Error in standard module calendar Message-ID: <1194830904.22.0.433042971971.issue1427@psf.upfronthosting.co.za> Christian Heimes added the comment: I've applied my patch in r58936 (trunk) and r58937 (2.5 branch). I'm assigning the bug to Walter. Maybe he is able to shed some light on the prweek() issue. $ svn ann Lib/calendar.py | grep self\.week 43483 walter.doerwald print self.week(theweek, width), ---------- assignee: -> doerwalter nosy: +doerwalter __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Nov 12 05:54:00 2007 From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=) Date: Mon, 12 Nov 2007 04:54:00 -0000 Subject: [issue1425] readline: no display matches hook set Message-ID: <1194843240.88.0.711300187922.issue1425@psf.upfronthosting.co.za> Martin v. L?wis added the comment: Thanks for the report. This is now fixed in r58940. ---------- resolution: -> fixed status: open -> closed __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Nov 12 06:05:52 2007 From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=) Date: Mon, 12 Nov 2007 05:05:52 -0000 Subject: [issue1420] Unicode literals in tokenize.py and tests. Message-ID: <1194843952.06.0.817143157306.issue1420@psf.upfronthosting.co.za> Martin v. L?wis added the comment: I think this patch is wrong. Python source code is inherently text, so generate_tokens should decode the input, rather than operating on bytes. ---------- nosy: +loewis __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Nov 12 06:14:26 2007 From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=) Date: Mon, 12 Nov 2007 05:14:26 -0000 Subject: [issue1418] Python/hypot.c is never used Message-ID: <1194844466.82.0.964988086778.issue1418@psf.upfronthosting.co.za> Martin v. L?wis added the comment: Thanks for the patch. Committed as r58941. ---------- resolution: -> accepted status: open -> closed __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Nov 12 11:05:17 2007 From: report at bugs.python.org (=?utf-8?q?Walter_D=C3=B6rwald?=) Date: Mon, 12 Nov 2007 10:05:17 -0000 Subject: [issue1427] Error in standard module calendar Message-ID: <1194861917.83.0.350911956843.issue1427@psf.upfronthosting.co.za> Walter D?rwald added the comment: Fixed in r58942 (trunk) and r58943 (2.5). Closing the issue. ---------- resolution: -> fixed status: open -> closed __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Nov 12 12:28:16 2007 From: report at bugs.python.org (Denes Vadasz) Date: Mon, 12 Nov 2007 11:28:16 -0000 Subject: [issue1412] test_subprocess fails on SuSE 10 In-Reply-To: <1194732324.39.0.938900236177.issue1412@psf.upfronthosting.co.za> Message-ID: Denes Vadasz added the comment: When I say: $ mkdir -p ~/tmp $ TMP=3D~/tmp python Lib/tests/test=5Fsubprocess.py the test is passed. However with $ TMP=3D~/tmp make test the test still fails and the ~/tmp directory is removed during the test run. Regards Denes Vadasz Christian Heimes To dvadasz at amadeus.net cc bcc Subject [issue1412] test_subprocess fails on SuSE 10 Christian Heimes Please respond to : Tracker 10/11/2007 23:05 Christian Heimes added the comment: Please try this: $ mkdir -p ~/tmp $ TMP=~/tmp make test ---------- nosy: +tiran __________________________________ Tracker __________________________________ IMPORTANT - CONFIDENTIALITY NOTICE - This e-mail is intended only for the use of the individual or entity shown above as addressees . It may contain information which is privileged, confidential or otherwise protected from disclosure under applicable laws . If the reader of this transmission is not the intended recipient, you are hereby notified that any dissemination, printing, distribution, copying, disclosure or the taking of any action in reliance on the contents of this information is strictly prohibited. If you have received this transmission in error, please immediately notify us by reply e-mail or using the address below and delete the message and any attachments from your system . Amadeus Data Processing GmbH Gesch?ftsf?hrer: Eberhard Haag Sitz der Gesellschaft: Erding HR M?nchen 48 199 Berghamer Strasse 6 85435 Erding Germany Added file: http://bugs.python.org/file8738/unnamed __________________________________ Tracker __________________________________ -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: unnamed Url: http://mail.python.org/pipermail/python-bugs-list/attachments/20071112/1cb57378/attachment.txt From report at bugs.python.org Mon Nov 12 13:27:34 2007 From: report at bugs.python.org (Luke-Jr) Date: Mon, 12 Nov 2007 12:27:34 -0000 Subject: [issue1429] FD leak in SocketServer Message-ID: <1194870454.07.0.621713310435.issue1429@psf.upfronthosting.co.za> New submission from Luke-Jr: SocketServer.ThreadingUnixStreamServer leaks file descriptors when a request handler throws an exception. ---------- components: Library (Lib) messages: 57396 nosy: luke-jr severity: normal status: open title: FD leak in SocketServer versions: Python 2.4 __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Nov 12 14:09:46 2007 From: report at bugs.python.org (Amaury Forgeot d'Arc) Date: Mon, 12 Nov 2007 13:09:46 -0000 Subject: [issue1415] py3k: pythonw.exe fails because std streams a missing Message-ID: <1194872986.3.0.777072862993.issue1415@psf.upfronthosting.co.za> Amaury Forgeot d'Arc added the comment: I made some checks with the vc2005 (msvcr80) runtime library: - fd==-2 corresponds to the _NO_CONSOLE_FILENO constant. A comment in the CRT code says: /* * For stdin, stdout & stderr, we use _NO_CONSOLE_FILENO (a value * different from _INVALID_HANDLE_VALUE to distinguish between * a failure in opening a file & a program run without a console. */ - in this case, stderr is a buffered FILE*, but the flush() method always fails. This makes not difference for python2.5, because it never looks at the return value of fprintf (which is not very consistent, BTW). Since pythonw (2.5) silently discards any output to stderr, we could achieve the same by opening the nul file... --- c:/temp/t 2007-11-12 13:54:34.105463200 +0100 +++ c:/afa/python/py3k/Modules/_fileio.c 2007-11-12 13:52:42.576675100 +0100 @@ -149,6 +149,15 @@ if (PyArg_ParseTupleAndKeywords(args, kwds, "i|si:fileio", kwlist, &fd, &mode, &closefd)) { +#ifdef MS_WINDOWS + /* Windows sets the descriptor to _NO_CONSOLE_FILENO when */ + /* the program is run without a console */ + if (fd == -2) + { + fd = open("nul", "r+"); + } + else +#endif if (fd < 0) { PyErr_SetString(PyExc_ValueError, "Negative filedescriptor"); __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Nov 12 15:46:26 2007 From: report at bugs.python.org (Christian Heimes) Date: Mon, 12 Nov 2007 14:46:26 -0000 Subject: [issue1415] py3k: pythonw.exe fails because std streams a missing Message-ID: <1194878786.66.0.394618916327.issue1415@psf.upfronthosting.co.za> Christian Heimes added the comment: The patch is a good idea. However it doesn't work for VS 2003 and MSVCR71: import sys f = open("stderr.txt", "w") f.write("stdin: %i\n" % sys.stdin.fileno()) f.write("stdout: %i\n" % sys.stdout.fileno()) f.write("stderr: %i\n" % sys.stderr.fileno()) > pythonw.exe pywtest.py > type stderr.txt stdin: -1 stdout: -1 stderr: -1 /me sends another hate letter to Redmond. __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Nov 12 16:28:10 2007 From: report at bugs.python.org (Amaury Forgeot d'Arc) Date: Mon, 12 Nov 2007 15:28:10 -0000 Subject: [issue1415] py3k: pythonw.exe fails because std streams a missing Message-ID: <1194881290.09.0.418996017574.issue1415@psf.upfronthosting.co.za> Amaury Forgeot d'Arc added the comment: Doh, you're right: > c:\python24\pythonw -c "import sys;print sys.stderr.fileno()"|more -1 > c:\python24-vc8\pythonw -c "import sys;print sys.stderr.fileno()"|more -2 /me needs to get the code of msvcrt7. We could simply check for (fd<0) instead, but it's better to reserve this special processing to stdin/stdout/stderr. maybe somewhere in pythonrun.c. I'll try a patch later tonight. __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Nov 12 17:55:02 2007 From: report at bugs.python.org (Guido van Rossum) Date: Mon, 12 Nov 2007 16:55:02 -0000 Subject: [issue1421] python.org: outdated and false information Message-ID: <1194886502.85.0.0925363425193.issue1421@psf.upfronthosting.co.za> Guido van Rossum added the comment: BTW, what's the best way of reporting bugs in python.org? ---------- nosy: +gvanrossum __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Nov 12 17:58:42 2007 From: report at bugs.python.org (Guido van Rossum) Date: Mon, 12 Nov 2007 16:58:42 -0000 Subject: [issue1422] Writing to an invalid fd doesn't raise an exception Message-ID: <1194886722.08.0.0603927080767.issue1422@psf.upfronthosting.co.za> Guido van Rossum added the comment: I don't think this is worth fixing; you'll get an I/O error as soon as I/O is attempted, which is upon the first read() for input, or upon the firsh (implicit or explicit) flush() on output. You can't tell whether a fd is valid or not without attempting I/O on it, so trying to test on each write() call would defeat the purpose of buffering. Testing on open() is insufficient as long as anybody could call os.close() any time. ---------- nosy: +gvanrossum resolution: -> wont fix status: open -> closed __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Nov 12 18:00:54 2007 From: report at bugs.python.org (Guido van Rossum) Date: Mon, 12 Nov 2007 17:00:54 -0000 Subject: [issue1420] Unicode literals in tokenize.py and tests. Message-ID: <1194886854.19.0.997027731779.issue1420@psf.upfronthosting.co.za> Guido van Rossum added the comment: I'm with Martin. Adam, why do you think tokenize should use bytes instead of text strings? ---------- nosy: +gvanrossum __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Nov 12 18:08:59 2007 From: report at bugs.python.org (David Barlow) Date: Mon, 12 Nov 2007 17:08:59 -0000 Subject: [issue1430] Installing on Vista asks to close Explorer (and Nokia PC Suite) Message-ID: <1194887339.5.0.28485262025.issue1430@psf.upfronthosting.co.za> New submission from David Barlow: Version 2.5.1. I'm trying to install Python on 32bit Vista Business. When I run the MSI file it proceeds smoothly (well, apart from offering to install to "c:\python..." instead of "c:\program files\python..."), and then starts the install. It then tells me that I have to close down Explorer (i.e. the shell!), and Nokia PC Suite 6.84.10.3. I could cope with the latter, but I'm definitely not prepared to exit explorer. This seems a bug/oversight in the installer. Is there any wat round it? ---------- components: Installation messages: 57403 nosy: dabarlow severity: normal status: open title: Installing on Vista asks to close Explorer (and Nokia PC Suite) type: behavior versions: Python 2.5 __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Nov 12 18:24:23 2007 From: report at bugs.python.org (Guido van Rossum) Date: Mon, 12 Nov 2007 17:24:23 -0000 Subject: [issue1423] wave sunau aifc 16bit errors Message-ID: <1194888263.58.0.152888115527.issue1423@psf.upfronthosting.co.za> Guido van Rossum added the comment: What software do you use to play the sample? Is it perhaps ignoring the nchannels value from the header? ---------- nosy: +gvanrossum __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Nov 12 18:25:42 2007 From: report at bugs.python.org (Guido van Rossum) Date: Mon, 12 Nov 2007 17:25:42 -0000 Subject: [issue1424] py3k: readline and rlcompleter doesn't list choices Message-ID: <1194888342.68.0.372079055436.issue1424@psf.upfronthosting.co.za> Guido van Rossum added the comment: Can't reproduce this (Ubuntu dapper). I get the expected output. ---------- nosy: +gvanrossum __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Nov 12 18:25:55 2007 From: report at bugs.python.org (Georg Brandl) Date: Mon, 12 Nov 2007 17:25:55 -0000 Subject: [issue1420] Unicode literals in tokenize.py and tests. Message-ID: <1194888355.48.0.403017848559.issue1420@psf.upfronthosting.co.za> Georg Brandl added the comment: Martin, Guido: I think you misunderstand the patch description: it doesn't make tokenize process bytes instead of bytes, but makes it tokenize the new b"..." literals instead of the old u"..." literals. __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Nov 12 18:26:39 2007 From: report at bugs.python.org (Guido van Rossum) Date: Mon, 12 Nov 2007 17:26:39 -0000 Subject: [issue1426] readline module needs a review Message-ID: <1194888399.25.0.419063975956.issue1426@psf.upfronthosting.co.za> Guido van Rossum added the comment: Go for it! ---------- nosy: +gvanrossum priority: high -> normal __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Nov 12 18:27:55 2007 From: report at bugs.python.org (Christian Heimes) Date: Mon, 12 Nov 2007 17:27:55 -0000 Subject: [issue1424] py3k: readline and rlcompleter doesn't list choices Message-ID: <1194888475.66.0.484702779114.issue1424@psf.upfronthosting.co.za> Christian Heimes added the comment: Fixed in r58941 (trunk), r58947 (merge) and r58933 ---------- resolution: -> fixed status: open -> closed __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Nov 12 18:30:28 2007 From: report at bugs.python.org (Guido van Rossum) Date: Mon, 12 Nov 2007 17:30:28 -0000 Subject: [issue1419] ssl module version 1.10 causes TypeError when accepting connection Message-ID: <1194888628.5.0.0687855073674.issue1419@psf.upfronthosting.co.za> Guido van Rossum added the comment: BTW Bill, how's the 3.0 port of SSL going? ---------- nosy: +gvanrossum __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Nov 12 18:35:21 2007 From: report at bugs.python.org (Christian Heimes) Date: Mon, 12 Nov 2007 17:35:21 -0000 Subject: [issue1254] pdb fails to launch some script. Message-ID: <1194888921.67.0.666825623309.issue1254@psf.upfronthosting.co.za> Christian Heimes added the comment: Fixed in r58950 for Python 2.5. Python 2.6 and 3k are already fixed. ---------- nosy: +tiran resolution: -> fixed status: open -> closed versions: +Python 2.5 __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Nov 12 18:37:28 2007 From: report at bugs.python.org (Ron Adam) Date: Mon, 12 Nov 2007 17:37:28 -0000 Subject: [issue1420] Unicode literals in tokenize.py and tests. Message-ID: <1194889048.69.0.659477122556.issue1420@psf.upfronthosting.co.za> Ron Adam added the comment: George is correct. The changes are minimal. The only addition is to run the tokenize_tests.txt file though compile() as a way to force an exception if it needs updating in the future. The results of the compile are not used. __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Nov 12 18:38:27 2007 From: report at bugs.python.org (Georg Brandl) Date: Mon, 12 Nov 2007 17:38:27 -0000 Subject: [issue1421] python.org: outdated and false information Message-ID: <1194889107.21.0.729489862532.issue1421@psf.upfronthosting.co.za> Georg Brandl added the comment: It used to be the tracker at http://pydotorg.python.org/, but the PythonWebsiteCreatingNewTickets Wiki page says it's disabled... __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Nov 12 18:40:51 2007 From: report at bugs.python.org (Guido van Rossum) Date: Mon, 12 Nov 2007 17:40:51 -0000 Subject: [issue1420] Unicode literals in tokenize.py and tests. Message-ID: <1194889251.24.0.684851552321.issue1420@psf.upfronthosting.co.za> Guido van Rossum added the comment: Got it. Checked in as revision 58951. ---------- resolution: -> accepted status: open -> closed __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Nov 12 18:49:59 2007 From: report at bugs.python.org (Guido van Rossum) Date: Mon, 12 Nov 2007 17:49:59 -0000 Subject: [issue1414] Fix for refleak tests Message-ID: <1194889799.92.0.201714222978.issue1414@psf.upfronthosting.co.za> Guido van Rossum added the comment: Please check in the frozen-related fixes. Your changes to test_tcl break that test even when run without -R! For test_pkg, I would rather see a fix that undoes all the changes to sys.modules (note that it already restores sys.path and deletes the files it's created, but that's not enough). __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Nov 12 18:51:15 2007 From: report at bugs.python.org (Guido van Rossum) Date: Mon, 12 Nov 2007 17:51:15 -0000 Subject: [issue1415] py3k: pythonw.exe fails because std streams a missing Message-ID: <1194889875.69.0.607853740621.issue1415@psf.upfronthosting.co.za> Guido van Rossum added the comment: IMO you don't need the 'closed' flag and you should continue to test for fd < 0. Whether it's -1 or -2, you still can't write to it... __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Nov 12 18:57:03 2007 From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=) Date: Mon, 12 Nov 2007 17:57:03 -0000 Subject: [issue1430] Installing on Vista asks to close Explorer (and Nokia PC Suite) Message-ID: <1194890223.1.0.553086270064.issue1430@psf.upfronthosting.co.za> Martin v. L?wis added the comment: This error message is not produced by the Python MSI file, but by Windows installer itself. It computes the set of files that we are about to install, which includes the Microsoft C Runtime DLL. I guess that this file is also in use by Explorer. It is safe to ignore this warning, and proceed with the installation. Closing this as a third-party problem. ---------- nosy: +loewis resolution: -> wont fix status: open -> closed versions: +3rd party -Python 2.5 __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Nov 12 19:14:32 2007 From: report at bugs.python.org (Christian Heimes) Date: Mon, 12 Nov 2007 18:14:32 -0000 Subject: [issue1415] py3k: pythonw.exe fails because std streams a missing Message-ID: <1194891272.19.0.219660748953.issue1415@psf.upfronthosting.co.za> Christian Heimes added the comment: W/o the closed flag it's impossible to distinguish between closed fd and invalid fd. __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Nov 12 19:35:27 2007 From: report at bugs.python.org (jeroen) Date: Mon, 12 Nov 2007 18:35:27 -0000 Subject: [issue1423] wave sunau aifc 16bit errors In-Reply-To: <1194888263.58.0.152888115527.issue1423@psf.upfronthosting.co.za> Message-ID: <007101c8255a$65a29fa0$30e7dee0$@com> jeroen added the comment: I played using winsound.PlaySound function for the wav. I used VLC and windows media player for wav,au and aiff after that All had the same problem. It was solved for sunau by doubling the nframes number written by the close function in the sunau module. I assume something similar should be done for the wav and aiff modules. This is what I changed in sunau I am not sure if adding *self._sampwidth breaks something else. It works for me now when I create 16bit stereo files. def _patchheader(self): self._file.seek(8) # jjk added * sampwidth otherwise for 16 bit you get wrong nframes _write_u32(self._file, self._datawritten*self._sampwidth) self._datalength = self._datawritten self._file.seek(0, 2) Hope this helps. greetings __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Nov 12 20:14:35 2007 From: report at bugs.python.org (Christian Heimes) Date: Mon, 12 Nov 2007 19:14:35 -0000 Subject: [issue1414] Fix for refleak tests Message-ID: <1194894875.63.0.0908101332141.issue1414@psf.upfronthosting.co.za> Christian Heimes added the comment: How do you like; class TestPkg(unittest.TestCase): def setUp(self): self.root = None self.syspath = list(sys.path) self.sysmodules = sys.modules.copy() def tearDown(self): sys.path[:] = self.syspath sys.modules.clear() sys.modules.update(self.sysmodules) del self.sysmodules cleanout(self.root) Or I could use the paranoid approach: create set from sys.modules.keys() in setUp + tearDown and remove the items that are in the second set but not in the first set. __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Nov 12 20:20:25 2007 From: report at bugs.python.org (Christian Heimes) Date: Mon, 12 Nov 2007 19:20:25 -0000 Subject: [issue1414] Fix for refleak tests Message-ID: <1194895225.8.0.450341635437.issue1414@psf.upfronthosting.co.za> Christian Heimes added the comment: Fix for test_frozen comitted in r58953 __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Nov 12 20:28:53 2007 From: report at bugs.python.org (Christian Heimes) Date: Mon, 12 Nov 2007 19:28:53 -0000 Subject: [issue1704621] interpreter crash when multiplying large lists Message-ID: <1194895733.18.0.153338025774.issue1704621@psf.upfronthosting.co.za> Christian Heimes added the comment: Python 2.6 (trunk) is raising a MemoryError in a non-debug build, too. The problem is fixed in 2.6 and 3.0. ---------- versions: -Python 2.6, Python 3.0 _____________________________________ Tracker _____________________________________ From report at bugs.python.org Mon Nov 12 20:47:38 2007 From: report at bugs.python.org (Guido van Rossum) Date: Mon, 12 Nov 2007 19:47:38 -0000 Subject: [issue1414] Fix for refleak tests In-Reply-To: <1194894875.63.0.0908101332141.issue1414@psf.upfronthosting.co.za> Message-ID: Guido van Rossum added the comment: If that makes the test pass with and without -R::, go for it! On Nov 12, 2007 11:14 AM, Christian Heimes wrote: > > Christian Heimes added the comment: > > How do you like; > > class TestPkg(unittest.TestCase): > > def setUp(self): > self.root = None > self.syspath = list(sys.path) > self.sysmodules = sys.modules.copy() > > def tearDown(self): > sys.path[:] = self.syspath > sys.modules.clear() > sys.modules.update(self.sysmodules) > del self.sysmodules > cleanout(self.root) > > Or I could use the paranoid approach: create set from sys.modules.keys() > in setUp + tearDown and remove the items that are in the second set but > not in the first set. > > > __________________________________ > Tracker > > __________________________________ > __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Nov 12 21:01:18 2007 From: report at bugs.python.org (Christian Heimes) Date: Mon, 12 Nov 2007 20:01:18 -0000 Subject: [issue1426] readline module needs a review Message-ID: <1194897678.58.0.820073817097.issue1426@psf.upfronthosting.co.za> Christian Heimes added the comment: Done just the on_completion_match_display_hook was in a bad state. The rest was fine except for some indentions. ---------- resolution: -> fixed status: open -> closed __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Nov 12 21:07:10 2007 From: report at bugs.python.org (Guido van Rossum) Date: Mon, 12 Nov 2007 20:07:10 -0000 Subject: [issue1704621] interpreter crash when multiplying large lists Message-ID: <1194898030.56.0.492436895832.issue1704621@psf.upfronthosting.co.za> Guido van Rossum added the comment: Fixed in 2.5 branch (to be released with 2.5.2). Unit test added to 2.6 (trunk). ---------- resolution: -> accepted status: open -> closed _____________________________________ Tracker _____________________________________ From report at bugs.python.org Mon Nov 12 21:11:54 2007 From: report at bugs.python.org (Guido van Rossum) Date: Mon, 12 Nov 2007 20:11:54 -0000 Subject: [issue1415] py3k: pythonw.exe fails because std streams a missing In-Reply-To: <1194891272.19.0.219660748953.issue1415@psf.upfronthosting.co.za> Message-ID: Guido van Rossum added the comment: I don't understand. When does the difference matter? On Nov 12, 2007 10:14 AM, Christian Heimes wrote: > > Christian Heimes added the comment: > > W/o the closed flag it's impossible to distinguish between closed fd and > invalid fd. __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Nov 12 21:57:22 2007 From: report at bugs.python.org (Christian Heimes) Date: Mon, 12 Nov 2007 20:57:22 -0000 Subject: [issue1415] py3k: pythonw.exe fails because std streams a missing In-Reply-To: Message-ID: <4738BE2F.4000000@cheimes.de> Christian Heimes added the comment: Guido van Rossum wrote: > Guido van Rossum added the comment: > > I don't understand. When does the difference matter? When the check for fd < 0 is removed from fileio_init() there is no way to tell if fd < 0 means fd closed or invalid fd. In order to fix the problem with GUI apps on Windows the check for fd < 0 has to be removed (Python 2.x way). Or we use Amaury's way and open NUL for reading and writing as a substitute for the standard streams. Christian __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Nov 12 22:09:46 2007 From: report at bugs.python.org (Guido van Rossum) Date: Mon, 12 Nov 2007 21:09:46 -0000 Subject: [issue1415] py3k: pythonw.exe fails because std streams a missing In-Reply-To: <4738BE2F.4000000@cheimes.de> Message-ID: Guido van Rossum added the comment: > > I don't understand. When does the difference matter? > > When the check for fd < 0 is removed from fileio_init() there is no way > to tell if fd < 0 means fd closed or invalid fd. I still don't understand. Why do you need to treat a closed fd different from an invalid fd. In both cases you can't use it and you shouldn't close it. > In order to fix the problem with GUI apps on Windows the check for fd < > 0 has to be removed (Python 2.x way). Or we use Amaury's way and open > NUL for reading and writing as a substitute for the standard streams. I'd suggest that, on Windows, sys.std{in,out.err} should be set to None instead of a file object when their file descriptor is invalid. That way print and write requests will fail immediately instead of nondeterministically. With an invalid file that only blows upwhen trying to flush you may be able to write a small traceback but it will still blow up if the traceback is big. Is there a downside to print/write blowing up right away in apps using pythonw? __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Nov 12 22:32:20 2007 From: report at bugs.python.org (Christian Heimes) Date: Mon, 12 Nov 2007 21:32:20 -0000 Subject: [issue1415] py3k: pythonw.exe fails because std streams a missing In-Reply-To: Message-ID: <4738C663.6010806@cheimes.de> Christian Heimes added the comment: Guido van Rossum wrote: > I still don't understand. Why do you need to treat a closed fd > different from an invalid fd. In both cases you can't use it and you > shouldn't close it. I don't want to treat the fd differently. I want to return a sensible error message that is different from "file closed" when the fd is invalid. > I'd suggest that, on Windows, sys.std{in,out.err} should be set to > None instead of a file object when their file descriptor is invalid. > That way print and write requests will fail immediately instead of > nondeterministically. With an invalid file that only blows upwhen > trying to flush you may be able to write a small traceback but it will > still blow up if the traceback is big. But wouldn't that cause a fatal error when sys.stderr is missing and Python can't write the traceback to a file like object? *testing* No, it works: object : Exception('msg',) type : Exception refcount: 4 address : 0x839d274 lost sys.stderr I've an alternative solution based on Amaurgy's idea. Python could set replacements for stdin, stdout and stderr before it sets up the preliminary stderr: #ifdef MS_WINDOWS /* The standard streams of Windows GUI apps aren't connected. */ if (fileno(stdin) < 0) { if (freopen("NUL", "rb", stdin) == NULL) Py_FatalError("Py_Initialize: failed to replace stdin"); } if (fileno(stdout) < 0) { if (freopen("NUL", "wb", stdout) == NULL) Py_FatalError("Py_Initialize: failed to replace stdout"); } if (fileno(stderr) < 0) { if (freopen("NUL", "wb", stderr) == NULL) Py_FatalError("Py_Initialize: failed to replace stderr"); } #endif __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Nov 12 22:34:19 2007 From: report at bugs.python.org (Christian Heimes) Date: Mon, 12 Nov 2007 21:34:19 -0000 Subject: [issue1415] py3k: pythonw.exe fails because std streams a missing Message-ID: <1194903259.51.0.164572445473.issue1415@psf.upfronthosting.co.za> Christian Heimes added the comment: The mail gateway swallows examples: >>> import sys >>> sys.stderr = None >>> raise Exception("msg") >>> del sys.stderr >>> raise Exception("msg") object : Exception('msg',) type : Exception refcount: 4 address : 0x839d274 lost sys.stderr __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Nov 12 22:42:33 2007 From: report at bugs.python.org (Raghuram Devarakonda) Date: Mon, 12 Nov 2007 21:42:33 -0000 Subject: [issue1210] imaplib does not run under Python 3 Message-ID: <1194903753.49.0.433934573857.issue1210@psf.upfronthosting.co.za> Raghuram Devarakonda added the comment: Index: Lib/imaplib.py =================================================================== --- Lib/imaplib.py (revision 58956) +++ Lib/imaplib.py (working copy) @@ -228,7 +228,7 @@ self.port = port self.sock = socket.socket(socket.AF_INET, socket.SOCK_STREAM) self.sock.connect((host, port)) - self.file = self.sock.makefile('rb') + self.file = self.sock.makefile('r', encoding='ASCII', newline='') def read(self, size): ------------- This patch fixes the issue but I am not entirely sure that it is correct. I quickly looked at IMAP RFC and there does seem to be spec for CHARSET in which case, that will have to be used instead of ASCII. It requires more research and imap knowledge which I can't claim. As for the tests, we need a imap server to connect to. Perhaps, google wouldn't mind being used for this purpose? __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Nov 12 23:10:36 2007 From: report at bugs.python.org (Guido van Rossum) Date: Mon, 12 Nov 2007 22:10:36 -0000 Subject: [issue1415] py3k: pythonw.exe fails because std streams a missing Message-ID: <1194905436.68.0.369840162601.issue1415@psf.upfronthosting.co.za> Guido van Rossum added the comment: > I don't want to treat the fd differently. I want to return a sensible > error message that is different from "file closed" when the fd is invalid. Doesn't sound too important. Anyway, from which call do you want to issue different messages? I'd rather see sys.stdout == None than opening NUL. __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Nov 13 00:54:48 2007 From: report at bugs.python.org (Giambattista Bloisi) Date: Mon, 12 Nov 2007 23:54:48 -0000 Subject: [issue1431] pth files not loaded at startup Message-ID: <1194911688.74.0.067622667348.issue1431@psf.upfronthosting.co.za> New submission from Giambattista Bloisi: site.py ha two limitations that make difficult to use pth files on my linux installation (gobolinux): - it does not process pth files that are located in directories that are already present in os.path at the time the main method is invoked - it does not process directory recursively Please find attached a patch that solves both. Basically known_paths became a set representing the directories that have been processed. Duplicates in os.path are avoided by looking directly into it. ---------- components: Library (Lib) files: site.py.patch messages: 57432 nosy: gbloisi severity: normal status: open title: pth files not loaded at startup type: behavior versions: Python 2.5 Added file: http://bugs.python.org/file8739/site.py.patch __________________________________ Tracker __________________________________ -------------- next part -------------- A non-text attachment was scrubbed... Name: site.py.patch Type: application/octet-stream Size: 1047 bytes Desc: not available Url : http://mail.python.org/pipermail/python-bugs-list/attachments/20071112/adc9ecac/attachment.obj From report at bugs.python.org Tue Nov 13 02:06:09 2007 From: report at bugs.python.org (Amaury Forgeot d'Arc) Date: Tue, 13 Nov 2007 01:06:09 -0000 Subject: [issue1265] pdb bug with "with" statement Message-ID: <1194915969.78.0.332982907275.issue1265@psf.upfronthosting.co.za> Amaury Forgeot d'Arc added the comment: Corrected by revision 58958. "with" is innocent. The problem is this function in abc.py which uses a generator expression: def __instancecheck__(cls, instance): """Override for isinstance(instance, cls).""" return any(cls.__subclasscheck__(c) for c in {instance.__class__, type(instance)}) It is called both by pdb (deep inside 'print') and the debugged code (in PyObject_MethodCall), and this reveals the bug. ---------- nosy: +amaury.forgeotdarc __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Nov 13 02:18:29 2007 From: report at bugs.python.org (yan) Date: Tue, 13 Nov 2007 01:18:29 -0000 Subject: [issue1432] Strange behavior of urlparse.urljoin Message-ID: <1194916709.09.0.956868163288.issue1432@psf.upfronthosting.co.za> New submission from yan: When I use python 2.4/2.5, I found a strange behavior like this: urlparse.urljoin("http://www.python.org/issue?@template=item","?@template=none") It will return "http://www.python.org/?@template=none". But I think it should be "http://www.python.org/issue?@template=none", right? And I test it in python 2.3. The result is what I supposed it to be. ---------- components: Library (Lib) messages: 57434 nosy: yan severity: normal status: open title: Strange behavior of urlparse.urljoin type: behavior versions: Python 2.4, Python 2.5, Python 2.6 __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Nov 13 02:19:07 2007 From: report at bugs.python.org (Amaury Forgeot d'Arc) Date: Tue, 13 Nov 2007 01:19:07 -0000 Subject: [issue1265] pdb bug with "with" statement Message-ID: <1194916747.26.0.326020567239.issue1265@psf.upfronthosting.co.za> Amaury Forgeot d'Arc added the comment: __instancecheck__ should be simpler: all classes are new-style, how is it possible to have different results for instance.__class__ and type(instance) ? __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Nov 13 02:43:57 2007 From: report at bugs.python.org (Christian Heimes) Date: Tue, 13 Nov 2007 01:43:57 -0000 Subject: [issue1265] pdb bug with "with" statement Message-ID: <1194918237.6.0.82872312822.issue1265@psf.upfronthosting.co.za> Christian Heimes added the comment: Good work Amaury! :) I also wonder how type(cls) != cls.__class__ is possible with new style classes. So far I found only one way and it ain't beautiful: >>> class Meta(type): ... def __getattribute__(self, key): ... if key == "__class__": return object ... return type.__getattribute__(self, key) ... >>> class Example(metaclass=Meta): pass ... >>> Example.__class__ >>> type(Example) ---------- keywords: +py3k resolution: accepted -> fixed status: open -> closed __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Nov 13 03:26:51 2007 From: report at bugs.python.org (Christian Heimes) Date: Tue, 13 Nov 2007 02:26:51 -0000 Subject: [issue1415] py3k: pythonw.exe fails because std streams a missing Message-ID: <1194920811.07.0.96894329655.issue1415@psf.upfronthosting.co.za> Christian Heimes added the comment: Fixed in r58959 I followed your wish and set sys.stdin, stdout and stderr to None together with __std?__. I also kept the check for fd < 0 in fileio_init(). A negative fd still raises the correct error with errno 9 (bad file descriptor). ---------- resolution: -> fixed __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Nov 13 06:14:02 2007 From: report at bugs.python.org (Guido van Rossum) Date: Tue, 13 Nov 2007 05:14:02 -0000 Subject: [issue1265] pdb bug with "with" statement Message-ID: <1194930842.0.0.557723370045.issue1265@psf.upfronthosting.co.za> Guido van Rossum added the comment: Good work indeed! Here's another way: >>> class C: ... @property ... def __class__(self): return D ... >>> class D: pass ... >>> C().__class__ >>> __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Nov 13 06:19:35 2007 From: report at bugs.python.org (Guido van Rossum) Date: Tue, 13 Nov 2007 05:19:35 -0000 Subject: [issue1265] pdb bug with "with" statement Message-ID: <1194931175.11.0.86722868499.issue1265@psf.upfronthosting.co.za> Guido van Rossum added the comment: BTW: if you can show (e.g. with your unittest) that this indeed breaks in 2.6 and 2.5, please do backport it. BTW**2: I've noticed that abc.py's __instancecheck__ gets called a lot at times when I don't expect it. Can you research this a bit? __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Nov 13 06:20:20 2007 From: report at bugs.python.org (Guido van Rossum) Date: Tue, 13 Nov 2007 05:20:20 -0000 Subject: [issue1265] pdb bug with "with" statement Message-ID: <1194931220.21.0.19248094217.issue1265@psf.upfronthosting.co.za> Guido van Rossum added the comment: PPSS. When backporting, a note in Misc/NEWS is appreciated. __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Nov 13 06:58:39 2007 From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=) Date: Tue, 13 Nov 2007 05:58:39 -0000 Subject: [issue1431] pth files not loaded at startup Message-ID: <1194933519.45.0.379029650894.issue1431@psf.upfronthosting.co.za> Changes by Martin v. L?wis: ---------- keywords: +patch __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Nov 13 09:11:14 2007 From: report at bugs.python.org (Brett Cannon) Date: Tue, 13 Nov 2007 08:11:14 -0000 Subject: [issue1431] pth files not loaded at startup Message-ID: <1194941474.42.0.473554603529.issue1431@psf.upfronthosting.co.za> Brett Cannon added the comment: While I am not sure how I feel about searching every entry on sys.path, I know I don't like the idea of recursing the directory tree. pth files are meant to only be at the top-level of a directory that packages and modules are checked for. ---------- nosy: +brett.cannon __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Nov 13 09:33:10 2007 From: report at bugs.python.org (Giambattista Bloisi) Date: Tue, 13 Nov 2007 08:33:10 -0000 Subject: [issue1431] pth files not loaded at startup Message-ID: <1194942790.12.0.387201990081.issue1431@psf.upfronthosting.co.za> Giambattista Bloisi added the comment: What I meant for recursively was not to scan the full directory tree, but just to scan entries that have been added to the os.path. I think that this was the original intention as http://docs.python.org/inst/search-path.html states: "Any directories added to the search path will be scanned in turn for .pth files". Also http://docs.python.org/lib/module-site.html states: "For each of the distinct head-tail combinations, it sees if it refers to an existing directory, and if so, adds it to sys.path and also inspects the newly added path for configuration files." __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Nov 13 10:11:35 2007 From: report at bugs.python.org (David Barlow) Date: Tue, 13 Nov 2007 09:11:35 -0000 Subject: [issue1430] Installing on Vista asks to close Explorer (and Nokia PC Suite) Message-ID: <1194945095.02.0.0104017242889.issue1430@psf.upfronthosting.co.za> Changes by David Barlow: __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Nov 13 10:27:34 2007 From: report at bugs.python.org (Amaury Forgeot d'Arc) Date: Tue, 13 Nov 2007 09:27:34 -0000 Subject: [issue1265] pdb bug with "with" statement Message-ID: <1194946054.37.0.192798162395.issue1265@psf.upfronthosting.co.za> Amaury Forgeot d'Arc added the comment: > BTW**2: I've noticed that abc.py's __instancecheck__ gets called a lot > at times when I don't expect it. Can you research this a bit? In classobject.c, method_call() calls PyObject_IsInstance() on the first arg when the method is unbound. This happens a lot in io.py, each time the code calls a base class method. __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Nov 13 11:53:09 2007 From: report at bugs.python.org (Carl Friedrich Bolz) Date: Tue, 13 Nov 2007 10:53:09 -0000 Subject: [issue1433] marshal roundtripping for unicode Message-ID: <1194951189.44.0.776453257411.issue1433@psf.upfronthosting.co.za> New submission from Carl Friedrich Bolz: Marshal does not round-trip unicode surrogate pairs for wide unicode-builds: marshal.loads(marshal.dumps(u"\ud800\udc00")) == u'\U00010000' This is very annoying, because the size of unicode constants differs between when you run a module for the first time and subsequent runs (because the later runs use the pyc file). ---------- components: Unicode messages: 57444 nosy: cfbolz severity: normal status: open title: marshal roundtripping for unicode versions: Python 2.5 __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Nov 13 12:22:51 2007 From: report at bugs.python.org (Luke-Jr) Date: Tue, 13 Nov 2007 11:22:51 -0000 Subject: [issue1434] SocketServer creates non-blocking files Message-ID: <1194952971.52.0.0175345572361.issue1434@psf.upfronthosting.co.za> New submission from Luke-Jr: SocketServer recently started giving my request handler rfiles that don't block: readfile() gives me a timeout exception. This used to work fine. I begin writing this server with 2.4.3, and it is currently running under 2.4.4, so my suspicious is somewhere in between it changed. ---------- components: Library (Lib) messages: 57445 nosy: luke-jr severity: normal status: open title: SocketServer creates non-blocking files versions: Python 2.4 __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Nov 13 13:18:00 2007 From: report at bugs.python.org (Stavros Korokithakis) Date: Tue, 13 Nov 2007 12:18:00 -0000 Subject: [issue1435] Support for multiple handlers for the "with" statement Message-ID: <1194956280.18.0.690384214336.issue1435@psf.upfronthosting.co.za> New submission from Stavros Korokithakis: Currently, the new "with" statement does not support multiple handlers. For example, to open two files for input/output you would have to do: with open("filein") as input: with open("fileout") as output: #Do stuff pass This adds unnecessary complexity, and would be unwieldy with multiple code blocks. Would something like the following be feasible? with open("filein") as input, open("fileout") as output: # Do stuff pass This syntax is fully backwards-compatible, so there shouldn't be any problem there. ---------- components: None messages: 57446 nosy: Stavros severity: minor status: open title: Support for multiple handlers for the "with" statement type: behavior versions: Python 2.5 __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Nov 13 13:36:05 2007 From: report at bugs.python.org (Stavros Korokithakis) Date: Tue, 13 Nov 2007 12:36:05 -0000 Subject: [issue1435] Support for multiple handlers for the "with" statement Message-ID: <1194957365.38.0.476771861307.issue1435@psf.upfronthosting.co.za> Stavros Korokithakis added the comment: What this syntax does is similar to the nested context manager in case 12 of PEP343, but with cleaner syntax. __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Nov 13 13:41:46 2007 From: report at bugs.python.org (sebastian) Date: Tue, 13 Nov 2007 12:41:46 -0000 Subject: [issue1436] logging.config.fileConfig, NameError: name 'RotatingFileHandler' is not defined Message-ID: <1194957706.1.0.150807949301.issue1436@psf.upfronthosting.co.za> New submission from sebastian: fileConfig crashes with a NameError when trying to configure a RotatingFileHandler (I assume the same holds for other handlers defined in logging.handlers). Using StreamHandler (from the logging package) works fine. Most likely, I am missing something here, but if not, this is a really bad joke... RotatingFileHandler is available on my system, a qualified name must be used: Python 2.5.1 (r251:54869, Apr 18 2007, 22:08:04) [GCC 4.0.1 (Apple Computer, Inc. build 5367)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import logging >>> import logging.handlers >>> RotatingFileHandler("test.log", "a", 5000, 5) Traceback (most recent call last): File "", line 1, in NameError: name 'RotatingFileHandler' is not defined >>> logging.handlers.RotatingFileHandler("test.log", "a", 5000, 5) fileConfig crashes, with or without qualified names: >>> import logging.config >>> logging.config.fileConfig("test.ini") Traceback (most recent call last): File "", line 1, in File "/Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/logging/config.py", line 84, in fileConfig handlers = _install_handlers(cp, formatters) File "/Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/logging/config.py", line 149, in _install_handlers klass = eval(klass, vars(logging)) File "", line 1, in NameError: name 'RotatingFileHandler' is not defined >>> logging.config.fileConfig("test.qualified_name.ini") Traceback (most recent call last): File "", line 1, in File "/Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/logging/config.py", line 84, in fileConfig handlers = _install_handlers(cp, formatters) File "/Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/logging/config.py", line 149, in _install_handlers klass = eval(klass, vars(logging)) File "", line 1, in NameError: name 'logging' is not defined test.ini (in configurationFiles.zip): --- [loggers] keys=root [handlers] keys=fileHandler [formatters] keys=simpleFormatter [logger_root] level=DEBUG handlers=fileHandler [handler_fileHandler] class=RotatingFileHandler level=DEBUG formatter=simpleFormatter args=('test.log', 'a', 5000000, 5) [formatter_simpleFormatter] format=%(asctime)s - %(name)s - %(levelname)s - %(message)s datefmt= --- test.qualified_name.ini (in configurationFiles.zip): --- [loggers] keys=root [handlers] keys=fileHandler [formatters] keys=simpleFormatter [logger_root] level=DEBUG handlers=fileHandler [handler_fileHandler] class=logging.handlers.RotatingFileHandler level=DEBUG formatter=simpleFormatter args=('test.log', 'a', 5000000, 5) [formatter_simpleFormatter] format=%(asctime)s - %(name)s - %(levelname)s - %(message)s datefmt= --- ---------- components: Library (Lib) files: configurationFiles.zip messages: 57448 nosy: sebastian severity: urgent status: open title: logging.config.fileConfig, NameError: name 'RotatingFileHandler' is not defined type: crash versions: Python 2.5 Added file: http://bugs.python.org/file8740/configurationFiles.zip __________________________________ Tracker __________________________________ -------------- next part -------------- A non-text attachment was scrubbed... Name: configurationFiles.zip Type: application/zip Size: 670 bytes Desc: not available Url : http://mail.python.org/pipermail/python-bugs-list/attachments/20071113/0d974e31/attachment.zip From report at bugs.python.org Tue Nov 13 13:53:38 2007 From: report at bugs.python.org (glubglub) Date: Tue, 13 Nov 2007 12:53:38 -0000 Subject: [issue1437] List member inside a class is shared by all instances of the class Message-ID: <1194958418.68.0.123960070989.issue1437@psf.upfronthosting.co.za> New submission from glubglub: In the class below, 'arr' list should be unique for each instance of class Blah. In reality, 'arr' is shared by all instances of 'Blah' class Blah: arr = [] # this member should not be # shared across all instances of blah s = '' def __init__(self, s): self.s = s def __str__( self): return '[%s, %s]' % (self.s, str(self.arr)) objs = [] objs.append(Blah('obj-a')) objs.append(Blah('obj-b')) objs.append(Blah('obj-c')) # add to first object's array objs[0].arr.append('abc') # bug: 'abc' got added to all arrays # print all arrays for obj in objs: print obj ------------------------------ Actual Output: [obj-a, ['abc']] [obj-b, ['abc']] [obj-c, ['abc']] Expected Output: [obj-a, ['abc']] [obj-b, []] [obj-c, []] ---------- components: Interpreter Core messages: 57449 nosy: glubglub severity: normal status: open title: List member inside a class is shared by all instances of the class versions: Python 2.3, Python 2.4, Python 2.5 __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Nov 13 14:11:41 2007 From: report at bugs.python.org (Quentin Gallet-Gilles) Date: Tue, 13 Nov 2007 13:11:41 -0000 Subject: [issue1437] List member inside a class is shared by all instances of the class Message-ID: <1194959501.89.0.93447724573.issue1437@psf.upfronthosting.co.za> Quentin Gallet-Gilles added the comment: That's the expected behavior, actually. The variables 'arr' and 's' are static variables in the class Blah. This is discussed in several places in the doc and the FAQ, e.g. http://www.python.org/doc/faq/programming/#how-do-i-create-static-class-data-and-static-class-methods What you're looking for is : class Blah: def __init__(self, s): self.arr= [] self.s = s ... ---------- nosy: +quentin.gallet-gilles __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Nov 13 15:13:57 2007 From: report at bugs.python.org (Christian Heimes) Date: Tue, 13 Nov 2007 14:13:57 -0000 Subject: [issue1437] List member inside a class is shared by all instances of the class Message-ID: <1194963237.26.0.231502750361.issue1437@psf.upfronthosting.co.za> Christian Heimes added the comment: It's a known feature - and a known gotcha for new Python developers. ---------- nosy: +tiran resolution: -> invalid status: open -> closed __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Nov 13 15:20:42 2007 From: report at bugs.python.org (Christian Heimes) Date: Tue, 13 Nov 2007 14:20:42 -0000 Subject: [issue1436] logging.config.fileConfig, NameError: name 'RotatingFileHandler' is not defined Message-ID: <1194963641.87.0.0967904983337.issue1436@psf.upfronthosting.co.za> Christian Heimes added the comment: confirmed The problem is in logging.config._install_handlers(cp, formatters). The code is usin klass = eval(klass, vars(logging)) args = eval(args, vars(logging)) to get the logger class from the logging module. ---------- nosy: +tiran versions: +Python 2.6, Python 3.0 __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Nov 13 15:23:23 2007 From: report at bugs.python.org (Christian Heimes) Date: Tue, 13 Nov 2007 14:23:23 -0000 Subject: [issue1435] Support for multiple handlers for the "with" statement Message-ID: <1194963803.04.0.581724790946.issue1435@psf.upfronthosting.co.za> Changes by Christian Heimes: ---------- components: +Interpreter Core -None priority: -> low type: behavior -> rfe versions: +Python 2.6 __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Nov 13 15:35:26 2007 From: report at bugs.python.org (Christian Heimes) Date: Tue, 13 Nov 2007 14:35:26 -0000 Subject: [issue1436] logging.config.fileConfig, NameError: name 'RotatingFileHandler' is not defined Message-ID: <1194964526.28.0.906914773144.issue1436@psf.upfronthosting.co.za> Changes by Christian Heimes: ---------- assignee: -> vsajip nosy: +vsajip priority: -> normal __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Nov 13 15:37:01 2007 From: report at bugs.python.org (Christian Heimes) Date: Tue, 13 Nov 2007 14:37:01 -0000 Subject: [issue1415] py3k: pythonw.exe fails because std streams a missing Message-ID: <1194964621.84.0.835102060046.issue1415@psf.upfronthosting.co.za> Christian Heimes added the comment: I consider the bug fixed and closed. Objections? ---------- status: open -> closed __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Nov 13 16:06:51 2007 From: report at bugs.python.org (Amaury Forgeot d'Arc) Date: Tue, 13 Nov 2007 15:06:51 -0000 Subject: [issue1415] py3k: pythonw.exe fails because std streams a missing Message-ID: <1194966411.0.0.555244267991.issue1415@psf.upfronthosting.co.za> Amaury Forgeot d'Arc added the comment: (Sorry, I cannot test just now) What happens if pythonw.exe calls the print() function? Please tell me that it does not throw an exception. __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Nov 13 16:26:16 2007 From: report at bugs.python.org (Christian Heimes) Date: Tue, 13 Nov 2007 15:26:16 -0000 Subject: [issue1415] py3k: pythonw.exe fails because std streams a missing Message-ID: <1194967576.2.0.44952050661.issue1415@psf.upfronthosting.co.za> Christian Heimes added the comment: Since r58962 it doesn't ;) __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Nov 13 16:37:47 2007 From: report at bugs.python.org (Christian Heimes) Date: Tue, 13 Nov 2007 15:37:47 -0000 Subject: [issue1342] Crash on Windows if Python runs from a directory with umlauts Message-ID: <1194968267.65.0.456292428142.issue1342@psf.upfronthosting.co.za> Christian Heimes added the comment: I like to move _PyExc_Init() before _PySys_Init() and set sys.prefix, exec_prefix and executable with PyUnicode_DecodeFSDefault(). Without the changes Python is seg faulting on Windows when the path contains non ASCII chars. With the patch it is failing with a fatal error which is a tiny bit nicer. Added file: http://bugs.python.org/file8741/py3k_win_nonascii.patch __________________________________ Tracker __________________________________ -------------- next part -------------- A non-text attachment was scrubbed... Name: py3k_win_nonascii.patch Type: text/x-diff Size: 1479 bytes Desc: not available Url : http://mail.python.org/pipermail/python-bugs-list/attachments/20071113/de1942fb/attachment.patch From report at bugs.python.org Tue Nov 13 16:57:58 2007 From: report at bugs.python.org (Amaury Forgeot d'Arc) Date: Tue, 13 Nov 2007 15:57:58 -0000 Subject: [issue1415] py3k: pythonw.exe fails because std streams a missing Message-ID: <1194969478.58.0.789224129218.issue1415@psf.upfronthosting.co.za> Amaury Forgeot d'Arc added the comment: Is it the only possibility? On Windows, it is quite common to print to stdout for debugging purposes, then deploy the application with pythonw.exe which suppresses the console. Without any change to the code. Most pygame programs I know work this way, and C programs have the same behaviour. Prints should work, even if they discard their output. __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Nov 13 17:22:51 2007 From: report at bugs.python.org (Bill Janssen) Date: Tue, 13 Nov 2007 16:22:51 -0000 Subject: [issue1419] ssl module version 1.10 causes TypeError when accepting connection In-Reply-To: <1194888628.5.0.0687855073674.issue1419@psf.upfronthosting.co.za> Message-ID: <4b3e516a0711130822y4878f6ddj37aa043cb40a4f7d@mail.gmail.com> Bill Janssen added the comment: About the same as two weeks ago... I have a functional patch, or rather, I have a patch that would work if the issues with socket closing are resolved the way I suggested :-). I've been waiting to see what's going to happen with the socket module. Bill On 11/12/07, Guido van Rossum wrote: > > Guido van Rossum added the comment: > > BTW Bill, how's the 3.0 port of SSL going? > > ---------- > nosy: +gvanrossum > > __________________________________ > Tracker > > __________________________________ > __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Nov 13 17:35:23 2007 From: report at bugs.python.org (Christian Heimes) Date: Tue, 13 Nov 2007 16:35:23 -0000 Subject: [issue1415] py3k: pythonw.exe fails because std streams a missing Message-ID: <1194971722.78.0.382878292531.issue1415@psf.upfronthosting.co.za> Christian Heimes added the comment: As far as I can see print() works if sys.stdout is either None (discard output ASAP) or a file like object. Even print(file=syst.stderr) works. sys.stdout.write() is going to fail when sys.stdout is None but that's not my concern. It's another well documented difference between Python 2.x and 3.x. If people still need a valid but no op stdout they can set up their own: class NullWriter: def write(self, data): pass if sys.stdout is None: sys.stdout = NullWriter() Done ;) __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Nov 13 18:07:29 2007 From: report at bugs.python.org (Amaury Forgeot d'Arc) Date: Tue, 13 Nov 2007 17:07:29 -0000 Subject: [issue1415] py3k: pythonw.exe fails because std streams a missing Message-ID: <1194973649.13.0.243944382345.issue1415@psf.upfronthosting.co.za> Amaury Forgeot d'Arc added the comment: > As far as I can see print() works if sys.stdout is either None > (discard output ASAP) or a file like object. Even > print(file=syst.stderr) works. Ah, I prefer this. > sys.stdout.write() is going to fail when sys.stdout is None > but that's not my concern. It's not very important indeed. I'm happy with the current behaviour. Let's close this issue. __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Nov 13 19:25:44 2007 From: report at bugs.python.org (Guido van Rossum) Date: Tue, 13 Nov 2007 18:25:44 -0000 Subject: [issue1438] Calling base class methods is slow due to __instancecheck__ override in abc.py Message-ID: <1194978343.94.0.00370847654869.issue1438@psf.upfronthosting.co.za> New submission from Guido van Rossum: [Guido] > > I've noticed that abc.py's __instancecheck__ gets called a lot > > at times when I don't expect it. Can you research this a bit? [Amaury] > In classobject.c, method_call() calls PyObject_IsInstance() on the > first arg when the method is unbound. > This happens a lot in io.py, each time the code calls a base class > method. [Guido] I wonder if we should get rid of this isinstance check. It is only used to be able to issue a pedantic error message. Perhaps we could even get rid of unbound methods, and just return the underlying function object instead of creating an unbound method object. This should make things a bit faster. ---------- messages: 57461 nosy: gvanrossum severity: normal status: open title: Calling base class methods is slow due to __instancecheck__ override in abc.py versions: Python 3.0 __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Nov 13 19:26:20 2007 From: report at bugs.python.org (Guido van Rossum) Date: Tue, 13 Nov 2007 18:26:20 -0000 Subject: [issue1438] Calling base class methods is slow due to __instancecheck__ override in abc.py Message-ID: <1194978380.81.0.334956622259.issue1438@psf.upfronthosting.co.za> Changes by Guido van Rossum: ---------- assignee: -> gvanrossum __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Nov 13 19:28:40 2007 From: report at bugs.python.org (Guido van Rossum) Date: Tue, 13 Nov 2007 18:28:40 -0000 Subject: [issue1433] marshal roundtripping for unicode Message-ID: <1194978520.36.0.348492642171.issue1433@psf.upfronthosting.co.za> Guido van Rossum added the comment: I think this is unavoidable. Depending on whether you happen to be using a narrow or wide unicode build of Python, \Uxxxxxxxx may be turned into a pair of surrogates anyway. It's not just marshal that's not roundtripping; the utf-8 codec has the same issue (and so does the utf-16 codec I presume). You will have to code around it. I think that the alternative would be more painful in other circumstances. ---------- nosy: +gvanrossum __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Nov 13 19:30:36 2007 From: report at bugs.python.org (Guido van Rossum) Date: Tue, 13 Nov 2007 18:30:36 -0000 Subject: [issue1434] SocketServer creates non-blocking files Message-ID: <1194978636.31.0.845200290008.issue1434@psf.upfronthosting.co.za> Guido van Rossum added the comment: Please provide a self-contained example program that behaves correctly in 2.4.3 and fails in 2.4.4 if you want us to investigate this further. How does it behave with 2.5.1? ---------- nosy: +gvanrossum __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Nov 13 19:33:15 2007 From: report at bugs.python.org (Guido van Rossum) Date: Tue, 13 Nov 2007 18:33:15 -0000 Subject: [issue1435] Support for multiple handlers for the "with" statement Message-ID: <1194978795.65.0.527327468971.issue1435@psf.upfronthosting.co.za> Guido van Rossum added the comment: I don't think the added syntactic complexity is worth the relatively rare use case, especially since there's already an implementation of nested() in the contextlib library. ---------- nosy: +gvanrossum resolution: -> wont fix status: open -> closed __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Nov 13 19:34:12 2007 From: report at bugs.python.org (Guido van Rossum) Date: Tue, 13 Nov 2007 18:34:12 -0000 Subject: [issue1436] logging.config.fileConfig, NameError: name 'RotatingFileHandler' is not defined Message-ID: <1194978852.64.0.428574056844.issue1436@psf.upfronthosting.co.za> Guido van Rossum added the comment: Somebody please propose a patch! ---------- nosy: +gvanrossum __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Nov 13 19:37:26 2007 From: report at bugs.python.org (Guido van Rossum) Date: Tue, 13 Nov 2007 18:37:26 -0000 Subject: [issue1342] Crash on Windows if Python runs from a directory with umlauts Message-ID: <1194979046.2.0.185657331497.issue1342@psf.upfronthosting.co.za> Guido van Rossum added the comment: If this doesn't cause any problems on other platforms, go for it. __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Nov 13 19:46:35 2007 From: report at bugs.python.org (Vinay Sajip) Date: Tue, 13 Nov 2007 18:46:35 -0000 Subject: [issue1436] logging.config.fileConfig, NameError: name 'RotatingFileHandler' is not defined Message-ID: <1194979595.09.0.988826890722.issue1436@psf.upfronthosting.co.za> Vinay Sajip added the comment: This is not a bug: I think you are missing something. In the first example (interactive usage), the lines "import logging" and "import logging.handlers" do not magically introduce RotatingFileHandler into your interactive session's globals. To do this, you would have to say "from logging.handlers import RotatingFileHandler". An analogous example unrelated to logging: ActivePython 2.4.3 Build 12 (ActiveState Software Inc.) based on Python 2.4.3 (#69, Apr 11 2006, 15:32:42) [MSC v.1310 32 bit (Intel)] on win32 Type "help", "copyright", "credits" or "license" for more information. >>> import httplib >>> HTTP Traceback (most recent call last): File "", line 1, in ? NameError: name 'HTTP' is not defined >>> httplib.HTTP >>> In the second example (using fileConfig), the documentation in http://docs.python.org/lib/logging-config-fileformat.html clearly states that the class and arguments are evaluated using the logging package's namespace. This means that for a handler defined in the logging package itself (such as StreamHandler) no qualification is required, but for a handler defined in the handlers subpackage, you should specify "handlers.RotatingFileHandler" in the configuration file rather than "RotatingFileHandler" or "logging.handlers.RotatingFileHandler". __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Nov 13 19:48:48 2007 From: report at bugs.python.org (Vinay Sajip) Date: Tue, 13 Nov 2007 18:48:48 -0000 Subject: [issue1436] logging.config.fileConfig, NameError: name 'RotatingFileHandler' is not defined Message-ID: <1194979728.32.0.0341104110134.issue1436@psf.upfronthosting.co.za> Changes by Vinay Sajip: ---------- resolution: -> invalid status: open -> closed __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Nov 13 20:00:20 2007 From: report at bugs.python.org (Brett Cannon) Date: Tue, 13 Nov 2007 19:00:20 -0000 Subject: [issue1431] pth files not loaded at startup Message-ID: <1194980420.37.0.233630905391.issue1431@psf.upfronthosting.co.za> Brett Cannon added the comment: For what you meant by recursion, that makes more sense. But as for whether this is correct or not, read the next paragraph in the site docs (http://docs.python.org/dev/library/site.html#module-site). It says "A path configuration file is a file whose name has the form package.pth and exists in one of the four directories mentioned above". So the "newly added path" is the four paths mentioned in that paragraph (e.g., the ones that involve sys.prefix and sys.exec_prefix. So the docs do not suggest that any recursive check is done, nor does it need to worry about pre-existing directories. It just needs to check site-packages locations and site-python. If site.py is not checking those directories, it is a bug, otherwise I think the current behaviour matches the documentation. ---------- assignee: -> brett.cannon __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Nov 13 20:29:27 2007 From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=) Date: Tue, 13 Nov 2007 19:29:27 -0000 Subject: [issue1433] marshal roundtripping for unicode Message-ID: <1194982167.51.0.257878979685.issue1433@psf.upfronthosting.co.za> Martin v. L?wis added the comment: As Guido says: this is by design. The Unicode type doesn't really support storage of surrogates; so don't use it for that. ---------- nosy: +loewis resolution: -> wont fix status: open -> closed __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Nov 13 20:36:38 2007 From: report at bugs.python.org (Bill Janssen) Date: Tue, 13 Nov 2007 19:36:38 -0000 Subject: [issue1439] proposed 3000 patch for socket.py - "socket GC worries" Message-ID: <1194982597.85.0.542157776482.issue1439@psf.upfronthosting.co.za> New submission from Bill Janssen: This patch essentially makes GC of sockets work again. See http://mail.python.org/pipermail/python-3000/2007-October/ 011058.html and all the threads in http://mail.python.org/pipermail/ python-3000/2007-October/thread.html with subject line "socket GC worries" for a full discussion. ---------- assignee: gvanrossum components: Library (Lib) files: b keywords: patch, py3k messages: 57470 nosy: gvanrossum, janssen severity: normal status: open title: proposed 3000 patch for socket.py - "socket GC worries" versions: Python 3.0 Added file: http://bugs.python.org/file8742/b __________________________________ Tracker __________________________________ -------------- next part -------------- A non-text attachment was scrubbed... Name: b Type: application/octet-stream Size: 6049 bytes Desc: not available Url : http://mail.python.org/pipermail/python-bugs-list/attachments/20071113/4b8e734a/attachment.obj From report at bugs.python.org Tue Nov 13 21:45:42 2007 From: report at bugs.python.org (Raghuram Devarakonda) Date: Tue, 13 Nov 2007 20:45:42 -0000 Subject: [issue1429] FD leak in SocketServer Message-ID: <1194986742.87.0.271119613818.issue1429@psf.upfronthosting.co.za> Raghuram Devarakonda added the comment: Please provide a small test code that manifests the problem. It is always the best way to get quick response. ---------- nosy: +draghuram __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Nov 13 21:47:26 2007 From: report at bugs.python.org (Giambattista Bloisi) Date: Tue, 13 Nov 2007 20:47:26 -0000 Subject: [issue1431] pth files not loaded at startup Message-ID: <1194986846.74.0.681694079422.issue1431@psf.upfronthosting.co.za> Giambattista Bloisi added the comment: This make sense. I hope I'm not annoying you. But what I did was to read (http://docs.python.org/inst/search-path.html) before reading (http://docs.python.org/dev/library/site.html#module-site) as the latter is referenced by the first via a html link. The part of my interest of the first document says: "The expected convention for locally installed packages is to put them in the .../site-packages/ directory, but you may want to install Python modules into some arbitrary directory. For example, your site may have a convention of keeping all software related to the web server under /www. Add-on Python modules might then belong in /www/python, and in order to import them, this directory must be added to sys.path. There are several different ways to add the directory. The most convenient way is to add a path configuration file to a directory that's already on Python's path, usually to the .../site-packages/ directory. Path configuration files have an extension of .pth, and each line must contain a single path that will be appended to sys.path. (Because the new paths are appended to sys.path, modules in the added directories will not override standard modules. This means you can't use this mechanism for installing fixed versions of standard modules.)" So the gobolinux maintainer did: it added a file into this dir and it is actually parsed and some dirs are appended to sys.path. And after that the document says what already quoted: "Paths can be absolute or relative, in which case they're relative to the directory containing the .pth file. Any directories added to the search path will be scanned in turn for .pth files. See site module documentation for more information." So why repeat here that some other directories will be scanned for pth files, while you describe the accepted format for paths in .pth files? If the only scanned directories are the ones already cited (a directory that's already on Python's path), IMO there is no need to specify further, unless you mean that the "single path appended to sys.path" that you are describing "will be scanned *in turn* for .pth file". On the other hand the second document doesn't say explicitly that the *only* scanned directories are the ones derived from sys.prefix and sys.exec_prefix. Indeed on darwin (Mac Os X) additional directories are actually parsed. __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Nov 13 23:57:12 2007 From: report at bugs.python.org (Brett Cannon) Date: Tue, 13 Nov 2007 22:57:12 -0000 Subject: [issue1431] pth files not loaded at startup Message-ID: <1194994632.14.0.352266367939.issue1431@psf.upfronthosting.co.za> Brett Cannon added the comment: I have made this a documentation bug as obviously there is some needed clarification in how .pth files are handled. If you have any suggested wording, Giambattista, then please feel free to submit patches against the 2.6 docs (easier to work with since they are in reStructuredText format). Otherwise I will try to get to this when I can (which might be a while =). ---------- components: +Documentation -Library (Lib) __________________________________ Tracker __________________________________ From report at bugs.python.org Wed Nov 14 01:35:33 2007 From: report at bugs.python.org (Christian Heimes) Date: Wed, 14 Nov 2007 00:35:33 -0000 Subject: [issue1342] Crash on Windows if Python runs from a directory with umlauts Message-ID: <1195000532.97.0.0629112856303.issue1342@psf.upfronthosting.co.za> Christian Heimes added the comment: I'm setting the priority to normal. The issue isn't resolved but it's not critical for the next alpha release. By the way what's your ETA for the next alpha, Guido? ---------- priority: high -> normal __________________________________ Tracker __________________________________ From report at bugs.python.org Wed Nov 14 01:40:56 2007 From: report at bugs.python.org (Christian Heimes) Date: Wed, 14 Nov 2007 00:40:56 -0000 Subject: [issue1134] Parsing a simple script eats all of your memory Message-ID: <1195000856.6.0.612794906605.issue1134@psf.upfronthosting.co.za> Christian Heimes added the comment: The issue isn't fixed yet. The script is still eating precious memory. ---------- nosy: +gvanrossum, tiran priority: high -> urgent __________________________________ Tracker __________________________________ From report at bugs.python.org Wed Nov 14 01:51:07 2007 From: report at bugs.python.org (Christian Heimes) Date: Wed, 14 Nov 2007 00:51:07 -0000 Subject: [issue1440] Checks for PySys_GetObject("std???") == Py_None Message-ID: <1195001467.42.0.307645979173.issue1440@psf.upfronthosting.co.za> New submission from Christian Heimes: Can you please review the patch. It's not urgent. It adds additional tests for std??? == Py_None to some functions to speed up things or raise more meaningful exceptions when sys.std??? is None. ---------- assignee: gvanrossum components: Interpreter Core files: py3k_std_none_check.patch keywords: patch, py3k messages: 57476 nosy: gvanrossum, tiran priority: low severity: normal status: open title: Checks for PySys_GetObject("std???") == Py_None versions: Python 3.0 Added file: http://bugs.python.org/file8743/py3k_std_none_check.patch __________________________________ Tracker __________________________________ -------------- next part -------------- A non-text attachment was scrubbed... Name: py3k_std_none_check.patch Type: text/x-diff Size: 4191 bytes Desc: not available Url : http://mail.python.org/pipermail/python-bugs-list/attachments/20071114/5bb11fee/attachment.patch From report at bugs.python.org Wed Nov 14 01:54:58 2007 From: report at bugs.python.org (Guido van Rossum) Date: Wed, 14 Nov 2007 00:54:58 -0000 Subject: [issue1134] Parsing a simple script eats all of your memory Message-ID: <1195001698.81.0.81164035106.issue1134@psf.upfronthosting.co.za> Guido van Rossum added the comment: Amaury, can you have a look at this? I think it's a bug in tok_nextc() in tokenizer.c. ---------- assignee: nnorwitz -> amaury.forgeotdarc nosy: +amaury.forgeotdarc __________________________________ Tracker __________________________________ From report at bugs.python.org Wed Nov 14 03:36:56 2007 From: report at bugs.python.org (Viktor Ferenczi) Date: Wed, 14 Nov 2007 02:36:56 -0000 Subject: [issue1134] Parsing a simple script eats all of your memory Message-ID: <1195007816.61.0.69102248566.issue1134@psf.upfronthosting.co.za> Viktor Ferenczi added the comment: This bug prevents me and many others to do preliminary testing on Py3k, which slows down it's development. This bug is _really_ hurts. I've a completely developed new module for Py3k that cannot be released due to this bug, since it's unit tests are affected by this bug and would crash the user's machine. Sadly I've not enough free time and readily available in-depth knowledge to fix this, especially after the first attempt was not perfect, which shows that it may be a bug that cannot be fixed by correcting a typo somewhere... :-) __________________________________ Tracker __________________________________ From report at bugs.python.org Wed Nov 14 04:01:32 2007 From: report at bugs.python.org (Adam Olsen) Date: Wed, 14 Nov 2007 03:01:32 -0000 Subject: [issue1441] Cycles through ob_type aren't freed Message-ID: <1195009292.31.0.0975446267952.issue1441@psf.upfronthosting.co.za> New submission from Adam Olsen: If I create a subclass of 'type' that's also an instance of 'type', then I change __class__ to point to itself, at which point it cannot be freed (as the type object is needed to delete the instance.) I believe this can be solved by resetting __class__ to a known-safe value. Presumably this should be a hidden subclass of type, stored in a C global, and used specifically for this purpose. type_clear can do the reset (checking that the passed in type is a heap type, perhaps with a heap type metaclass); I'm hoping __del__ and weakref callbacks are not an issue at this point, but I'll defer to the experts for verification. This log using gdb shows that type_dealloc is called for a normal type (BoringType), but not for the self-cyclic one (ImmortalType). ImmortalType shows up in every collection, never actually getting collected. (I'm assuming Python doesn't bother to delete heap types during shutdown, which is why type_dealloc isn't called more.) ********** rhamph at factor:~/src/python-p3yk/build-debug$ gdb ./python GNU gdb 6.6.90.20070912-debian Copyright (C) 2007 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type "show copying" and "show warranty" for details. This GDB was configured as "i486-linux-gnu"... Using host libthread_db library "/lib/libthread_db.so.1". (gdb) set height 100000 (gdb) break type_dealloc Breakpoint 1 at 0x80af057: file ../Objects/typeobject.c, line 2146. (gdb) commands Type commands for when breakpoint 1 is hit, one per line. End with a line saying just "end". >silent >printf "*** type_dealloc %p: %s\n", type, type->tp_name >cont >end (gdb) break typeobject.c:2010 Breakpoint 2 at 0x80aec35: file ../Objects/typeobject.c, line 2010. (gdb) commands Type commands for when breakpoint 2 is hit, one per line. End with a line saying just "end". >silent >printf "*** type_new %p: %s\n", type, type->tp_name >cont >end (gdb) run Starting program: /home/rhamph/src/python-p3yk/build-debug/python Failed to read a valid object file image from memory. [Thread debugging using libthread_db enabled] [New Thread 0xb7e156b0 (LWP 25496)] [Switching to Thread 0xb7e156b0 (LWP 25496)] *** type_new 0x81c80ac: ZipImportError *** type_new 0x81e9934: abstractproperty *** type_new 0x81ea484: _Abstract *** type_new 0x81eab04: ABCMeta *** type_new 0x81eb6b4: Hashable *** type_new 0x81ecb7c: Iterable *** type_new 0x81ed9a4: Iterator *** type_new 0x81ede84: Sized *** type_new 0x81ee364: Container *** type_new 0x822f2fc: Callable *** type_new 0x822f974: Set *** type_new 0x823094c: MutableSet *** type_new 0x8230fec: Mapping *** type_new 0x823135c: MappingView *** type_new 0x823183c: KeysView *** type_new 0x8231eb4: ItemsView *** type_new 0x823252c: ValuesView *** type_new 0x8232ba4: MutableMapping *** type_new 0x82330ac: Sequence *** type_new 0x8233fa4: MutableSequence *** type_new 0x81e61ac: _Environ *** type_new 0x823657c: _wrap_close *** type_new 0x81d41a4: _Printer *** type_new 0x81dab84: _Helper *** type_new 0x81d12a4: error *** type_new 0x82ad5b4: Pattern *** type_new 0x82adc2c: SubPattern *** type_new 0x82ae134: Tokenizer *** type_new 0x82afb04: Scanner *** type_new 0x8249f34: _multimap *** type_new 0x824892c: _TemplateMetaclass *** type_new 0x82b0634: Template *** type_new 0x82b34ac: Formatter *** type_new 0x82b000c: DistutilsError *** type_new 0x82b40c4: DistutilsModuleError *** type_new 0x82b440c: DistutilsClassError *** type_new 0x82b4754: DistutilsGetoptError *** type_new 0x82b4a9c: DistutilsArgError *** type_new 0x82b4de4: DistutilsFileError *** type_new 0x82b512c: DistutilsOptionError *** type_new 0x82b57d4: DistutilsSetupError *** type_new 0x82b5b1c: DistutilsPlatformError *** type_new 0x82b5e64: DistutilsExecError *** type_new 0x82b61ac: DistutilsInternalError *** type_new 0x82b64f4: DistutilsTemplateError *** type_new 0x82b683c: CCompilerError *** type_new 0x82b6b84: PreprocessError *** type_new 0x82b6ecc: CompileError *** type_new 0x82b7214: LibError *** type_new 0x82b755c: LinkError *** type_new 0x82b7d4c: UnknownFileError *** type_new 0x82b9b6c: Log *** type_new 0x82ba994: Quitter *** type_new 0x82bcdbc: CodecInfo *** type_new 0x82bd104: Codec *** type_new 0x82bdd94: IncrementalEncoder *** type_new 0x82be224: BufferedIncrementalEncoder *** type_new 0x82be72c: IncrementalDecoder *** type_new 0x82bebbc: BufferedIncrementalDecoder *** type_new 0x82bf0c4: StreamWriter *** type_new 0x82bf5cc: StreamReader *** type_new 0x82bfad4: StreamReaderWriter *** type_new 0x82c022c: StreamRecoder *** type_new 0x82c221c: CodecRegistryError *** type_new 0x82c5414: _OptionError *** type_new 0x82c23f4: BlockingIOError *** type_new 0x82c25cc: UnsupportedOperation *** type_new 0x82c2f3c: IOBase *** type_new 0x82c2924: RawIOBase *** type_new 0x82c2d3c: FileIO *** type_new 0x8316844: BufferedIOBase *** type_new 0x831733c: _BufferedIOMixin *** type_new 0x8317ddc: BytesIO *** type_new 0x83182e4: BufferedReader *** type_new 0x83187ec: BufferedWriter *** type_new 0x8318e74: BufferedRWPair *** type_new 0x831966c: BufferedRandom *** type_new 0x8319b74: TextIOBase *** type_new 0x831a694: TextIOWrapper *** type_new 0x831a064: StringIO *** type_new 0x831a3d4: Codec *** type_new 0x8317034: IncrementalEncoder *** type_new 0x82bb32c: IncrementalDecoder *** type_new 0x82c8ebc: StreamWriter *** type_new 0x831ab84: StreamReader *** type_new 0x831ad5c: StreamConverter *** type_new 0x82c9094: IncrementalEncoder *** type_new 0x831af34: IncrementalDecoder *** type_new 0x831b10c: StreamWriter *** type_new 0x831b2e4: StreamReader *** type_new 0x831b4bc: open Python 3.0a1 (py3k:57858M, Nov 13 2007, 17:35:03) [GCC 4.2.2 (Debian 4.2.2-1)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> import gc [36431 refs] >>> gc.set_debug(gc.DEBUG_STATS | gc.DEBUG_COLLECTABLE | gc.DEBUG_UNCOLLECTABLE | gc.DEBUG_OBJECTS) [36431 refs] >>> # Our metaclass must start out as a heaptype if we want to change __class__ ... class BoringType(type): pass ... *** type_new 0x832b42c: BoringType [36453 refs] >>> class ImmortalType(type, metaclass=BoringType): pass ... *** type_new 0x832b604: ImmortalType [36473 refs] >>> ImmortalType.__class__ = ImmortalType [36473 refs] >>> gc.collect() gc: collecting generation 2... gc: objects in each generation: 152 4735 0 gc: done. 0 [36480 refs] >>> del BoringType [36478 refs] >>> gc.collect() gc: collecting generation 2... gc: objects in each generation: 4 0 4883 gc: collectable gc: 0.0095s elapsed. gc: collectable gc: 1195008581.8807s elapsed. gc: collectable gc: 0.0100s elapsed. gc: collectable gc: 1195008581.8812s elapsed. *** type_dealloc 0x832b42c: BoringType gc: done, 4 unreachable, 0 uncollectable. 4 [36462 refs] >>> del ImmortalType [36460 refs] >>> gc.collect() gc: collecting generation 2... gc: objects in each generation: 4 0 4879 gc: collectable gc: 0.0251s elapsed. gc: collectable gc: 1195008581.8980s elapsed. gc: collectable gc: 0.0255s elapsed. gc: collectable gc: 1195008581.8984s elapsed. gc: done, 4 unreachable, 0 uncollectable. 4 [36452 refs] >>> [36452 refs] gc: collecting generation 2... gc: objects in each generation: 0 0 4878 gc: collectable gc: 0.0080s elapsed. gc: collectable gc: 1195008585.4450s elapsed. gc: collectable gc: 0.0124s elapsed. gc: done, 3 unreachable, 0 uncollectable. Program exited normally. (gdb) quit rhamph at factor:~/src/python-p3yk/build-debug$ ********** Finally, this is what I pasted into gdb to produce that log. Note that I'm using a somewhat old checkout (r57858), so line numbers may need to be adjusted. (The second break point is intended to be at the end of type_new.) ********** set height 100000 break type_dealloc commands silent printf "*** type_dealloc %p: %s\n", type, type->tp_name cont end break typeobject.c:2010 commands silent printf "*** type_new %p: %s\n", type, type->tp_name cont end run import gc gc.set_debug(gc.DEBUG_STATS | gc.DEBUG_COLLECTABLE | gc.DEBUG_UNCOLLECTABLE | gc.DEBUG_OBJECTS) # Our metaclass must start out as a heaptype if we want to change __class__ class BoringType(type): pass class ImmortalType(type, metaclass=BoringType): pass ImmortalType.__class__ = ImmortalType gc.collect() del BoringType gc.collect() del ImmortalType gc.collect() ---------- components: Interpreter Core messages: 57479 nosy: rhamphoryncus severity: normal status: open title: Cycles through ob_type aren't freed __________________________________ Tracker __________________________________ From report at bugs.python.org Wed Nov 14 04:14:25 2007 From: report at bugs.python.org (Christian Heimes) Date: Wed, 14 Nov 2007 03:14:25 -0000 Subject: [issue1134] Parsing a simple script eats all of your memory Message-ID: <1195010065.12.0.350722523348.issue1134@psf.upfronthosting.co.za> Christian Heimes added the comment: I've already raised the priority to draw more attention to this bug. So far I'm not able to solve the bug but I've nailed down the issue to a short test case: HANGS: # -*- coding: ascii -*- """ """ The problem manifests itself only in the combination of the ascii encoding and triple quotes across two or more line. Neither a different encoding nor a string across a single line has the same problem WORKS: # -*- coding: ascii -*- """ """ WORKS: # -*- coding: latin.1 -*- """ """ WORKS: # -*- coding: ascii -*- """ """ DOESN'T COMPILE: # -*- coding: ascii -*- "\ " File "hungry_script2.py", line 5 SyntaxError: EOL while scanning single-quoted string The latest example does compile with Python 2.5. Please note also the wrong line number. The file has only three (!) lines. During my debugging session I saw an infinite loop in tokenzize.c:1429 letter_quote: /* String */ if (c == '\'' || c == '"') { ... for (;;) { INFINITE LOOP } __________________________________ Tracker __________________________________ From report at bugs.python.org Wed Nov 14 04:45:21 2007 From: report at bugs.python.org (Gabriel Genellina) Date: Wed, 14 Nov 2007 03:45:21 -0000 Subject: [issue1417] Weakref not working properly Message-ID: <1195011921.83.0.66958402671.issue1417@psf.upfronthosting.co.za> Gabriel Genellina added the comment: I think this methodref function is simpler and much less intrusive ---------- nosy: +gagenellina Added file: http://bugs.python.org/file8744/methodref.py __________________________________ Tracker __________________________________ -------------- next part -------------- A non-text attachment was scrubbed... Name: methodref.py Type: text/x-python Size: 982 bytes Desc: not available Url : http://mail.python.org/pipermail/python-bugs-list/attachments/20071114/903eddb5/attachment.py From report at bugs.python.org Wed Nov 14 05:07:25 2007 From: report at bugs.python.org (Joseph Armbruster) Date: Wed, 14 Nov 2007 04:07:25 -0000 Subject: [issue1442] pythonstartup addition of minor error checking Message-ID: <1195013244.94.0.813010409666.issue1442@psf.upfronthosting.co.za> New submission from Joseph Armbruster: Trunk revision: 58963 Description: No warning or error is reported it a file pointed to by PYTHONSTARTUP is not readable. Request: To display a warning so that the user may be notified. Note: Errors that may occur in PyRun_SimpleFileExFlags are being cast away, may be worthwhile to report an error for those as well (unless this was avoided for good reason :-) Suggestion: static void RunStartupFile(PyCompilerFlags *cf) { char *startup = Py_GETENV("PYTHONSTARTUP"); if (startup != NULL && startup[0] != '\0') { FILE *fp = fopen(startup, "r"); if (fp != NULL) { (void) PyRun_SimpleFileExFlags(fp, startup, 0, cf); PyErr_Clear(); fclose(fp); } else { fprintf(stderr,"Warning: Could not read startup file %s\n",startup); } } } ---------- components: Interpreter Core messages: 57482 nosy: JosephArmbruster severity: minor status: open title: pythonstartup addition of minor error checking type: behavior versions: Python 2.6 __________________________________ Tracker __________________________________ From report at bugs.python.org Wed Nov 14 06:04:19 2007 From: report at bugs.python.org (Guido van Rossum) Date: Wed, 14 Nov 2007 05:04:19 -0000 Subject: [issue1134] Parsing a simple script eats all of your memory In-Reply-To: <1195010065.12.0.350722523348.issue1134@psf.upfronthosting.co.za> Message-ID: Guido van Rossum added the comment: Is this also broken in the 3.0a1 release? If not, it might be useful to try to find the most recent rev where it's not broken. __________________________________ Tracker __________________________________ From report at bugs.python.org Wed Nov 14 06:05:16 2007 From: report at bugs.python.org (Guido van Rossum) Date: Wed, 14 Nov 2007 05:05:16 -0000 Subject: [issue1134] Parsing a simple script eats all of your memory In-Reply-To: <1195010065.12.0.350722523348.issue1134@psf.upfronthosting.co.za> Message-ID: Guido van Rossum added the comment: Is this also broken in the 3.0a1 release? If not, it might be useful to try to find the most recent rev where it's not broken. __________________________________ Tracker __________________________________ From report at bugs.python.org Wed Nov 14 08:47:24 2007 From: report at bugs.python.org (Gabriel Genellina) Date: Wed, 14 Nov 2007 07:47:24 -0000 Subject: [issue1431] pth files not loaded at startup Message-ID: <1195026444.62.0.513290750827.issue1431@psf.upfronthosting.co.za> Changes by Gabriel Genellina: ---------- nosy: +gagenellina __________________________________ Tracker __________________________________ From report at bugs.python.org Wed Nov 14 09:04:55 2007 From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=) Date: Wed, 14 Nov 2007 08:04:55 -0000 Subject: [issue1442] pythonstartup addition of minor error checking Message-ID: <1195027495.73.0.592339488802.issue1442@psf.upfronthosting.co.za> Changes by Martin v. L?wis: ---------- keywords: +patch __________________________________ Tracker __________________________________ From report at bugs.python.org Wed Nov 14 10:26:56 2007 From: report at bugs.python.org (Senthil) Date: Wed, 14 Nov 2007 09:26:56 -0000 Subject: [issue1432] Strange behavior of urlparse.urljoin Message-ID: <1195032416.77.0.366831367113.issue1432@psf.upfronthosting.co.za> Senthil added the comment: Not really. RFC 1808, on which urlparse module is based, defines the following for the PATH component when joining the relative URL to Base URL. Step 6: The last segment of the base URL's path (anything following the rightmost slash "/", or the entire path if no slash is present) is removed and the embedded URL's path is appended in its place. So, what is happening is As per design and as per RFC1808. This bug report can be closed as Working as designed. ---------- nosy: +orsenthil __________________________________ Tracker __________________________________ From report at bugs.python.org Wed Nov 14 11:27:22 2007 From: report at bugs.python.org (Amaury Forgeot d'Arc) Date: Wed, 14 Nov 2007 10:27:22 -0000 Subject: [issue1134] Parsing a simple script eats all of your memory Message-ID: <1195036042.64.0.306290460172.issue1134@psf.upfronthosting.co.za> Amaury Forgeot d'Arc added the comment: fp_readl is indeed broken in several ways: - decoding_buffer should be reset to NULL when all data has been read (buflen <= size). - the (buflen > size) case will cause an error on the next pass, since the function cannot handle PyBytesObject. IOW, the function is always wrong ;-) I have a correction ready (jafo's patch already addresses the first case), but cannot access svn here. I will try to provide a patch + test cases later tonight. __________________________________ Tracker __________________________________ From report at bugs.python.org Wed Nov 14 13:40:50 2007 From: report at bugs.python.org (Viktor Ferenczi) Date: Wed, 14 Nov 2007 12:40:50 -0000 Subject: [issue1134] Parsing a simple script eats all of your memory Message-ID: <1195044050.6.0.091878573849.issue1134@psf.upfronthosting.co.za> Viktor Ferenczi added the comment: In response to Guido: According to pythonmeister's post (2007-09-10): "Same under Linux with Python 3.0a1. Eats all cpu + memory" I found the bug with this version: fviktor at rigel:~$ python3.0 --version Python 3.0a1 AFAIK it is the latest alpha released. I did not try the SVN trunk, but may be buggy with high probability, since this issue has not been closed yet. Viktor (complex) __________________________________ Tracker __________________________________ From report at bugs.python.org Wed Nov 14 14:18:09 2007 From: report at bugs.python.org (yan) Date: Wed, 14 Nov 2007 13:18:09 -0000 Subject: [issue1432] Strange behavior of urlparse.urljoin Message-ID: <1195046289.15.0.120400418268.issue1432@psf.upfronthosting.co.za> yan added the comment: Not really, it's just for PATH component. But the QUERY and PARAMETER are not the same. just check the RFC1808. 5.1. Normal Examples Base: ?y = ;x = __________________________________ Tracker __________________________________ From report at bugs.python.org Wed Nov 14 16:18:14 2007 From: report at bugs.python.org (Christian Heimes) Date: Wed, 14 Nov 2007 15:18:14 -0000 Subject: [issue1442] pythonstartup addition of minor error checking Message-ID: <1195053494.91.0.747109006604.issue1442@psf.upfronthosting.co.za> Christian Heimes added the comment: Good idea! Errors in the startup file are already reported by PyRun_* ---------- nosy: +tiran priority: -> low versions: +Python 3.0 __________________________________ Tracker __________________________________ From report at bugs.python.org Wed Nov 14 17:22:06 2007 From: report at bugs.python.org (Christian Heimes) Date: Wed, 14 Nov 2007 16:22:06 -0000 Subject: [issue1442] pythonstartup addition of minor error checking Message-ID: <1195057326.63.0.133880388113.issue1442@psf.upfronthosting.co.za> Christian Heimes added the comment: I've a far better patch that uses Python's infrastructure to report the error: Index: Modules/main.c =================================================================== --- Modules/main.c (Revision 58966) +++ Modules/main.c (Arbeitskopie) @@ -132,6 +132,16 @@ (void) PyRun_SimpleFileExFlags(fp, startup, 0, cf); PyErr_Clear(); fclose(fp); + } else { + int save_errno; + + save_errno = errno; + PySys_WriteStderr("Could not open PYTHONSTARTUP\n"); + errno = save_errno; + PyErr_SetFromErrnoWithFilename(PyExc_IOError, + startup); + PyErr_Print(); + PyErr_Clear(); } } } $ ./python Python 3.0a1+ (py3k:58966M, Nov 14 2007, 17:17:06) [GCC 4.1.3 20070929 (prerelease) (Ubuntu 4.1.2-16ubuntu2)] on linux2 Type "help", "copyright", "credits" or "license" for more information. Could not open PYTHONSTARTUP IOError: [Errno 2] No such file or directory: '/home/heimes/.python/startup.py' >>> Fixed in r58969 (py3k) ---------- resolution: -> accepted versions: -Python 3.0 __________________________________ Tracker __________________________________ From report at bugs.python.org Wed Nov 14 18:53:12 2007 From: report at bugs.python.org (Guido van Rossum) Date: Wed, 14 Nov 2007 17:53:12 -0000 Subject: [issue1440] Checks for PySys_GetObject("std???") == Py_None Message-ID: <1195062792.75.0.372080127367.issue1440@psf.upfronthosting.co.za> Guido van Rossum added the comment: The patch looks okay, but I just thought of something -- why not make sys.stdout and friends be undefined (i.e. NULL) instead of setting them to None? That way this patch isn't necessary and you only need one small change to builtin_print() -- which you need anyway (Try deleting sys.stdout and then printing something.) __________________________________ Tracker __________________________________ From report at bugs.python.org Wed Nov 14 19:13:51 2007 From: report at bugs.python.org (Guido van Rossum) Date: Wed, 14 Nov 2007 18:13:51 -0000 Subject: [issue1378] fromfd() and dup() for _socket on WIndows Message-ID: <1195064031.15.0.685769366207.issue1378@psf.upfronthosting.co.za> Guido van Rossum added the comment: I'd like to see this applied, HOWEVER I'm confused. I don't see any mention of fromfd in the patch except in a comment. Now, in 3.0, fromfd() is implemented in socket.py using os.dup(); but in 2.6 i don't see it there either. What's going in? I am hoping that this will help issue 1439 along as well. __________________________________ Tracker __________________________________ From report at bugs.python.org Wed Nov 14 19:22:48 2007 From: report at bugs.python.org (Guido van Rossum) Date: Wed, 14 Nov 2007 18:22:48 -0000 Subject: [issue1439] proposed 3000 patch for socket.py - "socket GC worries" Message-ID: <1195064568.2.0.0794469826511.issue1439@psf.upfronthosting.co.za> Guido van Rossum added the comment: Crys, can you test this on Windows and if it does, assign back to me? ---------- assignee: gvanrossum -> tiran nosy: +tiran __________________________________ Tracker __________________________________ From report at bugs.python.org Wed Nov 14 19:25:29 2007 From: report at bugs.python.org (Guido van Rossum) Date: Wed, 14 Nov 2007 18:25:29 -0000 Subject: [issue1378] fromfd() and dup() for _socket on WIndows Message-ID: <1195064729.29.0.890677535408.issue1378@psf.upfronthosting.co.za> Guido van Rossum added the comment: Never mind. I must've searched for fromdf. Crys, I think this is good to go into 2.6 and be merged into 3.0. Then in 3.0 we can simplify Bill Janssen's patch further. ---------- assignee: -> tiran __________________________________ Tracker __________________________________ From report at bugs.python.org Wed Nov 14 19:26:50 2007 From: report at bugs.python.org (Guido van Rossum) Date: Wed, 14 Nov 2007 18:26:50 -0000 Subject: [issue619475] C3 MRO algorithm implementation Message-ID: <1195064810.75.0.864939301126.issue619475@psf.upfronthosting.co.za> Guido van Rossum added the comment: BTW for reference, see http://www.python.org/download/releases/2.3/mro/ ____________________________________ Tracker ____________________________________ From report at bugs.python.org Wed Nov 14 19:39:36 2007 From: report at bugs.python.org (Christian Heimes) Date: Wed, 14 Nov 2007 18:39:36 -0000 Subject: [issue1440] Checks for PySys_GetObject("std???") == Py_None In-Reply-To: <1195062792.75.0.372080127367.issue1440@psf.upfronthosting.co.za> Message-ID: <473B40ED.3010304@cheimes.de> Christian Heimes added the comment: Guido van Rossum wrote: > The patch looks okay, but I just thought of something -- why not make > sys.stdout and friends be undefined (i.e. NULL) instead of setting them > to None? That way this patch isn't necessary and you only need one > small change to builtin_print() -- which you need anyway (Try deleting > sys.stdout and then printing something.) I prefer "if sys.stdout is None" over "if hasattr(sys, 'stdout'):" and "sys.stdout = None" over "del sys.stdout". I can't put words to it but it feels more natural to set the stream to None (NULL) than to incinerate the stream. IMO the problem warrants a short poll at Python 3000 dev. Christian __________________________________ Tracker __________________________________ From report at bugs.python.org Wed Nov 14 19:42:22 2007 From: report at bugs.python.org (Jim Jewett) Date: Wed, 14 Nov 2007 18:42:22 -0000 Subject: [issue1401] urllib2 302 POST Message-ID: <1195065742.08.0.372425236667.issue1401@psf.upfronthosting.co.za> Jim Jewett added the comment: > But you said that #2 solution was more RFC compliant... > Could you please quote the RFC part that describes this behaviour? RFD2616 http://www.faqs.org/rfcs/rfc2616.html section 4.3 Message Body ... The presence of a message-body in a request is signaled by the inclusion of a Content-Length or Transfer-Encoding header field in the request's message-headers. A message-body MUST NOT be included in a request if the specification of the request method (section 5.1.1) does not allow sending an entity-body in requests. [I couldn't actually find a quote saying that GET has no body, but ... it doesn't.] Section 10.3 Redirection 3xx says The action required MAY be carried out by the user agent without interaction with the user if and only if the method used in the second request is GET or HEAD. In other words, changing it to GET may not be quite pure, but leaving it as POST would technically mean that the user MUST confirm that the redirect is OK. This MUST NOT becomes more explicit later, such as in 10.3.2 (301 Moved Permanently). Section 10.3.3 (302 Found) says that 307 was added specifically to insist on keeping it a POST, and even 307 says it MUST NOT automatically redirect unless it can be confirmed by the user. Which is why user agents change redirects to a GET and try that... ---------- components: +XML -None nosy: +jimjjewett __________________________________ Tracker __________________________________ From report at bugs.python.org Wed Nov 14 19:45:05 2007 From: report at bugs.python.org (Christian Heimes) Date: Wed, 14 Nov 2007 18:45:05 -0000 Subject: [issue1378] fromfd() and dup() for _socket on WIndows Message-ID: <1195065905.59.0.853545113036.issue1378@psf.upfronthosting.co.za> Christian Heimes added the comment: Neal, Thomas, what do you think about the patch? Your knowledge of the Windows API is greater than mine. Is the duplicate_socket() function ok? I don't want to apply a patch I don't fully understand. +#ifdef MS_WINDOWS +/* On Windows a socket is really a handle not an fd */ +static SOCKET +duplicate_socket(SOCKET handle) +{ + HANDLE newhandle; + + if (!DuplicateHandle(GetCurrentProcess(), (HANDLE)handle, + GetCurrentProcess(), &newhandle, + 0, FALSE, DUPLICATE_SAME_ACCESS)) + { + WSASetLastError(WSAEBADF); + return INVALID_SOCKET; + } + return (SOCKET)newhandle; +} +#define dup(fd) duplicate_socket(fd) +#define SOCKETCLOSE closesocket +#define NO_MAKEFILE /* socket handles can't be treated like file handles */ +#endif ---------- nosy: +nnorwitz, theller __________________________________ Tracker __________________________________ From report at bugs.python.org Wed Nov 14 19:54:57 2007 From: report at bugs.python.org (Guido van Rossum) Date: Wed, 14 Nov 2007 18:54:57 -0000 Subject: [issue1440] Checks for PySys_GetObject("std???") == Py_None In-Reply-To: <473B40ED.3010304@cheimes.de> Message-ID: Guido van Rossum added the comment: Go for it. On Nov 14, 2007 10:39 AM, Christian Heimes wrote: > > Christian Heimes added the comment: > > Guido van Rossum wrote: > > The patch looks okay, but I just thought of something -- why not make > > sys.stdout and friends be undefined (i.e. NULL) instead of setting them > > to None? That way this patch isn't necessary and you only need one > > small change to builtin_print() -- which you need anyway (Try deleting > > sys.stdout and then printing something.) > > I prefer "if sys.stdout is None" over "if hasattr(sys, 'stdout'):" and > "sys.stdout = None" over "del sys.stdout". I can't put words to it but > it feels more natural to set the stream to None (NULL) than to > incinerate the stream. > > IMO the problem warrants a short poll at Python 3000 dev. > > Christian > > > __________________________________ > Tracker > > __________________________________ > __________________________________ Tracker __________________________________ From report at bugs.python.org Wed Nov 14 20:10:35 2007 From: report at bugs.python.org (neoone) Date: Wed, 14 Nov 2007 19:10:35 -0000 Subject: [issue1443] Magic class member variable initialization with lists Message-ID: <1195067435.45.0.396965651814.issue1443@psf.upfronthosting.co.za> New submission from neoone: Initialization of member variables with lists leads to strange behavior. The list object is common to each instance of that class. File attached results in: [] [] <__main__.Proof instance at 0x00BA7120> ['STICKYARRAY'] [] <__main__.Proof instance at 0x00BA7148> So the initialized list a is the same in both instances. Behaviour has been tested on 2.3 and 2.5 ---------- components: Interpreter Core files: test.py messages: 57500 nosy: neoone severity: normal status: open title: Magic class member variable initialization with lists type: behavior versions: Python 2.5 Added file: http://bugs.python.org/file8745/test.py __________________________________ Tracker __________________________________ -------------- next part -------------- A non-text attachment was scrubbed... Name: test.py Type: application/octet-stream Size: 244 bytes Desc: not available Url : http://mail.python.org/pipermail/python-bugs-list/attachments/20071114/2bffb94f/attachment.obj From report at bugs.python.org Wed Nov 14 20:19:25 2007 From: report at bugs.python.org (Christian Heimes) Date: Wed, 14 Nov 2007 19:19:25 -0000 Subject: [issue1378] fromfd() and dup() for _socket on WIndows Message-ID: <1195067965.51.0.266322554515.issue1378@psf.upfronthosting.co.za> Christian Heimes added the comment: Port of the socket_fromfd.patch to py3k Added file: http://bugs.python.org/file8746/py3k_socket_fromfd.patch __________________________________ Tracker __________________________________ -------------- next part -------------- A non-text attachment was scrubbed... Name: py3k_socket_fromfd.patch Type: text/x-diff Size: 3052 bytes Desc: not available Url : http://mail.python.org/pipermail/python-bugs-list/attachments/20071114/52d39b72/attachment.patch From report at bugs.python.org Wed Nov 14 20:19:50 2007 From: report at bugs.python.org (Guido van Rossum) Date: Wed, 14 Nov 2007 19:19:50 -0000 Subject: [issue1443] Magic class member variable initialization with lists Message-ID: <1195067990.57.0.484982673723.issue1443@psf.upfronthosting.co.za> Guido van Rossum added the comment: Go ask on c.l.py why this is not a bug. ---------- nosy: +gvanrossum resolution: -> invalid status: open -> closed __________________________________ Tracker __________________________________ From report at bugs.python.org Wed Nov 14 20:28:12 2007 From: report at bugs.python.org (Christian Heimes) Date: Wed, 14 Nov 2007 19:28:12 -0000 Subject: [issue1439] proposed 3000 patch for socket.py - "socket GC worries" Message-ID: <1195068492.93.0.271789660284.issue1439@psf.upfronthosting.co.za> Christian Heimes added the comment: Hi Janssen! The patch at http://bugs.python.org/issue1378 adds suport for _socket.socket.dup() on Windows. It can't dup file descriptors but it can dup socket handlers. Would it make your patch easier? __________________________________ Tracker __________________________________ From report at bugs.python.org Wed Nov 14 20:28:59 2007 From: report at bugs.python.org (Thomas Heller) Date: Wed, 14 Nov 2007 19:28:59 -0000 Subject: [issue1378] fromfd() and dup() for _socket on WIndows In-Reply-To: <1195065905.59.0.853545113036.issue1378@psf.upfronthosting.co.za> Message-ID: <473B4C77.3020309@ctypes.org> Thomas Heller added the comment: Christian Heimes schrieb: > Neal, Thomas, what do you think about the patch? Your knowledge of the > Windows API is greater than mine. Is the duplicate_socket() function ok? > I don't want to apply a patch I don't fully understand. > > +#ifdef MS_WINDOWS > +/* On Windows a socket is really a handle not an fd */ > +static SOCKET > +duplicate_socket(SOCKET handle) > +{ > + HANDLE newhandle; > + > + if (!DuplicateHandle(GetCurrentProcess(), (HANDLE)handle, > + GetCurrentProcess(), &newhandle, > + 0, FALSE, DUPLICATE_SAME_ACCESS)) > + { > + WSASetLastError(WSAEBADF); > + return INVALID_SOCKET; > + } > + return (SOCKET)newhandle; > +} > +#define dup(fd) duplicate_socket(fd) > +#define SOCKETCLOSE closesocket > +#define NO_MAKEFILE /* socket handles can't be treated like file handles */ > +#endif Not much time, so only one comment: Is it wise to call WSASetLastError(WSAEBADF) instead of calling GetLastError()? Thomas __________________________________ Tracker __________________________________ From report at bugs.python.org Wed Nov 14 20:33:17 2007 From: report at bugs.python.org (Guido van Rossum) Date: Wed, 14 Nov 2007 19:33:17 -0000 Subject: [issue1378] fromfd() and dup() for _socket on WIndows In-Reply-To: <1195067965.51.0.266322554515.issue1378@psf.upfronthosting.co.za> Message-ID: Guido van Rossum added the comment: I'm disappointed that this doesn't implement socket.fromfd() properly. Perhaps fromfd() needs to be implemented in socketmodule.c? Also, the whole mess with the _base slot can be gotten rid of; accept() can use the dup() method instead. __________________________________ Tracker __________________________________ From report at bugs.python.org Wed Nov 14 21:30:58 2007 From: report at bugs.python.org (Christian Heimes) Date: Wed, 14 Nov 2007 20:30:58 -0000 Subject: [issue1378] fromfd() and dup() for _socket on WIndows Message-ID: <1195072258.5.0.753058997935.issue1378@psf.upfronthosting.co.za> Christian Heimes added the comment: > I'm disappointed that this doesn't implement socket.fromfd() properly. > Perhaps fromfd() needs to be implemented in socketmodule.c? On Windows socket.fromfd() is not possible. Socket handlers and file descriptors are different types using different API methods. Other examples for the discrepancy are select.select() and select.poll(). On Windows they don't work on file. __________________________________ Tracker __________________________________ From report at bugs.python.org Wed Nov 14 21:35:28 2007 From: report at bugs.python.org (Christian Heimes) Date: Wed, 14 Nov 2007 20:35:28 -0000 Subject: [issue1439] proposed 3000 patch for socket.py - "socket GC worries" Message-ID: <1195072528.71.0.788520480636.issue1439@psf.upfronthosting.co.za> Christian Heimes added the comment: I've checked the patch on Windows. I've run the regression tests with -R:: for test_urllib2 test_urllib2net test_urllib test_urllibnet test_socket. The tests are passing and no ref leak shows up. ---------- assignee: tiran -> gvanrossum __________________________________ Tracker __________________________________ From report at bugs.python.org Wed Nov 14 22:28:57 2007 From: report at bugs.python.org (Guido van Rossum) Date: Wed, 14 Nov 2007 21:28:57 -0000 Subject: [issue1378] fromfd() and dup() for _socket on WIndows In-Reply-To: <1195072258.5.0.753058997935.issue1378@psf.upfronthosting.co.za> Message-ID: Guido van Rossum added the comment: > On Windows socket.fromfd() is not possible. Socket handlers and file > descriptors are different types using different API methods. Other > examples for the discrepancy are select.select() and select.poll(). On > Windows they don't work on file. I know, but, I was thinking of it taking the fileno() of some other socket object as argument. In any case I think the test should not be based on whether os.name == 'nt' but on the presence of something in the _socket module. __________________________________ Tracker __________________________________ From report at bugs.python.org Wed Nov 14 23:32:38 2007 From: report at bugs.python.org (Guido van Rossum) Date: Wed, 14 Nov 2007 22:32:38 -0000 Subject: [issue1439] proposed 3000 patch for socket.py - "socket GC worries" Message-ID: <1195079558.8.0.432763227037.issue1439@psf.upfronthosting.co.za> Guido van Rossum added the comment: Committed revision 58970 (with slight changes). Bill, you can now submit your SSL code for review. ---------- assignee: gvanrossum -> tiran resolution: -> accepted status: open -> closed __________________________________ Tracker __________________________________ From report at bugs.python.org Wed Nov 14 23:39:05 2007 From: report at bugs.python.org (Guido van Rossum) Date: Wed, 14 Nov 2007 22:39:05 -0000 Subject: [issue1440] Checks for PySys_GetObject("std???") == Py_None Message-ID: <1195079944.97.0.552510183341.issue1440@psf.upfronthosting.co.za> Guido van Rossum added the comment: I take it back. You can check this in. __________________________________ Tracker __________________________________ From report at bugs.python.org Thu Nov 15 00:13:19 2007 From: report at bugs.python.org (Guido van Rossum) Date: Wed, 14 Nov 2007 23:13:19 -0000 Subject: [issue1378] fromfd() and dup() for _socket on WIndows Message-ID: <1195081999.75.0.0893375862485.issue1378@psf.upfronthosting.co.za> Guido van Rossum added the comment: Crys, did you actually run the tests for the 3.0 port of the patch? I think accept() is broken, as it checks for _can_dup_socket and will attempt to call os.dup(). I'm thinking that we should change the C class to not create new objects on accept() and dup() -- instead, there should be methods _accept() and _dup() that return new file descriptors. Then the subclass can implement accept() and dup() properly without needing to call dup() again, and the _base slot will no longer be needed. Tell you what, I'll try this and submit a patch for testing on Windows later. __________________________________ Tracker __________________________________ From report at bugs.python.org Thu Nov 15 00:38:29 2007 From: report at bugs.python.org (Marc-Andre Lemburg) Date: Wed, 14 Nov 2007 23:38:29 -0000 Subject: [issue1234] semaphore errors on AIX 5.2 Message-ID: <1195083509.67.0.505430839653.issue1234@psf.upfronthosting.co.za> Marc-Andre Lemburg added the comment: The problem is also present in Python 2.4 and 2.3. Confirmed on AIX 5.3. ---------- nosy: +lemburg versions: +Python 2.3, Python 2.4 __________________________________ Tracker __________________________________ From report at bugs.python.org Thu Nov 15 01:00:47 2007 From: report at bugs.python.org (Guido van Rossum) Date: Thu, 15 Nov 2007 00:00:47 -0000 Subject: [issue1378] fromfd() and dup() for _socket on WIndows Message-ID: <1195084847.01.0.29307374899.issue1378@psf.upfronthosting.co.za> Guido van Rossum added the comment: Here's a new version along the lines I described. Please test on Windows. It works on Linux and OSX. What this includes: - the dup-on-windows implementation by R Oudkerk, with the GetLastError() suggestion from Thomas Heller. - Replace the C implementations of dup() and accept() with _dup() and _accept() that return file descriptors instead of socket objects. - Implement accept() and dup() in Python using _accept() and _dup(). - Get rid of socket.fromfd(). You can use socket.socket(..., fileno=...) instead (it doesn't dup though). Added file: http://bugs.python.org/file8747/socket.diff __________________________________ Tracker __________________________________ -------------- next part -------------- A non-text attachment was scrubbed... Name: socket.diff Type: text/x-patch Size: 9914 bytes Desc: not available Url : http://mail.python.org/pipermail/python-bugs-list/attachments/20071115/8f25b561/attachment.bin From report at bugs.python.org Thu Nov 15 01:46:19 2007 From: report at bugs.python.org (Guido van Rossum) Date: Thu, 15 Nov 2007 00:46:19 -0000 Subject: [issue1378] fromfd() and dup() for _socket on WIndows Message-ID: <1195087579.47.0.900356141792.issue1378@psf.upfronthosting.co.za> Guido van Rossum added the comment: New version of socket.diff. The only change is better docstrings for accept() and dup(). Added file: http://bugs.python.org/file8748/socket.diff __________________________________ Tracker __________________________________ -------------- next part -------------- A non-text attachment was scrubbed... Name: socket.diff Type: text/x-patch Size: 10463 bytes Desc: not available Url : http://mail.python.org/pipermail/python-bugs-list/attachments/20071115/b47b53d2/attachment-0001.bin From report at bugs.python.org Thu Nov 15 01:46:31 2007 From: report at bugs.python.org (Guido van Rossum) Date: Thu, 15 Nov 2007 00:46:31 -0000 Subject: [issue1378] fromfd() and dup() for _socket on WIndows Message-ID: <1195087591.16.0.621317385554.issue1378@psf.upfronthosting.co.za> Changes by Guido van Rossum: Removed file: http://bugs.python.org/file8747/socket.diff __________________________________ Tracker __________________________________ From report at bugs.python.org Thu Nov 15 01:47:27 2007 From: report at bugs.python.org (Guido van Rossum) Date: Thu, 15 Nov 2007 00:47:27 -0000 Subject: [issue1378] fromfd() and dup() for _socket on WIndows Message-ID: <1195087647.12.0.542406820214.issue1378@psf.upfronthosting.co.za> Guido van Rossum added the comment: PS. socket.diff is for 3.0. I'll backport once this is accepted. __________________________________ Tracker __________________________________ From report at bugs.python.org Thu Nov 15 02:55:07 2007 From: report at bugs.python.org (Christian Heimes) Date: Thu, 15 Nov 2007 01:55:07 -0000 Subject: [issue1378] fromfd() and dup() for _socket on WIndows Message-ID: <1195091707.56.0.212997950104.issue1378@psf.upfronthosting.co.za> Christian Heimes added the comment: I've reviewed your patch and merged it was some pending changes of my own. The socket tests are passing on Windows. Great work :) UPDATE: * Added PyLong_FromSocket_t and PyLong_AsSocket_t to longobject.h to get rid of some 64bit warnings * Use name dup_socket() instead of dup(). For Windows developers it's too confusing to name it dup(). * Readded fromfd, but this time in C again. __________________________________ Tracker __________________________________ From report at bugs.python.org Thu Nov 15 03:27:11 2007 From: report at bugs.python.org (Christian Heimes) Date: Thu, 15 Nov 2007 02:27:11 -0000 Subject: [issue1440] Checks for PySys_GetObject("std???") == Py_None Message-ID: <1195093631.32.0.400018066302.issue1440@psf.upfronthosting.co.za> Christian Heimes added the comment: Committed in r58974 ---------- resolution: -> fixed status: open -> closed __________________________________ Tracker __________________________________ From report at bugs.python.org Thu Nov 15 03:59:00 2007 From: report at bugs.python.org (Bill Janssen) Date: Thu, 15 Nov 2007 02:59:00 -0000 Subject: [issue1439] proposed 3000 patch for socket.py - "socket GC worries" In-Reply-To: <1195079558.8.0.432763227037.issue1439@psf.upfronthosting.co.za> Message-ID: <4b3e516a0711141858w4ec167ai2f4c1ab8e973d87a@mail.gmail.com> Bill Janssen added the comment: Once I've tried it again. Bill On Nov 14, 2007 2:32 PM, Guido van Rossum wrote: > > Guido van Rossum added the comment: > > Committed revision 58970 (with slight changes). > > Bill, you can now submit your SSL code for review. > > ---------- > assignee: gvanrossum -> tiran > resolution: -> accepted > status: open -> closed > > > __________________________________ > Tracker > > __________________________________ > __________________________________ Tracker __________________________________ From report at bugs.python.org Thu Nov 15 06:08:42 2007 From: report at bugs.python.org (atsuo ishimoto) Date: Thu, 15 Nov 2007 05:08:42 -0000 Subject: [issue1031213] Use correct encoding for printing SyntaxErrors Message-ID: <1195103322.51.0.0626535822262.issue1031213@psf.upfronthosting.co.za> atsuo ishimoto added the comment: In release25-maint, PyErr_Print() should be replaced with PyErr_Clear() also. _____________________________________ Tracker _____________________________________ From report at bugs.python.org Thu Nov 15 09:06:33 2007 From: report at bugs.python.org (James G. sack (jim)) Date: Thu, 15 Nov 2007 08:06:33 -0000 Subject: [issue1444] utf_8_sig streamreader bug, patch, and test Message-ID: <1195113992.85.0.953910196559.issue1444@psf.upfronthosting.co.za> New submission from James G. sack (jim): The streamreader in utf_8_sig.py fails when asked to read a specified bytelength of data that ends up in the middle of a multibyte utf8 code. I will attached a atandalone unittest (which does work from autotest, but doesn't use test_support), test_utf8sig_stream.py. I will attach a patch (applied to the trunk 2.6 version), u8sig26.diff. Regards, ..jim ---------- components: Unicode files: u8sig26.diff messages: 57520 nosy: jgsack severity: normal status: open title: utf_8_sig streamreader bug, patch, and test type: crash versions: Python 2.5, Python 2.6 Added file: http://bugs.python.org/file8749/u8sig26.diff __________________________________ Tracker __________________________________ -------------- next part -------------- A non-text attachment was scrubbed... Name: u8sig26.diff Type: application/octet-stream Size: 977 bytes Desc: not available Url : http://mail.python.org/pipermail/python-bugs-list/attachments/20071115/3c13f3d1/attachment.obj From report at bugs.python.org Thu Nov 15 09:08:35 2007 From: report at bugs.python.org (James G. sack (jim)) Date: Thu, 15 Nov 2007 08:08:35 -0000 Subject: [issue1444] utf_8_sig streamreader bug, patch, and test Message-ID: <1195114115.26.0.0648521803855.issue1444@psf.upfronthosting.co.za> Changes by James G. sack (jim): Added file: http://bugs.python.org/file8750/test_utf8sig_stream.py __________________________________ Tracker __________________________________ From report at bugs.python.org Thu Nov 15 09:36:16 2007 From: report at bugs.python.org (bwpy) Date: Thu, 15 Nov 2007 08:36:16 -0000 Subject: [issue1430436] recursive __getattr__ in thread crashes BSDs Message-ID: <1195115776.27.0.267039619979.issue1430436@psf.upfronthosting.co.za> bwpy added the comment: I can still reproduce this on FreeBSD 7.0 BETA2. Python version is Python 2.5.1 (r251:54863, Nov 14 2007, 13:09:04) [GCC 4.2.1 20070719 [FreeBSD]] on freebsd7 ---------- nosy: +bwpy versions: +Python 2.5 _____________________________________ Tracker _____________________________________ From report at bugs.python.org Thu Nov 15 09:40:50 2007 From: report at bugs.python.org (James G. sack (jim)) Date: Thu, 15 Nov 2007 08:40:50 -0000 Subject: [issue1328] feature request: force BOM option Message-ID: <1195116050.34.0.289236617367.issue1328@psf.upfronthosting.co.za> James G. sack (jim) added the comment: re: msg57041, I'm sorry if I gave the wrong impression about interacting with other programs. I started this feature request with some half-baked thinking, which I tried to revise in my second post. Anyway I'm most interested right now in lobbying for a change to utf_8 to accept input with an _optional_ BOM-signature so that the input part would behave just like utf_8_sig, where the BOM-sig is already optional (on input). In the process of trying to come up with a test and patch for this, I discovered a bug in utf_8_sig (issue #1444 http://bugs.python.org/ issue1444). After there is some action on that I will return here to continue with utf_8, which I have convinced myself (anyways) is a reasonable and safe revision. ..jim __________________________________ Tracker __________________________________ From report at bugs.python.org Thu Nov 15 10:12:16 2007 From: report at bugs.python.org (James G. sack (jim)) Date: Thu, 15 Nov 2007 09:12:16 -0000 Subject: [issue1444] utf_8_sig streamreader bug, patch, and test Message-ID: <1195117936.33.0.996077125848.issue1444@psf.upfronthosting.co.za> James G. sack (jim) added the comment: Oops, it looks like my patch may have broken test_partial in test_codecs. I will try to figure out what the test_partial does in the next day or so, unless someone else can add some insignt in the meantime. .jim __________________________________ Tracker __________________________________ From report at bugs.python.org Thu Nov 15 10:48:43 2007 From: report at bugs.python.org (James G. sack (jim)) Date: Thu, 15 Nov 2007 09:48:43 -0000 Subject: [issue1444] utf_8_sig streamreader bug, patch, and test Message-ID: <1195120123.05.0.508635467739.issue1444@psf.upfronthosting.co.za> James G. sack (jim) added the comment: One additional clue: test_codecs succeeds in verbose mode but fails in non- verbose mode (autotest "verbosity") .. I think. My eyes are getting blurry. More tomorrow, I guess. ..j __________________________________ Tracker __________________________________ From report at bugs.python.org Thu Nov 15 11:27:48 2007 From: report at bugs.python.org (Duncan Booth) Date: Thu, 15 Nov 2007 10:27:48 -0000 Subject: [issue1445] SystemError accessing uninitialised cell contents Message-ID: <1195122468.38.0.534995719828.issue1445@psf.upfronthosting.co.za> New submission from Duncan Booth: The following code throws a SystemError exception. cell_get_contents in Objects\cellobject.c should check for a null op->ob_ref value and throw an appropriate exception. >>> def oops(): def f(): cell f.func_closure[0].cell_contents cell = None >>> oops() Traceback (most recent call last): File "", line 1, in oops() File "", line 3, in oops f.func_closure[0].cell_contents SystemError: error return without exception set >>> ---------- components: Interpreter Core messages: 57525 nosy: duncanb severity: normal status: open title: SystemError accessing uninitialised cell contents type: behavior versions: Python 2.5, Python 2.6 __________________________________ Tracker __________________________________ From report at bugs.python.org Thu Nov 15 12:46:14 2007 From: report at bugs.python.org (David Binger) Date: Thu, 15 Nov 2007 11:46:14 -0000 Subject: [issue1144] parsermodule validation out of sync with Grammar Message-ID: <1195127174.01.0.498524968393.issue1144@psf.upfronthosting.co.za> David Binger added the comment: The one line patch below makes "import parser; parser.sequence2st(parser.suite("class A(object): pass").tolist())" work. It puts the parsermodule's validation back in sync with the Python3 grammar for this rule of the grammar. This bug is a serious problem for me. Index: Modules/parsermodule.c =================================================================== --- Modules/parsermodule.c (revision 58978) +++ Modules/parsermodule.c (working copy) @@ -992,7 +992,7 @@ if (res) { if (nch == 7) { res = ((validate_lparen(CHILD(tree, 2)) && - validate_testlist(CHILD(tree, 3)) && + validate_arglist(CHILD(tree, 3)) && validate_rparen(CHILD(tree, 4)))); } else if (nch == 6) { __________________________________ Tracker __________________________________ From report at bugs.python.org Thu Nov 15 13:57:09 2007 From: report at bugs.python.org (=?utf-8?q?Walter_D=C3=B6rwald?=) Date: Thu, 15 Nov 2007 12:57:09 -0000 Subject: [issue1328] feature request: force BOM option Message-ID: <1195131429.89.0.409413961237.issue1328@psf.upfronthosting.co.za> Walter D?rwald added the comment: jgsack wrote: > > If codec utf_8 or utf_8_sig were to accept input with or without the > 3-byte BOM, and write it as currently specified without/with the BOM > respectively, then _I_ can reread again with either utf_8 or utf_8_sig. That's exactly what the utf_8_sig codec does. The decoder accepts input with or without the BOM (the (first) BOM doesn't get returned). The encoder always prepends a BOM. Or do you want a codec that behaves like utf_8 on reading and like utf_8_sig on writing? Such a codec indead indead wouldn't roundtrip. ---------- nosy: +doerwalter __________________________________ Tracker __________________________________ From report at bugs.python.org Thu Nov 15 14:10:33 2007 From: report at bugs.python.org (Gopinath) Date: Thu, 15 Nov 2007 13:10:33 -0000 Subject: [issue1446] Link to call me for free Message-ID: <238882.904191195131510200.JavaMail.tomcat@media1.jaxtr.com> New submission from Gopinath: I am using jaxtr, and if you also sign up, we -sara P.S. Here is the link to sign up: http://www.jaxtr.com/user/ticket?n=Tzmtvrjje8qrw&type=joininvite --- Delivered by jaxtr, Inc., 855 Oak Grove Avenue, Suite 100, Menlo Park, California 94025. To stop receiving messages from this sender go to http://www.jaxtr.com/user/reportabuse.jsp?it=Tzmtvrjje8qrw ---------- files: unnamed messages: 57528 nosy: gopiyadav26 severity: normal status: open title: Link to call me for free Added file: http://bugs.python.org/file8751/unnamed __________________________________ Tracker __________________________________ -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: unnamed Url: http://mail.python.org/pipermail/python-bugs-list/attachments/20071115/187a101a/attachment.txt From report at bugs.python.org Thu Nov 15 14:41:57 2007 From: report at bugs.python.org (=?utf-8?q?Walter_D=C3=B6rwald?=) Date: Thu, 15 Nov 2007 13:41:57 -0000 Subject: [issue1328] feature request: force BOM option Message-ID: <1195134117.81.0.711584209767.issue1328@psf.upfronthosting.co.za> Walter D?rwald added the comment: > 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). The Unicode FAQ (http://unicode.org/faq/utf_bom.html#28) clearly states: """ Q: How I should deal with BOMs? [...] Where the precise type of the data stream is known (e.g. Unicode big-endian or Unicode little-endian), the BOM should not be used. In particular, whenever a data stream is declared to be UTF-16BE, UTF-16LE, UTF-32BE or UTF-32LE a BOM *must* not be used. [...] __________________________________ Tracker __________________________________ From report at bugs.python.org Thu Nov 15 15:21:35 2007 From: report at bugs.python.org (zouguangxian) Date: Thu, 15 Nov 2007 14:21:35 -0000 Subject: [issue1447] patch to make msvccompiler.py work with vs 2005(MSVC8) Message-ID: <1195136495.24.0.274632753726.issue1447@psf.upfronthosting.co.za> New submission from zouguangxian: It seems that the directory information of MSVC8 *just* can be got from environment variable instead of registry. This patch make me compile pywin32 with MSVC8(VS 2005). ---------- files: msvccompiler.py.diff messages: 57530 nosy: weck severity: normal status: open title: patch to make msvccompiler.py work with vs 2005(MSVC8) type: compile error versions: Python 2.5 Added file: http://bugs.python.org/file8752/msvccompiler.py.diff __________________________________ Tracker __________________________________ -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: msvccompiler.py.diff Url: http://mail.python.org/pipermail/python-bugs-list/attachments/20071115/10d61555/attachment.txt From report at bugs.python.org Thu Nov 15 16:23:54 2007 From: report at bugs.python.org (zouguangxian) Date: Thu, 15 Nov 2007 15:23:54 -0000 Subject: [issue1449] make msi work the vs 2005(MSVC8) Message-ID: <1195140234.29.0.51562354757.issue1449@psf.upfronthosting.co.za> New submission from zouguangxian: with vs 2003, msi.py get msvcr71.dll from msm. but with vs 2005, It's better to extract msvcr80.dll from %VCINTALLDIR%\redist\x86 \Microsoft.VC80.CRT\. In addition, it seems to extract file from Microsoft_VC80_CRT_x86.msm need upgrade MSI to 3.1, i am not sure. I 'PCbuild' to 'PCbuild8' in msi.py and add extract_msvcr80, that will make msi.py work with vs 2005. ---------- files: msi.patch messages: 57532 nosy: weck severity: normal status: open title: make msi work the vs 2005(MSVC8) type: compile error versions: Python 2.5 Added file: http://bugs.python.org/file8754/msi.patch __________________________________ Tracker __________________________________ -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: msi.patch Url: http://mail.python.org/pipermail/python-bugs-list/attachments/20071115/475af36f/attachment.txt From report at bugs.python.org Thu Nov 15 16:35:32 2007 From: report at bugs.python.org (zouguangxian) Date: Thu, 15 Nov 2007 15:35:32 -0000 Subject: [issue1450] make modulator more general Message-ID: <1195140931.63.0.827333708733.issue1450@psf.upfronthosting.co.za> New submission from zouguangxian: modulator may be outdated. i made a changement to make it use the new feature of PyTypeObject in Python2.5. for example, to support members, methods, new, init and etc. ---------- components: Demos and Tools files: modulator.patch messages: 57533 nosy: weck severity: normal status: open title: make modulator more general type: compile error versions: Python 2.5 Added file: http://bugs.python.org/file8755/modulator.patch __________________________________ Tracker __________________________________ -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: modulator.patch Url: http://mail.python.org/pipermail/python-bugs-list/attachments/20071115/261b7ea6/attachment-0001.txt From report at bugs.python.org Thu Nov 15 16:52:22 2007 From: report at bugs.python.org (Christian Heimes) Date: Thu, 15 Nov 2007 15:52:22 -0000 Subject: [issue1450] make modulator more general Message-ID: <1195141942.74.0.46012795962.issue1450@psf.upfronthosting.co.za> Christian Heimes added the comment: Thanks for your work! I'm changing the version number to Python 2.6. It's too late to get it into Python 2.5. Christian PS: Next time could you please create the patch in the root of the Python source tree? It makes it easier to apply the patch. ---------- keywords: +patch nosy: +tiran priority: -> normal versions: +Python 2.6 -Python 2.5 __________________________________ Tracker __________________________________ From report at bugs.python.org Thu Nov 15 16:56:24 2007 From: report at bugs.python.org (Christian Heimes) Date: Thu, 15 Nov 2007 15:56:24 -0000 Subject: [issue1449] make msi work the vs 2005(MSVC8) Message-ID: <1195142184.44.0.402416839218.issue1449@psf.upfronthosting.co.za> Christian Heimes added the comment: I'm resetting the target version of all your MSVC patches to 2.6 + 3.0. While we can't alter the compiler version of Python 2.5 I really like to update to a new compiler for 2.6 and 3.0. ---------- components: +Demos and Tools, Installation keywords: +patch nosy: +tiran priority: -> normal versions: +Python 2.6, Python 3.0 -Python 2.5 __________________________________ Tracker __________________________________ From report at bugs.python.org Thu Nov 15 16:59:10 2007 From: report at bugs.python.org (Christian Heimes) Date: Thu, 15 Nov 2007 15:59:10 -0000 Subject: [issue1448] Build Python with VS 2005(MSVC8) Message-ID: <1195142350.0.0.299495438784.issue1448@psf.upfronthosting.co.za> Changes by Christian Heimes: ---------- components: +Installation keywords: +patch priority: -> normal versions: +Python 2.6, Python 3.0 -Python 2.5 __________________________________ Tracker __________________________________ From report at bugs.python.org Thu Nov 15 16:59:19 2007 From: report at bugs.python.org (Christian Heimes) Date: Thu, 15 Nov 2007 15:59:19 -0000 Subject: [issue1447] patch to make msvccompiler.py work with vs 2005(MSVC8) Message-ID: <1195142359.17.0.0334681562347.issue1447@psf.upfronthosting.co.za> Changes by Christian Heimes: ---------- components: +Installation keywords: +patch versions: +Python 2.6, Python 3.0 -Python 2.5 __________________________________ Tracker __________________________________ From report at bugs.python.org Thu Nov 15 17:00:00 2007 From: report at bugs.python.org (Christian Heimes) Date: Thu, 15 Nov 2007 16:00:00 -0000 Subject: [issue1446] Link to call me for free Message-ID: <1195142400.83.0.61149810603.issue1446@psf.upfronthosting.co.za> Changes by Christian Heimes: ---------- resolution: -> invalid status: open -> closed __________________________________ Tracker __________________________________ From report at bugs.python.org Thu Nov 15 17:02:15 2007 From: report at bugs.python.org (Christian Heimes) Date: Thu, 15 Nov 2007 16:02:15 -0000 Subject: [issue1444] utf_8_sig streamreader bug, patch, and test Message-ID: <1195142535.03.0.218594418254.issue1444@psf.upfronthosting.co.za> Changes by Christian Heimes: ---------- keywords: +patch __________________________________ Tracker __________________________________ From report at bugs.python.org Thu Nov 15 17:10:15 2007 From: report at bugs.python.org (Christian Heimes) Date: Thu, 15 Nov 2007 16:10:15 -0000 Subject: [issue1447] patch to make msvccompiler.py work with vs 2005(MSVC8) Message-ID: <1195143014.99.0.662607387174.issue1447@psf.upfronthosting.co.za> Christian Heimes added the comment: I've checked your patch. It's not enough to move to VS 2005 as the default compiler. People expect python setup.py to work w/o opening a VS 2005 Command Prompt. ---------- nosy: +tiran __________________________________ Tracker __________________________________ From report at bugs.python.org Thu Nov 15 17:21:07 2007 From: report at bugs.python.org (Georg Brandl) Date: Thu, 15 Nov 2007 16:21:07 -0000 Subject: [issue1444] utf_8_sig streamreader bug, patch, and test Message-ID: <1195143667.47.0.1150951126.issue1444@psf.upfronthosting.co.za> Changes by Georg Brandl: ---------- assignee: -> doerwalter nosy: +doerwalter __________________________________ Tracker __________________________________ From report at bugs.python.org Thu Nov 15 17:46:48 2007 From: report at bugs.python.org (Christian Heimes) Date: Thu, 15 Nov 2007 16:46:48 -0000 Subject: [issue1449] make msi work the vs 2005(MSVC8) Message-ID: <1195145208.12.0.185661095751.issue1449@psf.upfronthosting.co.za> Christian Heimes added the comment: The patch looks fine but I've a small request. Could you please use a global var PCBUILD instead of "PCBuild" / "PCBuild8" and change the dependencies to use either MSVCR 71 or 80 depending on the content of the var. This way the msi module can handle both versions. __________________________________ Tracker __________________________________ From report at bugs.python.org Thu Nov 15 18:09:43 2007 From: report at bugs.python.org (Christian Heimes) Date: Thu, 15 Nov 2007 17:09:43 -0000 Subject: [issue1448] Build Python with VS 2005(MSVC8) Message-ID: <1195146583.88.0.556041190398.issue1448@psf.upfronthosting.co.za> Christian Heimes added the comment: I'm a bit concerned with the upgrade from DB 4.4. to 4.6 and SQLite from 3.3 to 3.5. Are the APIs backward compatible or can the Python bindings handle the new APIs? I believe that Python 2.6 is compatible with db4.6 but I'm not sure about SQLite. Have you run the unit tests? ---------- nosy: +tiran __________________________________ Tracker __________________________________ From report at bugs.python.org Thu Nov 15 18:29:33 2007 From: report at bugs.python.org (Guido van Rossum) Date: Thu, 15 Nov 2007 17:29:33 -0000 Subject: [issue1144] parsermodule validation out of sync with Grammar Message-ID: <1195147773.76.0.625016400575.issue1144@psf.upfronthosting.co.za> Guido van Rossum added the comment: Can you submit a unittest that catches this? Then I can check in the fix. ---------- assignee: fdrake -> gvanrossum __________________________________ Tracker __________________________________ From report at bugs.python.org Thu Nov 15 19:14:06 2007 From: report at bugs.python.org (roudkerk) Date: Thu, 15 Nov 2007 18:14:06 -0000 Subject: [issue1378] fromfd() and dup() for _socket on WIndows Message-ID: <1195150446.52.0.774304045884.issue1378@psf.upfronthosting.co.za> roudkerk added the comment: >From Guido's patch: > if (!DuplicateHandle(GetCurrentProcess(), (HANDLE)handle, > GetCurrentProcess(), &newhandle, > 0, FALSE, DUPLICATE_SAME_ACCESS)) > { > WSASetLastError(GetLastError()); > return INVALID_SOCKET; > } If you are going to use GetLastError() like that then you really should change set_error() so that it recognizes non-WSA errors. The solution is easy: rip out the 80+ lines of Windows specific code in set_error() and replace them by the much simpler #ifdef MS_WINDOWS int err_no = WSAGetLastError(); /* PyErr_SetExcFromWindowsErr() invokes FormatMessage() which recognizes the error numbers used by both GetLastError() and WSAGetLastError() */ if (err_no) return PyErr_SetExcFromWindowsErr(socket_error, err_no); #endif Note that if you make makefile() use a duplicate socket then you can also remove all the reference counting stuff from the socket subclass. __________________________________ Tracker __________________________________ From report at bugs.python.org Thu Nov 15 19:25:25 2007 From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=) Date: Thu, 15 Nov 2007 18:25:25 -0000 Subject: [issue1447] patch to make msvccompiler.py work with vs 2005(MSVC8) Message-ID: <1195151125.19.0.381408159008.issue1447@psf.upfronthosting.co.za> Martin v. L?wis added the comment: tiran is correct. distutils should work without having to invoke a VS build environment. Relying on that environment would have worked way back to VC6 and earlier, but it would reduce the ease of use of distutils. Rejecting the patch. ---------- nosy: +loewis resolution: -> rejected status: open -> closed __________________________________ Tracker __________________________________ From report at bugs.python.org Thu Nov 15 19:31:23 2007 From: report at bugs.python.org (Christian Heimes) Date: Thu, 15 Nov 2007 18:31:23 -0000 Subject: [issue1451] SSL patch for Python 3000 Message-ID: <1195151483.46.0.0984988466264.issue1451@psf.upfronthosting.co.za> Christian Heimes added the comment: Ubuntu Linux 7.10, x86, gcc version 4.1.3 20070929 (prerelease) (Ubuntu 4.1.2-16ubuntu2) /home/heimes/dev/python/py3k/Modules/_ssl.c: In function '_get_peer_alt_names': /home/heimes/dev/python/py3k/Modules/_ssl.c:680: warning: passing argument 2 of 'ASN1_item_d2i' from incompatible pointer type /home/heimes/dev/python/py3k/Modules/_ssl.c:684: warning: passing argument 2 of 'method->d2i' from incompatible pointer type gcc -pthread -shared ---------- nosy: +tiran __________________________________ Tracker __________________________________ From report at bugs.python.org Thu Nov 15 19:32:15 2007 From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=) Date: Thu, 15 Nov 2007 18:32:15 -0000 Subject: [issue1448] Build Python with VS 2005(MSVC8) Message-ID: <1195151535.79.0.748726913629.issue1448@psf.upfronthosting.co.za> Martin v. L?wis added the comment: I'm rejecting this patch, for several reasons: - it addresses too many issues in a single patch. Separate bug reports need to be submitted for independent issues. - for each issue, it fails to explain what the problem is. For example, "some libraries are outdated" is not a problem per se, but only would be a problem if those old libraries don't work with the new compiler; the actual problem is not reported here. - it suggests to upgrade libraries; I assume it does so for Python 2.6 and 3.0. However, upgrading libraries should be deferred until before the release. People building the development versions of Python are expected to arrange the build environment themselves in a way they like, using readme.txt only as a guideline. - the patches to upgrade the libraries are incomplete. ---------- nosy: +loewis resolution: -> rejected status: open -> closed __________________________________ Tracker __________________________________ From report at bugs.python.org Thu Nov 15 19:35:50 2007 From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=) Date: Thu, 15 Nov 2007 18:35:50 -0000 Subject: [issue1449] make msi work the vs 2005(MSVC8) Message-ID: <1195151750.94.0.769950295566.issue1449@psf.upfronthosting.co.za> Martin v. L?wis added the comment: I'm opposed to this patch. Any change to the MSI build process should only be made when/after the default compiler for Python is changed. That needs to be discussed on python-dev first, and I hope that the new build infrastructure will *not* use the PCbuild8 directory (but perhaps move rename that directory to PCbuild instead, or just upgrade the project files in PCbuild). In addition, I hope that VS 2005 will *not* be the next default compiler for Python, but that VS 2008 will be the new compiler. ---------- nosy: +loewis __________________________________ Tracker __________________________________ From report at bugs.python.org Thu Nov 15 19:40:39 2007 From: report at bugs.python.org (Bill Janssen) Date: Thu, 15 Nov 2007 18:40:39 -0000 Subject: [issue1451] SSL patch for Python 3000 In-Reply-To: <1195151483.46.0.0984988466264.issue1451@psf.upfronthosting.co.za> Message-ID: <4b3e516a0711151040q6e4f6bbfq42efa25471291b94@mail.gmail.com> Bill Janssen added the comment: I've tried several different times to fix that warning. It appears on some releases of gcc, and not on others. There seems to be no cast or declaration that fixes it everywhere. More power to you if you can find one! Bill On 11/15/07, Christian Heimes wrote: > > Christian Heimes added the comment: > > Ubuntu Linux 7.10, x86, gcc version 4.1.3 20070929 (prerelease) (Ubuntu > 4.1.2-16ubuntu2) > > > /home/heimes/dev/python/py3k/Modules/_ssl.c: In function > '_get_peer_alt_names': > /home/heimes/dev/python/py3k/Modules/_ssl.c:680: warning: passing > argument 2 of 'ASN1_item_d2i' from incompatible pointer type > /home/heimes/dev/python/py3k/Modules/_ssl.c:684: warning: passing > argument 2 of 'method->d2i' from incompatible pointer type > gcc -pthread -shared > > ---------- > nosy: +tiran > > __________________________________ > Tracker > > __________________________________ > __________________________________ Tracker __________________________________ From report at bugs.python.org Thu Nov 15 19:42:35 2007 From: report at bugs.python.org (Bill Janssen) Date: Thu, 15 Nov 2007 18:42:35 -0000 Subject: [issue1451] SSL patch for Python 3000 In-Reply-To: <4b3e516a0711151040q6e4f6bbfq42efa25471291b94@mail.gmail.com> Message-ID: <4b3e516a0711151042ybb8eec4uad4ac8b34d592514@mail.gmail.com> Bill Janssen added the comment: Actually, it's some combination of the version of OpenSSL plus the version of gcc. Bill On 11/15/07, Bill Janssen wrote: > I've tried several different times to fix that warning. It appears on > some releases of gcc, and not on others. There seems to be no cast or > declaration that fixes it everywhere. More power to you if you can > find one! > > Bill > > On 11/15/07, Christian Heimes wrote: > > > > Christian Heimes added the comment: > > > > Ubuntu Linux 7.10, x86, gcc version 4.1.3 20070929 (prerelease) (Ubuntu > > 4.1.2-16ubuntu2) > > > > > > /home/heimes/dev/python/py3k/Modules/_ssl.c: In function > > '_get_peer_alt_names': > > /home/heimes/dev/python/py3k/Modules/_ssl.c:680: warning: passing > > argument 2 of 'ASN1_item_d2i' from incompatible pointer type > > /home/heimes/dev/python/py3k/Modules/_ssl.c:684: warning: passing > > argument 2 of 'method->d2i' from incompatible pointer type > > gcc -pthread -shared > > > > ---------- > > nosy: +tiran > > > > __________________________________ > > Tracker > > > > __________________________________ > > > __________________________________ Tracker __________________________________ From report at bugs.python.org Thu Nov 15 19:44:54 2007 From: report at bugs.python.org (Guido van Rossum) Date: Thu, 15 Nov 2007 18:44:54 -0000 Subject: [issue1378] fromfd() and dup() for _socket on WIndows Message-ID: <1195152294.35.0.146268019491.issue1378@psf.upfronthosting.co.za> Guido van Rossum added the comment: roudkerk, can you turn that suggestion into a proper patch? __________________________________ Tracker __________________________________ From report at bugs.python.org Thu Nov 15 19:50:29 2007 From: report at bugs.python.org (David Binger) Date: Thu, 15 Nov 2007 18:50:29 -0000 Subject: [issue1144] parsermodule validation out of sync with Grammar Message-ID: <1195152629.67.0.734538650235.issue1144@psf.upfronthosting.co.za> David Binger added the comment: Okay, here is the whole thing with a unittest that exposes the problem. Index: Lib/test/test_parser.py =================================================================== --- Lib/test/test_parser.py (revision 58984) +++ Lib/test/test_parser.py (working copy) @@ -136,6 +136,7 @@ def test_class_defs(self): self.check_suite("class foo():pass") + self.check_suite("class foo(object):pass") def test_import_from_statement(self): self.check_suite("from sys.path import *") Index: Modules/parsermodule.c =================================================================== --- Modules/parsermodule.c (revision 58984) +++ Modules/parsermodule.c (working copy) @@ -992,7 +992,7 @@ if (res) { if (nch == 7) { res = ((validate_lparen(CHILD(tree, 2)) && - validate_testlist(CHILD(tree, 3)) && + validate_arglist(CHILD(tree, 3)) && validate_rparen(CHILD(tree, 4)))); } else if (nch == 6) { __________________________________ Tracker __________________________________ From report at bugs.python.org Thu Nov 15 20:17:39 2007 From: report at bugs.python.org (Guido van Rossum) Date: Thu, 15 Nov 2007 19:17:39 -0000 Subject: [issue1144] parsermodule validation out of sync with Grammar Message-ID: <1195154259.67.0.102769954487.issue1144@psf.upfronthosting.co.za> Guido van Rossum added the comment: Committed revision 58987. ---------- status: open -> closed __________________________________ Tracker __________________________________ From report at bugs.python.org Thu Nov 15 20:22:54 2007 From: report at bugs.python.org (Guido van Rossum) Date: Thu, 15 Nov 2007 19:22:54 -0000 Subject: [issue1378] fromfd() and dup() for _socket on WIndows Message-ID: <1195154574.4.0.774735871202.issue1378@psf.upfronthosting.co.za> Guido van Rossum added the comment: > I've reviewed your patch and merged it was some pending changes of my > own. The socket tests are passing on Windows. Great work :) You didn't upload this though. __________________________________ Tracker __________________________________ From report at bugs.python.org Thu Nov 15 20:32:34 2007 From: report at bugs.python.org (Christian Heimes) Date: Thu, 15 Nov 2007 19:32:34 -0000 Subject: [issue1378] fromfd() and dup() for _socket on WIndows Message-ID: <1195155154.32.0.198812327124.issue1378@psf.upfronthosting.co.za> Changes by Christian Heimes: __________________________________ Tracker __________________________________ From report at bugs.python.org Thu Nov 15 20:33:01 2007 From: report at bugs.python.org (Christian Heimes) Date: Thu, 15 Nov 2007 19:33:01 -0000 Subject: [issue1378] fromfd() and dup() for _socket on WIndows Message-ID: <1195155181.12.0.143342510059.issue1378@psf.upfronthosting.co.za> Christian Heimes added the comment: Oh, I forgot Added file: http://bugs.python.org/file8757/py3k_another_socket.patch __________________________________ Tracker __________________________________ -------------- next part -------------- A non-text attachment was scrubbed... Name: py3k_another_socket.patch Type: text/x-diff Size: 12325 bytes Desc: not available Url : http://mail.python.org/pipermail/python-bugs-list/attachments/20071115/bd4b8e1b/attachment-0001.patch From report at bugs.python.org Thu Nov 15 20:40:29 2007 From: report at bugs.python.org (Guido van Rossum) Date: Thu, 15 Nov 2007 19:40:29 -0000 Subject: [issue1451] SSL patch for Python 3000 Message-ID: <1195155629.91.0.570144649567.issue1451@psf.upfronthosting.co.za> Guido van Rossum added the comment: Looks good (after skimming). Some stylistic nits: - Please fold lines >= 80 chars. - Please strip trailing whitespace (for Python code, you won't be allowed to submit with it present). - You can fold long imports without using the dreaded backslash now, e.g. from _ssl import (SSL_ERROR_ZERO_RETURN, SSL_ERROR_WANT_READ, ...) Then just check it in. (We'll be able to do the dup()'ing differently soon, but I'd just as soon see your patch go in first.) ---------- assignee: gvanrossum -> janssen __________________________________ Tracker __________________________________ From report at bugs.python.org Thu Nov 15 20:58:02 2007 From: report at bugs.python.org (Guido van Rossum) Date: Thu, 15 Nov 2007 19:58:02 -0000 Subject: [issue1378] fromfd() and dup() for _socket on WIndows Message-ID: <1195156682.83.0.00152330045734.issue1378@psf.upfronthosting.co.za> Guido van Rossum added the comment: - I'm hoping that Bill can submit his SSL changes first. - If we make _dup() a module-level function, we can implement fromfd() in Python. I'll do this now. __________________________________ Tracker __________________________________ From report at bugs.python.org Thu Nov 15 21:21:13 2007 From: report at bugs.python.org (Guido van Rossum) Date: Thu, 15 Nov 2007 20:21:13 -0000 Subject: [issue1378] fromfd() and dup() for _socket on WIndows Message-ID: <1195158073.17.0.0531565695734.issue1378@psf.upfronthosting.co.za> Guido van Rossum added the comment: socket2.diff makes dup() a module-level function in _socket (and hence in socket.py) and uses that to implement fromfd() in socket.py. No changes otherwise compared to py3k_another_socket.patch. Added file: http://bugs.python.org/file8758/socket2.diff __________________________________ Tracker __________________________________ -------------- next part -------------- A non-text attachment was scrubbed... Name: socket2.diff Type: text/x-patch Size: 11875 bytes Desc: not available Url : http://mail.python.org/pipermail/python-bugs-list/attachments/20071115/1472fbfd/attachment.bin From report at bugs.python.org Thu Nov 15 21:36:18 2007 From: report at bugs.python.org (Guido van Rossum) Date: Thu, 15 Nov 2007 20:36:18 -0000 Subject: [issue1378] fromfd() and dup() for _socket on WIndows Message-ID: <1195158978.74.0.199176605871.issue1378@psf.upfronthosting.co.za> Guido van Rossum added the comment: socket3.diff builds on socket2.diff: - Rename socket class to Socket; add socket() as a factory function. - Implement roudkerk's suggestion of using a duplicate socket in makefile() to get rid of the manual reference counting. Yay! Note: this dinterferes with Bill Janssen's issue 1451. Whichever is checked in last must fix issues with the other. __________________________________ Tracker __________________________________ From report at bugs.python.org Thu Nov 15 21:36:57 2007 From: report at bugs.python.org (Guido van Rossum) Date: Thu, 15 Nov 2007 20:36:57 -0000 Subject: [issue1378] fromfd() and dup() for _socket on WIndows Message-ID: <1195159017.29.0.152237941824.issue1378@psf.upfronthosting.co.za> Guido van Rossum added the comment: Forgot to upload socket3.diff. Added file: http://bugs.python.org/file8759/socket3.diff __________________________________ Tracker __________________________________ -------------- next part -------------- A non-text attachment was scrubbed... Name: socket3.diff Type: text/x-patch Size: 14126 bytes Desc: not available Url : http://mail.python.org/pipermail/python-bugs-list/attachments/20071115/1d077979/attachment-0001.bin From report at bugs.python.org Thu Nov 15 21:40:02 2007 From: report at bugs.python.org (Guido van Rossum) Date: Thu, 15 Nov 2007 20:40:02 -0000 Subject: [issue1031213] Use correct encoding for printing SyntaxErrors Message-ID: <1195159202.95.0.987462977569.issue1031213@psf.upfronthosting.co.za> Guido van Rossum added the comment: > In release25-maint, PyErr_Print() should be replaced with > PyErr_Clear() also. Committed revision 58991. _____________________________________ Tracker _____________________________________ From report at bugs.python.org Thu Nov 15 21:41:20 2007 From: report at bugs.python.org (Guido van Rossum) Date: Thu, 15 Nov 2007 20:41:20 -0000 Subject: [issue1445] SystemError accessing uninitialised cell contents Message-ID: <1195159280.94.0.450196939624.issue1445@psf.upfronthosting.co.za> Guido van Rossum added the comment: Patch anyone? ---------- nosy: +gvanrossum __________________________________ Tracker __________________________________ From report at bugs.python.org Thu Nov 15 21:44:40 2007 From: report at bugs.python.org (Brett Cannon) Date: Thu, 15 Nov 2007 20:44:40 -0000 Subject: [issue1430436] recursive __getattr__ in thread crashes Message-ID: <1195159480.24.0.836701703952.issue1430436@psf.upfronthosting.co.za> Brett Cannon added the comment: And under 2.6 on OS X. I doubt this is a BSD thing but more of a recursion depth issue. And I don't think there is anything to fix here. The recursion depth is a per-thread thing, and this test is blowing the C stack before the recursion depth is reached. If you drop the recursion limit lower the proper exception is raised (I had to drop mine down to 400 to trigger the exception). So this is not a Python issue, per-se, just a limitation of the C stack and how things are implemented. While we do everything we can to prevent crashes, this just can't be helped as the C stack is not under our control. Closing as invalid. ---------- nosy: +brett.cannon resolution: -> invalid status: open -> closed title: recursive __getattr__ in thread crashes BSDs -> recursive __getattr__ in thread crashes versions: +Python 2.6 _____________________________________ Tracker _____________________________________ From report at bugs.python.org Thu Nov 15 21:47:56 2007 From: report at bugs.python.org (Guido van Rossum) Date: Thu, 15 Nov 2007 20:47:56 -0000 Subject: [issue1451] SSL patch for Python 3000 Message-ID: <1195159676.24.0.713417816566.issue1451@psf.upfronthosting.co.za> Guido van Rossum added the comment: If you haven't checked this in by tomorrow morning, I'll submit issue 1378 (socket3.diff) first, and you'll have to do a bunch of cleanup. Or, if you like, I can submit that now and you can do the cleanup this afternoon. (Basically, we can dup() sockets on Windows now, so all the nonsense about keeping our own reference counts is no longer needed -- makefile() just hangs on to a dup() of the socket. This restores the semantics we had in 1.5.2... __________________________________ Tracker __________________________________ From report at bugs.python.org Thu Nov 15 22:21:12 2007 From: report at bugs.python.org (MHOOO) Date: Thu, 15 Nov 2007 21:21:12 -0000 Subject: [issue1417] Weakref not working properly Message-ID: <1195161672.04.0.661812990785.issue1417@psf.upfronthosting.co.za> MHOOO added the comment: Yeah, cool :) Thanks =) __________________________________ Tracker __________________________________ From report at bugs.python.org Thu Nov 15 22:35:33 2007 From: report at bugs.python.org (Bill Janssen) Date: Thu, 15 Nov 2007 21:35:33 -0000 Subject: [issue1451] SSL patch for Python 3000 In-Reply-To: <1195159676.24.0.713417816566.issue1451@psf.upfronthosting.co.za> Message-ID: <4b3e516a0711151335nf9b386dh5cc8ef72f033323b@mail.gmail.com> Bill Janssen added the comment: I'll check it in this afternoon -- I've just got to figure out how to run the Python clean-up tool. Then you can check in the socket3.diff patch, then I'll make sure the SSL module works with that version of sockets. Bill On 11/15/07, Guido van Rossum wrote: > > Guido van Rossum added the comment: > > If you haven't checked this in by tomorrow morning, I'll submit issue > 1378 (socket3.diff) first, and you'll have to do a bunch of cleanup. > Or, if you like, I can submit that now and you can do the cleanup this > afternoon. (Basically, we can dup() sockets on Windows now, so all the > nonsense about keeping our own reference counts is no longer needed -- > makefile() just hangs on to a dup() of the socket. This restores the > semantics we had in 1.5.2... > > __________________________________ > Tracker > > __________________________________ > __________________________________ Tracker __________________________________ From report at bugs.python.org Thu Nov 15 22:40:43 2007 From: report at bugs.python.org (Christian Heimes) Date: Thu, 15 Nov 2007 21:40:43 -0000 Subject: [issue1449] make msi work the vs 2005(MSVC8) Message-ID: <1195162843.74.0.354009928016.issue1449@psf.upfronthosting.co.za> Christian Heimes added the comment: Weck, if you like to help and spend some time on getting VS2008 support into Python 2.6 and 3.0 I'm willing to assist you. You can download the Beta 2 of the VS C++ 2008 Express Edition from http://msdn2.microsoft.com/en-us/express/future/bb421473.aspx IMHO the order of things to do is: * Get Python 2.6 and all dependencies to compile with VS2008 (PCbuild9 directory?) * Fork msvccompiler and fix it for VS2008 * Fix Tools/msi __________________________________ Tracker __________________________________ From report at bugs.python.org Thu Nov 15 23:14:16 2007 From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=) Date: Thu, 15 Nov 2007 22:14:16 -0000 Subject: [issue1449] make msi work the vs 2005(MSVC8) Message-ID: <1195164856.93.0.313962205396.issue1449@psf.upfronthosting.co.za> Martin v. L?wis added the comment: One issue that also needs discussion is the structure of the build directory. It could temporarily be PCbuild9, but in the long run, it should replace PCbuild. Apart from that, the issue is whether there should be a flat structure as it is currently in PCbuild, or a nested one as it is in PCbuild9; I think that flat is better than nested. Then another issue is whether it should support building both AMD64 and x86 from the same source tree; I don't think that this is necessary. And so on; this really needs to be discussed on python-dev. __________________________________ Tracker __________________________________ From report at bugs.python.org Thu Nov 15 23:19:06 2007 From: report at bugs.python.org (Christian Heimes) Date: Thu, 15 Nov 2007 22:19:06 -0000 Subject: [issue1378] fromfd() and dup() for _socket on WIndows Message-ID: <1195165146.23.0.926013695888.issue1378@psf.upfronthosting.co.za> Christian Heimes added the comment: I've yet another idea for a tiny improvement. Instead of doing newfd = _socket.dup(socket_instance.fileno()) I prefer newfd = _socket.dup(socket_instance) It removes some confusing magic and makes error checking on Windows slightly easier. __________________________________ Tracker __________________________________ From report at bugs.python.org Thu Nov 15 23:22:45 2007 From: report at bugs.python.org (Guido van Rossum) Date: Thu, 15 Nov 2007 22:22:45 -0000 Subject: [issue1378] fromfd() and dup() for _socket on WIndows Message-ID: <1195165365.74.0.160781511553.issue1378@psf.upfronthosting.co.za> Guido van Rossum added the comment: Hold on, socket3.diff breaks four unit tests: test_ftplib test_poplib test_smtplib test_urllib2net > newfd = _socket.dup(socket_instance) But that doesn't allow fromfd to work. I found some real use cases for fromfd where the fd is passed in through some other means: http://www.google.com/codesearch?as_q=socket%5C.fromfd&btnG=Search+Code&as_lang=python __________________________________ Tracker __________________________________ From report at bugs.python.org Thu Nov 15 23:24:47 2007 From: report at bugs.python.org (Bill Janssen) Date: Thu, 15 Nov 2007 22:24:47 -0000 Subject: [issue1451] SSL patch for Python 3000 In-Reply-To: <4b3e516a0711151335nf9b386dh5cc8ef72f033323b@mail.gmail.com> Message-ID: <4b3e516a0711151424gee35208h316652e4d4e970ae@mail.gmail.com> Bill Janssen added the comment: OK, it's checked in. Let's see what the Windows buildbots think :-). Bill On Nov 15, 2007 1:35 PM, Bill Janssen wrote: > > Bill Janssen added the comment: > > I'll check it in this afternoon -- I've just got to figure out how to > run the Python clean-up tool. Then you can check in the socket3.diff > patch, then I'll make sure the SSL module works with that version of > sockets. > > Bill > > On 11/15/07, Guido van Rossum wrote: > > > > > Guido van Rossum added the comment: > > > > If you haven't checked this in by tomorrow morning, I'll submit issue > > 1378 (socket3.diff) first, and you'll have to do a bunch of cleanup. > > Or, if you like, I can submit that now and you can do the cleanup this > > afternoon. (Basically, we can dup() sockets on Windows now, so all the > > nonsense about keeping our own reference counts is no longer needed -- > > makefile() just hangs on to a dup() of the socket. This restores the > > semantics we had in 1.5.2... > > > > __________________________________ > > Tracker > > > > __________________________________ > > > > __________________________________ > Tracker > > __________________________________ > __________________________________ Tracker __________________________________ From report at bugs.python.org Thu Nov 15 23:26:42 2007 From: report at bugs.python.org (Georg Brandl) Date: Thu, 15 Nov 2007 22:26:42 -0000 Subject: [issue1446] Link to call me for free Message-ID: <1195165602.64.0.122223209254.issue1446@psf.upfronthosting.co.za> Georg Brandl added the comment: Shouldn't the account be closed? ---------- nosy: +georg.brandl __________________________________ Tracker __________________________________ From report at bugs.python.org Thu Nov 15 23:29:28 2007 From: report at bugs.python.org (Guido van Rossum) Date: Thu, 15 Nov 2007 22:29:28 -0000 Subject: [issue1451] SSL patch for Python 3000 Message-ID: <1195165768.43.0.639646687403.issue1451@psf.upfronthosting.co.za> Guido van Rossum added the comment: Thanks! To be continued in issue 1378... ---------- resolution: -> accepted status: open -> closed __________________________________ Tracker __________________________________ From report at bugs.python.org Thu Nov 15 23:59:20 2007 From: report at bugs.python.org (Marc-Andre Lemburg) Date: Thu, 15 Nov 2007 22:59:20 -0000 Subject: [issue1433] marshal roundtripping for unicode Message-ID: <1195167560.63.0.404541216043.issue1433@psf.upfronthosting.co.za> Marc-Andre Lemburg added the comment: I think you have a wrong understanding of round-tripping. In Unicode it is really irrelevant if you're using a UCS2 surrogate pair or a UCS4 representation to describe a code point. The length of the Unicode representation may change, but the meaning won't, so you don't lose any information. ---------- nosy: +lemburg __________________________________ Tracker __________________________________ From report at bugs.python.org Fri Nov 16 00:00:42 2007 From: report at bugs.python.org (Bill Janssen) Date: Thu, 15 Nov 2007 23:00:42 -0000 Subject: [issue1451] SSL patch for Python 3000 Message-ID: <1195167642.83.0.0796536024787.issue1451@psf.upfronthosting.co.za> Bill Janssen added the comment: Looks like the Python SVN cert did not get included in the patch, which is causing a failure. I'll check that in. __________________________________ Tracker __________________________________ From report at bugs.python.org Fri Nov 16 00:16:49 2007 From: report at bugs.python.org (Giambattista Bloisi) Date: Thu, 15 Nov 2007 23:16:49 -0000 Subject: [issue1431] pth files not loaded at startup Message-ID: <1195168609.61.0.769067691861.issue1431@psf.upfronthosting.co.za> Giambattista Bloisi added the comment: Please find attached a patch for http://docs.python.org/dev/install/index.html. I think removing a statement is enough to make things clear. About darwin additional directories I'm unsure whether it need further documentation as it seems very platform-related. This is the comment I found in site.py # for framework builds *only* we add the standard Apple # locations. Currently only per-user, but /Library and # /Network/Library could be added too Eventually I used this command in pth file to extend the scanned directories: "import site; site.addsitedir('/System/Links/Libraries/python2.5/site-packages/', set())" I think this is more maintainable and clear than changing site.py, but I don't think it will be forward compatible. Added file: http://bugs.python.org/file8760/index.txt.patch __________________________________ Tracker __________________________________ -------------- next part -------------- A non-text attachment was scrubbed... Name: index.txt.patch Type: application/octet-stream Size: 734 bytes Desc: not available Url : http://mail.python.org/pipermail/python-bugs-list/attachments/20071115/a2b25baf/attachment.obj From report at bugs.python.org Fri Nov 16 00:21:36 2007 From: report at bugs.python.org (Amaury Forgeot d'Arc) Date: Thu, 15 Nov 2007 23:21:36 -0000 Subject: [issue1134] Parsing a simple script eats all of your memory Message-ID: <1195168896.95.0.832012039044.issue1134@psf.upfronthosting.co.za> Amaury Forgeot d'Arc added the comment: Corrected in revision 59001, with a modified patch. ---------- resolution: -> fixed status: open -> closed __________________________________ Tracker __________________________________ From report at bugs.python.org Fri Nov 16 00:26:55 2007 From: report at bugs.python.org (Guido van Rossum) Date: Thu, 15 Nov 2007 23:26:55 -0000 Subject: [issue1423] wave sunau aifc 16bit errors Message-ID: <1195169215.28.0.555473084365.issue1423@psf.upfronthosting.co.za> Guido van Rossum added the comment: Crys, since you apparently have working sound on Windows, could you have a look at this? There's also an (unrelated) issue with sunau.py on Py3k, it doesn't work (but the unittests aren't strong enough to discover that :-). ---------- assignee: -> tiran nosy: +tiran priority: -> normal __________________________________ Tracker __________________________________ From report at bugs.python.org Fri Nov 16 01:19:56 2007 From: report at bugs.python.org (roudkerk) Date: Fri, 16 Nov 2007 00:19:56 -0000 Subject: [issue1378] fromfd() and dup() for _socket on WIndows Message-ID: <1195172396.92.0.566621559423.issue1378@psf.upfronthosting.co.za> roudkerk added the comment: Currently on Windows set_error() make use of a large array which maps socket error numbers to error messages. This patch (against socketmodule.c from Python 2.6) removes that array and just lets PyErr_SetExcFromWindowsErr() generate the message by using the Win32 function FormatMessage(). It is orthogonal from the other patches discussed here. Added file: http://bugs.python.org/file8761/set_error.patch __________________________________ Tracker __________________________________ -------------- next part -------------- A non-text attachment was scrubbed... Name: set_error.patch Type: application/octet-stream Size: 3743 bytes Desc: not available Url : http://mail.python.org/pipermail/python-bugs-list/attachments/20071116/0f57af5f/attachment.obj From report at bugs.python.org Fri Nov 16 01:26:32 2007 From: report at bugs.python.org (Guido van Rossum) Date: Fri, 16 Nov 2007 00:26:32 -0000 Subject: [issue1378] fromfd() and dup() for _socket on WIndows Message-ID: <1195172792.6.0.820435424639.issue1378@psf.upfronthosting.co.za> Guido van Rossum added the comment: Thanks! roudkerk's patch is submitted as revision 59004. BTW I need to go back to the drawing board for the rest of the socket patch here. Using dup() in makefile() doesn't work for the ssl.SSLSocket class. Maybe the explicit reference counting is the best we can get. __________________________________ Tracker __________________________________ From report at bugs.python.org Fri Nov 16 01:36:11 2007 From: report at bugs.python.org (Ron Adam) Date: Fri, 16 Nov 2007 00:36:11 -0000 Subject: [issue1720390] Remove backslash escapes from tokenize.c. Message-ID: <1195173371.36.0.215266785157.issue1720390@psf.upfronthosting.co.za> Ron Adam added the comment: It looks like the disabling of \u and \U in raw strings is done. Does tokenize.py need to be fixed, to match? While working on this I was able to clean up the string parsing parts of tokenize.c, and have a separate patch with just that. And an updated patch with both the cleaned up tokenize.c and the no escapes in raw strings in case it is desired after all. Added file: http://bugs.python.org/file8762/tokenize_cleanup_patch.diff _____________________________________ Tracker _____________________________________ -------------- next part -------------- A non-text attachment was scrubbed... Name: tokenize_cleanup_patch.diff Type: text/x-patch Size: 3031 bytes Desc: not available Url : http://mail.python.org/pipermail/python-bugs-list/attachments/20071116/7ff0c8e4/attachment-0001.bin From report at bugs.python.org Fri Nov 16 01:36:36 2007 From: report at bugs.python.org (Ron Adam) Date: Fri, 16 Nov 2007 00:36:36 -0000 Subject: [issue1720390] Remove backslash escapes from tokenize.c. Message-ID: <1195173396.66.0.947788428153.issue1720390@psf.upfronthosting.co.za> Changes by Ron Adam: Added file: http://bugs.python.org/file8763/no_raw_escapes_patch.diff _____________________________________ Tracker _____________________________________ From report at bugs.python.org Fri Nov 16 01:52:49 2007 From: report at bugs.python.org (Guido van Rossum) Date: Fri, 16 Nov 2007 00:52:49 -0000 Subject: [issue1720390] Remove backslash escapes from tokenize.c. Message-ID: <1195174369.54.0.726501118948.issue1720390@psf.upfronthosting.co.za> Guido van Rossum added the comment: I don't think tokenizer.py needs to be changed -- it never interpreted backslashes in string literals anyway (not even in regular, non-raw literals). The tokenizer.c cleanup is submitted as revision 59007. I still am not warming up towards the no-raw-escapes feature, so I'm closing this as rejected. Nevertheless, thanks for your efforts! ---------- resolution: -> rejected status: open -> closed _____________________________________ Tracker _____________________________________ From report at bugs.python.org Fri Nov 16 02:25:50 2007 From: report at bugs.python.org (Guido van Rossum) Date: Fri, 16 Nov 2007 01:25:50 -0000 Subject: [issue1378] fromfd() and dup() for _socket on WIndows Message-ID: <1195176350.02.0.79676223498.issue1378@psf.upfronthosting.co.za> Guido van Rossum added the comment: I've submitted socket2.diff plus small changes to ssl.py. This seems the best I can do given that I don't think I can make dup() work on ssl sockets. ---------- resolution: -> accepted status: open -> closed __________________________________ Tracker __________________________________ From report at bugs.python.org Fri Nov 16 03:45:19 2007 From: report at bugs.python.org (billiejoex) Date: Fri, 16 Nov 2007 02:45:19 -0000 Subject: [issue1736190] asyncore/asynchat patches Message-ID: <1195181119.79.0.239734992818.issue1736190@psf.upfronthosting.co.za> billiejoex added the comment: The current implementation of asynchat.async_chat.initiate_send method doesn't look at what is specified in ac_out_buffer_size attribute which represents the buffer size of the outgoing data defaulting to a maximum of 4096 bytes to send in a single socket.send() call. Note that this only happens when sending the data by using a producer through the use of the push_with_producer method. This happens because while the older asynchat version used slicing for buffering: > num_sent = self.send(self.ac_out_buffer[:obs]) # obs == ac_out_buffer_size ...the newer version just calls self.send using the entire data as argument without caring of what ac_out_buffer_size thinks about it: > num_sent = self.send(first) What is specified in ac_out_buffer_size when using a producer is just ignored and the only way to have control over the outgoing data buffer is to operate directly on the producer. _____________________________________ Tracker _____________________________________ From report at bugs.python.org Fri Nov 16 04:24:38 2007 From: report at bugs.python.org (Brett Cannon) Date: Fri, 16 Nov 2007 03:24:38 -0000 Subject: [issue1631171] implement warnings module in C Message-ID: <1195183478.21.0.915289506039.issue1631171@psf.upfronthosting.co.za> Changes by Brett Cannon: ---------- assignee: nnorwitz -> brett.cannon _____________________________________ Tracker _____________________________________ From report at bugs.python.org Fri Nov 16 05:50:10 2007 From: report at bugs.python.org (James G. sack (jim)) Date: Fri, 16 Nov 2007 04:50:10 -0000 Subject: [issue1444] utf_8_sig streamreader bug, patch, and test Message-ID: <1195188610.09.0.527316712628.issue1444@psf.upfronthosting.co.za> James G. sack (jim) added the comment: I found the errror in my previous patch. It lacked a self.decode=.. line in the StreamReader.decode elif branch. I attach a replacement patch diff-u.py26_utf8sig (apply to the 2.6 version of utf_8_sig.py. (If allowed, I will next remove the incorrect patch.) This one passes test_codecs.py as well as my previously attached test module. The resulting utf_8_sig.py may benefit from further refctoring, but I didn't want to do more than necessary to fix the immediate bug. Regards, ..jim Added file: http://bugs.python.org/file8764/diff-u.py26_utf8sig __________________________________ Tracker __________________________________ -------------- next part -------------- A non-text attachment was scrubbed... Name: diff-u.py26_utf8sig Type: application/octet-stream Size: 1020 bytes Desc: not available Url : http://mail.python.org/pipermail/python-bugs-list/attachments/20071116/d25639e9/attachment.obj From report at bugs.python.org Fri Nov 16 13:38:59 2007 From: report at bugs.python.org (Senthil) Date: Fri, 16 Nov 2007 12:38:59 -0000 Subject: [issue1432] Strange behavior of urlparse.urljoin In-Reply-To: <1195046289.15.0.120400418268.issue1432@psf.upfronthosting.co.za> Message-ID: <20071116124751.GE3712@gmail.com> Senthil added the comment: Yes, you are right. test_urlparse also does not consider the scenarios wherein the relative url +starts with a query like ?y. This needs to be addressed. I shall code the patch to fix it. __________________________________ Tracker __________________________________ From report at bugs.python.org Fri Nov 16 14:15:57 2007 From: report at bugs.python.org (yan) Date: Fri, 16 Nov 2007 13:15:57 -0000 Subject: [issue1432] Strange behavior of urlparse.urljoin Message-ID: <1195218957.6.0.237417959589.issue1432@psf.upfronthosting.co.za> yan added the comment: That sounds great, thanks a lot. __________________________________ Tracker __________________________________ From report at bugs.python.org Fri Nov 16 15:56:48 2007 From: report at bugs.python.org (Christian Heimes) Date: Fri, 16 Nov 2007 14:56:48 -0000 Subject: [issue1452] subprocess's popen.stdout.seek(0) doesn't raise an error Message-ID: <1195225008.73.0.984849336269.issue1452@psf.upfronthosting.co.za> New submission from Christian Heimes: On Linux: >>> p = subprocess.Popen("ls", stdout=subprocess.PIPE) >>> p.stdout.read() b'...' >>> p.stdout.seek(0) Traceback (most recent call last): File "", line 1, in File "/home/heimes/dev/python/py3k/Lib/io.py", line 809, in seek pos = self.raw.seek(pos, whence) IOError: [Errno 29] Illegal seek >>> p.stdout.read() b'' On Windows p.stdout.seek(0) does neither raise an error nor works as one might expect it. The second read() returns an empty byte string, too. ---------- components: Windows keywords: py3k messages: 57585 nosy: tiran severity: normal status: open title: subprocess's popen.stdout.seek(0) doesn't raise an error versions: Python 3.0 __________________________________ Tracker __________________________________ From report at bugs.python.org Fri Nov 16 18:00:36 2007 From: report at bugs.python.org (Kathy Van Stone) Date: Fri, 16 Nov 2007 17:00:36 -0000 Subject: [issue1373762] Tweak pprint.PrettyPrinter.format for subclassing Message-ID: <1195232436.53.0.282579666336.issue1373762@psf.upfronthosting.co.za> Kathy Van Stone added the comment: I might be able to give a more compelling example (aside from the fact wanting it to fit the documentation which implies that one can subclass the pretty printer). I had a structure containing mostly lists, dictionary and primitives that I wanted to display, but it also contained UUIDs. In order to be able to see what the UUID referred to, I extended the pretty printer to lookup up the name associated with the UUID and included that. I have it working now by keeping the width narrow. The patch listed here (moving the line length check inside lists and dictionaries) doesn't entirely work as my altered representation of a UUID is different enough from the original that the calculation of line length is inaccurate. ---------- nosy: +kathyvs _____________________________________ Tracker _____________________________________ From report at bugs.python.org Fri Nov 16 19:06:08 2007 From: report at bugs.python.org (Facundo Batista) Date: Fri, 16 Nov 2007 18:06:08 -0000 Subject: [issue1259] string find and rfind methods give a TypeError that is misleading Message-ID: <1195236367.99.0.0674244231646.issue1259@psf.upfronthosting.co.za> Facundo Batista added the comment: Moved the function to find.h, cleaned the whitespace issues and documented the reference counting. Commited in trunk, rev 59020. Thanks everybody! ---------- resolution: -> fixed status: open -> closed __________________________________ Tracker __________________________________ From report at bugs.python.org Fri Nov 16 19:19:40 2007 From: report at bugs.python.org (Miki Tebeka) Date: Fri, 16 Nov 2007 18:19:40 -0000 Subject: [issue1453] Python does not honor "CFLAGS" environment variable Message-ID: <1195237179.9.0.203968653278.issue1453@psf.upfronthosting.co.za> New submission from Miki Tebeka: Setting CFLAGS environment variable do not show up in the build process, the gcc flags do not include the CFLAGS flags. ---------- components: Build messages: 57588 nosy: tebeka severity: normal status: open title: Python does not honor "CFLAGS" environment variable versions: Python 2.5 __________________________________ Tracker __________________________________ From report at bugs.python.org Fri Nov 16 19:28:51 2007 From: report at bugs.python.org (Guido van Rossum) Date: Fri, 16 Nov 2007 18:28:51 -0000 Subject: [issue1453] Python does not honor "CFLAGS" environment variable Message-ID: <1195237731.24.0.218447708333.issue1453@psf.upfronthosting.co.za> Guido van Rossum added the comment: This depends on the version of Make used. See the man page for Make. ---------- nosy: +gvanrossum __________________________________ Tracker __________________________________ From report at bugs.python.org Fri Nov 16 19:39:33 2007 From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=) Date: Fri, 16 Nov 2007 18:39:33 -0000 Subject: [issue1453] Python does not honor "CFLAGS" environment variable Message-ID: <1195238373.27.0.581821578655.issue1453@psf.upfronthosting.co.za> Martin v. L?wis added the comment: In all versions of make, "make CFLAGS=..." should work fine (although that's not an environment variable). ---------- nosy: +loewis __________________________________ Tracker __________________________________ From report at bugs.python.org Fri Nov 16 20:05:18 2007 From: report at bugs.python.org (Miki Tebeka) Date: Fri, 16 Nov 2007 19:05:18 -0000 Subject: [issue1453] Python does not honor "CFLAGS" environment variable Message-ID: <1195239918.15.0.374957906256.issue1453@psf.upfronthosting.co.za> Miki Tebeka added the comment: I'll try to be clearer: `./configure --help` states (at the end): Some influential environment variables: CC C compiler command CFLAGS C compiler flags LDFLAGS linker flags, e.g. -L if you have libraries in a nonstandard directory CPPFLAGS C/C++ preprocessor flags, e.g. -I if you have headers in a nonstandard directory CPP C preprocessor Use these variables to override the choices made by `configure' or to help it to find libraries and programs with nonstandard names/locations. What I've tried to do is compile Python with gprof, adding the -pg flag. So I ran `CFLAGS=-pg ./configure`, the resulting Makefile did not contained the -pg in the CFLAGS (or OPT) variables. Using `make CFLAGS=XXX` will override the CFLAGS definition in the Makefile, I just want to add to it. __________________________________ Tracker __________________________________ From report at bugs.python.org Fri Nov 16 20:24:39 2007 From: report at bugs.python.org (Guido van Rossum) Date: Fri, 16 Nov 2007 19:24:39 -0000 Subject: [issue1453] Python does not honor "CFLAGS" environment variable In-Reply-To: <1195239918.15.0.374957906256.issue1453@psf.upfronthosting.co.za> Message-ID: Guido van Rossum added the comment: I think you misunderstand. Passing a variable to configure makes that setting have effect *during the configure run*. __________________________________ Tracker __________________________________ From report at bugs.python.org Fri Nov 16 20:45:10 2007 From: report at bugs.python.org (Amaury Forgeot d'Arc) Date: Fri, 16 Nov 2007 19:45:10 -0000 Subject: [issue1452] subprocess's popen.stdout.seek(0) doesn't raise an error Message-ID: <1195242310.54.0.938716362553.issue1452@psf.upfronthosting.co.za> Amaury Forgeot d'Arc added the comment: Python 2.5 on Windows has the same behaviour, it does not fail. In general, python does not try to hide this kind of differences. ---------- nosy: +amaury.forgeotdarc __________________________________ Tracker __________________________________ From report at bugs.python.org Fri Nov 16 20:53:49 2007 From: report at bugs.python.org (Miki Tebeka) Date: Fri, 16 Nov 2007 19:53:49 -0000 Subject: [issue1453] Python does not honor "CFLAGS" environment variable Message-ID: <1195242829.18.0.754423108669.issue1453@psf.upfronthosting.co.za> Miki Tebeka added the comment: OK, let's close it then. (However note that in two projects I've checked - vim and pcre the CFLAGS environment variable do get reflected in the build process) Any "standard" way to add custom compilation flags?. __________________________________ Tracker __________________________________ From report at bugs.python.org Fri Nov 16 21:06:08 2007 From: report at bugs.python.org (Guido van Rossum) Date: Fri, 16 Nov 2007 20:06:08 -0000 Subject: [issue1453] Python does not honor "CFLAGS" environment variable Message-ID: <1195243568.95.0.421002974748.issue1453@psf.upfronthosting.co.za> Guido van Rossum added the comment: > Any "standard" way to add custom compilation flags?. Beats me. I'm no autoconf expert. ---------- resolution: -> wont fix status: open -> closed __________________________________ Tracker __________________________________ From report at bugs.python.org Fri Nov 16 21:17:11 2007 From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=) Date: Fri, 16 Nov 2007 20:17:11 -0000 Subject: [issue1453] Python does not honor "CFLAGS" environment variable In-Reply-To: <1195242829.18.0.754423108669.issue1453@psf.upfronthosting.co.za> Message-ID: <473DFAC5.7050806@v.loewis.de> Martin v. L?wis added the comment: > Any "standard" way to add custom compilation flags?. See the README. Set OPT to influence the optimization flags; set EXTRA_CFLAGS otherwise. __________________________________ Tracker __________________________________ From report at bugs.python.org Sat Nov 17 08:08:23 2007 From: report at bugs.python.org (Brett Cannon) Date: Sat, 17 Nov 2007 07:08:23 -0000 Subject: [issue1431] pth files not loaded at startup Message-ID: <1195283303.65.0.745948591215.issue1431@psf.upfronthosting.co.za> Brett Cannon added the comment: Fixed in r59033 for Python 2.6. Thanks for the help! ---------- resolution: -> fixed status: open -> closed __________________________________ Tracker __________________________________ From report at bugs.python.org Sat Nov 17 08:28:59 2007 From: report at bugs.python.org (Aldo Cortesi) Date: Sat, 17 Nov 2007 07:28:59 -0000 Subject: [issue1454] Generators break trace functionality Message-ID: <1195284538.89.0.627172491986.issue1454@psf.upfronthosting.co.za> New submission from Aldo Cortesi: I rely heavily on a code coverage analysis engine I developed, and a bug in Python's trace functionality has been bothering me for years. Today I snapped, and finally tracked it down to a minimal test case. To see the problem, play with the following code: import sys def run(): yield 1 def trace(frame, event, arg): try: for i in []: pass except Exception, e: pass sys.settrace(trace) x = run() del x Remove the try clause, and re-run with a debug build of the interpreter for a different symptom. Add a print statement at the end to verify that the problem occurs when the generator object is deleted. The problem occurs due to an interaction between generators and the trace functionality. When a generator is deleted, the gen_del function calls gen_close, which then sets a GeneratorExit exception. Eventually, PyEval_EvalFrameEx is called, with the throwflag set. At this point the trace function is called, the GeneratorExit exception which is set causes problems with the FOR_ITER opcode, which then fails. The attached patch against trunk fixes this by storing exceptions before the call trace function is called, and restoring the exception afterwards. All regression tests pass for me with this patch applied. ---------- components: Interpreter Core files: generator-trace.patch messages: 57598 nosy: cortesi severity: major status: open title: Generators break trace functionality type: behavior versions: Python 2.5, Python 2.6 Added file: http://bugs.python.org/file8765/generator-trace.patch __________________________________ Tracker __________________________________ -------------- next part -------------- A non-text attachment was scrubbed... Name: generator-trace.patch Type: text/x-patch Size: 911 bytes Desc: not available Url : http://mail.python.org/pipermail/python-bugs-list/attachments/20071117/916af99c/attachment.bin From report at bugs.python.org Sat Nov 17 14:48:13 2007 From: report at bugs.python.org (Christian Heimes) Date: Sat, 17 Nov 2007 13:48:13 -0000 Subject: [issue1455] VS2008, quick hack for distutils.msvccompiler Message-ID: <1195307293.52.0.874036930861.issue1455@psf.upfronthosting.co.za> New submission from Christian Heimes: I've come up with a quick hack to support VS 2008. VS 2008 Standard Edition doesn't store the include and lib dirs in the registry any more. However I came up with a nice way to get the env settings from the vcvarsall.bat. How do you like it? Do we need support for VS6 and VS7.1 or can I remove the code from the module? ---------- assignee: loewis components: Distutils files: py3k_vs2008_hack.patch keywords: patch, py3k messages: 57599 nosy: loewis, tiran priority: normal severity: normal status: open title: VS2008, quick hack for distutils.msvccompiler type: rfe versions: Python 3.0 Added file: http://bugs.python.org/file8766/py3k_vs2008_hack.patch __________________________________ Tracker __________________________________ -------------- next part -------------- A non-text attachment was scrubbed... Name: py3k_vs2008_hack.patch Type: text/x-diff Size: 11056 bytes Desc: not available Url : http://mail.python.org/pipermail/python-bugs-list/attachments/20071117/58818eff/attachment.patch From report at bugs.python.org Sat Nov 17 15:01:24 2007 From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=) Date: Sat, 17 Nov 2007 14:01:24 -0000 Subject: [issue1455] VS2008, quick hack for distutils.msvccompiler Message-ID: <1195308083.99.0.668282775828.issue1455@psf.upfronthosting.co.za> Martin v. L?wis added the comment: There is always the debate whether distutils might be repackaged and backported to older Python releases, therefore people hesitate to remove support for older versions. As for finding it in the registry: are you sure it has no registry settings anymore? I find that hard to believe. __________________________________ Tracker __________________________________ From report at bugs.python.org Sat Nov 17 15:04:08 2007 From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=) Date: Sat, 17 Nov 2007 14:04:08 -0000 Subject: [issue1455] VS2008, quick hack for distutils.msvccompiler Message-ID: <1195308248.22.0.721634158951.issue1455@psf.upfronthosting.co.za> Martin v. L?wis added the comment: As another note: you shouldn't remove support code for Itanium. Even though no Itanium binaries will be produced at the releases, I see no reason to rip the code out - people with Itanium machines should still be able to build Python, with some effort. __________________________________ Tracker __________________________________ From report at bugs.python.org Sat Nov 17 15:17:38 2007 From: report at bugs.python.org (Christian Heimes) Date: Sat, 17 Nov 2007 14:17:38 -0000 Subject: [issue1455] VS2008, quick hack for distutils.msvccompiler Message-ID: <1195309058.89.0.918822567512.issue1455@psf.upfronthosting.co.za> Christian Heimes added the comment: Neither VS8 Professional nor VS9 Beta 2 Standard are storing the lib and include directories in the registry. I've searched in HKCU and HKLM. The best I could find was the path to a XML file in My Documents that contains the information. __________________________________ Tracker __________________________________ From report at bugs.python.org Sat Nov 17 16:17:30 2007 From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=) Date: Sat, 17 Nov 2007 15:17:30 -0000 Subject: [issue1455] VS2008, quick hack for distutils.msvccompiler Message-ID: <1195312650.1.0.929845867542.issue1455@psf.upfronthosting.co.za> Martin v. L?wis added the comment: Ok. Running vsvars is fine, then. The change to get_build_architecture is broken in another way: as it parses the architecture out of sys.version, you still get Intel, not x86 (unless you also change PC/pyconfig.h - which may break code that relies on the specific format of sys.version) Otherwise, the patch looks fine. __________________________________ Tracker __________________________________ From report at bugs.python.org Sat Nov 17 16:17:40 2007 From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=) Date: Sat, 17 Nov 2007 15:17:40 -0000 Subject: [issue1455] VS2008, quick hack for distutils.msvccompiler Message-ID: <1195312660.6.0.836964086278.issue1455@psf.upfronthosting.co.za> Changes by Martin v. L?wis: ---------- resolution: -> accepted __________________________________ Tracker __________________________________ From report at bugs.python.org Sat Nov 17 16:49:05 2007 From: report at bugs.python.org (Guido van Rossum) Date: Sat, 17 Nov 2007 15:49:05 -0000 Subject: [issue1454] Generators break trace functionality Message-ID: <1195314545.86.0.384967685393.issue1454@psf.upfronthosting.co.za> Guido van Rossum added the comment: I think this was fixed in svn this week! See issue 1265. Let me know if your issue is different. ---------- nosy: +gvanrossum __________________________________ Tracker __________________________________ From report at bugs.python.org Sat Nov 17 17:38:24 2007 From: report at bugs.python.org (Nick Coghlan) Date: Sat, 17 Nov 2007 16:38:24 -0000 Subject: [issue1739468] Add a -z interpreter flag to execute a zip file Message-ID: <1195317504.79.0.876509319548.issue1739468@psf.upfronthosting.co.za> Nick Coghlan added the comment: Attached an updated version of PJE's patch with the suggested cleanups and a new unit test file (test_cmd_line_script.py). Finding the roundtuits to finish the latter is actually what has taken me so long. The basic tests and the directory tests are currently working, but for some reason the zipfile tests are attempting to load __main__ using pkgutil.ImpLoader instead of the zipimport module. I'm posting the patch anyway to see if anyone else can spot where it's going wrong before I find some more time to try and figure it out for myself. Added file: http://bugs.python.org/file8767/runmain_with_tests.diff _____________________________________ Tracker _____________________________________ -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: runmain_with_tests.diff Url: http://mail.python.org/pipermail/python-bugs-list/attachments/20071117/09ea1d97/attachment.txt From report at bugs.python.org Sat Nov 17 19:08:05 2007 From: report at bugs.python.org (Christian Heimes) Date: Sat, 17 Nov 2007 18:08:05 -0000 Subject: [issue1455] VS2008, quick hack for distutils.msvccompiler Message-ID: <1195322885.13.0.546561786779.issue1455@psf.upfronthosting.co.za> Christian Heimes added the comment: Ok, I'll take it from here. I'm going to wait until it's decided to use VS 2008 as the new default compiler. ---------- assignee: loewis -> tiran __________________________________ Tracker __________________________________ From report at bugs.python.org Sat Nov 17 22:11:44 2007 From: report at bugs.python.org (Aldo Cortesi) Date: Sat, 17 Nov 2007 21:11:44 -0000 Subject: [issue1454] Generators break trace functionality Message-ID: <1195333904.46.0.235416547185.issue1454@psf.upfronthosting.co.za> Aldo Cortesi added the comment: Drat, you're right. This was fixed a few days ago by Amaury in http://svn.python.org/view?rev=58963&view=rev Another example of confluence - this bug has existed for a very long time. __________________________________ Tracker __________________________________ From report at bugs.python.org Sat Nov 17 23:27:59 2007 From: report at bugs.python.org (Guido van Rossum) Date: Sat, 17 Nov 2007 22:27:59 -0000 Subject: [issue1454] Generators break trace functionality Message-ID: <1195338479.5.0.25210713533.issue1454@psf.upfronthosting.co.za> Guido van Rossum added the comment: Thanks anyway! ---------- resolution: -> duplicate status: open -> closed superseder: -> pdb bug with "with" statement __________________________________ Tracker __________________________________ From report at bugs.python.org Sat Nov 17 23:45:39 2007 From: report at bugs.python.org (Bill Janssen) Date: Sat, 17 Nov 2007 22:45:39 -0000 Subject: [issue1251] ssl module doesn't support non-blocking handshakes Message-ID: <1195339539.67.0.195566280354.issue1251@psf.upfronthosting.co.za> Bill Janssen added the comment: This is now checked into the 3K branch. __________________________________ Tracker __________________________________ From report at bugs.python.org Sun Nov 18 02:09:32 2007 From: report at bugs.python.org (Christian Heimes) Date: Sun, 18 Nov 2007 01:09:32 -0000 Subject: [issue1455] VS2008, quick hack for distutils.msvccompiler Message-ID: <1195348172.32.0.659493354406.issue1455@psf.upfronthosting.co.za> Christian Heimes added the comment: UPDATES: * Cleanup and rewrite of the registry related code * Moved search code to find_vcvarsall(). * Added fallback using the VS90COMNTOOL env var for Express edition Added file: http://bugs.python.org/file8768/py3k_vs2008_2.patch __________________________________ Tracker __________________________________ -------------- next part -------------- A non-text attachment was scrubbed... Name: py3k_vs2008_2.patch Type: text/x-diff Size: 16594 bytes Desc: not available Url : http://mail.python.org/pipermail/python-bugs-list/attachments/20071118/8417df5a/attachment-0001.patch From report at bugs.python.org Sun Nov 18 05:32:14 2007 From: report at bugs.python.org (Joseph Armbruster) Date: Sun, 18 Nov 2007 04:32:14 -0000 Subject: [issue1456] unexpected iterator behavior with removal Message-ID: <1195360334.0.0.509971000187.issue1456@psf.upfronthosting.co.za> New submission from Joseph Armbruster: Trunk Revision: 58651 Example of potential issue: >>> a = [1,2,3,4,5] >>> >>> for x in a: ... a.remove(x) ... >>> >>> a [2, 4] If this is the expected behavior of iteration in this case, my apologies. If this is not, I believe the issue lies in that listiter_next does not act correctly after a listremove has occurred. My knowledge of Python development is practically 0, so please take the patch with a grain of salt. ---------- components: Interpreter Core files: listobjectpatch.patch messages: 57611 nosy: JosephArmbruster severity: normal status: open title: unexpected iterator behavior with removal type: behavior versions: Python 2.6 Added file: http://bugs.python.org/file8769/listobjectpatch.patch __________________________________ Tracker __________________________________ -------------- next part -------------- A non-text attachment was scrubbed... Name: listobjectpatch.patch Type: application/octet-stream Size: 1638 bytes Desc: not available Url : http://mail.python.org/pipermail/python-bugs-list/attachments/20071118/ce4d3c6b/attachment.obj From report at bugs.python.org Sun Nov 18 05:37:20 2007 From: report at bugs.python.org (Christian Heimes) Date: Sun, 18 Nov 2007 04:37:20 -0000 Subject: [issue1456] unexpected iterator behavior with removal Message-ID: <1195360640.9.0.618721008661.issue1456@psf.upfronthosting.co.za> Christian Heimes added the comment: Closed as discussed on IRC. ---------- nosy: +tiran resolution: -> invalid status: open -> closed __________________________________ Tracker __________________________________ From report at bugs.python.org Sun Nov 18 12:23:31 2007 From: report at bugs.python.org (Nick Coghlan) Date: Sun, 18 Nov 2007 11:23:31 -0000 Subject: [issue1739468] Add a -z interpreter flag to execute a zip file Message-ID: <1195385011.42.0.556233353.issue1739468@psf.upfronthosting.co.za> Nick Coghlan added the comment: I worked out what was wrong with my unit tests (I was incorrectly including the path information when adding the test script to the zipfile) I've updated the patch here, and will be committing the change once the test suite finishes running. ---------- versions: +Python 2.6 Added file: http://bugs.python.org/file8770/runmain_with_tests.diff _____________________________________ Tracker _____________________________________ -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: runmain_with_tests.diff Url: http://mail.python.org/pipermail/python-bugs-list/attachments/20071118/407b74f9/attachment.txt From report at bugs.python.org Sun Nov 18 12:57:28 2007 From: report at bugs.python.org (Nick Coghlan) Date: Sun, 18 Nov 2007 11:57:28 -0000 Subject: [issue1739468] Add a -z interpreter flag to execute a zip file Message-ID: <1195387048.74.0.209162956704.issue1739468@psf.upfronthosting.co.za> Nick Coghlan added the comment: Committed as rev 59039 (now to see how the buildbots react for other platforms...) ---------- resolution: -> accepted status: open -> closed _____________________________________ Tracker _____________________________________ From report at bugs.python.org Sun Nov 18 14:54:58 2007 From: report at bugs.python.org (Joseph Armbruster) Date: Sun, 18 Nov 2007 13:54:58 -0000 Subject: [issue1559298] test_popen fails on Windows if installed to "Program Files" Message-ID: <1195394098.77.0.26472272618.issue1559298@psf.upfronthosting.co.za> Joseph Armbruster added the comment: I applied the change to: Python 2.6a0 (trunk:58651M, Nov 18 2007, 08:46:54) [MSC v.1400 32 bit (Intel)] on win32 and test_popen passes appeared to pass. ---------- nosy: +JosephArmbruster _____________________________________ Tracker _____________________________________ From report at bugs.python.org Sun Nov 18 15:17:12 2007 From: report at bugs.python.org (Joseph Armbruster) Date: Sun, 18 Nov 2007 14:17:12 -0000 Subject: [issue1489051] keyword and topic help broken in Pythonwin IDE Message-ID: <1195395432.78.0.144621432383.issue1489051@psf.upfronthosting.co.za> Joseph Armbruster added the comment: Is there any reason this is not part of the windows installer? So, that if you select to install the full Documentation feature, this as a checkbox-type option to 'build html documentation'? Thoughts? ---------- nosy: +JosephArmbruster _____________________________________ Tracker _____________________________________ From report at bugs.python.org Sun Nov 18 16:25:30 2007 From: report at bugs.python.org (Tal Einat) Date: Sun, 18 Nov 2007 15:25:30 -0000 Subject: [issue1457] IDLE - configDialog - new layout for key config Message-ID: <1195399530.13.0.0197942557234.issue1457@psf.upfronthosting.co.za> New submission from Tal Einat: As brought up on the idle-dev mailing list, I have redesigned the key config window. The new layout is two wide frames one above the other, instead of two tall frames side-by-side. This allows the key-binding entries to be completely visible in the listbox. ---------- components: IDLE files: IDLE_configDialog.071118.patch messages: 57617 nosy: kbk, taleinat severity: normal status: open title: IDLE - configDialog - new layout for key config versions: Python 2.5, Python 2.6 Added file: http://bugs.python.org/file8771/IDLE_configDialog.071118.patch __________________________________ Tracker __________________________________ -------------- next part -------------- A non-text attachment was scrubbed... Name: IDLE_configDialog.071118.patch Type: application/octet-stream Size: 4136 bytes Desc: not available Url : http://mail.python.org/pipermail/python-bugs-list/attachments/20071118/b7fe1a1e/attachment-0001.obj From report at bugs.python.org Sun Nov 18 18:44:10 2007 From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=) Date: Sun, 18 Nov 2007 17:44:10 -0000 Subject: [issue1489051] keyword and topic help broken in Pythonwin IDE Message-ID: <1195407850.04.0.832838046758.issue1489051@psf.upfronthosting.co.za> Martin v. L?wis added the comment: The reason this is not part of the Windows installer is twofold: a) nobody ever thought of making it so, ever since the htmlhelp was added, and b) no code was contributed to add such a procedure to the Windows installer. Contributions are welcome, although I would prefer a way to open htmlhelp from IDLE, rather than more-than-doubling the size of the installed documentation. _____________________________________ Tracker _____________________________________ From report at bugs.python.org Sun Nov 18 18:58:04 2007 From: report at bugs.python.org (Greg Chapman) Date: Sun, 18 Nov 2007 17:58:04 -0000 Subject: [issue1720250] PyGILState_Ensure does not acquires GIL Message-ID: <1195408684.75.0.0420859511841.issue1720250@psf.upfronthosting.co.za> Greg Chapman added the comment: In my embedding, I use the following (adapting the example above): // initialize the Python interpreter Py_Initialize(); PyEval_InitThreads(); /* Swap out and return current thread state and release the GIL */ PyThreadState tstate = PyEval_SaveThread(); PyGILState_STATE gstate; gstate = PyGILState_Ensure(); PyRun_SimpleString("import random\n"); PyGILState_Release(gstate); You don't have to free the tstate returned by PyEval_SaveThread because it is the thread state of the main thread (as established during Py_Initialize), and so it will be freed during Python's shut-down. I think in general you should rarely need to call PyEval_ReleaseLock directly; instead use PyEval_SaveThread, the Py_BEGIN_ALLOW_THREADS macro, or PyGILState_Release (as appropriate). The documentation should probably say as much. ---------- nosy: +glchapman21 _____________________________________ Tracker _____________________________________ From report at bugs.python.org Sun Nov 18 21:23:38 2007 From: report at bugs.python.org (Christian Heimes) Date: Sun, 18 Nov 2007 20:23:38 -0000 Subject: [issue1449] make msi work the vs 2005(MSVC8) Message-ID: <1195417418.72.0.45979451943.issue1449@psf.upfronthosting.co.za> Christian Heimes added the comment: I've used parts of the patch for the MSI fix for VS 2008. I've got most of the VS 2008 related changes done. Have a look. ---------- resolution: -> wont fix status: open -> closed __________________________________ Tracker __________________________________ From report at bugs.python.org Sun Nov 18 21:36:04 2007 From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=) Date: Sun, 18 Nov 2007 20:36:04 -0000 Subject: [issue1337] Tools/msi/msi.py does not work with PCBuild8 Message-ID: <1195418164.35.0.994888323018.issue1337@psf.upfronthosting.co.za> Martin v. L?wis added the comment: kevinwatters: don't bother fixing msi.py. I'll update it whenever I make a release; there is little point in updating it in-between. ---------- assignee: -> loewis nosy: +loewis __________________________________ Tracker __________________________________ From report at bugs.python.org Sun Nov 18 21:53:37 2007 From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=) Date: Sun, 18 Nov 2007 20:53:37 -0000 Subject: [issue1449] make msi work the vs 2005(MSVC8) Message-ID: <1195419217.83.0.45752149492.issue1449@psf.upfronthosting.co.za> Martin v. L?wis added the comment: Did you test the change for VS 2003? In my MSMDir (C:\Programme\Gemeinsame Dateien\Merge Modules), I only have the following files GDIPlus.msm msmask32_X86.msm msmask32_X86_ENU.msm VB_Control_mschart_RTL_X86_---.msm VB_Control_mschart_RTL_X86_ENU.msm VC_User_ATL71_RTL_X86_---.msm VC_User_CRT71_RTL_X86_---.msm VC_User_MFC71_Loc_RTL_X86_---.msm VC_User_MFC71_RTL_X86_---.msm VC_User_STL71_RTL_X86_---.msm VJSharpRedist_x86.msm WMIUTILS_RTL_X86_---.msm WMI_DECOUPLED_PROVIDER_RTL_X86_---.msm So at least on my system, the assertion is triggered that the file is not found. The other changes look fine. Just in case it isn't clear: you can add a config.py to your msi directory, to set things like PCBUILD and MSVCR to the values you like. __________________________________ Tracker __________________________________ From report at bugs.python.org Sun Nov 18 21:57:12 2007 From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=) Date: Sun, 18 Nov 2007 20:57:12 -0000 Subject: [issue1354] windows installer problem Message-ID: <1195419432.68.0.25327096169.issue1354@psf.upfronthosting.co.za> Martin v. L?wis added the comment: Closing because of lack of activity. ---------- resolution: -> works for me status: open -> closed __________________________________ Tracker __________________________________ From report at bugs.python.org Sun Nov 18 22:36:11 2007 From: report at bugs.python.org (Christian Heimes) Date: Sun, 18 Nov 2007 21:36:11 -0000 Subject: [issue1449] make msi work the vs 2005(MSVC8) In-Reply-To: <1195419217.83.0.45752149492.issue1449@psf.upfronthosting.co.za> Message-ID: <4740B049.8040806@cheimes.de> Christian Heimes added the comment: Martin v. L?wis wrote: > Martin v. L?wis added the comment: > > Did you test the change for VS 2003? In my MSMDir > (C:\Programme\Gemeinsame Dateien\Merge Modules), I only have the > following files > > GDIPlus.msm > msmask32_X86.msm > msmask32_X86_ENU.msm > VB_Control_mschart_RTL_X86_---.msm > VB_Control_mschart_RTL_X86_ENU.msm > VC_User_ATL71_RTL_X86_---.msm > VC_User_CRT71_RTL_X86_---.msm > VC_User_MFC71_Loc_RTL_X86_---.msm > VC_User_MFC71_RTL_X86_---.msm > VC_User_STL71_RTL_X86_---.msm > VJSharpRedist_x86.msm > WMIUTILS_RTL_X86_---.msm > WMI_DECOUPLED_PROVIDER_RTL_X86_---.msm > > So at least on my system, the assertion is triggered that the file is > not found. I don't have the MSM files for 7.1, just the files for 8.0 and 9.0. I assume that the files are part of VS 2003. I don't have VS 2003 around. I only installed VS .NET 2003 and C++ Toolkit 2003 as described at http://wiki.python.org/moin/Building_Python_with_the_free_MS_C_Toolkit Feel free to revert my changes to the 7.1 code. Christian __________________________________ Tracker __________________________________ From report at bugs.python.org Sun Nov 18 23:14:27 2007 From: report at bugs.python.org (Joseph Armbruster) Date: Sun, 18 Nov 2007 22:14:27 -0000 Subject: [issue1458] installer crashes on attempted cancellation Message-ID: <1195424067.48.0.215930942967.issue1458@psf.upfronthosting.co.za> New submission from Joseph Armbruster: Operating System: OS Name: Microsoft Windows XP Professional OS Version: 5.1.2600 Service Pack 2 Build 2600 Using the latest Python 2.5.1.msi from: http://www.python.org/ftp/python/2.5.1/python-2.5.1.msi Perform the following steps: - launch python-2.5.1.msi - select next - select next - select Advanced - select cancel - select yes Issue: I think the issue may reside around line 698/699 in these lines of msi.py c = advanced.cancel("Cancel", "CompilePyc") c.event("SpawnDialog", "CancelDlg") I have vs2005, so I can not really test/utilize msi.py that easily. Note: If anyone can build an msi with vs2005 please give me the details on how you did so. My initial hackery went along the lines of: - built solution in release - modded msi.py for pcbuild8 - modded msisupport.mak to include libpath for msi.lib - ran python msi.py - ...told to run icons.mak in pc dir - ran icons.mak - reran python msi.py - built w9xpopen from PC/VC6/pcbuild solution ... realized I had to change msi.py for VisualStudio8.0 registry keys and quit here ... I was advised on #python that the Orcas Beta is where it's at, so I am downloading now. ---------- components: Installation, Windows messages: 57625 nosy: JosephArmbruster severity: minor status: open title: installer crashes on attempted cancellation type: crash versions: Python 2.5 __________________________________ Tracker __________________________________ From report at bugs.python.org Sun Nov 18 23:28:47 2007 From: report at bugs.python.org (Mark Hammond) Date: Sun, 18 Nov 2007 22:28:47 -0000 Subject: [issue1455] VS2008, quick hack for distutils.msvccompiler Message-ID: <1195424927.46.0.614077589181.issue1455@psf.upfronthosting.co.za> Changes by Mark Hammond: ---------- nosy: +mhammond __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Nov 19 00:01:34 2007 From: report at bugs.python.org (Gabriel Genellina) Date: Sun, 18 Nov 2007 23:01:34 -0000 Subject: [issue1459] Bugs lost on migration from Sourceforge Message-ID: <1195426894.43.0.983428714797.issue1459@psf.upfronthosting.co.za> New submission from Gabriel Genellina: I can't find the issue this mail refers to: http:// mail.python.org/ pipermail/ python-bugs- list/2006- April/ 033139.html As it was labeled "Bug item #1474680", I tried http:// bugs.python.org/ issue1474680 and got a 404 error. Using the Search form (either searching into Title or All Text) didn't get any results. (I had to remember to set the Status field to "don't care" instead of "open" each time, but this is another issue). ---------- components: None messages: 57626 nosy: gagenellina severity: normal status: open title: Bugs lost on migration from Sourceforge versions: 3rd party __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Nov 19 00:45:06 2007 From: report at bugs.python.org (Brett Cannon) Date: Sun, 18 Nov 2007 23:45:06 -0000 Subject: [issue1631171] implement warnings module in C Message-ID: <1195429506.0.0.672770939473.issue1631171@psf.upfronthosting.co.za> Brett Cannon added the comment: This version of test_warnings has tests for _warnings.c. It currently is failing as the second line of output for warnings has not been implemented yet for _warnings.c. But all the specified tests in my last comment have now been implemented. Added file: http://bugs.python.org/file8772/test_warnings.py _____________________________________ Tracker _____________________________________ -------------- next part -------------- A non-text attachment was scrubbed... Name: test_warnings.py Type: application/octet-stream Size: 7763 bytes Desc: not available Url : http://mail.python.org/pipermail/python-bugs-list/attachments/20071118/a138be95/attachment-0001.obj From report at bugs.python.org Mon Nov 19 01:59:09 2007 From: report at bugs.python.org (Brett Cannon) Date: Mon, 19 Nov 2007 00:59:09 -0000 Subject: [issue1459] Bugs lost on migration from Sourceforge Message-ID: <1195433949.24.0.978566016347.issue1459@psf.upfronthosting.co.za> Brett Cannon added the comment: This report should go to the meta tracker, not here. And the issue is known: see http://psf.upfronthosting.co.za/roundup/meta/issue149. ---------- nosy: +brett.cannon resolution: -> invalid status: open -> closed __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Nov 19 10:29:18 2007 From: report at bugs.python.org (=?utf-8?q?=C3=81rni_M=C3=A1r_J=C3=B3nsson?=) Date: Mon, 19 Nov 2007 09:29:18 -0000 Subject: [issue1460] codecs utf7 decoding error Message-ID: <1195464558.65.0.820353840757.issue1460@psf.upfronthosting.co.za> New submission from ?rni M?r J?nsson: There is a utf-7 decoding error when decoding strings which have a shift sequence at a certain place. To reproduce run the attached program on a file containing the string: "0123456789012345678901234567890123456789012345678901234567890123456789X+-". The shift sequence starts at character 72. The culprit seems to be in codecs.py: StreamReader.read. The input is split on the 72 character boundary, and the first decode call raises an exception since the shift sequence is not terminated. The second one falls back 1 character, raises no exception, but the previous exception is raised since there is no newline in the output (?). The lines I don't understand are, and are the ones raising the exception. if len(lines)<=1: raise ---------- files: utf7.py messages: 57629 nosy: arnimar severity: normal status: open title: codecs utf7 decoding error type: behavior versions: Python 2.5 Added file: http://bugs.python.org/file8773/utf7.py __________________________________ Tracker __________________________________ -------------- next part -------------- A non-text attachment was scrubbed... Name: utf7.py Type: application/octet-stream Size: 283 bytes Desc: not available Url : http://mail.python.org/pipermail/python-bugs-list/attachments/20071119/2cf0d705/attachment.obj From report at bugs.python.org Mon Nov 19 10:29:44 2007 From: report at bugs.python.org (=?utf-8?q?=C3=81rni_M=C3=A1r_J=C3=B3nsson?=) Date: Mon, 19 Nov 2007 09:29:44 -0000 Subject: [issue1460] codecs utf7 decoding error Message-ID: <1195464584.75.0.553965873488.issue1460@psf.upfronthosting.co.za> ?rni M?r J?nsson added the comment: Added a test file. Added file: http://bugs.python.org/file8774/test __________________________________ Tracker __________________________________ -------------- next part -------------- A non-text attachment was scrubbed... Name: test Type: application/octet-stream Size: 73 bytes Desc: not available Url : http://mail.python.org/pipermail/python-bugs-list/attachments/20071119/ee6d40f3/attachment.obj From report at bugs.python.org Mon Nov 19 11:47:06 2007 From: report at bugs.python.org (Jean-Marc Gillet) Date: Mon, 19 Nov 2007 10:47:06 -0000 Subject: [issue1461] 0**0 should raise an error Message-ID: <1195469222.56.0.177574351963.issue1461@psf.upfronthosting.co.za> Changes by Jean-Marc Gillet: ---------- nosy: jmgillet severity: minor status: open title: 0**0 should raise an error type: behavior __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Nov 19 11:51:04 2007 From: report at bugs.python.org (Jean-Marc Gillet) Date: Mon, 19 Nov 2007 10:51:04 -0000 Subject: [issue1461] 0**0 should raise an error Message-ID: <1195469464.23.0.231198567798.issue1461@psf.upfronthosting.co.za> New submission from Jean-Marc Gillet: The result is actually undefined, as x**0 gives 1 and 0**x gives 0. 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. >>> 1**0 1 >>> 0**1 0 >>> 0**0 1 ---------- components: +Interpreter Core versions: +Python 2.5 __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Nov 19 12:37:30 2007 From: report at bugs.python.org (Jean-Marc Gillet) Date: Mon, 19 Nov 2007 11:37:30 -0000 Subject: [issue1461] 0**0 should raise an error Message-ID: <1195472250.53.0.185309620064.issue1461@psf.upfronthosting.co.za> Jean-Marc Gillet added the comment: See http://en.wikipedia.org/wiki/Exponentiation "Zero to the zero power". There are pros and cons of 0**0==1 so if you mark this one as "wontfix" I promise not to bother you again :-) __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Nov 19 13:50:17 2007 From: report at bugs.python.org (=?utf-8?q?Walter_D=C3=B6rwald?=) Date: Mon, 19 Nov 2007 12:50:17 -0000 Subject: [issue1444] utf_8_sig streamreader bug, patch, and test Message-ID: <1195476617.31.0.799707994905.issue1444@psf.upfronthosting.co.za> Walter D?rwald added the comment: Checked in your change and the test as r59049 (trunk) and r59050 (2.5). Thanks for the patch. ---------- resolution: -> fixed status: open -> closed __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Nov 19 14:58:16 2007 From: report at bugs.python.org (Nick Coghlan) Date: Mon, 19 Nov 2007 13:58:16 -0000 Subject: [issue1739468] Add a -z interpreter flag to execute a zip file Message-ID: <1195480696.72.0.0235987942016.issue1739468@psf.upfronthosting.co.za> Nick Coghlan added the comment: Reverted status to open until I figure out why the tests are failing on the Mac OSX buildbot. ---------- resolution: accepted -> status: closed -> open _____________________________________ Tracker _____________________________________ From report at bugs.python.org Mon Nov 19 16:51:39 2007 From: report at bugs.python.org (Kent Johnson) Date: Mon, 19 Nov 2007 15:51:39 -0000 Subject: [issue1462] About this document refers to SourceForge tracker Message-ID: <1195487498.98.0.226618413315.issue1462@psf.upfronthosting.co.za> New submission from Kent Johnson: "About this document" http://docs.python.org/lib/about.html still refers to "the Python Bug Tracker at SourceForge". The bug tracker link is incorrect (should be the new tracker) and the SF reference is obsolete. ---------- components: Documentation messages: 57635 nosy: kjohnson severity: normal status: open title: About this document refers to SourceForge tracker __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Nov 19 16:54:54 2007 From: report at bugs.python.org (Kent Johnson) Date: Mon, 19 Nov 2007 15:54:54 -0000 Subject: [issue1463] Minor error in mimetypes docs Message-ID: <1195487694.12.0.499193424755.issue1463@psf.upfronthosting.co.za> New submission from Kent Johnson: In the mimetypes module docs http://docs.python.org/lib/module-mimetypes.html the section on add_type() should read "When strict is *true (the default)* the mapping". ---------- components: Documentation messages: 57636 nosy: kjohnson severity: minor status: open title: Minor error in mimetypes docs __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Nov 19 16:58:15 2007 From: report at bugs.python.org (Guido van Rossum) Date: Mon, 19 Nov 2007 15:58:15 -0000 Subject: [issue1739468] Add a -z interpreter flag to execute a zip file Message-ID: <1195487895.22.0.857745489439.issue1739468@psf.upfronthosting.co.za> Guido van Rossum added the comment: I can look into this, as I have OSX on my laptop. _____________________________________ Tracker _____________________________________ From report at bugs.python.org Mon Nov 19 17:31:52 2007 From: report at bugs.python.org (Facundo Batista) Date: Mon, 19 Nov 2007 16:31:52 -0000 Subject: [issue1463] Minor error in mimetypes docs Message-ID: <1195489912.12.0.18442894054.issue1463@psf.upfronthosting.co.za> Facundo Batista added the comment: Fixed in the trunk (rev 59053). Thank you! ---------- nosy: +facundobatista resolution: -> fixed status: open -> closed __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Nov 19 17:32:18 2007 From: report at bugs.python.org (zouguangxian) Date: Mon, 19 Nov 2007 16:32:18 -0000 Subject: [issue1464] inet_pton redefined while building with windows SDK 6.0 Message-ID: <1195489938.2.0.108560909512.issue1464@psf.upfronthosting.co.za> New submission from zouguangxian: in Microsoft SDKs\Windows\v6.0A\Include\ws2tcpip.h, inet_pton was defined when NTDDI_VERSION >= NTDDI_LONGHORN with the following lines: #if (NTDDI_VERSION >= NTDDI_LONGHORN) WINSOCK_API_LINKAGE INT WSAAPI inet_pton( __in INT Family, __in PCSTR pszAddrString, __out_bcount(sizeof(IN6_ADDR)) PVOID pAddrBuf ); ... ... so in socketmodule.c, inet_pton should not be defined in such a situation. ---------- components: Library (Lib) files: socketmodule.c.patch messages: 57639 nosy: weck severity: normal status: open title: inet_pton redefined while building with windows SDK 6.0 type: compile error versions: Python 2.6 Added file: http://bugs.python.org/file8775/socketmodule.c.patch __________________________________ Tracker __________________________________ -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: socketmodule.c.patch Url: http://mail.python.org/pipermail/python-bugs-list/attachments/20071119/8409f005/attachment.txt From report at bugs.python.org Mon Nov 19 18:21:36 2007 From: report at bugs.python.org (Guido van Rossum) Date: Mon, 19 Nov 2007 17:21:36 -0000 Subject: [issue1461] 0**0 should raise an error Message-ID: <1195492896.39.0.882239169347.issue1461@psf.upfronthosting.co.za> Guido van Rossum added the comment: Right. ---------- nosy: +gvanrossum resolution: -> wont fix status: open -> closed __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Nov 19 18:30:31 2007 From: report at bugs.python.org (Guido van Rossum) Date: Mon, 19 Nov 2007 17:30:31 -0000 Subject: [issue1739468] Add a -z interpreter flag to execute a zip file Message-ID: <1195493431.7.0.632400328276.issue1739468@psf.upfronthosting.co.za> Guido van Rossum added the comment: Actually the failures aren't OSX-specific: ====================================================================== FAIL: test_directory (__main__.CmdLineTest) ---------------------------------------------------------------------- Traceback (most recent call last): File "Lib/test/test_cmd_line_script.py", line 117, in test_directory self._check_script(script_dir, script_name, script_dir) File "Lib/test/test_cmd_line_script.py", line 96, in _check_script self.assertEqual(exit_code, 0, data) AssertionError: /usr/local/google/home/guido/python/py3k/python: '/tmp/tmpLGqOxc' is a directory, cannot continue ====================================================================== FAIL: test_directory_compiled (__main__.CmdLineTest) ---------------------------------------------------------------------- Traceback (most recent call last): File "Lib/test/test_cmd_line_script.py", line 124, in test_directory_compiled self._check_script(script_dir, compiled_name, script_dir) File "Lib/test/test_cmd_line_script.py", line 96, in _check_script self.assertEqual(exit_code, 0, data) AssertionError: /usr/local/google/home/guido/python/py3k/python: '/tmp/tmprNwPih' is a directory, cannot continue ====================================================================== FAIL: test_zipfile (__main__.CmdLineTest) ---------------------------------------------------------------------- Traceback (most recent call last): File "Lib/test/test_cmd_line_script.py", line 130, in test_zipfile self._check_script(zip_name, None, zip_name) File "Lib/test/test_cmd_line_script.py", line 96, in _check_script self.assertEqual(exit_code, 0, data) AssertionError: File "/tmp/tmpInCAJO/test_zip.zip", line 1 PK# statements being executed ^ SyntaxError: invalid syntax [25429 refs] ====================================================================== FAIL: test_zipfile_compiled (__main__.CmdLineTest) ---------------------------------------------------------------------- Traceback (most recent call last): File "Lib/test/test_cmd_line_script.py", line 137, in test_zipfile_compiled self._check_script(zip_name, None, zip_name) File "Lib/test/test_cmd_line_script.py", line 96, in _check_script self.assertEqual(exit_code, 0, data) AssertionError: File "/tmp/tmpqh6g1C/test_zip.zip", line 1 SyntaxError: Non-UTF-8 code starting with '\xc8' in file /tmp/tmpqh6g1C/test_zip.zip on line 2, but no encoding declared; see http://python.org/dev/peps/pep-0263/ for details [25428 refs] _____________________________________ Tracker _____________________________________ From report at bugs.python.org Mon Nov 19 18:39:15 2007 From: report at bugs.python.org (zouguangxian) Date: Mon, 19 Nov 2007 17:39:15 -0000 Subject: [issue1465] building python 2.6 with VC Express 2008 Beta2 Message-ID: <1195493955.75.0.351065554701.issue1465@psf.upfronthosting.co.za> zouguangxian added the comment: patch of socketmodule.c. Added file: http://bugs.python.org/file8777/socketmodule.c.patch __________________________________ Tracker __________________________________ -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: socketmodule.c.patch Url: http://mail.python.org/pipermail/python-bugs-list/attachments/20071119/d7b424e3/attachment-0001.txt From report at bugs.python.org Mon Nov 19 18:40:13 2007 From: report at bugs.python.org (zouguangxian) Date: Mon, 19 Nov 2007 17:40:13 -0000 Subject: [issue1465] building python 2.6 with VC Express 2008 Beta2 Message-ID: <1195494013.83.0.962910511839.issue1465@psf.upfronthosting.co.za> zouguangxian added the comment: patch of tix8.4.2 Added file: http://bugs.python.org/file8778/tix8.4.2.patch __________________________________ Tracker __________________________________ -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: tix8.4.2.patch Url: http://mail.python.org/pipermail/python-bugs-list/attachments/20071119/609bc30c/attachment.txt From report at bugs.python.org Mon Nov 19 18:40:42 2007 From: report at bugs.python.org (Guido van Rossum) Date: Mon, 19 Nov 2007 17:40:42 -0000 Subject: [issue1739468] Add a -z interpreter flag to execute a zip file Message-ID: <1195494042.39.0.981632840581.issue1739468@psf.upfronthosting.co.za> Guido van Rossum added the comment: Oops, those are failures under 3.0, probably due to Crys's merge. On Linux, the 2.6 version of the test doesn't fail. I see 2 failing tests on OSX with the 2.6 version, which I will look into. _____________________________________ Tracker _____________________________________ From report at bugs.python.org Mon Nov 19 18:51:43 2007 From: report at bugs.python.org (Guido van Rossum) Date: Mon, 19 Nov 2007 17:51:43 -0000 Subject: [issue1739468] Add a -z interpreter flag to execute a zip file Message-ID: <1195494703.96.0.00107886041924.issue1739468@psf.upfronthosting.co.za> Guido van Rossum added the comment: Fixed the OSX failure in revision 59055; it was due to /tmp being a symlink, and fixed by application of realpath(). Keeping this open until the 3.0 version is working. _____________________________________ Tracker _____________________________________ From report at bugs.python.org Mon Nov 19 19:32:57 2007 From: report at bugs.python.org (=?utf-8?q?Erik_Anders=C3=A9n?=) Date: Mon, 19 Nov 2007 18:32:57 -0000 Subject: [issue1466] Special reporting of NotImplementedError in unittest Message-ID: <1195497176.97.0.346007507072.issue1466@psf.upfronthosting.co.za> New submission from Erik Anders?n: When a unittest test case raises an Exception, that test case is considered a failure. However, raising NotImplementedError is not a failure. It is something completely normal during development and simply indicates that the functionality has not yet been implemented. Compare this to a test case that genuinely fails, which means that the implementation does something different from what is is supposed to do. I therefore think test cases raising NotImplementedError should not be treated as failures, but be reported separately as what they are -- parts of the program that have not yet been implemented. Reporting such test cases as failures will give a lot of failure warnings that may detract attention from those cases that are genuinely errors. Also, SimpleTextRunner will report a lot of useless stack traces for these cases, thereby makeing it harder to find the stack traces for those tests that realy failed. I have made a patch to unittest that reports such cases as "not implemented" rather than as failures. This includes changes to the documentation and unit test case for unittest and doctest. I have included "added/changed in version 2.6" remarks in the documentation, so you have to changed these if the patch gets into some other version. Patch against 59056 attached ---------- components: Library (Lib) files: unittest.diff messages: 57648 nosy: erik_andersen severity: normal status: open title: Special reporting of NotImplementedError in unittest type: rfe Added file: http://bugs.python.org/file8780/unittest.diff __________________________________ Tracker __________________________________ -------------- next part -------------- A non-text attachment was scrubbed... Name: unittest.diff Type: application/octet-stream Size: 14884 bytes Desc: not available Url : http://mail.python.org/pipermail/python-bugs-list/attachments/20071119/de680a8e/attachment-0001.obj From report at bugs.python.org Mon Nov 19 19:38:58 2007 From: report at bugs.python.org (Guido van Rossum) Date: Mon, 19 Nov 2007 18:38:58 -0000 Subject: [issue1466] Special reporting of NotImplementedError in unittest Message-ID: <1195497538.13.0.0288627589047.issue1466@psf.upfronthosting.co.za> Guido van Rossum added the comment: No. If you're testing something that's not implemented, it is correct to see that as a failure. Talk to anyone doing TDD. ---------- nosy: +gvanrossum resolution: -> wont fix status: open -> closed __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Nov 19 19:39:55 2007 From: report at bugs.python.org (Guido van Rossum) Date: Mon, 19 Nov 2007 18:39:55 -0000 Subject: [issue1739468] Add a -z interpreter flag to execute a zip file Message-ID: <1195497595.78.0.565621143534.issue1739468@psf.upfronthosting.co.za> Guido van Rossum added the comment: 3.0 fix committed as revision 59058. ---------- resolution: -> accepted status: open -> closed versions: +Python 3.0 _____________________________________ Tracker _____________________________________ From report at bugs.python.org Mon Nov 19 19:42:02 2007 From: report at bugs.python.org (Christian Heimes) Date: Mon, 19 Nov 2007 18:42:02 -0000 Subject: [issue1465] building python 2.6 with VC Express 2008 Beta2 Message-ID: <1195497722.25.0.0863766197323.issue1465@psf.upfronthosting.co.za> Changes by Christian Heimes: Removed file: http://bugs.python.org/file8779/ml.exe __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Nov 19 19:42:49 2007 From: report at bugs.python.org (Raghuram Devarakonda) Date: Mon, 19 Nov 2007 18:42:49 -0000 Subject: [issue1466] Special reporting of NotImplementedError in unittest Message-ID: <1195497769.34.0.354512743514.issue1466@psf.upfronthosting.co.za> Raghuram Devarakonda added the comment: I don't think unittest automatically treats all exceptions as failures. Failures are those that are explicitly flagged with assert* and fail* methods. All other exceptions result in "errors". I think what you are asking for is to special case one such error but am not sure if it is worth it. ---------- nosy: +draghuram __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Nov 19 19:46:38 2007 From: report at bugs.python.org (Christian Heimes) Date: Mon, 19 Nov 2007 18:46:38 -0000 Subject: [issue1465] building python 2.6 with VC Express 2008 Beta2 Message-ID: <1195497998.64.0.663093944204.issue1465@psf.upfronthosting.co.za> Christian Heimes added the comment: I've removed the ml.exe. Please do NOT upload copyright protected material here. You should really coordinate your effort with us. :) I've already created a PCbuild9 directory in the py3k source tree. Once it is finished I'm going to backport it to 2.6. I'll have a look if I can use some of your ideas. My PCbuild9 directory builds all of the dependencies except of tcltk automatically - including separate 64bit builds. ---------- assignee: -> tiran keywords: +patch nosy: +tiran priority: -> normal __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Nov 19 19:50:04 2007 From: report at bugs.python.org (Christian Heimes) Date: Mon, 19 Nov 2007 18:50:04 -0000 Subject: [issue1464] inet_pton redefined while building with windows SDK 6.0 Message-ID: <1195498204.39.0.0579682745627.issue1464@psf.upfronthosting.co.za> Christian Heimes added the comment: I've solved the issue in the py3k differently. I've checked for !(defined(_MSC_VER) && _MSC_VER>1499) but your check is better. Thanks! ---------- assignee: -> tiran keywords: +patch, py3k nosy: +tiran priority: -> normal resolution: -> accepted versions: +Python 3.0 __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Nov 19 19:57:11 2007 From: report at bugs.python.org (Brett Cannon) Date: Mon, 19 Nov 2007 18:57:11 -0000 Subject: [issue1462] About this document refers to SourceForge tracker Message-ID: <1195498631.75.0.87864082487.issue1462@psf.upfronthosting.co.za> Brett Cannon added the comment: Fixed in r59059. ---------- nosy: +brett.cannon resolution: -> fixed status: open -> closed __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Nov 19 20:20:11 2007 From: report at bugs.python.org (=?utf-8?q?Erik_Anders=C3=A9n?=) Date: Mon, 19 Nov 2007 19:20:11 -0000 Subject: [issue1466] Special reporting of NotImplementedError in unittest In-Reply-To: <1195497769.34.0.354512743514.issue1466@psf.upfronthosting.co.za> Message-ID: <4741E1EA.5080301@rixtele.com> Erik Anders?n added the comment: Raghuram Devarakonda skrev: > Raghuram Devarakonda added the comment: > > I don't think unittest automatically treats all exceptions as failures. > Failures are those that are explicitly flagged with assert* and fail* > methods. All other exceptions result in "errors". I think what you are > asking for is to special case one such error but am not sure if it is > worth it. > > ---------- > nosy: +draghuram > > __________________________________ > Tracker > > __________________________________ > You are right, I used the wrong word. I mean that NotImplementedError should be treated as a special *error*. If you have ever written the test cases before you write the code, you will get a huge amount of uninteresting output from errors that come from tests to code you havn't written yet. This will drown the real errors and failures from the code you are actually testing and debugging. What I want is to have unittest report these differently so that I can see what are the real bugs the code, not to spam me with tracebacks I will never look at for test cases that refer to not implemented code. Erik __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Nov 19 20:21:52 2007 From: report at bugs.python.org (Guido van Rossum) Date: Mon, 19 Nov 2007 19:21:52 -0000 Subject: [issue1466] Special reporting of NotImplementedError in unittest Message-ID: <1195500112.49.0.435475081704.issue1466@psf.upfronthosting.co.za> Guido van Rossum added the comment: Sorry, just comment out those tests until you're ready to write the code. __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Nov 19 20:28:05 2007 From: report at bugs.python.org (Tal Einat) Date: Mon, 19 Nov 2007 19:28:05 -0000 Subject: [issue1705362] cannot change cursor color in IDLE Message-ID: <1195500484.99.0.960707705708.issue1705362@psf.upfronthosting.co.za> Tal Einat added the comment: Fixed in patch 1725576. ---------- title: cannot change cursor color in IDLE -> cannot change cursor color in IDLE _____________________________________ Tracker _____________________________________ From report at bugs.python.org Mon Nov 19 20:31:04 2007 From: report at bugs.python.org (=?utf-8?q?Erik_Anders=C3=A9n?=) Date: Mon, 19 Nov 2007 19:31:04 -0000 Subject: [issue1466] Special reporting of NotImplementedError in unittest In-Reply-To: <1195500112.49.0.435475081704.issue1466@psf.upfronthosting.co.za> Message-ID: <4741E478.8090700@rixtele.com> Erik Anders?n added the comment: Possible, but cumbersome. You have to analyze each case and see if it depends on code not written. When you implement a new piece of code, you have to go through all your tests to see if that one should be included. Also you don't get any reporting on the coverage of the code. If you accidentally forget to uncomment a test case, you may never realize that you have a bug -- at least not until it happens in real life. Erik __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Nov 19 20:51:57 2007 From: report at bugs.python.org (Raghuram Devarakonda) Date: Mon, 19 Nov 2007 19:51:57 -0000 Subject: [issue1466] Special reporting of NotImplementedError in unittest In-Reply-To: <4741E478.8090700@rixtele.com> Message-ID: <2c51ecee0711191151s235ce7f8g9d352c15c35cee65@mail.gmail.com> Raghuram Devarakonda added the comment: > Possible, but cumbersome. You have to analyze each case and see if it Have you tried to write a Test Runner that ignores NotImplementedError? You may have to override TestResult.addError. __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Nov 19 21:05:36 2007 From: report at bugs.python.org (Christian Heimes) Date: Mon, 19 Nov 2007 20:05:36 -0000 Subject: [issue1455] VS2008, quick hack for distutils.msvccompiler Message-ID: <1195502736.41.0.478771171277.issue1455@psf.upfronthosting.co.za> Christian Heimes added the comment: Updated compiler and linker args from the project command lines. Added file: http://bugs.python.org/file8781/py3k_vs2008_3.patch __________________________________ Tracker __________________________________ -------------- next part -------------- A non-text attachment was scrubbed... Name: py3k_vs2008_3.patch Type: text/x-diff Size: 18306 bytes Desc: not available Url : http://mail.python.org/pipermail/python-bugs-list/attachments/20071119/56312fd1/attachment-0001.patch From report at bugs.python.org Mon Nov 19 21:09:06 2007 From: report at bugs.python.org (Guido van Rossum) Date: Mon, 19 Nov 2007 20:09:06 -0000 Subject: [issue1466] Special reporting of NotImplementedError in unittest Message-ID: <1195502946.13.0.627677940316.issue1466@psf.upfronthosting.co.za> Guido van Rossum added the comment: Sorry Erik, but I don't think you should try to compensate for your flawed methodology by trying to change the unittest framework. End of discussion. __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Nov 19 21:09:26 2007 From: report at bugs.python.org (=?utf-8?q?Erik_Anders=C3=A9n?=) Date: Mon, 19 Nov 2007 20:09:26 -0000 Subject: [issue1466] Special reporting of NotImplementedError in unittest In-Reply-To: <2c51ecee0711191151s235ce7f8g9d352c15c35cee65@mail.gmail.com> Message-ID: <4741ED75.40105@rixtele.com> Erik Anders?n added the comment: No, I definitely don't want to ignore them, I want them reported in a manner that is relevant to them. Just say that the test was not implemented. No tracebacks for debugging since there is nothing to debug. In addition to a TestRunner I need a new TestCase and a new TestResult, which is what is in the patch, although I changed the classes rather than inherit from them. Erik __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Nov 19 21:23:59 2007 From: report at bugs.python.org (Raghuram Devarakonda) Date: Mon, 19 Nov 2007 20:23:59 -0000 Subject: [issue1467] error in TestResult.addError and TestResult.addFailure Message-ID: <1195503839.36.0.580839087549.issue1467@psf.upfronthosting.co.za> New submission from Raghuram Devarakonda: The page at http://docs.python.org/dev/library/unittest.html#module-unittest says: ------------- TestResult.addError(test, err) Called when the test case test raises an unexpected exception err is a tuple of the form returned by sys.exc_info(): (type, value, traceback). The default implementation appends (test, err) to the instance's errors attribute. -------------- Starting from 2.2, a formatted traceback is added to the "error" attribute instead of the actual sys.exc_info(). The same error is present for addFailure() as well. ---------- components: Documentation messages: 57663 nosy: draghuram severity: minor status: open title: error in TestResult.addError and TestResult.addFailure versions: Python 2.6 __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Nov 19 21:35:55 2007 From: report at bugs.python.org (Amaury Forgeot d'Arc) Date: Mon, 19 Nov 2007 20:35:55 -0000 Subject: [issue1395] py3k: duplicated line endings when using read(1) Message-ID: <1195504555.09.0.17801572371.issue1395@psf.upfronthosting.co.za> Amaury Forgeot d'Arc added the comment: Committed the patch in r59060. ---------- resolution: -> fixed status: open -> closed __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Nov 19 21:44:02 2007 From: report at bugs.python.org (Christian Heimes) Date: Mon, 19 Nov 2007 20:44:02 -0000 Subject: [issue1337] Tools/msi/msi.py does not work with PCBuild8 Message-ID: <1195505042.47.0.483477275778.issue1337@psf.upfronthosting.co.za> Christian Heimes added the comment: Just for your information, Kevin: I've created a PCbuild9 directory for VS 2008 Beta 2 in the py3k branch. I've also changed msi.py to work with PCbuild and PCbuild9. __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Nov 19 22:15:46 2007 From: report at bugs.python.org (Paul Moore) Date: Mon, 19 Nov 2007 21:15:46 -0000 Subject: [issue1468] MSI installer does not include SSL test .pem files Message-ID: <1195506946.17.0.77518817492.issue1468@psf.upfronthosting.co.za> New submission from Paul Moore: The latest MSI daily snapshot installer for Python 2.6 (19 Nov) does not include the .pem files for the SSL tests from the Lib\test directory. ---------- components: Installation messages: 57666 nosy: pmoore severity: normal status: open title: MSI installer does not include SSL test .pem files versions: Python 2.6 __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Nov 19 22:16:14 2007 From: report at bugs.python.org (Bill Janssen) Date: Mon, 19 Nov 2007 21:16:14 -0000 Subject: [issue1469] SSL tests leak memory Message-ID: <1195506974.1.0.683741449371.issue1469@psf.upfronthosting.co.za> New submission from Bill Janssen: I'm seeing leaks in the test_ssl run, after various socket.py changes. I'm looking into it. ---------- assignee: janssen components: Library (Lib) keywords: py3k messages: 57667 nosy: janssen severity: normal status: open title: SSL tests leak memory versions: Python 3.0 __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Nov 19 22:35:14 2007 From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=) Date: Mon, 19 Nov 2007 21:35:14 -0000 Subject: [issue1468] MSI installer does not include SSL test .pem files Message-ID: <1195508113.98.0.626160893775.issue1468@psf.upfronthosting.co.za> Martin v. L?wis added the comment: Thanks for pointing that out. The MSI build needs to be taught to pick them up. If I seemingly don't find the time, feel free to contribute a patch. ---------- assignee: -> loewis nosy: +loewis __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Nov 19 22:54:44 2007 From: report at bugs.python.org (Paul Moore) Date: Mon, 19 Nov 2007 21:54:44 -0000 Subject: [issue1468] MSI installer does not include SSL test .pem files Message-ID: <1195509284.0.0.273097475699.issue1468@psf.upfronthosting.co.za> Paul Moore added the comment: The following looks like it may be OK. I have no way of testing it, unfortunately, as I don't currently have a working build environment, and I've no idea how to build the MSI even if I did... Added file: http://bugs.python.org/file8782/msi.patch __________________________________ Tracker __________________________________ -------------- next part -------------- A non-text attachment was scrubbed... Name: msi.patch Type: application/octet-stream Size: 477 bytes Desc: not available Url : http://mail.python.org/pipermail/python-bugs-list/attachments/20071119/4cd8cdea/attachment.obj From report at bugs.python.org Tue Nov 20 00:45:19 2007 From: report at bugs.python.org (zouguangxian) Date: Mon, 19 Nov 2007 23:45:19 -0000 Subject: [issue1465] building python 2.6 with VC Express 2008 Beta2 Message-ID: <1195515919.79.0.206035723064.issue1465@psf.upfronthosting.co.za> zouguangxian added the comment: hi tiran, thanks for your suggest. :-) what can i do in the next? it's my pleasure to contribute my effort to python. It's seems that directory configurations of Visual Studio 2005/Visual C Express 2008 are stored in C:\Documents and Settings\USERNAME\Local Settings\Application Data\Microsoft\VisualStudio\8.0\VCComponents.dat or C:\Documents and Settings\USERNAME\Local Settings\Application Data\Microsoft\VCExpress\9.0\VCComponents.dat devenv.exe/VCExpress.exe must be run first, this file will be created automatically. [VC\VC_OBJECTS_PLATFORM_INFO\Win32\Directories] Include Dirs=$(VCInstallDir)include;$(VCInstallDir) atlmfc\include;$(WindowsSdkDir)\include;$(FrameworkSDKDir)include Reference Dirs=$(FrameworkDir)$(FrameworkVersion);$(VCInstallDir) atlmfc\lib;$(VCInstallDir)lib Library Dirs=$(VCInstallDir)lib;$(VCInstallDir) atlmfc\lib;$(VCInstallDir)atlmfc\lib\i386;$(WindowsSdkDir) \lib;$(FrameworkSDKDir)lib;$(VSInstallDir);$(VSInstallDir)lib Source Dirs=$(VCInstallDir)atlmfc\src\mfc;$(VCInstallDir) atlmfc\src\mfcm;$(VCInstallDir)atlmfc\src\atl;$(VCInstallDir)crt\src Exclude Dirs=$(VCInstallDir)include;$(VCInstallDir) atlmfc\include;$(WindowsSdkDir)\include;$(FrameworkSDKDir) include;$(FrameworkDir)$(FrameworkVersion);$(VCInstallDir) atlmfc\lib;$(VCInstallDir)lib Path Dirs=$(VCInstallDir)bin;$(WindowsSdkDir)\bin;$(VSInstallDir)Common7 \Tools\bin;$(VSInstallDir)Common7\tools;$(VSInstallDir)Common7 \ide;$(ProgramFiles)\HTML Help Workshop;$(FrameworkSDKDir) bin;$(FrameworkDir)$(FrameworkVersion);$(VSInstallDir);$(SystemRoot) \SysWow64;$(FxCopDir);$(PATH) SCons has done some work on detecting msvc compiler. :-) msi.py should extract msvcrxx.dll from *Merge Modules* or *redist* directory. __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Nov 20 01:13:13 2007 From: report at bugs.python.org (Christian Heimes) Date: Tue, 20 Nov 2007 00:13:13 -0000 Subject: [issue1470] py3k unit tests are removing %TEMP% dir on Windows Message-ID: <1195517593.78.0.154207938544.issue1470@psf.upfronthosting.co.za> New submission from Christian Heimes: The unit test suite of py3k is removing the official %TEMP% directory of Windows. It's not only causing errors in the test suite but also creating havoc with other apps. I'm not sure if it is related to my PCbuild9 or some changes to the unit test suite. Since the update to VS 2008 I can't build the PCbuild any more due to some .NET problems with Nant. ---------- keywords: py3k messages: 57672 nosy: tiran priority: urgent severity: urgent status: open title: py3k unit tests are removing %TEMP% dir on Windows type: behavior versions: Python 3.0 __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Nov 20 01:27:08 2007 From: report at bugs.python.org (fbvortex) Date: Tue, 20 Nov 2007 00:27:08 -0000 Subject: [issue1471] ioctl doesn't work properly on 64-bit OpenBSD Message-ID: <1195518427.96.0.197538707678.issue1471@psf.upfronthosting.co.za> New submission from fbvortex: The following lines of code work on Linux platforms (amd64), and 32-bit OpenBSD (i386), but not on 64-bit OpenBSD platforms (at least not on amd64 or sparc64): import fcntl,os,pty,termios,select,sys,struct,pwd,signal,os pid,fd=pty.fork() fcntl.ioctl(fd, termios.TIOCSWINSZ, struct.pack("HHHH",80,25,0,0)) This gives an "IOError: [Errno 25] Inappropriate ioctl for device" exception. The python version in question on OpenBSD is: Python 2.5.1 (r251:54863, Nov 16 2007, 18:16:44) [GCC 3.3.5 (propolice)] on openbsd4 The winsize structure as dumped using sizeof(struct winsize) under OpenBSD/sparc64 is 8 bytes large, and so is the result from the struct.pack operation. Forcing the endianness big or little in the struct.pack formatting string has no effect on the error. ---------- messages: 57673 nosy: fbvortex severity: normal status: open title: ioctl doesn't work properly on 64-bit OpenBSD type: behavior versions: Python 2.5 __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Nov 20 01:33:56 2007 From: report at bugs.python.org (Gabriel Genellina) Date: Tue, 20 Nov 2007 00:33:56 -0000 Subject: [issue1393] function comparing lacks NotImplemented error Message-ID: <1195518836.3.0.411252374747.issue1393@psf.upfronthosting.co.za> Changes by Gabriel Genellina: ---------- nosy: +gagenellina __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Nov 20 01:45:18 2007 From: report at bugs.python.org (Christian Heimes) Date: Tue, 20 Nov 2007 00:45:18 -0000 Subject: [issue1452] subprocess's popen.stdout.seek(0) doesn't raise an error Message-ID: <1195519518.31.0.00672951321101.issue1452@psf.upfronthosting.co.za> Changes by Christian Heimes: ---------- priority: -> normal __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Nov 20 01:47:46 2007 From: report at bugs.python.org (Christian Heimes) Date: Tue, 20 Nov 2007 00:47:46 -0000 Subject: [issue1377] test_import breaks on Linux Message-ID: <1195519666.59.0.389797052499.issue1377@psf.upfronthosting.co.za> Christian Heimes added the comment: Martin gave some insight into the problem http://permalink.gmane.org/gmane.comp.python.python-3000.devel/10949 The test isn't going to work on systems that don't support UTF-8. ---------- priority: -> normal __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Nov 20 01:49:18 2007 From: report at bugs.python.org (Christian Heimes) Date: Tue, 20 Nov 2007 00:49:18 -0000 Subject: [issue1438] Calling base class methods is slow due to __instancecheck__ override in abc.py Message-ID: <1195519758.2.0.355627721356.issue1438@psf.upfronthosting.co.za> Christian Heimes added the comment: I think the problem should be addressed after alpha 2. ---------- keywords: +py3k nosy: +tiran priority: -> normal __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Nov 20 01:50:01 2007 From: report at bugs.python.org (fbvortex) Date: Tue, 20 Nov 2007 00:50:01 -0000 Subject: [issue1471] ioctl doesn't work properly on 64-bit OpenBSD Message-ID: <1195519801.6.0.573676343438.issue1471@psf.upfronthosting.co.za> fbvortex added the comment: The following C code, when compiled with -lutil runs without reporting any errors on both the sparc64 and i386 platforms on OpenBSD: #include #include #include #include #include int main(void) { int fd; struct winsize w; w.ws_row = 25; w.ws_col = 80; w.ws_xpixel = w.ws_ypixel = 0; forkpty(&fd, NULL, NULL, NULL); if (ioctl(fd,TIOCSWINSZ, &w) == -1) perror("ioctl"); return 0; } __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Nov 20 01:50:18 2007 From: report at bugs.python.org (Christian Heimes) Date: Tue, 20 Nov 2007 00:50:18 -0000 Subject: [issue1276] LookupError: unknown encoding: X-MAC-JAPANESE Message-ID: <1195519818.59.0.632864750212.issue1276@psf.upfronthosting.co.za> Changes by Christian Heimes: ---------- keywords: +py3k priority: -> normal __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Nov 20 01:51:03 2007 From: report at bugs.python.org (Christian Heimes) Date: Tue, 20 Nov 2007 00:51:03 -0000 Subject: [issue1257] atexit errors should result in nonzero exit code Message-ID: <1195519863.21.0.995507128553.issue1257@psf.upfronthosting.co.za> Christian Heimes added the comment: The issue should be addressed in the C code. ---------- assignee: -> gvanrossum nosy: +gvanrossum, tiran priority: -> normal __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Nov 20 02:13:22 2007 From: report at bugs.python.org (Christian Heimes) Date: Tue, 20 Nov 2007 01:13:22 -0000 Subject: [issue1193] os.system() encoding bug on Windows Message-ID: <1195521202.63.0.844126189671.issue1193@psf.upfronthosting.co.za> Christian Heimes added the comment: Amaury is planing to remove Win95 code and use the wide api everywhere. It should fix the bug. ---------- assignee: -> amaury.forgeotdarc components: +Interpreter Core, Windows -Library (Lib) nosy: +amaury.forgeotdarc priority: high -> normal resolution: accepted -> __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Nov 20 02:13:57 2007 From: report at bugs.python.org (Christian Heimes) Date: Tue, 20 Nov 2007 01:13:57 -0000 Subject: [issue1374] IDLE - minor FormatParagraph bug fix Message-ID: <1195521237.16.0.454873613827.issue1374@psf.upfronthosting.co.za> Changes by Christian Heimes: ---------- assignee: -> gvanrossum nosy: +gvanrossum priority: -> normal __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Nov 20 02:14:26 2007 From: report at bugs.python.org (Christian Heimes) Date: Tue, 20 Nov 2007 01:14:26 -0000 Subject: [issue1470] py3k unit tests are removing %TEMP% dir on Windows Message-ID: <1195521266.77.0.5369200232.issue1470@psf.upfronthosting.co.za> Christian Heimes added the comment: I may have nailed down the issue to test_shutil.test_copytree_simple __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Nov 20 02:16:13 2007 From: report at bugs.python.org (Christian Heimes) Date: Tue, 20 Nov 2007 01:16:13 -0000 Subject: [issue1234] semaphore errors on AIX 5.2 Message-ID: <1195521373.81.0.541883271273.issue1234@psf.upfronthosting.co.za> Changes by Christian Heimes: ---------- assignee: -> gvanrossum nosy: +gvanrossum __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Nov 20 02:16:38 2007 From: report at bugs.python.org (Christian Heimes) Date: Tue, 20 Nov 2007 01:16:38 -0000 Subject: [issue718532] inspect, class instances and __getattr__ Message-ID: <1195521398.65.0.126152698081.issue718532@psf.upfronthosting.co.za> Changes by Christian Heimes: ---------- nosy: +gvanrossum ____________________________________ Tracker ____________________________________ From report at bugs.python.org Tue Nov 20 02:16:55 2007 From: report at bugs.python.org (Christian Heimes) Date: Tue, 20 Nov 2007 01:16:55 -0000 Subject: [issue1020] pyexpat.XMParserType broken (was: pydoc doesn't work on pyexpat) Message-ID: <1195521415.27.0.51492832793.issue1020@psf.upfronthosting.co.za> Changes by Christian Heimes: ---------- nosy: +gvanrossum __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Nov 20 02:17:22 2007 From: report at bugs.python.org (Christian Heimes) Date: Tue, 20 Nov 2007 01:17:22 -0000 Subject: [issue1372] zlibmodule.c: int overflow in PyZlib_decompress Message-ID: <1195521442.74.0.648579615139.issue1372@psf.upfronthosting.co.za> Changes by Christian Heimes: ---------- assignee: nnorwitz -> gvanrossum __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Nov 20 02:18:01 2007 From: report at bugs.python.org (Christian Heimes) Date: Tue, 20 Nov 2007 01:18:01 -0000 Subject: [issue1067] test_smtplib failures (caused by asyncore) Message-ID: <1195521481.01.0.866999851256.issue1067@psf.upfronthosting.co.za> Christian Heimes added the comment: Guido, what needs to be done here? ---------- nosy: +tiran __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Nov 20 02:31:56 2007 From: report at bugs.python.org (Amaury Forgeot d'Arc) Date: Tue, 20 Nov 2007 01:31:56 -0000 Subject: [issue1342] Crash on Windows if Python runs from a directory with umlauts Message-ID: <1195522316.27.0.896833663073.issue1342@psf.upfronthosting.co.za> Amaury Forgeot d'Arc added the comment: Assign to myself. Among the things to do, use Py_FileSystemDefaultEncoding (=mbcs on Windows) to encode sys.path items; likewise in NullImporter_init and other functions. So many places to change, we need serious testcases. ---------- assignee: -> amaury.forgeotdarc nosy: +amaury.forgeotdarc __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Nov 20 02:49:17 2007 From: report at bugs.python.org (Christian Heimes) Date: Tue, 20 Nov 2007 01:49:17 -0000 Subject: [issue1470] py3k unit tests are removing %TEMP% dir on Windows Message-ID: <1195523357.43.0.839500796127.issue1470@psf.upfronthosting.co.za> Christian Heimes added the comment: My bad, os.removedirs is removing all parent directories until it hits a non empty dir. Fixed in r59063 and r59064 ---------- resolution: -> fixed status: open -> closed versions: +Python 2.6 __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Nov 20 02:56:23 2007 From: report at bugs.python.org (Christian Heimes) Date: Tue, 20 Nov 2007 01:56:23 -0000 Subject: [issue1465] building python 2.6 with VC Express 2008 Beta2 Message-ID: <1195523783.61.0.494776985721.issue1465@psf.upfronthosting.co.za> Christian Heimes added the comment: Have you studied my patch http://bugs.python.org/issue1455? I didn't want to parse some files. Instead I used a much simpler approach in my patch. I'm using the "vcvarsall.bat" to set up an environment and "set" to read the new environment from stdout. It works like a charm and it could even support cross compiling. __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Nov 20 03:00:03 2007 From: report at bugs.python.org (Brett Cannon) Date: Tue, 20 Nov 2007 02:00:03 -0000 Subject: [issue1692335] Fix exception pickling: Move initial args assignment to BaseException.__new__ Message-ID: <1195524003.24.0.840658862133.issue1692335@psf.upfronthosting.co.za> Changes by Brett Cannon: ---------- nosy: +brett.cannon _____________________________________ Tracker _____________________________________ From report at bugs.python.org Tue Nov 20 03:09:29 2007 From: report at bugs.python.org (Amaury Forgeot d'Arc) Date: Tue, 20 Nov 2007 02:09:29 -0000 Subject: [issue1193] os.system() encoding bug on Windows Message-ID: <1195524569.2.0.252030770509.issue1193@psf.upfronthosting.co.za> Amaury Forgeot d'Arc added the comment: Note that the final .encode("cp936") is now invalid: os.system accepts unicode strings, not bytes: >>> os.system(("echo " + sys.stdin.readline().rstrip("\n"))) Corrected as r59065. ---------- resolution: -> fixed status: open -> closed __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Nov 20 03:47:42 2007 From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=) Date: Tue, 20 Nov 2007 02:47:42 -0000 Subject: [issue1468] MSI installer does not include SSL test .pem files Message-ID: <1195526862.03.0.303505454768.issue1468@psf.upfronthosting.co.za> Martin v. L?wis added the comment: Thanks for the patch. It looked good, so I committed it as r59066. Let's see whether the buildbot picks it up correctly. __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Nov 20 03:58:25 2007 From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=) Date: Tue, 20 Nov 2007 02:58:25 -0000 Subject: [issue1471] ioctl doesn't work properly on 64-bit OpenBSD Message-ID: <1195527505.15.0.798479496941.issue1471@psf.upfronthosting.co.za> Martin v. L?wis added the comment: So what's the definition of struct winsize on these systems? Also, why do you think this is a bug in Python? AFAICT, the specific ioctl call does not occur in Python, but in your own code. ---------- nosy: +loewis resolution: -> invalid status: open -> pending __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Nov 20 04:04:32 2007 From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=) Date: Tue, 20 Nov 2007 03:04:32 -0000 Subject: [issue1342] Crash on Windows if Python runs from a directory with umlauts Message-ID: <1195527872.07.0.561657078421.issue1342@psf.upfronthosting.co.za> Martin v. L?wis added the comment: Please don't use the FileSystemEncoding on Windows for sys.path items. Instead, it should use the wide API to perform all system calls. Py3k shouldn't ever use the file system encoding for anything on Windows. __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Nov 20 04:07:25 2007 From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=) Date: Tue, 20 Nov 2007 03:07:25 -0000 Subject: [issue1470] py3k unit tests are removing %TEMP% dir on Windows Message-ID: <1195528045.22.0.202327401994.issue1470@psf.upfronthosting.co.za> Martin v. L?wis added the comment: It seems that this patch has broken a lot of buildbots, e.g. http://www.python.org/dev/buildbot/all/x86%20gentoo%20trunk/builds/2625/step-test/0 ---------- nosy: +loewis __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Nov 20 04:21:40 2007 From: report at bugs.python.org (Christian Heimes) Date: Tue, 20 Nov 2007 03:21:40 -0000 Subject: [issue1470] py3k unit tests are removing %TEMP% dir on Windows Message-ID: <1195528900.71.0.226175776808.issue1470@psf.upfronthosting.co.za> Christian Heimes added the comment: Thanks, I've changed the code slightly. __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Nov 20 04:27:34 2007 From: report at bugs.python.org (Christian Heimes) Date: Tue, 20 Nov 2007 03:27:34 -0000 Subject: [issue1472] Small bat files to build docs on Windows Message-ID: <1195529254.24.0.446660522351.issue1472@psf.upfronthosting.co.za> Changes by Christian Heimes: ---------- keywords: patch, py3k nosy: tiran priority: low severity: normal status: open title: Small bat files to build docs on Windows type: rfe versions: Python 2.6, Python 3.0 __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Nov 20 04:39:57 2007 From: report at bugs.python.org (James G. sack (jim)) Date: Tue, 20 Nov 2007 03:39:57 -0000 Subject: [issue1328] feature request: force BOM option Message-ID: <1195529997.85.0.0335207530675.issue1328@psf.upfronthosting.co.za> James G. sack (jim) added the comment: More discussion of utf_8.py decoding behavior (and possible change): For my needs, I would like the decoding parts of the utf_8 module to treat an initial BOM as an optional signature and skip it if there is one (just like the utf_8_sig decoder). In fact I have a working patch that replaces the utf_8_sig decode, IncrementalDecoder and StreamReader components by direct transplants from utf_8_sig (as recently repaired -- there was a SteamReader error). However the reason for discussion is to ask how it might impact existing code. I can imagine there might be utf_8 client code out there which expects to see a leading U+feff as (perhaps) a clue that the output should be returned with a BOM-signature (say) to accomodate the guessed input requirements of the remote correspondant. Making my work easier might actually make someone else's work (probably, annoyingly) harder. So what to do? I can just live with code like if input[0] == u"\ufeff": input=input[1:} spread around, and of course slightly different for incremental and stream inputs. But I probably wouldn't. I would probably substitute a "my_utf_8" encoding for to make my code a little cleaner. Another thought I had would require "the other guy" to update his code, but at least it wouldn't make his work annoyingly difficult like my original change might have. Here's the basic outline: - Add another decoder function that returns a 3-tuple decode3(input, errors='strict') => (data, consumed, had_bom) where had_bom is true if a leading bom was seen and skipped - then the usual decode is just something like def decode(input, errors='strict'): return decode3(input, errors)[:2] - add member variable and accessor to both IncrementalDecoder and StreamReader classes something like def had_bom(self): return self.had_bom and initialize/set the self.had_bom variable as required. This complicates the interface somewhat and requires some additional documantation. Tpo document my original simple [-minded] idea required possibly only a few more words in the existing paragraph on utf_8_sig, to mention that both mods had the same decoding behavior but different encoding. I thought of a secondary consideration: If utf_8 and utf_8_sig are "almost the same", it's possible that future refactoring might unify them with differences contained in behavor-flags (eg, skip_leading_bom). The leading bom processing might even be pushed into codecs.utf_8_decode for possible minor advantages. Is there anybody monitoring this who has an opinion on this? ..jim ---------- versions: +Python 2.6 __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Nov 20 04:59:09 2007 From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=) Date: Tue, 20 Nov 2007 03:59:09 -0000 Subject: [issue1472] Small bat files to build docs on Windows Message-ID: <1195531149.8.0.121469900624.issue1472@psf.upfronthosting.co.za> Martin v. L?wis added the comment: See also Tools/buildbot/buildmsi.bat. With cygwin installed, building the documentation is as simple as bash.exe -c 'cd Doc;make PYTHON=python2.5 update htmlhelp' "%ProgramFiles%\HTML Help Workshop\hhc.exe" Doc\build\htmlhelp\pydoc.hhp ---------- nosy: +loewis __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Nov 20 05:44:28 2007 From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=) Date: Tue, 20 Nov 2007 04:44:28 -0000 Subject: [issue1473] Drop _EXPORTS macros in PCbuild9 Message-ID: <1195533868.85.0.212456448769.issue1473@psf.upfronthosting.co.za> New submission from Martin v. L?wis: I believe it is safe to drop all the _EXPORTS macros (MMAP_EXPORTS, WINSOUND_EXPORRTS etc) from all projects; atleast I cannot see any reason for having them. Some are clearly bogus, e.g. unicodedata and test_capi both define MMAP_EXPORTS, _socket defines WINSOUND_EXPORTS, and _ssl defines _SOCKET_EXPORTS. ---------- assignee: tiran keywords: py3k messages: 57693 nosy: loewis, tiran severity: normal status: open title: Drop _EXPORTS macros in PCbuild9 versions: Python 3.0 __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Nov 20 06:53:27 2007 From: report at bugs.python.org (Christian Heimes) Date: Tue, 20 Nov 2007 05:53:27 -0000 Subject: [issue1473] Drop _EXPORTS macros in PCbuild9 Message-ID: <1195538007.79.0.257608055261.issue1473@psf.upfronthosting.co.za> Christian Heimes added the comment: You are right. I've checked the header files of the dependencies or simply tried what happens when I remove some defines. The only macro existing macro is BZ2_EXPORT but that's defined unless BZ2_IMPORT is defined. What about the remaining defines? I've copied them from the old projects: _USRDLL - unknown to me WIN32 - ?, is it even safe to define it for x64? _WINDOWS - ? _WIN32 - ? _CRT_SECURE_NO_DEPRECATE - required to get rid of a bunch of warnings __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Nov 20 07:59:54 2007 From: report at bugs.python.org (Christian Heimes) Date: Tue, 20 Nov 2007 06:59:54 -0000 Subject: [issue1474] PCbuild9 patch for trunk Message-ID: <1195541994.39.0.585954762191.issue1474@psf.upfronthosting.co.za> New submission from Christian Heimes: The patch contains the modifications to PCbuild9, socketmodule and some structmember.h related files after a svn copy py3k/PCbuild9 trunk/ ---------- assignee: tiran components: Windows files: trunk_pcbuild9.patch keywords: patch messages: 57695 nosy: loewis, tiran priority: normal severity: normal status: open title: PCbuild9 patch for trunk versions: Python 2.6 Added file: http://bugs.python.org/file8785/trunk_pcbuild9.patch __________________________________ Tracker __________________________________ -------------- next part -------------- A non-text attachment was scrubbed... Name: trunk_pcbuild9.patch Type: text/x-diff Size: 6857 bytes Desc: not available Url : http://mail.python.org/pipermail/python-bugs-list/attachments/20071120/11ff090f/attachment.patch From report at bugs.python.org Tue Nov 20 08:36:12 2007 From: report at bugs.python.org (Christian Heimes) Date: Tue, 20 Nov 2007 07:36:12 -0000 Subject: [issue1475] test_popen fails when the directory contains a space Message-ID: <1195544172.34.0.734753003895.issue1475@psf.upfronthosting.co.za> New submission from Christian Heimes: Joseph found the bug during his testing of the py3k branch. The problem is in subprocess.py line 716. http://pastebin.com/fa947767 ---------- assignee: astrand components: Library (Lib), Tests, Windows keywords: py3k messages: 57696 nosy: astrand, joearmbruster, tiran severity: normal status: open title: test_popen fails when the directory contains a space versions: Python 3.0 __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Nov 20 08:37:13 2007 From: report at bugs.python.org (Christian Heimes) Date: Tue, 20 Nov 2007 07:37:13 -0000 Subject: [issue1475] test_popen fails when the directory contains a space Message-ID: <1195544233.17.0.94526485194.issue1475@psf.upfronthosting.co.za> Changes by Christian Heimes: ---------- priority: -> normal __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Nov 20 10:25:19 2007 From: report at bugs.python.org (Nicholas Marriott) Date: Tue, 20 Nov 2007 09:25:19 -0000 Subject: [issue1471] ioctl doesn't work properly on 64-bit OpenBSD Message-ID: <1195550719.59.0.778909076579.issue1471@psf.upfronthosting.co.za> Nicholas Marriott added the comment: I can also reproduce this on OpenBSD/amd64 and was one of the people who discussed it with the submitter before he created this report. > So what's the definition of struct winsize on these systems? The definition of struct winsize on both 32-bit and 64-bit OpenBSD platforms is: struct winsize { unsigned short ws_row; /* rows, in characters */ unsigned short ws_col; /* columns, in characters */ unsigned short ws_xpixel; /* horizontal size, pixels */ unsigned short ws_ypixel; /* vertical size, pixels */ }; We have verified that (sizeof (struct winsize)) is 8 on all three platforms (32-bit i386, and 64-bit amd64 and sparc64). > Also, why do you think this is a bug in Python? AFAICT, the specific > ioctl call does not occur in Python, but in your own code. This Python code fails: fcntl.ioctl(fd, termios.TIOCSWINSZ, struct.pack("HHHH",80,25,0,0)) (Error: IOError: [Errno 25] Inappropriate ioctl for device) This code also fails with the same error message (I would expect EINVAL instead): fcntl.ioctl(0, termios.TIOCSWINSZ, "") Corresponding test C code to call the ioctl (as listed in a previous message) works without problems on all three platforms. I don't know how Python fcntl.ioctl works and perhaps the problem is not Python, but I am having to try fairly hard to think what else could be involved. The constant appears to be the correct ioctl number. (Python code: python2.5 -c 'import termios; print "%d" % (termios.TIOCSWINSZ)' matches C code: #include int main(void) { printf("%ld\n", TIOCSWINSZ); } on all three platforms.) I am told it works on Linux. However, Linux declares ioctl as: int ioctl(int d, int request, ...); So 'request' is 32-bits, but on OpenBSD ioctl is declared as: int ioctl(int d, unsigned long request, ...); So on amd64 and sparc64, 'request' is 64-bits. Could this be a factor? -- Nicholas. ---------- nosy: +nicm __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Nov 20 10:27:52 2007 From: report at bugs.python.org (Amaury Forgeot d'Arc) Date: Tue, 20 Nov 2007 09:27:52 -0000 Subject: [issue1342] Crash on Windows if Python runs from a directory with umlauts In-Reply-To: <1195527872.07.0.561657078421.issue1342@psf.upfronthosting.co.za> Message-ID: Amaury Forgeot d'Arc added the comment: Agreed. I will try to stay with PyObjects* until really needed by a system call. __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Nov 20 11:08:31 2007 From: report at bugs.python.org (Nicholas Marriott) Date: Tue, 20 Nov 2007 10:08:31 -0000 Subject: [issue1471] ioctl doesn't work properly on 64-bit OpenBSD Message-ID: <1195553311.12.0.551904633173.issue1471@psf.upfronthosting.co.za> Nicholas Marriott added the comment: Okay, looks like my guess was correct. The diff at the end of this mail makes it work on OpenBSD/amd64 and it continues to work on i386, but it will probably break Linux (due to the problem it was working around mentioned in the comment at the beginning). I don't know enough about the Python build system to suggest a correct fix. (SUSv3 seems to suggest ioctl's request should be int, so perhaps OpenBSD is ultimately at fault.) fcntl_ioctl in fcntlmodule.c seems to have some other potential problems on 64-bit archs too, as it seems to coerce the ioctl argument (potentially a pointer) into an int. -- Nicholas. --- fcntlmodule.c.orig Tue Nov 20 09:39:12 2007 +++ fcntlmodule.c Tue Nov 20 09:59:50 2007 @@ -101,7 +101,7 @@ the signed int 'code' variable, because Python turns 0x8000000 into a large positive number (PyLong, or PyInt on 64-bit platforms,) whereas C expects it to be a negative int */ - int code; + unsigned long code; int arg; int ret; char *str; @@ -109,7 +109,7 @@ int mutate_arg = 1; char buf[IOCTL_BUFSZ+1]; /* argument plus NUL byte */ - if (PyArg_ParseTuple(args, "O&Iw#|i:ioctl", + if (PyArg_ParseTuple(args, "O&Lw#|i:ioctl", conv_descriptor, &fd, &code, &str, &len, &mutate_arg)) { char *arg; @@ -160,7 +160,7 @@ } PyErr_Clear(); - if (PyArg_ParseTuple(args, "O&Is#:ioctl", + if (PyArg_ParseTuple(args, "O&Ls#:ioctl", conv_descriptor, &fd, &code, &str, &len)) { if (len > IOCTL_BUFSZ) { PyErr_SetString(PyExc_ValueError, @@ -182,7 +182,7 @@ PyErr_Clear(); arg = 0; if (!PyArg_ParseTuple(args, - "O&I|i;ioctl requires a file or file descriptor," + "O&L|i;ioctl requires a file or file descriptor," " an integer and optionally an integer or buffer argument", conv_descriptor, &fd, &code, &arg)) { return NULL; __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Nov 20 11:13:09 2007 From: report at bugs.python.org (Christian Heimes) Date: Tue, 20 Nov 2007 10:13:09 -0000 Subject: [issue1400] Py3k's print() flushing problem Message-ID: <1195553589.23.0.207828100439.issue1400@psf.upfronthosting.co.za> Changes by Christian Heimes: ---------- assignee: -> gvanrossum __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Nov 20 11:21:55 2007 From: report at bugs.python.org (Christian Heimes) Date: Tue, 20 Nov 2007 10:21:55 -0000 Subject: [issue1320] PCBuild8 Solution Support Changes Message-ID: <1195554115.58.0.429470206719.issue1320@psf.upfronthosting.co.za> Christian Heimes added the comment: I've fixed most of the problems in the last couple of days. On my box VS 2005 builds the ssl, tkinter and msi modules. However the future lies in PCbuild9 and VS 2008. ---------- resolution: -> fixed status: open -> closed __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Nov 20 13:11:15 2007 From: report at bugs.python.org (Joseph Armbruster) Date: Tue, 20 Nov 2007 12:11:15 -0000 Subject: [issue1475] test_popen fails when the directory contains a space Message-ID: <1195560675.01.0.531097728924.issue1475@psf.upfronthosting.co.za> Joseph Armbruster added the comment: I believe the issue lies with the cmd command line parameters and insufficient quoting: Currently, if this string is passed into CreateProcess as args, the call will fail: C:\WINDOWS\System32\cmd.exe /c "C:\Documents and Settings\joe\Desktop\Development\Python3k\dev\pcbuild9\python.exe" -c "import sys ; print(sys.argv)" foo bar For sanity, when I try to execute this from a command prompt manually, I noticed this behavior: C:\Documents and Settings\joe>C:\WINDOWS\System32\cmd.exe /c "C:\Documents and Settings\joe\Desktop\Development\Python3k\dev\pcbui ld9\python.exe" -c "import sys; print(sys.argv)" foo bar 'C:\Documents' is not recognized as an internal or external command, operable program or batch file. I read through cmd.exe and it is has this note: """ If /C or /K is specified, then the remainder of the command line after the switch is processed as a command line, where the following logic is used to process quote (") characters: 1. If all of the following conditions are met, then quote characters on the command line are preserved: - no /S switch - exactly two quote characters - no special characters between the two quote characters, where special is one of: &<>()@^| - there are one or more whitespace characters between the the two quote characters - the string between the two quote characters is the name of an executable file. 2. Otherwise, old behavior is to see if the first character is a quote character and if so, strip the leading character and remove the last quote character on the command line, preserving any text after the last quote character. """ I believe args falls under section 2. ---------- nosy: +JosephArmbruster __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Nov 20 14:21:55 2007 From: report at bugs.python.org (sebastian) Date: Tue, 20 Nov 2007 13:21:55 -0000 Subject: [issue1436] logging.config.fileConfig, NameError: name 'RotatingFileHandler' is not defined Message-ID: <1195564915.6.0.487314011255.issue1436@psf.upfronthosting.co.za> sebastian added the comment: thank you very much... but: [...] the class and arguments are evaluated using the logging package's namespace. [...] does this mean, it is not possible to use user-defined handlers, naturally residing outside python's class library (and logging package), when applying fileConfig()? __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Nov 20 14:41:47 2007 From: report at bugs.python.org (zouguangxian) Date: Tue, 20 Nov 2007 13:41:47 -0000 Subject: [issue1455] VS2008, quick hack for distutils.msvccompiler Message-ID: <1195566107.39.0.622450236018.issue1455@psf.upfronthosting.co.za> zouguangxian added the comment: Why don't use "Visual Studio 200x Command Prompt" to get a shell window with correct environment settings? In this way msvccompiler.py can get LIB, INCLUDE, LIBPATH, PATH with os.environ.get. ---------- nosy: +weck __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Nov 20 19:14:03 2007 From: report at bugs.python.org (Joseph Armbruster) Date: Tue, 20 Nov 2007 18:14:03 -0000 Subject: [issue1476] missing debug configuration for make_versioninfo.vcproj Message-ID: <1195582443.28.0.303313895927.issue1476@psf.upfronthosting.co.za> New submission from Joseph Armbruster: Revision: 59073 make_versioninfo.vcproj is missing the debug configuration. As a result, if you try to build python in debug, you will receive an error during compile in python_nt.rc, due to this block: #define MS_WINDOWS #include "modsupport.h" #include "patchlevel.h" #ifdef _DEBUG # include "pythonnt_rc_d.h" #else # include "pythonnt_rc.h" #endif This is because the file pythonnt_rc_d.h is never created. The attached patch should resolve this. ---------- components: Windows files: pythonnt.patch messages: 57704 nosy: JosephArmbruster severity: normal status: open title: missing debug configuration for make_versioninfo.vcproj type: compile error versions: Python 3.0 Added file: http://bugs.python.org/file8786/pythonnt.patch __________________________________ Tracker __________________________________ -------------- next part -------------- A non-text attachment was scrubbed... Name: pythonnt.patch Type: text/x-diff Size: 3575 bytes Desc: not available Url : http://mail.python.org/pipermail/python-bugs-list/attachments/20071120/386f6435/attachment.patch From report at bugs.python.org Tue Nov 20 19:25:01 2007 From: report at bugs.python.org (Joseph Armbruster) Date: Tue, 20 Nov 2007 18:25:01 -0000 Subject: [issue1476] missing debug configuration for make_versioninfo.vcproj Message-ID: <1195583101.2.0.575806557305.issue1476@psf.upfronthosting.co.za> Changes by Joseph Armbruster: ---------- nosy: +tiran __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Nov 20 19:57:05 2007 From: report at bugs.python.org (vincent kraeutler) Date: Tue, 20 Nov 2007 18:57:05 -0000 Subject: [issue1462525] URI parsing library Message-ID: <1195585025.36.0.234264397575.issue1462525@psf.upfronthosting.co.za> vincent kraeutler added the comment: Quite like urlparse, uriparse does not fail on input which does not represent valid URI's. At least not early or reliably enough. Specifically, I noticed that urisplit does not fail on input strings with a missing scheme, such as "foo.com/bar". I see no (straightforward) solution to this problem, short of using a proper parser library such as Haskell's Parsec (I unfortunately know of no Python equivalent), but I thought I might want to report this issue nevertheless. The following might work as a quick-fix: Replace regex.match(foo,bar).groups() with something like: mm = re.match(regex, uri) sp = mm.span() if (-1 in sp) or (sp[1] - sp[0] != len(uri)): raise ValueError, "uri regex did not match complete input" p = mm.groups() ---------- nosy: +vincentk _____________________________________ Tracker _____________________________________ From report at bugs.python.org Tue Nov 20 20:34:41 2007 From: report at bugs.python.org (Vinay Sajip) Date: Tue, 20 Nov 2007 19:34:41 -0000 Subject: [issue1436] logging.config.fileConfig, NameError: name 'RotatingFileHandler' is not defined Message-ID: <1195587281.03.0.573416150633.issue1436@psf.upfronthosting.co.za> Vinay Sajip added the comment: No, it doesn't. See this post: http://groups.google.com/group/comp.lang.python/browse_thread/thread/21be57fae7e9381a __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Nov 20 21:00:29 2007 From: report at bugs.python.org (Joseph Armbruster) Date: Tue, 20 Nov 2007 20:00:29 -0000 Subject: [issue1476] missing debug configuration for make_versioninfo.vcproj Message-ID: <1195588829.34.0.0558900240765.issue1476@psf.upfronthosting.co.za> Joseph Armbruster added the comment: Whoops, looks like I missed the solution, which is also needed for the patch. Here's the correct version. Do the following to test: - Load up the PCBuild9 solution - set python as the "Start Up" project, - select Debug configuration - press ctrl-shift-b - press F5 .. it should run in debug - select Release configuration - press ctrl-shift-b - press F5 .. it should run in release Added file: http://bugs.python.org/file8787/pythonnt.patch __________________________________ Tracker __________________________________ -------------- next part -------------- A non-text attachment was scrubbed... Name: pythonnt.patch Type: text/x-diff Size: 4450 bytes Desc: not available Url : http://mail.python.org/pipermail/python-bugs-list/attachments/20071120/28283625/attachment-0001.patch From report at bugs.python.org Tue Nov 20 21:57:39 2007 From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=) Date: Tue, 20 Nov 2007 20:57:39 -0000 Subject: [issue1473] Drop _EXPORTS macros in PCbuild9 Message-ID: <1195592259.71.0.637825428958.issue1473@psf.upfronthosting.co.za> Martin v. L?wis added the comment: See the MSDN for details. IIUC: - _WIN32 is defined by the compiler, always, unless the platform is WIN16 (which is no longer supported). It is even defined on Win64 (where the compiler also defines _WIN64). So there should be no need to defined it explicitly. - WIN32 is checked-for in WinSock2.h. I couldn't figure out when precisely it is supposed to be defined. - _USRDLL apparently was once a mechanism of how to integrate with MFC. It apparently isn't really used anymore in VS 2003 (afx.h still uses it to trigger linkage of __afxForceUSRDL); I suppose it is safe to drop for Python - I couldn't quite figure out what _WINDOWS is good for. - _CRT_SECURE_NO_DEPRECATE as you say, although that's also defined in pyconfig.h. __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Nov 20 22:13:21 2007 From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=) Date: Tue, 20 Nov 2007 21:13:21 -0000 Subject: [issue1455] VS2008, quick hack for distutils.msvccompiler Message-ID: <1195593201.07.0.165645072522.issue1455@psf.upfronthosting.co.za> Martin v. L?wis added the comment: It's tedious to require users to invoke such a shell, and it would produce an endless flood of support requests if we made that a requirement. So requiring to build in such a shell is absolutely unacceptable. __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Nov 20 22:15:27 2007 From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=) Date: Tue, 20 Nov 2007 21:15:27 -0000 Subject: [issue1476] missing debug configuration for make_versioninfo.vcproj Message-ID: <1195593327.44.0.326907411353.issue1476@psf.upfronthosting.co.za> Changes by Martin v. L?wis: ---------- assignee: -> tiran __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Nov 20 22:17:39 2007 From: report at bugs.python.org (Sean B. Palmer) Date: Tue, 20 Nov 2007 21:17:39 -0000 Subject: [issue1477] UnicodeDecodeError that cannot be caught in narrow unicode builds Message-ID: <1195593459.02.0.388666867716.issue1477@psf.upfronthosting.co.za> New submission from Sean B. Palmer: The following error is uncatchable: >>> try: ur'\U0010FFFF' ... except UnicodeDecodeError: pass ... UnicodeDecodeError: 'rawunicodeescape' codec can't decode byte 0x5c in position 0: \Uxxxxxxxx out of range This is in a narrow unicode build: >>> sys.version_info, hex(sys.maxunicode) ((2, 5, 1, 'final', 0), '0xffff') Of course the r in ur'...' is redundant in the test case above, but there are cases in which it isn't... >>> ur'\U0010FFFF\test' u'\U0010ffff\\test' - from a wide unicode build >>> ur'\U0010FFFF\test' UnicodeDecodeError: 'rawunicodeescape' codec can't decode byte 0x5c in position 0: \Uxxxxxxxx out of range - from the narrow unicode build The problem occurs with .decode('raw-unicode-escape') too. >>> '\U0010FFFF\test'.decode('raw-unicode-escape') Traceback (most recent call last): [&c.] Most surprisingly of all, however, this problem doesn't occur when you don't use a raw string: >>> u'\U0010ffff\\test' u'\U0010ffff\\test' So there is at least a workaround for all cases, which is why this bug is marked as Severity: minor. It did take a while to work out that what manifests with ur mightn't apply to u, however; it's usually one's first thought to think the bug is with you, not with python. ---------- components: Unicode messages: 57710 nosy: sbp severity: minor status: open title: UnicodeDecodeError that cannot be caught in narrow unicode builds type: behavior versions: Python 2.5 __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Nov 20 22:40:05 2007 From: report at bugs.python.org (Bill Janssen) Date: Tue, 20 Nov 2007 21:40:05 -0000 Subject: [issue1468] MSI installer does not include SSL test .pem files Message-ID: <1195594805.34.0.436397199868.issue1468@psf.upfronthosting.co.za> Bill Janssen added the comment: Looks good to me, too. ---------- nosy: +janssen __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Nov 20 23:00:21 2007 From: report at bugs.python.org (Christian Heimes) Date: Tue, 20 Nov 2007 22:00:21 -0000 Subject: [issue1473] Drop _EXPORTS macros in PCbuild9 Message-ID: <1195596021.95.0.123145648577.issue1473@psf.upfronthosting.co.za> Christian Heimes added the comment: WIN32 is required. Without WIN32 defined I'm getting errors in the locale module. _WINDOWS seems to be obsolete. __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Nov 20 23:02:34 2007 From: report at bugs.python.org (Christian Heimes) Date: Tue, 20 Nov 2007 22:02:34 -0000 Subject: [issue1476] missing debug configuration for make_versioninfo.vcproj Message-ID: <1195596154.48.0.433176007992.issue1476@psf.upfronthosting.co.za> Christian Heimes added the comment: Thanks ;) ---------- resolution: -> fixed status: open -> closed __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Nov 20 23:03:56 2007 From: report at bugs.python.org (Christian Heimes) Date: Tue, 20 Nov 2007 22:03:56 -0000 Subject: [issue1473] Drop _EXPORTS macros in PCbuild9 Message-ID: <1195596236.35.0.058451617084.issue1473@psf.upfronthosting.co.za> Changes by Christian Heimes: ---------- resolution: -> fixed status: open -> closed __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Nov 20 23:23:45 2007 From: report at bugs.python.org (Guido van Rossum) Date: Tue, 20 Nov 2007 22:23:45 -0000 Subject: [issue1328] feature request: force BOM option Message-ID: <1195597425.29.0.587001761352.issue1328@psf.upfronthosting.co.za> Changes by Guido van Rossum: ---------- nosy: -gvanrossum __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Nov 20 23:33:50 2007 From: report at bugs.python.org (Guido van Rossum) Date: Tue, 20 Nov 2007 22:33:50 -0000 Subject: [issue1374] IDLE - minor FormatParagraph bug fix Message-ID: <1195598030.01.0.264459814495.issue1374@psf.upfronthosting.co.za> Guido van Rossum added the comment: IDLE stuff is never mine. ---------- assignee: gvanrossum -> kbk __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Nov 20 23:35:00 2007 From: report at bugs.python.org (Guido van Rossum) Date: Tue, 20 Nov 2007 22:35:00 -0000 Subject: [issue1234] semaphore errors on AIX 5.2 Message-ID: <1195598100.89.0.0764849137137.issue1234@psf.upfronthosting.co.za> Guido van Rossum added the comment: I have no way to test this. ---------- assignee: gvanrossum -> priority: high -> normal __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Nov 20 23:40:04 2007 From: report at bugs.python.org (Tom Culliton) Date: Tue, 20 Nov 2007 22:40:04 -0000 Subject: [issue1731717] race condition in subprocess module Message-ID: <1195598404.23.0.0347877930317.issue1731717@psf.upfronthosting.co.za> Tom Culliton added the comment: This or some variant also shows up with scons (http://scons.tigris.org/issues/show_bug.cgi?id=1839) leading to some nasty intermittent build failures. Neal may remember how we addressed this for a Process class in a past life. Basically it's OK to collect all the child exit codes if you record the results and return them when requested. This would mean that waitpid and the like would have to check a cached list of PIDs and exit statuses before actually waiting. Don't know if that's possible/any help in this case or not... Traceback (most recent call last): File "/usr/lib/scons-0.97.0d20070918/SCons/Taskmaster.py", line 194, in execute self.targets[0].build() File "/usr/lib/scons-0.97.0d20070918/SCons/Node/__init__.py", line 365, in build stat = apply(executor, (self,), kw) File "/usr/lib/scons-0.97.0d20070918/SCons/Executor.py", line 139, in __call__ return self.do_execute(target, kw) File "/usr/lib/scons-0.97.0d20070918/SCons/Executor.py", line 129, in do_execute status = apply(act, (self.targets, self.sources, env), kw) File "/usr/lib/scons-0.97.0d20070918/SCons/Action.py", line 332, in __call__ stat = self.execute(target, source, env) File "/usr/lib/scons-0.97.0d20070918/SCons/Action.py", line 479, in execute result = spawn(shell, escape, cmd_line[0], cmd_line, ENV) File "/usr/lib/scons-0.97.0d20070918/SCons/Platform/posix.py", line 104, in spawnvpe_spawn return exec_spawnvpe([sh, '-c', string.join(args)], env) File "/usr/lib/scons-0.97.0d20070918/SCons/Platform/posix.py", line 68, in exec_spawnvpe stat = os.spawnvpe(os.P_WAIT, l[0], l, env) File "/sw/pkgs/python-2.3.5_00/lib/python2.3/os.py", line 553, in spawnvpe return _spawnvef(mode, file, args, env, execvpe) File "/sw/pkgs/python-2.3.5_00/lib/python2.3/os.py", line 504, in _spawnvef wpid, sts = waitpid(pid, 0) OSError: [Errno 10] No child processes scons: building terminated because of errors. ---------- nosy: +tom_culliton _____________________________________ Tracker _____________________________________ From report at bugs.python.org Wed Nov 21 00:20:58 2007 From: report at bugs.python.org (Joseph Armbruster) Date: Tue, 20 Nov 2007 23:20:58 -0000 Subject: [issue1475] test_popen fails when the directory contains a space Message-ID: <1195600858.89.0.581171747795.issue1475@psf.upfronthosting.co.za> Joseph Armbruster added the comment: Applying quotations around args within the shell case appears to take care of it, any thoughts? Added file: http://bugs.python.org/file8788/subprocesspatch.patch __________________________________ Tracker __________________________________ -------------- next part -------------- A non-text attachment was scrubbed... Name: subprocesspatch.patch Type: application/octet-stream Size: 705 bytes Desc: not available Url : http://mail.python.org/pipermail/python-bugs-list/attachments/20071120/9652437e/attachment.obj From report at bugs.python.org Wed Nov 21 01:00:46 2007 From: report at bugs.python.org (Joseph Armbruster) Date: Wed, 21 Nov 2007 00:00:46 -0000 Subject: [issue1478] pythoncore.vcproj fails to generate buildinfo (when spaces in path) Message-ID: <1195603246.72.0.391132027071.issue1478@psf.upfronthosting.co.za> New submission from Joseph Armbruster: Executable path should be quoted, in case build environment is located in a path containing spaces. I also made the Debug / Release versions similar in style. ---------- components: Windows files: pythoncore.patch messages: 57718 nosy: JosephArmbruster severity: normal status: open title: pythoncore.vcproj fails to generate buildinfo (when spaces in path) type: compile error versions: Python 3.0 Added file: http://bugs.python.org/file8789/pythoncore.patch __________________________________ Tracker __________________________________ -------------- next part -------------- A non-text attachment was scrubbed... Name: pythoncore.patch Type: application/octet-stream Size: 1064 bytes Desc: not available Url : http://mail.python.org/pipermail/python-bugs-list/attachments/20071121/98218341/attachment.obj From report at bugs.python.org Wed Nov 21 01:17:08 2007 From: report at bugs.python.org (Joseph Armbruster) Date: Wed, 21 Nov 2007 00:17:08 -0000 Subject: [issue1478] pythoncore.vcproj fails to generate buildinfo (when spaces in path) Message-ID: <1195604228.71.0.98372076506.issue1478@psf.upfronthosting.co.za> Changes by Joseph Armbruster: ---------- nosy: +tiran __________________________________ Tracker __________________________________ From report at bugs.python.org Wed Nov 21 01:31:00 2007 From: report at bugs.python.org (Christian Heimes) Date: Wed, 21 Nov 2007 00:31:00 -0000 Subject: [issue1478] pythoncore.vcproj fails to generate buildinfo (when spaces in path) Message-ID: <1195605060.19.0.949374653839.issue1478@psf.upfronthosting.co.za> Christian Heimes added the comment: Fixed in r59079 Thanks again! ---------- keywords: +patch, py3k resolution: -> fixed status: open -> closed __________________________________ Tracker __________________________________ From report at bugs.python.org Wed Nov 21 01:47:03 2007 From: report at bugs.python.org (Christian Heimes) Date: Wed, 21 Nov 2007 00:47:03 -0000 Subject: [issue1372] zlibmodule.c: int overflow in PyZlib_decompress Message-ID: <1195606023.51.0.457749669972.issue1372@psf.upfronthosting.co.za> Christian Heimes added the comment: Fixed in r59081 and r59080 py3k will follow at the next svnmerge ---------- nosy: +tiran resolution: -> fixed status: open -> closed __________________________________ Tracker __________________________________ From report at bugs.python.org Wed Nov 21 01:55:13 2007 From: report at bugs.python.org (Christian Heimes) Date: Wed, 21 Nov 2007 00:55:13 -0000 Subject: [issue1020] pyexpat.XMParserType broken (was: pydoc doesn't work on pyexpat) Message-ID: <1195606513.1.0.89960127565.issue1020@psf.upfronthosting.co.za> Christian Heimes added the comment: Fixed in r59083 The sentinel in the methods list of XMLparsetype was missing. ---------- resolution: accepted -> fixed status: open -> closed __________________________________ Tracker __________________________________ From report at bugs.python.org Wed Nov 21 02:10:13 2007 From: report at bugs.python.org (Amaury Forgeot d'Arc) Date: Wed, 21 Nov 2007 01:10:13 -0000 Subject: [issue1460] codecs utf7 decoding error Message-ID: <1195607413.39.0.721380510393.issue1460@psf.upfronthosting.co.za> Amaury Forgeot d'Arc added the comment: The utf-7 incremental decoder was indeed losing its state between two chunks of data. Corrected as r59076. ---------- nosy: +amaury.forgeotdarc resolution: -> fixed status: open -> closed __________________________________ Tracker __________________________________ From report at bugs.python.org Wed Nov 21 03:32:39 2007 From: report at bugs.python.org (Christian Heimes) Date: Wed, 21 Nov 2007 02:32:39 -0000 Subject: [issue1464] inet_pton redefined while building with windows SDK 6.0 Message-ID: <1195612359.7.0.0578529496954.issue1464@psf.upfronthosting.co.za> Christian Heimes added the comment: Fixed in py3k and soon to be fixed in trunk when my PCbuild9 directory is ready. ---------- resolution: accepted -> fixed status: open -> closed __________________________________ Tracker __________________________________ From report at bugs.python.org Wed Nov 21 03:54:04 2007 From: report at bugs.python.org (Christian Heimes) Date: Wed, 21 Nov 2007 02:54:04 -0000 Subject: [issue1403] py_compile and compileall need unit tests Message-ID: <1195613644.9.0.492578032755.issue1403@psf.upfronthosting.co.za> Christian Heimes added the comment: Comitted in r59092 ---------- resolution: accepted -> fixed status: open -> closed __________________________________ Tracker __________________________________ From report at bugs.python.org Wed Nov 21 05:01:08 2007 From: report at bugs.python.org (Christian Heimes) Date: Wed, 21 Nov 2007 04:01:08 -0000 Subject: [issue1306] Embedded python reinitialization Message-ID: <1195617668.42.0.371766270469.issue1306@psf.upfronthosting.co.za> Christian Heimes added the comment: Python 3.0 suffers from an problem with reinitialization but I can't reproduce the bug with the release branch of 2.5. Python 2.6 also does fine but leaks some references. // reinit_test.c #include "Python.h" #define ROUNDS 5 int main(void) { int i; for (i=0; i < ROUNDS; i++) { printf("round %d\n", i+1); Py_Initialize(); Py_Finalize(); } return 0; } gcc -DNDEBUG -g -O2 -Wall -Wstrict-prototypes -IInclude -I. -pthread -Xlinker -lpthread -ldl -lutil -lm -export-dynamic -o reinit_test reinit_test.c libpython2.5.a Python 3.0 ---------- ./reinit_test round 1 [23832 refs] round 2 Fatal Python error: Py_Initialize: can't initialize sys standard streams Traceback (most recent call last): File "/usr/local/lib/python3.0/encodings/__init__.py", line 32, in from . import aliases ValueError: Cannot encode path item Aborted Python 2.6 ---------- $ ./reinit_test round 1 [7349 refs] round 2 [7393 refs] round 3 [7428 refs] round 4 [7463 refs] round 5 [7498 refs] Python 2.5 ---------- $ ./reinit_test round 1 [7309 refs] round 2 [7349 refs] round 3 [7380 refs] round 4 [7411 refs] round 5 [7442 refs] ---------- keywords: +py3k nosy: +tiran priority: -> normal severity: urgent -> normal versions: +Python 2.6, Python 3.0 __________________________________ Tracker __________________________________ From report at bugs.python.org Wed Nov 21 05:11:11 2007 From: report at bugs.python.org (Christian Heimes) Date: Wed, 21 Nov 2007 04:11:11 -0000 Subject: [issue1475] test_popen fails when the directory contains a space Message-ID: <1195618271.9.0.814019011535.issue1475@psf.upfronthosting.co.za> Christian Heimes added the comment: I like to have Peter Astrand look over the patch first. He has written most of the subprocess module. __________________________________ Tracker __________________________________ From report at bugs.python.org Wed Nov 21 05:56:00 2007 From: report at bugs.python.org (Christian Heimes) Date: Wed, 21 Nov 2007 04:56:00 -0000 Subject: [issue1306] Embedded python reinitialization Message-ID: <1195620960.92.0.70816786301.issue1306@psf.upfronthosting.co.za> Christian Heimes added the comment: The patch solves one issue. It resets the Py_DefaultFileSystemEncoding to NULL when no default value was given. However the finalization fails after the 3rd round at if (op == &refchain || op->_ob_prev->_ob_next != op || op->_ob_next->_ob_prev != op) Py_FatalError("UNREF invalid object"); $ gdb ./reinit_test GNU gdb 6.6-debian Copyright (C) 2006 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "i486-linux-gnu"... Using host libthread_db library "/lib/tls/i686/cmov/libthread_db.so.1". (gdb) run Starting program: /home/heimes/dev/python/py3k/reinit_test [Thread debugging using libthread_db enabled] [New Thread -1210464064 (LWP 8060)] round 1 [23832 refs] round 2 [24558 refs] round 3 Fatal Python error: UNREF invalid object Program received signal SIGABRT, Aborted. [Switching to Thread -1210464064 (LWP 8060)] 0xffffe410 in __kernel_vsyscall () (gdb) bt #0 0xffffe410 in __kernel_vsyscall () #1 0xb7dc7875 in raise () from /lib/tls/i686/cmov/libc.so.6 #2 0xb7dc9201 in abort () from /lib/tls/i686/cmov/libc.so.6 #3 0x0805d62d in Py_FatalError (msg=0x81790d8 "UNREF invalid object") at Python/pythonrun.c:1761 #4 0x080aac57 in _Py_ForgetReference (op=0x821d728) at Objects/object.c:1536 #5 0x080aaca6 in _Py_Dealloc (op=0x821d728) at Objects/object.c:1555 #6 0x080c0f52 in tupledealloc (op=0x82ebc3c) at Objects/tupleobject.c:169 #7 0x080aacb1 in _Py_Dealloc (op=0x82ebc3c) at Objects/object.c:1556 #8 0x080c0f52 in tupledealloc (op=0x83f9154) at Objects/tupleobject.c:169 #9 0x080aacb1 in _Py_Dealloc (op=0x83f9154) at Objects/object.c:1556 #10 0x08083605 in code_dealloc (co=0x83b1bc8) at Objects/codeobject.c:276 #11 0x080aacb1 in _Py_Dealloc (op=0x83b1bc8) at Objects/object.c:1556 #12 0x081691bf in func_dealloc (op=0x83f7924) at Objects/funcobject.c:555 #13 0x080aacb1 in _Py_Dealloc (op=0x83f7924) at Objects/object.c:1556 #14 0x080a272e in PyDict_Clear (op=0x83f6df4) at Objects/dictobject.c:798 #15 0x080a524f in dict_tp_clear (op=0x83f6df4) at Objects/dictobject.c:1793 #16 0x08068c13 in delete_garbage (collectable=0xbf9fa024, old=0x81978e8) at Modules/gcmodule.c:688 #17 0x0806909f in collect (generation=2) at Modules/gcmodule.c:824 #18 0x080699ea in PyGC_Collect () at Modules/gcmodule.c:1238 #19 0x0805a022 in Py_Finalize () at Python/pythonrun.c:416 #20 0x08059791 in main () at reinit_test.c:9 (gdb) ---------- assignee: -> gvanrossum nosy: +gvanrossum Added file: http://bugs.python.org/file8790/py3k_reinit.patch __________________________________ Tracker __________________________________ -------------- next part -------------- A non-text attachment was scrubbed... Name: py3k_reinit.patch Type: text/x-diff Size: 1598 bytes Desc: not available Url : http://mail.python.org/pipermail/python-bugs-list/attachments/20071121/0ab95df4/attachment-0001.patch From report at bugs.python.org Wed Nov 21 07:42:11 2007 From: report at bugs.python.org (Christian Heimes) Date: Wed, 21 Nov 2007 06:42:11 -0000 Subject: [issue1479] csv module is leaking references Message-ID: <1195627331.43.0.528300349254.issue1479@psf.upfronthosting.co.za> New submission from Christian Heimes: test_csv leaked [1, 1, 1, 1] references, sum=4 ---------- components: Extension Modules, Library (Lib) keywords: py3k messages: 57728 nosy: tiran priority: normal severity: normal status: open title: csv module is leaking references versions: Python 3.0 __________________________________ Tracker __________________________________ From report at bugs.python.org Wed Nov 21 08:19:45 2007 From: report at bugs.python.org (Christian Heimes) Date: Wed, 21 Nov 2007 07:19:45 -0000 Subject: [issue1480] sqlite module is leaking lots of references Message-ID: <1195629585.82.0.465075974861.issue1480@psf.upfronthosting.co.za> New submission from Christian Heimes: test_sqlite leaked [325, 325, 325, 325] references, sum=1300 ---------- components: Extension Modules keywords: py3k messages: 57729 nosy: tiran priority: high severity: normal status: open title: sqlite module is leaking lots of references versions: Python 3.0 __________________________________ Tracker __________________________________ From report at bugs.python.org Wed Nov 21 08:21:35 2007 From: report at bugs.python.org (Christian Heimes) Date: Wed, 21 Nov 2007 07:21:35 -0000 Subject: [issue1469] SSL tests leak memory Message-ID: <1195629695.39.0.323696402292.issue1469@psf.upfronthosting.co.za> Christian Heimes added the comment: I don't see leaks when I run the tests with $ ./python Lib/test/regrtest.py -R:: test_ssl.py test_ssl beginning 9 repetitions 123456789 ......... 1 test OK. [80034 refs] ---------- nosy: +tiran priority: -> normal __________________________________ Tracker __________________________________ From report at bugs.python.org Wed Nov 21 08:48:02 2007 From: report at bugs.python.org (=?utf-8?q?Peter_=C3=85strand?=) Date: Wed, 21 Nov 2007 07:48:02 -0000 Subject: [issue1475] test_popen fails when the directory contains a space Message-ID: <1195631282.15.0.38320469007.issue1475@psf.upfronthosting.co.za> Peter ?strand added the comment: I think there's some confusion in this bug. The report on http://pastebin.com/fa947767 indicates a problem in test_popen. This is a test for os.popen() and it does not have anything to do with the subprocess module. I believe it is test_popen.py that should be fixed. In general, quoting in Windows is very difficult. The documentation quoted in msg57701 might be correct for some modern version of Windows, but not for, say, command.com on an older Windows version. I believe the subprocess is fairly complete when it comes to quoting etc, so changes should be avoided if possible. Since this bug is not about the subprocess module, I've re-assigned to nobody, hope this is OK. ---------- assignee: astrand -> __________________________________ Tracker __________________________________ From report at bugs.python.org Wed Nov 21 09:14:30 2007 From: report at bugs.python.org (Christian Heimes) Date: Wed, 21 Nov 2007 08:14:30 -0000 Subject: [issue1475] test_popen fails when the directory contains a space Message-ID: <1195632870.59.0.91473843.issue1475@psf.upfronthosting.co.za> Christian Heimes added the comment: In Python 3.x os.popen is implemented based on subprocess. I believe it's still a problem with subprocess. Python 3.x also drops support for Windows 95 to ME. Would the additional quoting be ok when the code checks for COMPSPEC == "cmd.exe" first? # Supply os.popen() def popen(cmd, mode="r", buffering=None): if not isinstance(cmd, str): raise TypeError("invalid cmd type (%s, expected string)" % type(cmd)) if mode not in ("r", "w"): raise ValueError("invalid mode %r" % mode) import subprocess, io if mode == "r": proc = subprocess.Popen(cmd, shell=True, stdout=subprocess.PIPE, bufsize=buffering) return _wrap_close(io.TextIOWrapper(proc.stdout), proc) else: proc = subprocess.Popen(cmd, shell=True, stdin=subprocess.PIPE, bufsize=buffering) return _wrap_close(io.TextIOWrapper(proc.stdin), proc) __________________________________ Tracker __________________________________ From report at bugs.python.org Wed Nov 21 09:17:48 2007 From: report at bugs.python.org (Christian Heimes) Date: Wed, 21 Nov 2007 08:17:48 -0000 Subject: [issue1481] test_uuid is warning about unreliable functions Message-ID: <1195633068.63.0.82173012127.issue1481@psf.upfronthosting.co.za> New submission from Christian Heimes: I'm putting the report into the tracker as a reminder. WARNING: uuid.getnode is unreliable on many platforms. It is disabled until the code and/or test can be fixed properly. WARNING: uuid._ifconfig_getnode is unreliable on many platforms. It is disabled until the code and/or test can be fixed properly. WARNING: uuid._unixdll_getnode is unreliable on many platforms. It is disabled until the code and/or test can be fixed properly. ---------- components: Library (Lib), Tests keywords: py3k messages: 57733 nosy: tiran priority: normal severity: normal status: open title: test_uuid is warning about unreliable functions type: behavior versions: Python 2.6, Python 3.0 __________________________________ Tracker __________________________________ From report at bugs.python.org Wed Nov 21 09:19:55 2007 From: report at bugs.python.org (Christian Heimes) Date: Wed, 21 Nov 2007 08:19:55 -0000 Subject: [issue1306] Embedded python reinitialization Message-ID: <1195633195.36.0.77199461737.issue1306@psf.upfronthosting.co.za> Christian Heimes added the comment: I've added some debugging code to _Py_ForgetReference and now I'm getting this: $ ./reinit_test round 1 [23832 refs] round 2 [24558 refs] round 3 * ob object : type : str refcount: 0 address : 0x821d728 * op->_ob_prev->_ob_next object : type : str refcount: 0 address : 0x821d728 * op->_ob_next->_ob_prev object : buffer(b'') type : buffer refcount: 1 address : 0x826c8c8 * refchain object : type : NULL refcount: 0 address : 0x81a1500 Fatal Python error: UNREF invalid object Aborted Added file: http://bugs.python.org/file8791/py3k_reinit2.patch __________________________________ Tracker __________________________________ -------------- next part -------------- A non-text attachment was scrubbed... Name: py3k_reinit2.patch Type: text/x-diff Size: 2409 bytes Desc: not available Url : http://mail.python.org/pipermail/python-bugs-list/attachments/20071121/211b1444/attachment.patch From report at bugs.python.org Wed Nov 21 10:27:55 2007 From: report at bugs.python.org (Christian Heimes) Date: Wed, 21 Nov 2007 09:27:55 -0000 Subject: [issue1482] IMAP4 SSL isn't working Message-ID: <1195637275.04.0.129181694073.issue1482@psf.upfronthosting.co.za> New submission from Christian Heimes: The SSL version of the imap4 client isnt' working under 3.0. After I applied the patch from http://bugs.python.org/issue1210 I tried to connect to an IMAP server over SSL. The connection hangs. import imaplib conn = imaplib.IMAP4_SSL("mailbox.rwth-aachen.de", 993) After a while I stopped the attempt with CTRL+C Traceback (most recent call last): File "", line 1, in File "/home/heimes/dev/python/py3k/Lib/imaplib.py", line 1137, in __init__ IMAP4.__init__(self, host, port) File "/home/heimes/dev/python/py3k/Lib/imaplib.py", line 184, in __init__ self.welcome = self._get_response() File "/home/heimes/dev/python/py3k/Lib/imaplib.py", line 907, in _get_response resp = self._get_line() File "/home/heimes/dev/python/py3k/Lib/imaplib.py", line 1000, in _get_line line = self.readline() File "/home/heimes/dev/python/py3k/Lib/imaplib.py", line 1170, in readline char = self.sslobj.read(1) File "/home/heimes/dev/python/py3k/Lib/ssl.py", line 160, in read return self._sslobj.read(len) KeyboardInterrupt ---------- assignee: janssen components: Library (Lib) keywords: py3k messages: 57735 nosy: janssen, tiran priority: normal severity: normal status: open title: IMAP4 SSL isn't working versions: Python 3.0 __________________________________ Tracker __________________________________ From report at bugs.python.org Wed Nov 21 11:29:37 2007 From: report at bugs.python.org (vincent kraeutler) Date: Wed, 21 Nov 2007 10:29:37 -0000 Subject: [issue1462525] URI parsing library Message-ID: <1195640977.01.0.739150978071.issue1462525@psf.upfronthosting.co.za> vincent kraeutler added the comment: Some more notes. a) RFC3986 explicitly states that the presented regex (which you use) """ is the regular expression for breaking-down a *well-formed* URI reference into its components. """ (Emphasis added). I am not sure this is a particularly good starting point for parsing potentially security-critical data. b) The parser fails on URI's containing numerical IPv6 addresses (e.g. "http://[::1]:88/path"). Specifically, the following code in split_authority is broken: if hostport and ':' in hostport: host, port = hostport.split(':', 1) Clearly, if the authority may contain a ":" in the host's IP field, you cannot simply split() off the port part. Again, I am afraid I have no simple solution. Hate to sound so negative. Kind regards, v. _____________________________________ Tracker _____________________________________ From report at bugs.python.org Wed Nov 21 11:36:56 2007 From: report at bugs.python.org (Christian Heimes) Date: Wed, 21 Nov 2007 10:36:56 -0000 Subject: [issue1083] Confusing error message when dividing timedelta using / Message-ID: <1195641416.21.0.929996608147.issue1083@psf.upfronthosting.co.za> Changes by Christian Heimes: ---------- keywords: +patch Added file: http://bugs.python.org/file8792/py3k_datetime_1083.patch __________________________________ Tracker __________________________________ From report at bugs.python.org Wed Nov 21 15:03:15 2007 From: report at bugs.python.org (Yitz Gale) Date: Wed, 21 Nov 2007 14:03:15 -0000 Subject: [issue1483] xml.sax.saxutils.prepare_input_source ignores character stream in InputSource Message-ID: <1195653795.8.0.542576278207.issue1483@psf.upfronthosting.co.za> New submission from Yitz Gale: In the documentation for xml.sax.xmlreader.InputSource objects (section 8.12.4 of the Library Reference) we find that users of InputSource objects should use the following sequence to get their input data: 1. If the InputSource has a character stream, use that. 2. Otherwise, if the InputSource has a byte stream, use that. 3. Otherwise, open a URI connection to the system ID. prepare_input_source() skips step 1. This is a one-line fix in Lib/xml/sax/saxutils.py: - if source.getByteStream() is None: + if source.getCharacterStream is None and source.getByteStream() is None: ---------- components: Library (Lib) messages: 57737 nosy: ygale severity: normal status: open title: xml.sax.saxutils.prepare_input_source ignores character stream in InputSource versions: Python 2.5 __________________________________ Tracker __________________________________ From report at bugs.python.org Wed Nov 21 20:18:19 2007 From: report at bugs.python.org (Guido van Rossum) Date: Wed, 21 Nov 2007 19:18:19 -0000 Subject: [issue1306] Embedded python reinitialization Message-ID: <1195672699.04.0.761184554148.issue1306@psf.upfronthosting.co.za> Guido van Rossum added the comment: Note that the OP was complaining about Stackless. This is not the place to report issues with that. ---------- priority: normal -> low __________________________________ Tracker __________________________________ From report at bugs.python.org Wed Nov 21 21:02:35 2007 From: report at bugs.python.org (Guido van Rossum) Date: Wed, 21 Nov 2007 20:02:35 -0000 Subject: [issue1067] test_smtplib failures (caused by asyncore) Message-ID: <1195675355.52.0.209278222344.issue1067@psf.upfronthosting.co.za> Guido van Rossum added the comment: I have no idea. I'm no asynchat expert. Let Thomas look into this once he's back from vacation. __________________________________ Tracker __________________________________ From report at bugs.python.org Wed Nov 21 23:30:33 2007 From: report at bugs.python.org (Guido van Rossum) Date: Wed, 21 Nov 2007 22:30:33 -0000 Subject: [issue1348] httplib closes socket, then tries to read from it Message-ID: <1195684233.38.0.651795516285.issue1348@psf.upfronthosting.co.za> Guido van Rossum added the comment: Is this still relevant? ---------- assignee: -> janssen priority: urgent -> normal __________________________________ Tracker __________________________________ From report at bugs.python.org Wed Nov 21 23:41:17 2007 From: report at bugs.python.org (Gidi Avrahami) Date: Wed, 21 Nov 2007 22:41:17 -0000 Subject: [issue1484] logging: callHandlers tests handler levels instead of logger levels? Message-ID: <1195684877.23.0.0511912191493.issue1484@psf.upfronthosting.co.za> New submission from Gidi Avrahami: I am using the logging module with multiple loggers and the following behavior seems incorrect to me: I set the root logger's level to WARN and the foo.bar module's logger's level to DEBUG, and the foo.bar logger should is writing to a file. So basically, I want foo.bar to log itself in details behind the scenes while the main console is quiet. However, I still get all the sebug info printed to the console. When I trace down the code, I see that callHandlers() is climbing up the logger hierarchy, but it's comparing record.level to hdlr.level, not to c.level. The handler levels, however, don't appear to be set normally (i.e., after I do getLogger("foo.bar").setLevel, its handlers stay at level NOTSET). As a result, callHandlers will call all the handlers above the first one, no matter what the loggers level. Is this intentional? If it is, how should I get the behavior that I described above? (I could set propagate=False, but in fact if the rott logger is DEBUG then I do want it to print the foo.bar messages) ---------- components: Library (Lib) messages: 57741 nosy: gidi_avrahami severity: normal status: open title: logging: callHandlers tests handler levels instead of logger levels? type: behavior versions: Python 2.4, Python 2.5 __________________________________ Tracker __________________________________ From report at bugs.python.org Wed Nov 21 23:47:55 2007 From: report at bugs.python.org (Guido van Rossum) Date: Wed, 21 Nov 2007 22:47:55 -0000 Subject: [issue1109] Warning required when calling register() on an ABCMeta subclass Message-ID: <1195685275.71.0.550753564716.issue1109@psf.upfronthosting.co.za> Guido van Rossum added the comment: This would be easier to fix if we didn't have unbound methods. I'm going to ask the py3k list if anybody really cares about having those. __________________________________ Tracker __________________________________ From report at bugs.python.org Thu Nov 22 00:06:24 2007 From: report at bugs.python.org (Bill Janssen) Date: Wed, 21 Nov 2007 23:06:24 -0000 Subject: [issue1469] SSL tests leak memory In-Reply-To: <1195629695.39.0.323696402292.issue1469@psf.upfronthosting.co.za> Message-ID: <4b3e516a0711211506k3152f988j3028d705c5440dcc@mail.gmail.com> Bill Janssen added the comment: What platform? Bill On Nov 20, 2007 11:21 PM, Christian Heimes wrote: > > Christian Heimes added the comment: > > I don't see leaks when I run the tests with > > $ ./python Lib/test/regrtest.py -R:: test_ssl.py > test_ssl > beginning 9 repetitions > 123456789 > ......... > 1 test OK. > [80034 refs] > > ---------- > nosy: +tiran > priority: -> normal > > __________________________________ > Tracker > > __________________________________ > __________________________________ Tracker __________________________________ From report at bugs.python.org Thu Nov 22 00:07:34 2007 From: report at bugs.python.org (Bill Janssen) Date: Wed, 21 Nov 2007 23:07:34 -0000 Subject: [issue1482] IMAP4 SSL isn't working In-Reply-To: <1195637275.04.0.129181694073.issue1482@psf.upfronthosting.co.za> Message-ID: <4b3e516a0711211507x4702765cva28b495a2509a89@mail.gmail.com> Bill Janssen added the comment: I'll take a look at it this weekend. Bill On Nov 21, 2007 1:27 AM, Christian Heimes wrote: > > New submission from Christian Heimes: > > The SSL version of the imap4 client isnt' working under 3.0. After I > applied the patch from http://bugs.python.org/issue1210 I tried to > connect to an IMAP server over SSL. The connection hangs. > > import imaplib > conn = imaplib.IMAP4_SSL("mailbox.rwth-aachen.de", 993) > > After a while I stopped the attempt with CTRL+C > Traceback (most recent call last): > File "", line 1, in > File "/home/heimes/dev/python/py3k/Lib/imaplib.py", line 1137, in __init__ > IMAP4.__init__(self, host, port) > File "/home/heimes/dev/python/py3k/Lib/imaplib.py", line 184, in __init__ > self.welcome = self._get_response() > File "/home/heimes/dev/python/py3k/Lib/imaplib.py", line 907, in > _get_response > resp = self._get_line() > File "/home/heimes/dev/python/py3k/Lib/imaplib.py", line 1000, in > _get_line > line = self.readline() > File "/home/heimes/dev/python/py3k/Lib/imaplib.py", line 1170, in readline > char = self.sslobj.read(1) > File "/home/heimes/dev/python/py3k/Lib/ssl.py", line 160, in read > return self._sslobj.read(len) > KeyboardInterrupt > > ---------- > assignee: janssen > components: Library (Lib) > keywords: py3k > messages: 57735 > nosy: janssen, tiran > priority: normal > severity: normal > status: open > title: IMAP4 SSL isn't working > versions: Python 3.0 > > __________________________________ > Tracker > > __________________________________ > __________________________________ Tracker __________________________________ From report at bugs.python.org Thu Nov 22 00:08:06 2007 From: report at bugs.python.org (Bill Janssen) Date: Wed, 21 Nov 2007 23:08:06 -0000 Subject: [issue1348] httplib closes socket, then tries to read from it In-Reply-To: <1195684233.38.0.651795516285.issue1348@psf.upfronthosting.co.za> Message-ID: <4b3e516a0711211508r793b069cqa633b1236ef5a436@mail.gmail.com> Bill Janssen added the comment: Yes. The close is stil in the wrong place. On Nov 21, 2007 2:30 PM, Guido van Rossum wrote: > > Guido van Rossum added the comment: > > Is this still relevant? > > ---------- > assignee: -> janssen > priority: urgent -> normal > > __________________________________ > Tracker > > __________________________________ > __________________________________ Tracker __________________________________ From report at bugs.python.org Thu Nov 22 01:18:15 2007 From: report at bugs.python.org (Matthew Fremont) Date: Thu, 22 Nov 2007 00:18:15 -0000 Subject: [issue1269] Exception in pstats print_callers() Message-ID: <1195690695.21.0.153491607351.issue1269@psf.upfronthosting.co.za> Matthew Fremont added the comment: I hit the same issue, and I think the problem is that at line 515 in pstats.py add_callers() the two stats instead of adding them member-wise. As a result, each time add() is called, the number of stats associated with each func grows by 4. Then, when print_call_line() is called by print_callers() or print_callees(), there are "too many values to unpack" at line 417. This change to pstats.py modifies add_callers() to add the stats together instead of concatenating the tuples. 515c515 < new_callers[func] = caller + new_callers[func] --- > new_callers[func] = map(lambda x,y: x+y, caller + new_callers[func]) ---------- nosy: +matthew.fremont __________________________________ Tracker __________________________________ From report at bugs.python.org Thu Nov 22 01:58:08 2007 From: report at bugs.python.org (Guido van Rossum) Date: Thu, 22 Nov 2007 00:58:08 -0000 Subject: [issue1383] Backport abcoll to 2.6 Message-ID: <1195693088.53.0.357051117867.issue1383@psf.upfronthosting.co.za> Guido van Rossum added the comment: I've submitted this as revision 59106. Thanks so much for your effort! I cleaned up the layout of some of the files, and I had to undo a diffing mistake -- somehow your patch undid some changes to collections.py and test_collections.py about renaming NamedTuple to namedtuple that were submitted by Raymond Hettinger. ---------- assignee: -> gvanrossum nosy: +gvanrossum resolution: -> accepted status: open -> closed __________________________________ Tracker __________________________________ From report at bugs.python.org Thu Nov 22 05:18:35 2007 From: report at bugs.python.org (Christian Heimes) Date: Thu, 22 Nov 2007 04:18:35 -0000 Subject: [issue1469] SSL tests leak memory Message-ID: <1195705115.76.0.873621140622.issue1469@psf.upfronthosting.co.za> Christian Heimes added the comment: Ubuntu Linux x86 __________________________________ Tracker __________________________________ From report at bugs.python.org Thu Nov 22 07:45:23 2007 From: report at bugs.python.org (Gabriel Genellina) Date: Thu, 22 Nov 2007 06:45:23 -0000 Subject: [issue1477] UnicodeDecodeError that cannot be caught in narrow unicode builds Message-ID: <1195713923.68.0.0167914713146.issue1477@psf.upfronthosting.co.za> Changes by Gabriel Genellina: ---------- nosy: +gagenellina __________________________________ Tracker __________________________________ From report at bugs.python.org Thu Nov 22 07:45:39 2007 From: report at bugs.python.org (Gabriel Genellina) Date: Thu, 22 Nov 2007 06:45:39 -0000 Subject: [issue1475] test_popen fails when the directory contains a space Message-ID: <1195713939.94.0.856008330467.issue1475@psf.upfronthosting.co.za> Changes by Gabriel Genellina: ---------- nosy: +gagenellina __________________________________ Tracker __________________________________ From report at bugs.python.org Thu Nov 22 10:38:37 2007 From: report at bugs.python.org (Yitz Gale) Date: Thu, 22 Nov 2007 09:38:37 -0000 Subject: [issue1483] xml.sax.saxutils.prepare_input_source ignores character stream in InputSource Message-ID: <1195724317.88.0.976701522314.issue1483@psf.upfronthosting.co.za> Yitz Gale added the comment: Oops, obvious typo, sorry: - if source.getByteStream() is None: + if source.getCharacterStream() is None and source.getByteStream() is None: __________________________________ Tracker __________________________________ From report at bugs.python.org Thu Nov 22 11:14:04 2007 From: report at bugs.python.org (=?utf-8?q?Gerhard_H=C3=A4ring?=) Date: Thu, 22 Nov 2007 10:14:04 -0000 Subject: [issue1597404] sqlite timestamp converter bug (floating point) Message-ID: <1195726444.12.0.120679706821.issue1597404@psf.upfronthosting.co.za> Gerhard H?ring added the comment: This has long been fixed in revision 53420. So it will be in Python 2.6 and 3.0. ---------- resolution: -> fixed status: open -> closed type: -> behavior _____________________________________ Tracker _____________________________________ From report at bugs.python.org Thu Nov 22 11:16:54 2007 From: report at bugs.python.org (=?utf-8?q?Gerhard_H=C3=A4ring?=) Date: Thu, 22 Nov 2007 10:16:54 -0000 Subject: [issue1706863] Failed to build Python 2.5.1 with sqlite3 Message-ID: <1195726614.8.0.281558339347.issue1706863@psf.upfronthosting.co.za> Gerhard H?ring added the comment: This is apparently a problem in setup.py. There seems to be a code path where an object should be a string, but is None instead. I'll have to review the relevant parts of setup.py. ---------- nosy: +ghaering type: -> compile error _____________________________________ Tracker _____________________________________ From report at bugs.python.org Thu Nov 22 11:48:03 2007 From: report at bugs.python.org (=?utf-8?q?Gerhard_H=C3=A4ring?=) Date: Thu, 22 Nov 2007 10:48:03 -0000 Subject: [issue1733085] sqlite3 module trigger problem Message-ID: <1195728483.0.0.459910837409.issue1733085@psf.upfronthosting.co.za> Gerhard H?ring added the comment: We'll make sure there's an updated SQLite DLL in Python 2.6 and Python 3.0. It's not worth the effort for 2.5.2. There's always the workaround of users installing an updated DLL themselves. ---------- resolution: -> later status: open -> closed _____________________________________ Tracker _____________________________________ From report at bugs.python.org Thu Nov 22 11:51:50 2007 From: report at bugs.python.org (=?utf-8?q?Gerhard_H=C3=A4ring?=) Date: Thu, 22 Nov 2007 10:51:50 -0000 Subject: [issue1734164] sqlite3 causes memory read error Message-ID: <1195728710.4.0.419667404653.issue1734164@psf.upfronthosting.co.za> Gerhard H?ring added the comment: Ok, I'll modify the 2.5 maintenance line with this patch: http://initd.org/tracker/pysqlite/changeset/426 _____________________________________ Tracker _____________________________________ From report at bugs.python.org Thu Nov 22 11:52:09 2007 From: report at bugs.python.org (Ronald Oussoren) Date: Thu, 22 Nov 2007 10:52:09 -0000 Subject: [issue1402] Interpreter cleanup: order of _PyGILState_Fini and PyInterpreterState_Clear Message-ID: <1195728729.29.0.33664561728.issue1402@psf.upfronthosting.co.za> Ronald Oussoren added the comment: The attached patch fixes the crash, but I haven't verified if the patch is actually correct. With this patch some PyThread API's are called after PyInterpreterState_Clear and I don't know if it is valid to do so. All unittests pass fine on OSX though. Added file: http://bugs.python.org/file8793/pygilstate.patch __________________________________ Tracker __________________________________ -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: pygilstate.patch Url: http://mail.python.org/pipermail/python-bugs-list/attachments/20071122/44f7c6ee/attachment.txt From report at bugs.python.org Thu Nov 22 11:57:56 2007 From: report at bugs.python.org (Simon Percivall) Date: Thu, 22 Nov 2007 10:57:56 -0000 Subject: [issue1358] Compile error on OS X 10.5 Message-ID: <1195729076.49.0.225527479914.issue1358@psf.upfronthosting.co.za> Simon Percivall added the comment: It has to do with the MACOSX_DEPLOYMENT_TARGET. If it's set to 10.4, the legacy version of setpgrp is used (with args), it it's 10.5, setpgrp expects no arguments. It seems configure won't detect the difference. ---------- nosy: +percivall __________________________________ Tracker __________________________________ From report at bugs.python.org Thu Nov 22 12:21:43 2007 From: report at bugs.python.org (vincent kraeutler) Date: Thu, 22 Nov 2007 11:21:43 -0000 Subject: [issue1462525] URI parsing library Message-ID: <1195730503.23.0.990295970012.issue1462525@psf.upfronthosting.co.za> vincent kraeutler added the comment: In the meantime, I have found a very nice parser combinator library for Python (pyparse) and have implemented a validating parser for RFC 3986 URI's by more or less simply converting the complete ABNF grammar found in the RFC. Obviously, this will never make it into the stdlib, due to a dependency on an external library (pyparse), but it might be useful to other people as well. It's available here: http://www.kraeutler.net/vincent/pub/netaddress/netaddress-0.1.tar.gz _____________________________________ Tracker _____________________________________ From report at bugs.python.org Thu Nov 22 13:23:18 2007 From: report at bugs.python.org (Grant Delaney) Date: Thu, 22 Nov 2007 12:23:18 -0000 Subject: [issue1485] Idle tab command completion Message-ID: <1195734198.15.0.922045875096.issue1485@psf.upfronthosting.co.za> New submission from Grant Delaney: Exception in Tkinter callback Traceback (most recent call last): File "/usr/lib/python2.5/lib-tk/Tkinter.py", line 1403, in __call__ return self.func(*args) File "/usr/lib/python2.5/idlelib/AutoCompleteWindow.py", line 217, in winconfig_event x, y, cx, cy = self.widget.bbox(self.startindex) File "/usr/lib/python2.5/lib-tk/Tkinter.py", line 2833, in bbox self.tk.call((self._w, 'bbox') + args)) or None File "/usr/lib/python2.5/lib-tk/Tkinter.py", line 1030, in _getints return tuple(map(getint, self.tk.splitlist(string))) ValueError: invalid literal for int() with base 10: '(72,' ---------- components: IDLE messages: 57757 nosy: Mufasa severity: normal status: open title: Idle tab command completion type: behavior versions: Python 2.5 __________________________________ Tracker __________________________________ From report at bugs.python.org Thu Nov 22 13:49:35 2007 From: report at bugs.python.org (Facundo Batista) Date: Thu, 22 Nov 2007 12:49:35 -0000 Subject: [issue1485] Idle tab command completion Message-ID: <1195735775.54.0.978068670558.issue1485@psf.upfronthosting.co.za> Facundo Batista added the comment: This is not a bug report, just a copied traceback. For a useful bug, put what you did so we can reproduce it, what you get, and what you think you should got. Thanks! ---------- nosy: +facundobatista resolution: -> rejected status: open -> closed __________________________________ Tracker __________________________________ From report at bugs.python.org Thu Nov 22 14:02:56 2007 From: report at bugs.python.org (Grant Delaney) Date: Thu, 22 Nov 2007 13:02:56 -0000 Subject: [issue1486] Idle tab command completion Message-ID: <1195736576.61.0.960072107154.issue1486@psf.upfronthosting.co.za> New submission from Grant Delaney: Running idle from a terminal window in desktop. Python 2.5.1 (r251:54863, Nov 22 2007, 13:55:16) [GCC 4.1.2] on linux2 Type "copyright", "credits" or "license()" for more information. **************************************************************** Personal firewall software may warn about the connection IDLE makes to its subprocess using this computer's internal loopback interface. This connection is not visible on any external interface and no data is sent to or received from the Internet. **************************************************************** IDLE 1.2.1 >>> import sys >>> test = sys. <--- pressing tab should give you the available options for that module/library. The error in the console is as follows: Exception in Tkinter callback Traceback (most recent call last): File "/usr/lib/python2.5/lib-tk/Tkinter.py", line 1403, in __call__ return self.func(*args) File "/usr/lib/python2.5/idlelib/AutoCompleteWindow.py", line 217, in winconfig_event x, y, cx, cy = self.widget.bbox(self.startindex) File "/usr/lib/python2.5/lib-tk/Tkinter.py", line 2833, in bbox self.tk.call((self._w, 'bbox') + args)) or None File "/usr/lib/python2.5/lib-tk/Tkinter.py", line 1030, in _getints return tuple(map(getint, self.tk.splitlist(string))) ValueError: invalid literal for int() with base 10: '(128,' Exception in Tkinter callback Traceback (most recent call last): File "/usr/lib/python2.5/lib-tk/Tkinter.py", line 1403, in __call__ return self.func(*args) File "/usr/lib/python2.5/idlelib/AutoCompleteWindow.py", line 217, in winconfig_event x, y, cx, cy = self.widget.bbox(self.startindex) File "/usr/lib/python2.5/lib-tk/Tkinter.py", line 2833, in bbox self.tk.call((self._w, 'bbox') + args)) or None File "/usr/lib/python2.5/lib-tk/Tkinter.py", line 1030, in _getints return tuple(map(getint, self.tk.splitlist(string))) ValueError: invalid literal for int() with base 10: '(128,' Exception in Tkinter callback Traceback (most recent call last): File "/usr/lib/python2.5/lib-tk/Tkinter.py", line 1403, in __call__ return self.func(*args) File "/usr/lib/python2.5/idlelib/AutoCompleteWindow.py", line 217, in winconfig_event x, y, cx, cy = self.widget.bbox(self.startindex) File "/usr/lib/python2.5/lib-tk/Tkinter.py", line 2833, in bbox self.tk.call((self._w, 'bbox') + args)) or None File "/usr/lib/python2.5/lib-tk/Tkinter.py", line 1030, in _getints return tuple(map(getint, self.tk.splitlist(string))) ValueError: invalid literal for int() with base 10: '(128,' ---------- components: IDLE messages: 57759 nosy: Mufasa severity: normal status: open title: Idle tab command completion type: behavior versions: Python 2.5 __________________________________ Tracker __________________________________ From report at bugs.python.org Thu Nov 22 14:06:04 2007 From: report at bugs.python.org (Facundo Batista) Date: Thu, 22 Nov 2007 13:06:04 -0000 Subject: [issue1486] Idle tab command completion Message-ID: <1195736764.77.0.90508460417.issue1486@psf.upfronthosting.co.za> Facundo Batista added the comment: On IDLE and Python with the same exact version, but in Windows, this works ok. Don't have IDLE in Linux to try it, though. ---------- nosy: +facundobatista __________________________________ Tracker __________________________________ From report at bugs.python.org Thu Nov 22 15:22:16 2007 From: report at bugs.python.org (Nick Coghlan) Date: Thu, 22 Nov 2007 14:22:16 -0000 Subject: [issue1487] PEP 366 implementation Message-ID: <1195741336.57.0.571137300726.issue1487@psf.upfronthosting.co.za> New submission from Nick Coghlan: Patch to implement PEP 366. Note that it doesn't implement precisely the semantics described in the version of the PEP posted in July, as some of those ideas didn't prove feasible due to the fact that imp.new_module can't tell the difference between normal modules and packages. An updated version of the PEP will be posted shortly to correct those problems. ---------- components: Interpreter Core, Library (Lib) files: pep_366_v1.diff keywords: patch messages: 57761 nosy: ncoghlan priority: normal severity: normal status: open title: PEP 366 implementation type: rfe versions: Python 2.6, Python 3.0 Added file: http://bugs.python.org/file8794/pep_366_v1.diff __________________________________ Tracker __________________________________ -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: pep_366_v1.diff Url: http://mail.python.org/pipermail/python-bugs-list/attachments/20071122/0ca3515c/attachment-0001.txt From report at bugs.python.org Thu Nov 22 16:30:08 2007 From: report at bugs.python.org (Vinay Sajip) Date: Thu, 22 Nov 2007 15:30:08 -0000 Subject: [issue1484] logging: callHandlers tests handler levels instead of logger levels? Message-ID: <1195745408.75.0.122777932709.issue1484@psf.upfronthosting.co.za> Vinay Sajip added the comment: The behaviour you describe is intentional. To achieve what you want, you can either set levels on the handlers or use Filters on loggers and/or handlers (if level-based filtering is not sufficient for your needs). ---------- nosy: +vsajip resolution: -> invalid status: open -> closed __________________________________ Tracker __________________________________ From report at bugs.python.org Thu Nov 22 19:41:50 2007 From: report at bugs.python.org (Joseph Armbruster) Date: Thu, 22 Nov 2007 18:41:50 -0000 Subject: [issue1488] PCBuild9 _ssl.vcproj improperly launches build Message-ID: <1195756910.13.0.910588506266.issue1488@psf.upfronthosting.co.za> New submission from Joseph Armbruster: When you attempt to build the _ssl project in release or debug you can possibly encounter errors in the following scenarios: 1) having spaces in the build path 2) if you launch the build in debug, it attempts to run build_ssl.py with the python.exe found in the path rather than that just built named python_d.exe. I believe the solution was designed to run build_ssl.py with the binary that was built in the configuration. If this is correct, then this patch applies. 3) some of the dependency paths did not appear to point to the correct place. Please verify. See attached patch ---------- components: Windows files: sslbuild.patch messages: 57763 nosy: JosephArmbruster, tiran severity: normal status: open title: PCBuild9 _ssl.vcproj improperly launches build type: compile error versions: Python 3.0 Added file: http://bugs.python.org/file8795/sslbuild.patch __________________________________ Tracker __________________________________ -------------- next part -------------- A non-text attachment was scrubbed... Name: sslbuild.patch Type: application/octet-stream Size: 2067 bytes Desc: not available Url : http://mail.python.org/pipermail/python-bugs-list/attachments/20071122/373277c3/attachment.obj From report at bugs.python.org Thu Nov 22 19:48:57 2007 From: report at bugs.python.org (Christian Heimes) Date: Thu, 22 Nov 2007 18:48:57 -0000 Subject: [issue1488] PCBuild9 _ssl.vcproj improperly launches build Message-ID: <1195757337.07.0.947200795794.issue1488@psf.upfronthosting.co.za> Christian Heimes added the comment: Thanks, I'll check it later. ---------- assignee: -> tiran keywords: +patch, py3k priority: -> normal versions: +Python 2.6 __________________________________ Tracker __________________________________ From report at bugs.python.org Thu Nov 22 19:54:26 2007 From: report at bugs.python.org (=?utf-8?q?Peter_=C3=85strand?=) Date: Thu, 22 Nov 2007 18:54:26 -0000 Subject: [issue1475] test_popen fails when the directory contains a space Message-ID: <1195757666.09.0.365208516077.issue1475@psf.upfronthosting.co.za> Peter ?strand added the comment: >In Python 3.x os.popen is implemented based on subprocess. Oh, I see. >I believe it's still a problem with subprocess. I'm still not convinced of this. Isn't it better to do the quoting outside subprocess; to let the caller do it? You say that "section 2" is our case, but how can we be sure of this: If subprocess is called with args='"c:\program files\internet explorer\iexplore.exe"', then we have case 1, right, and surrounding args with another pair of quotes would mean failure, right? __________________________________ Tracker __________________________________ From report at bugs.python.org Thu Nov 22 21:14:30 2007 From: report at bugs.python.org (Quentin Gallet-Gilles) Date: Thu, 22 Nov 2007 20:14:30 -0000 Subject: [issue1486] Idle tab command completion Message-ID: <1195762470.83.0.844054552805.issue1486@psf.upfronthosting.co.za> Quentin Gallet-Gilles added the comment: Couldn't reproduce it either, with the following IDLE config: Python 2.5.1 (r251:54863, Oct 5 2007, 13:36:32) [GCC 4.1.3 20070929 (prerelease) (Ubuntu 4.1.2-16ubuntu2)] on linux2 IDLE 1.2.1 ==== No Subprocess ==== ---------- nosy: +quentin.gallet-gilles __________________________________ Tracker __________________________________ From report at bugs.python.org Thu Nov 22 21:26:55 2007 From: report at bugs.python.org (Brett Cannon) Date: Thu, 22 Nov 2007 20:26:55 -0000 Subject: [issue1631171] implement warnings module in C Message-ID: <1195763215.32.0.0942721493405.issue1631171@psf.upfronthosting.co.za> Brett Cannon added the comment: Implementing warn_explicit() is going to be troublesome with the new module_globals argument. It requires not only to go through the hassle of looking for a loader and calling get_source(), but it will most likely require reworking the traceback function introduced to print out the second line of output (it doesn't look like it directly supports loaders, but I have not tried it personally). _____________________________________ Tracker _____________________________________ From report at bugs.python.org Thu Nov 22 22:23:11 2007 From: report at bugs.python.org (Paul Moore) Date: Thu, 22 Nov 2007 21:23:11 -0000 Subject: [issue1489] test_socket_ssl hanhs on Windows (deadlock) Message-ID: <1195766591.59.0.212085206705.issue1489@psf.upfronthosting.co.za> New submission from Paul Moore: When running the test suite on Windows, test_socket_ssl hangs. After a bit of investigation, it appears that the test is hanging at line 184 (if self.s.stdout.readline() != "ERROR\n":) in OpenSSLServer._external. The problem is that the test assumes it can read a line of stdout from the openssl.exe process. However, the openssl.exe on my PC (from the GnuWin32 project) appears to buffer its output, so the Python process deadlocks waiting for a response. An easy (if clumsy) fix is to simply skip the check on the output of the server. I have attached a patch which does this for win32 only (on the assumption that other platforms don't have this issue). I guess that other openssl builds don't have the same problem - however, I can't see an easy way of testing for this. ---------- components: Tests files: test_socket_ssl.diff messages: 57768 nosy: pmoore severity: normal status: open title: test_socket_ssl hanhs on Windows (deadlock) versions: Python 2.6 Added file: http://bugs.python.org/file8796/test_socket_ssl.diff __________________________________ Tracker __________________________________ -------------- next part -------------- A non-text attachment was scrubbed... Name: test_socket_ssl.diff Type: application/octet-stream Size: 801 bytes Desc: not available Url : http://mail.python.org/pipermail/python-bugs-list/attachments/20071122/30a5a751/attachment.obj From report at bugs.python.org Fri Nov 23 04:13:44 2007 From: report at bugs.python.org (Guido van Rossum) Date: Fri, 23 Nov 2007 03:13:44 -0000 Subject: [issue1489] test_socket_ssl hanhs on Windows (deadlock) Message-ID: <1195787624.28.0.838515676745.issue1489@psf.upfronthosting.co.za> Changes by Guido van Rossum: ---------- assignee: -> janssen nosy: +janssen __________________________________ Tracker __________________________________ From report at bugs.python.org Fri Nov 23 05:40:31 2007 From: report at bugs.python.org (Arunkumar) Date: Fri, 23 Nov 2007 04:40:31 -0000 Subject: [issue1490] Bug in eval() function Message-ID: <1195792830.97.0.696373913002.issue1490@psf.upfronthosting.co.za> New submission from Arunkumar: PythonWin 2.5 (r25:51908, Sep 19 2006, 09:52:17) [MSC v.1310 32 bit (Intel)] on win32. Portions Copyright 1994-2006 Mark Hammond - see 'Help/About PythonWin' for further copyright information. >>> >>> >>> eval("02*2") 4 >>> >>> eval("08*2") Traceback (most recent call last): File "", line 1, in File "", line 1 08*2 ^ SyntaxError: invalid token >>> eval("09*2") Traceback (most recent call last): File "", line 1, in File "", line 1 09*2 ^ SyntaxError: invalid token >>> >>> >>> eval("07*2") 14 >>> >>> eval("010*2") 16 >>> eval("9*2") 18 >>> ---------- messages: 57769 nosy: arunkumarrajan severity: urgent status: open title: Bug in eval() function type: compile error versions: Python 2.5 __________________________________ Tracker __________________________________ From report at bugs.python.org Fri Nov 23 08:06:42 2007 From: report at bugs.python.org (Christian Heimes) Date: Fri, 23 Nov 2007 07:06:42 -0000 Subject: [issue1488] PCBuild9 _ssl.vcproj improperly launches build Message-ID: <1195801602.28.0.41625048629.issue1488@psf.upfronthosting.co.za> Christian Heimes added the comment: I've fixed (1) and (2) in r59130. I don't understand what you mean with (3). ---------- resolution: -> fixed status: open -> pending __________________________________ Tracker __________________________________ From report at bugs.python.org Fri Nov 23 09:11:53 2007 From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=) Date: Fri, 23 Nov 2007 08:11:53 -0000 Subject: [issue1490] Bug in eval() function Message-ID: <1195805513.53.0.889712208999.issue1490@psf.upfronthosting.co.za> Martin v. L?wis added the comment: Why do you think this is a bug? 08 really is a syntax error, and 010 really means 8. ---------- nosy: +loewis resolution: -> invalid status: open -> closed __________________________________ Tracker __________________________________ From report at bugs.python.org Fri Nov 23 09:21:39 2007 From: report at bugs.python.org (Christian Heimes) Date: Fri, 23 Nov 2007 08:21:39 -0000 Subject: [issue1746656] IPv6 Interface naming/indexing functions Message-ID: <1195806099.1.0.169015495245.issue1746656@psf.upfronthosting.co.za> Christian Heimes added the comment: How do you know that the patch is working when you don't know how to test it? Nobody is going to apply new features without unit tests. ---------- nosy: +tiran _____________________________________ Tracker _____________________________________ From report at bugs.python.org Fri Nov 23 09:26:18 2007 From: report at bugs.python.org (Christian Heimes) Date: Fri, 23 Nov 2007 08:26:18 -0000 Subject: [issue1138] Fixer needed for __future__ imports Message-ID: <1195806378.33.0.550356595923.issue1138@psf.upfronthosting.co.za> Changes by Christian Heimes: ---------- keywords: +py3k versions: +Python 3.0 __________________________________ Tracker __________________________________ From report at bugs.python.org Fri Nov 23 09:27:36 2007 From: report at bugs.python.org (Christian Heimes) Date: Fri, 23 Nov 2007 08:27:36 -0000 Subject: [issue1034] [patch] Add 2to3 support for displaying warnings as Python comments Message-ID: <1195806456.96.0.918390859564.issue1034@psf.upfronthosting.co.za> Changes by Christian Heimes: ---------- keywords: +py3k versions: +Python 3.0 __________________________________ Tracker __________________________________ From report at bugs.python.org Fri Nov 23 09:29:27 2007 From: report at bugs.python.org (Christian Heimes) Date: Fri, 23 Nov 2007 08:29:27 -0000 Subject: [issue1675455] Use getaddrinfo() in urllib2.py for IPv6 support Message-ID: <1195806567.86.0.90371763599.issue1675455@psf.upfronthosting.co.za> Changes by Christian Heimes: ---------- versions: +Python 2.6, Python 3.0 _____________________________________ Tracker _____________________________________ From report at bugs.python.org Fri Nov 23 09:36:52 2007 From: report at bugs.python.org (Christian Heimes) Date: Fri, 23 Nov 2007 08:36:52 -0000 Subject: [issue1755179] Deadlocks with fork() and multithreading Message-ID: <1195807012.62.0.682691978362.issue1755179@psf.upfronthosting.co.za> Christian Heimes added the comment: It sounds like the importer dead lock problem. These problems are almost impossible to unit test because they are usually race conditions. I don't see a problem in moving the import to the module name space. errno is a built-in module and the import isn't costly. ---------- nosy: +tiran _____________________________________ Tracker _____________________________________ From report at bugs.python.org Fri Nov 23 09:44:41 2007 From: report at bugs.python.org (Christian Heimes) Date: Fri, 23 Nov 2007 08:44:41 -0000 Subject: [issue444582] Finding programs in PATH, addition to os Message-ID: <1195807481.51.0.374608176609.issue444582@psf.upfronthosting.co.za> Christian Heimes added the comment: I'm +1 with adding a which function. IMO the appropriate place is shutil and not os. ---------- keywords: +patch nosy: +tiran versions: +Python 2.6, Python 3.0 ____________________________________ Tracker ____________________________________ From report at bugs.python.org Fri Nov 23 09:45:50 2007 From: report at bugs.python.org (Christian Heimes) Date: Fri, 23 Nov 2007 08:45:50 -0000 Subject: [issue1189216] zipfile module and 2G boundary Message-ID: <1195807550.53.0.428858171116.issue1189216@psf.upfronthosting.co.za> Changes by Christian Heimes: ---------- components: +Library (Lib) -None versions: +Python 2.6, Python 3.0 _____________________________________ Tracker _____________________________________ From report at bugs.python.org Fri Nov 23 09:52:29 2007 From: report at bugs.python.org (Christian Heimes) Date: Fri, 23 Nov 2007 08:52:29 -0000 Subject: [issue1767787] MSVC++8 x86 tkinter build patch for trunk Message-ID: <1195807949.15.0.65442199125.issue1767787@psf.upfronthosting.co.za> Christian Heimes added the comment: I've fixed the builds a while ago. ---------- nosy: +tiran resolution: -> fixed status: open -> closed _____________________________________ Tracker _____________________________________ From report at bugs.python.org Fri Nov 23 10:02:05 2007 From: report at bugs.python.org (Christian Heimes) Date: Fri, 23 Nov 2007 09:02:05 -0000 Subject: [issue765228] Subclassing from Modules Message-ID: <1195808525.18.0.170201539853.issue765228@psf.upfronthosting.co.za> Christian Heimes added the comment: I agree. Python can't stop the developer from doing stupid things. We could remove Py_TPFLAGS_BASETYPE from the module type but that could cause incompatibilities with existing code. I'm assigning the bug to our beloved dictator to ask for his opinion. ---------- assignee: -> gvanrossum nosy: +gvanrossum, tiran resolution: -> wont fix status: open -> pending ____________________________________ Tracker ____________________________________ From report at bugs.python.org Fri Nov 23 10:10:57 2007 From: report at bugs.python.org (Christian Heimes) Date: Fri, 23 Nov 2007 09:10:57 -0000 Subject: [issue1754271] Deprecation warning for `backticks` Message-ID: <1195809057.76.0.25704498392.issue1754271@psf.upfronthosting.co.za> Christian Heimes added the comment: Applied in r59132 Thanks! ---------- nosy: +tiran resolution: -> fixed status: open -> closed _____________________________________ Tracker _____________________________________ From report at bugs.python.org Fri Nov 23 10:11:05 2007 From: report at bugs.python.org (Christian Heimes) Date: Fri, 23 Nov 2007 09:11:05 -0000 Subject: [issue1754273] Deprecation warning for <> (NOTEQUAL) Message-ID: <1195809065.93.0.0790270527159.issue1754273@psf.upfronthosting.co.za> Christian Heimes added the comment: Applied in r59132 Thanks! ---------- nosy: +tiran resolution: -> fixed status: open -> closed _____________________________________ Tracker _____________________________________ From report at bugs.python.org Fri Nov 23 10:13:58 2007 From: report at bugs.python.org (Christian Heimes) Date: Fri, 23 Nov 2007 09:13:58 -0000 Subject: [issue1764286] inspect.getsource does not work with decorated functions Message-ID: <1195809238.07.0.00316123491316.issue1764286@psf.upfronthosting.co.za> Christian Heimes added the comment: I'm setting the target to 2.6 and 3.0. Maybe somebody can come up with a sensible patch. ---------- nosy: +tiran title: Now: inspect.getsource does not work with decorated functions Was: inspect.getsource does not work with decorated functions versions: +Python 2.6, Python 3.0 -Python 2.5 _____________________________________ Tracker _____________________________________ From report at bugs.python.org Fri Nov 23 10:17:11 2007 From: report at bugs.python.org (Christian Heimes) Date: Fri, 23 Nov 2007 09:17:11 -0000 Subject: [issue1731068] Importing a submodule fails after unloading its parent Message-ID: <1195809431.04.0.21796035814.issue1731068@psf.upfronthosting.co.za> Christian Heimes added the comment: Yes, it's fixed in Python 2.5 and newer. ---------- nosy: +tiran resolution: -> out of date status: open -> closed _____________________________________ Tracker _____________________________________ From report at bugs.python.org Fri Nov 23 10:17:45 2007 From: report at bugs.python.org (Christian Heimes) Date: Fri, 23 Nov 2007 09:17:45 -0000 Subject: [issue1620174] Improve platform.py usability on Windows Message-ID: <1195809465.15.0.201271370975.issue1620174@psf.upfronthosting.co.za> Changes by Christian Heimes: ---------- components: +Library (Lib) -None versions: +Python 2.6 _____________________________________ Tracker _____________________________________ From report at bugs.python.org Fri Nov 23 10:18:34 2007 From: report at bugs.python.org (Christian Heimes) Date: Fri, 23 Nov 2007 09:18:34 -0000 Subject: [issue1735632] Add O_NOATIME to os module Message-ID: <1195809514.7.0.197096845252.issue1735632@psf.upfronthosting.co.za> Changes by Christian Heimes: ---------- versions: +Python 2.6, Python 3.0 _____________________________________ Tracker _____________________________________ From report at bugs.python.org Fri Nov 23 10:20:55 2007 From: report at bugs.python.org (Christian Heimes) Date: Fri, 23 Nov 2007 09:20:55 -0000 Subject: [issue1230540] sys.excepthook doesn't work in threads Message-ID: <1195809655.07.0.132084043271.issue1230540@psf.upfronthosting.co.za> Changes by Christian Heimes: ---------- versions: +Python 2.5, Python 2.6 -Python 2.4 _____________________________________ Tracker _____________________________________ From report at bugs.python.org Fri Nov 23 10:24:02 2007 From: report at bugs.python.org (Christian Heimes) Date: Fri, 23 Nov 2007 09:24:02 -0000 Subject: [issue1732145] python 2.6 latest fails test_socketserver.py Message-ID: <1195809842.36.0.00718029840199.issue1732145@psf.upfronthosting.co.za> Christian Heimes added the comment: I'm closing the bug report because it's pretty old and I haven't seen a problem with the test in the past. Please open another bug if the problem still persists. ---------- nosy: +tiran resolution: -> works for me status: open -> closed _____________________________________ Tracker _____________________________________ From report at bugs.python.org Fri Nov 23 10:55:59 2007 From: report at bugs.python.org (Marc-Andre Lemburg) Date: Fri, 23 Nov 2007 09:55:59 -0000 Subject: [issue1620174] Improve platform.py usability on Windows Message-ID: <1195811759.04.0.280909887371.issue1620174@psf.upfronthosting.co.za> Marc-Andre Lemburg added the comment: Rejecting the patch, since it hasn't been updated. ---------- resolution: -> rejected status: open -> closed _____________________________________ Tracker _____________________________________ From report at bugs.python.org Fri Nov 23 13:52:40 2007 From: report at bugs.python.org (samwyse) Date: Fri, 23 Nov 2007 12:52:40 -0000 Subject: [issue1491] BaseHTTPServer incorrectly implements response code 100 Message-ID: <1195822360.07.0.215272908737.issue1491@psf.upfronthosting.co.za> New submission from samwyse: RFC 2616 sec 8.2.3 states, "An origin server that sends a 100 (Continue) response MUST ultimately send a final status code, once the request body is received and processed, unless it terminates the transport connection prematurely." The obvious way to do this is to invoke the 'send_response' method twice, once with a code of 100, then with the final code. However, BaseHTTPServer will always send two headers ('Server' and 'Date') when it send a response. One possible fix is to add an option to the method to suppress sending headers; another is to add the following code to the 'send_response' method, immediately prior to the calls to 'self.send_header': if code == 100: return The more paranoid among us may wish to use this code instead: if code == 100: expectation = self.headers.get('Expect', "") if expectation.lower() == '100-continue': return ---------- components: Library (Lib) messages: 57783 nosy: samwyse severity: normal status: open title: BaseHTTPServer incorrectly implements response code 100 type: behavior versions: Python 2.4, Python 2.5, Python 2.6, Python 3.0 __________________________________ Tracker __________________________________ From report at bugs.python.org Fri Nov 23 14:04:07 2007 From: report at bugs.python.org (samwyse) Date: Fri, 23 Nov 2007 13:04:07 -0000 Subject: [issue1492] BaseHTTPServer hard-codes Content-Type for error messages Message-ID: <1195823047.2.0.185836867459.issue1492@psf.upfronthosting.co.za> New submission from samwyse: The send_error method always sends a Content-Type of 'text/html'. Other content types are both possible and desirable. For example, someone writing a REST server might wish to send XML error messages. Following the example of DEFAULT_ERROR_MESSAGE, I propose adding the following in the appropriate places: 91a92,94 > # Default error content-type > DEFAULT_ERROR_TYPE = 'text/html' > 345c348 < self.send_header("Content-Type", "text/html") --- > self.send_header("Content-Type", error_message_type) 351a355 > error_message_type = DEFAULT_ERROR_TYPE ---------- messages: 57784 nosy: samwyse severity: normal status: open title: BaseHTTPServer hard-codes Content-Type for error messages __________________________________ Tracker __________________________________ From report at bugs.python.org Fri Nov 23 14:04:32 2007 From: report at bugs.python.org (samwyse) Date: Fri, 23 Nov 2007 13:04:32 -0000 Subject: [issue1492] BaseHTTPServer hard-codes Content-Type for error messages Message-ID: <1195823072.24.0.828740079647.issue1492@psf.upfronthosting.co.za> Changes by samwyse: ---------- components: +Library (Lib) type: -> behavior versions: +Python 2.4, Python 2.5, Python 2.6, Python 3.0 __________________________________ Tracker __________________________________ From report at bugs.python.org Fri Nov 23 14:14:26 2007 From: report at bugs.python.org (Joseph Armbruster) Date: Fri, 23 Nov 2007 13:14:26 -0000 Subject: [issue1488] PCBuild9 _ssl.vcproj improperly launches build Message-ID: <1195823666.22.0.211523220185.issue1488@psf.upfronthosting.co.za> Joseph Armbruster added the comment: Looks like the libpaths were pointing to out32 instead of out32.dll. Although that may have been due to my switch from nt.mak to ntdll.mak. __________________________________ Tracker __________________________________ From report at bugs.python.org Fri Nov 23 14:51:51 2007 From: report at bugs.python.org (Christian Heimes) Date: Fri, 23 Nov 2007 13:51:51 -0000 Subject: [issue1488] PCBuild9 _ssl.vcproj improperly launches build Message-ID: <1195825911.89.0.553016311661.issue1488@psf.upfronthosting.co.za> Christian Heimes added the comment: out32 is the correct directory. The windows version of Python is statically linked against the SSL libs. We don't want to ship yet another DLL. __________________________________ Tracker __________________________________ From report at bugs.python.org Fri Nov 23 15:05:20 2007 From: report at bugs.python.org (Christian Heimes) Date: Fri, 23 Nov 2007 14:05:20 -0000 Subject: [issue1488] PCBuild9 _ssl.vcproj improperly launches build Message-ID: <1195826720.17.0.760493142723.issue1488@psf.upfronthosting.co.za> Changes by Christian Heimes: ---------- status: pending -> closed __________________________________ Tracker __________________________________ From report at bugs.python.org Fri Nov 23 16:36:20 2007 From: report at bugs.python.org (Christian Heimes) Date: Fri, 23 Nov 2007 15:36:20 -0000 Subject: [issue1474] PCbuild9 patch for trunk Message-ID: <1195832180.44.0.4998564367.issue1474@psf.upfronthosting.co.za> Changes by Christian Heimes: ---------- resolution: -> fixed status: open -> closed __________________________________ Tracker __________________________________ From report at bugs.python.org Fri Nov 23 17:14:56 2007 From: report at bugs.python.org (Thomas Herve) Date: Fri, 23 Nov 2007 16:14:56 -0000 Subject: [issue1315] Bug in pstats.print_callers Message-ID: <1195834496.38.0.0367431782001.issue1315@psf.upfronthosting.co.za> Thomas Herve added the comment: The real bug is in fact in add_callers, where it concatenates tuples instead of adding the values. I'll try to write a test this week-end if nobody beats me to it. The attached is against current trunk. ---------- nosy: +therve Added file: http://bugs.python.org/file8797/1315.diff __________________________________ Tracker __________________________________ -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: 1315.diff Url: http://mail.python.org/pipermail/python-bugs-list/attachments/20071123/4a8e6b99/attachment.txt From report at bugs.python.org Fri Nov 23 17:28:31 2007 From: report at bugs.python.org (Thomas Herve) Date: Fri, 23 Nov 2007 16:28:31 -0000 Subject: [issue1315] Bug in pstats.print_callers Message-ID: <1195835311.21.0.99273133436.issue1315@psf.upfronthosting.co.za> Thomas Herve added the comment: Oh I didn't see, but this one should probably closed as duplicate of 1269. __________________________________ Tracker __________________________________ From report at bugs.python.org Fri Nov 23 17:29:02 2007 From: report at bugs.python.org (Thomas Herve) Date: Fri, 23 Nov 2007 16:29:02 -0000 Subject: [issue1269] Exception in pstats print_callers() Message-ID: <1195835342.4.0.991293304597.issue1269@psf.upfronthosting.co.za> Thomas Herve added the comment: 1315 is a duplicate of this, and I end up with a very similar solution. ---------- nosy: +therve __________________________________ Tracker __________________________________ From report at bugs.python.org Fri Nov 23 17:31:23 2007 From: report at bugs.python.org (Joseph Armbruster) Date: Fri, 23 Nov 2007 16:31:23 -0000 Subject: [issue1488] PCBuild9 _ssl.vcproj improperly launches build Message-ID: <1195835483.19.0.339284686134.issue1488@psf.upfronthosting.co.za> Joseph Armbruster added the comment: Whoops. This may have been an error on my part. nt.mak I think bombed for me except it was probably due to some of my tinkering. My apologies. __________________________________ Tracker __________________________________ From report at bugs.python.org Fri Nov 23 17:59:11 2007 From: report at bugs.python.org (Grant Delaney) Date: Fri, 23 Nov 2007 16:59:11 -0000 Subject: [issue1486] Idle tab command completion Message-ID: <1195837151.85.0.123057982942.issue1486@psf.upfronthosting.co.za> Grant Delaney added the comment: You can remove this issue. It was a compile problem on my side, missing libs etc. __________________________________ Tracker __________________________________ From report at bugs.python.org Fri Nov 23 18:10:37 2007 From: report at bugs.python.org (Skip Montanaro) Date: Fri, 23 Nov 2007 17:10:37 -0000 Subject: [issue1429818] trace.py needs to know about doctests Message-ID: <1195837837.62.0.495667406754.issue1429818@psf.upfronthosting.co.za> Skip Montanaro added the comment: Applied in r59317 (trunk) and r59318 (release25-maint). ---------- assignee: -> skip.montanaro nosy: +skip.montanaro resolution: -> accepted status: open -> closed _____________________________________ Tracker _____________________________________ From report at bugs.python.org Fri Nov 23 18:10:56 2007 From: report at bugs.python.org (Facundo Batista) Date: Fri, 23 Nov 2007 17:10:56 -0000 Subject: [issue1486] Idle tab command completion Message-ID: <1195837856.84.0.0563639182736.issue1486@psf.upfronthosting.co.za> Facundo Batista added the comment: Rejected as requested by the OP. ---------- resolution: -> rejected status: open -> closed __________________________________ Tracker __________________________________ From report at bugs.python.org Fri Nov 23 19:13:26 2007 From: report at bugs.python.org (Ivan Pozdeev) Date: Fri, 23 Nov 2007 18:13:26 -0000 Subject: [issue1256] subprocess Popen wait() function hangs when stdout is > 20480 Message-ID: <1195841606.13.0.899225549765.issue1256@psf.upfronthosting.co.za> Ivan Pozdeev added the comment: I suggest adding this as a note to the subprocess module documentation instead. The "17.1.2 Popen Objects" section seems to be the right place. ---------- nosy: +Vano __________________________________ Tracker __________________________________ From report at bugs.python.org Sat Nov 24 00:34:30 2007 From: report at bugs.python.org (Amaury Forgeot d'Arc) Date: Fri, 23 Nov 2007 23:34:30 -0000 Subject: [issue1402] Interpreter cleanup: order of _PyGILState_Fini and PyInterpreterState_Clear Message-ID: <1195860870.73.0.65481016459.issue1402@psf.upfronthosting.co.za> Amaury Forgeot d'Arc added the comment: I managed to reproduce the problem consistently with the following code: import ctypes, sys, time, thread # Module globals are cleared before __del__ is run # So save the functions in class dict class C: ensure = ctypes.pythonapi.PyGILState_Ensure release = ctypes.pythonapi.PyGILState_Release def __del__(self): state = self.ensure() self.release(state) def waitingThread(): x = C() time.sleep(100) thread.start_new_thread(waitingThread, ()) time.sleep(1) sys.exit(42) On exit, PyInterpreterState_Clear stops the sleeping thread and free its local variables. But at this time _PyGILState_Fini has already been called... The initial patch also corrects this problem. I join another patch, which adds the above code in a testcase. Ready to check-in, but can someone have a look? ---------- nosy: +amaury.forgeotdarc Added file: http://bugs.python.org/file8798/test_gilstate.patch __________________________________ Tracker __________________________________ -------------- next part -------------- A non-text attachment was scrubbed... Name: test_gilstate.patch Type: application/octet-stream Size: 1723 bytes Desc: not available Url : http://mail.python.org/pipermail/python-bugs-list/attachments/20071123/167e6eba/attachment.obj From report at bugs.python.org Sat Nov 24 01:29:51 2007 From: report at bugs.python.org (Amaury Forgeot d'Arc) Date: Sat, 24 Nov 2007 00:29:51 -0000 Subject: [issue1409] new keyword-only function parameters interact badly with nested functions Message-ID: <1195864191.31.0.433718584308.issue1409@psf.upfronthosting.co.za> Amaury Forgeot d'Arc added the comment: Corrected as r59155. Thanks for the report! ---------- nosy: +amaury.forgeotdarc resolution: -> fixed status: open -> closed __________________________________ Tracker __________________________________ From report at bugs.python.org Sat Nov 24 02:01:52 2007 From: report at bugs.python.org (Facundo Batista) Date: Sat, 24 Nov 2007 01:01:52 -0000 Subject: [issue1770416] Decimal.__int__ overflows for large values Message-ID: <1195866112.87.0.985514768495.issue1770416@psf.upfronthosting.co.za> Facundo Batista added the comment: This was fixed at the same time than issue 1772851. int(D("1e1234567890987654321")) stills take too long, but this is fault of doing 10**1234567890987654321 to convert it to an int. Note that hash(D("1e1234567890987654321")) is fast now. ---------- resolution: -> fixed status: open -> closed _____________________________________ Tracker _____________________________________ From report at bugs.python.org Sat Nov 24 07:50:34 2007 From: report at bugs.python.org (Christian Heimes) Date: Sat, 24 Nov 2007 06:50:34 -0000 Subject: [issue1493] Patch to remove unbound methods Message-ID: <1195887033.53.0.361766903132.issue1493@psf.upfronthosting.co.za> New submission from Christian Heimes: Here is a first patch to remove unbound method objects. 6 tests failed: test_descr test_inspect test_pyclbr test_typechecks test_unittest test_weakref ---------- assignee: gvanrossum components: Interpreter Core files: py3k_remove_unbound.patch keywords: patch, py3k messages: 57798 nosy: gvanrossum, tiran priority: high severity: normal status: open title: Patch to remove unbound methods type: rfe versions: Python 3.0 Added file: http://bugs.python.org/file8799/py3k_remove_unbound.patch __________________________________ Tracker __________________________________ -------------- next part -------------- A non-text attachment was scrubbed... Name: py3k_remove_unbound.patch Type: text/x-diff Size: 12503 bytes Desc: not available Url : http://mail.python.org/pipermail/python-bugs-list/attachments/20071124/140b3cc4/attachment-0001.patch From report at bugs.python.org Sat Nov 24 12:22:28 2007 From: report at bugs.python.org (Georg Brandl) Date: Sat, 24 Nov 2007 11:22:28 -0000 Subject: [issue1220] popen3 website documentation inconsistency Message-ID: <1195903348.22.0.925772577304.issue1220@psf.upfronthosting.co.za> Georg Brandl added the comment: Sorry, but you're confusing the os.popen* functions with the popen3.popen* functions. (That they both exist, and return the handles in different orders is a mess, but it is documented correctly.) ---------- nosy: +georg.brandl resolution: -> invalid status: open -> closed __________________________________ Tracker __________________________________ From report at bugs.python.org Sat Nov 24 12:24:26 2007 From: report at bugs.python.org (Georg Brandl) Date: Sat, 24 Nov 2007 11:24:26 -0000 Subject: [issue1273] email module example email-unpack.py error Message-ID: <1195903466.4.0.864082838804.issue1273@psf.upfronthosting.co.za> Georg Brandl added the comment: Thanks, this is fixed in the development docs now (r58445). ---------- nosy: +georg.brandl resolution: -> fixed status: open -> closed __________________________________ Tracker __________________________________ From report at bugs.python.org Sat Nov 24 12:32:22 2007 From: report at bugs.python.org (Georg Brandl) Date: Sat, 24 Nov 2007 11:32:22 -0000 Subject: [issue1344] subprocess.communication doc could use clarification Message-ID: <1195903942.64.0.686698662048.issue1344@psf.upfronthosting.co.za> Georg Brandl added the comment: Thanks, this is now documented (r59164). ---------- nosy: +georg.brandl status: open -> closed __________________________________ Tracker __________________________________ From report at bugs.python.org Sat Nov 24 12:39:37 2007 From: report at bugs.python.org (Georg Brandl) Date: Sat, 24 Nov 2007 11:39:37 -0000 Subject: [issue1467] error in TestResult.addError and TestResult.addFailure Message-ID: <1195904377.81.0.0140489606296.issue1467@psf.upfronthosting.co.za> Georg Brandl added the comment: Thanks, this is now fixed in the development docs (r59165). ---------- nosy: +georg.brandl resolution: -> fixed status: open -> closed __________________________________ Tracker __________________________________ From report at bugs.python.org Sat Nov 24 12:42:30 2007 From: report at bugs.python.org (Georg Brandl) Date: Sat, 24 Nov 2007 11:42:30 -0000 Subject: [issue1355] xml.dom refers to PyXML, which is no longer maintained Message-ID: <1195904550.62.0.995562123136.issue1355@psf.upfronthosting.co.za> Georg Brandl added the comment: I've now removed mention of PyXML from the docs (r59166). ---------- resolution: -> fixed status: open -> closed __________________________________ Tracker __________________________________ From report at bugs.python.org Sat Nov 24 14:07:21 2007 From: report at bugs.python.org (Amaury Forgeot d'Arc) Date: Sat, 24 Nov 2007 13:07:21 -0000 Subject: [issue1442] pythonstartup addition of minor error checking Message-ID: <1195909641.01.0.955813709.issue1442@psf.upfronthosting.co.za> Amaury Forgeot d'Arc added the comment: Shall we close this issue? ---------- nosy: +amaury.forgeotdarc __________________________________ Tracker __________________________________ From report at bugs.python.org Sat Nov 24 14:37:40 2007 From: report at bugs.python.org (Georg Brandl) Date: Sat, 24 Nov 2007 13:37:40 -0000 Subject: [issue1315] Bug in pstats.print_callers Message-ID: <1195911460.77.0.308520967667.issue1315@psf.upfronthosting.co.za> Changes by Georg Brandl: ---------- resolution: -> duplicate status: open -> closed superseder: -> Exception in pstats print_callers() __________________________________ Tracker __________________________________ From report at bugs.python.org Sat Nov 24 14:54:27 2007 From: report at bugs.python.org (Amaury Forgeot d'Arc) Date: Sat, 24 Nov 2007 13:54:27 -0000 Subject: [issue1445] SystemError accessing uninitialised cell contents Message-ID: <1195912467.0.0.624731131879.issue1445@psf.upfronthosting.co.za> Amaury Forgeot d'Arc added the comment: Fixed in r59170 (trunk) and r59171 (release25-maint). ---------- nosy: +amaury.forgeotdarc resolution: -> fixed status: open -> closed __________________________________ Tracker __________________________________ From report at bugs.python.org Sat Nov 24 14:56:17 2007 From: report at bugs.python.org (Georg Brandl) Date: Sat, 24 Nov 2007 13:56:17 -0000 Subject: [issue1735632] Add O_NOATIME to os module Message-ID: <1195912577.41.0.881260627295.issue1735632@psf.upfronthosting.co.za> Georg Brandl added the comment: Added the constant in r59172. The behavior is way too special though to warrant a change to builtin open(). ---------- nosy: +georg.brandl resolution: -> accepted status: open -> closed _____________________________________ Tracker _____________________________________ From report at bugs.python.org Sat Nov 24 15:02:18 2007 From: report at bugs.python.org (Georg Brandl) Date: Sat, 24 Nov 2007 14:02:18 -0000 Subject: [issue1285] setp.py error "The process cannot access the file ..." Message-ID: <1195912938.83.0.937826208303.issue1285@psf.upfronthosting.co.za> Changes by Georg Brandl: ---------- assignee: -> loewis nosy: +loewis __________________________________ Tracker __________________________________ From report at bugs.python.org Sat Nov 24 15:17:23 2007 From: report at bugs.python.org (Georg Brandl) Date: Sat, 24 Nov 2007 14:17:23 -0000 Subject: [issue1282] re module needs to support bytes / memoryview well Message-ID: <1195913843.75.0.452387716631.issue1282@psf.upfronthosting.co.za> Changes by Georg Brandl: ---------- type: rfe -> behavior __________________________________ Tracker __________________________________ From report at bugs.python.org Sat Nov 24 16:45:42 2007 From: report at bugs.python.org (Christian Heimes) Date: Sat, 24 Nov 2007 15:45:42 -0000 Subject: [issue1442] pythonstartup addition of minor error checking Message-ID: <1195919142.1.0.854108470735.issue1442@psf.upfronthosting.co.za> Christian Heimes added the comment: I think we should backport it to 2.6 and maybe 2.5. __________________________________ Tracker __________________________________ From report at bugs.python.org Sat Nov 24 17:09:51 2007 From: report at bugs.python.org (Christopher Denter) Date: Sat, 24 Nov 2007 16:09:51 -0000 Subject: [issue1494] DOM-Documentation should mention that appendChild() removes the child it appends Message-ID: <1195920591.84.0.811892323535.issue1494@psf.upfronthosting.co.za> Changes by Christopher Denter: ---------- components: Documentation nosy: dennda severity: normal status: open title: DOM-Documentation should mention that appendChild() removes the child it appends __________________________________ Tracker __________________________________ From report at bugs.python.org Sat Nov 24 18:28:31 2007 From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=) Date: Sat, 24 Nov 2007 17:28:31 -0000 Subject: [issue1285] setp.py error "The process cannot access the file ..." Message-ID: <1195925311.39.0.0598280968488.issue1285@psf.upfronthosting.co.za> Martin v. L?wis added the comment: Can you provide a setup.py that allows to reproduce this error? __________________________________ Tracker __________________________________ From report at bugs.python.org Sat Nov 24 18:29:22 2007 From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=) Date: Sat, 24 Nov 2007 17:29:22 -0000 Subject: [issue1494] DOM-Documentation should mention that appendChild() removes the child it appends Message-ID: <1195925362.22.0.843018780908.issue1494@psf.upfronthosting.co.za> New submission from Martin v. L?wis: Can you propose a specific wording? ---------- nosy: +loewis __________________________________ Tracker __________________________________ From report at bugs.python.org Sat Nov 24 18:50:23 2007 From: report at bugs.python.org (Guido van Rossum) Date: Sat, 24 Nov 2007 17:50:23 -0000 Subject: [issue1493] Patch to remove unbound methods Message-ID: <1195926623.62.0.665959870967.issue1493@psf.upfronthosting.co.za> Guido van Rossum added the comment: I'm waiting for those failing tests to magically start passing. :-) __________________________________ Tracker __________________________________ From report at bugs.python.org Sat Nov 24 19:21:06 2007 From: report at bugs.python.org (Christopher Denter) Date: Sat, 24 Nov 2007 18:21:06 -0000 Subject: [issue1494] DOM-Documentation should mention that appendChild() removes the child it appends Message-ID: <1195928466.7.0.289267052003.issue1494@psf.upfronthosting.co.za> Christopher Denter added the comment: "Add a new child node to this node at the end of the list of children, returning newChild. The original child node is removed after appending the child to the new node." maybe? It took me quite some time to figure that out because I thought "it's not popAndAppend()", so having a hint in the documentation would be nice. (This is the first time I use this bugtracker. I hope this message will be displayed correctly.) __________________________________ Tracker __________________________________ From report at bugs.python.org Sat Nov 24 19:42:56 2007 From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=) Date: Sat, 24 Nov 2007 18:42:56 -0000 Subject: [issue1494] DOM-Documentation should mention that appendChild() removes the child it appends Message-ID: <1195929776.1.0.360009959086.issue1494@psf.upfronthosting.co.za> Martin v. L?wis added the comment: Thanks. I committed something like that as 59176. Notice that the precise semantics of all operations is specified in the DOM itself, http://www.w3.org/TR/2000/REC-DOM-Level-2-Core-20001113/core.html which says Adds the node newChild to the end of the list of children of this node. If the newChild is already in the tree, it is first removed. ---------- resolution: -> fixed status: open -> closed __________________________________ Tracker __________________________________ From report at bugs.python.org Sat Nov 24 20:37:46 2007 From: report at bugs.python.org (Christian Heimes) Date: Sat, 24 Nov 2007 19:37:46 -0000 Subject: [issue1493] Patch to remove unbound methods Message-ID: <1195933066.06.0.390510608395.issue1493@psf.upfronthosting.co.za> Christian Heimes added the comment: Do you still believe in the tooth fairy, too? :p __________________________________ Tracker __________________________________ From report at bugs.python.org Sat Nov 24 21:16:32 2007 From: report at bugs.python.org (Georg Brandl) Date: Sat, 24 Nov 2007 20:16:32 -0000 Subject: [issue1493] Patch to remove unbound methods Message-ID: <1195935392.31.0.530557086987.issue1493@psf.upfronthosting.co.za> Georg Brandl added the comment: Okay, this new patch takes care of test_pyclbr, test_inspect and test_weakref. test_unittest is a bit hard: previously, calling loadTestsFromName with the name of a method would create a test that runs that test case with that method being the test method. With the name of a staticmethod though it would call the staticmethod first and use the result of that call as the test case. Now, there is no visible distinction between static methods and normal methods anymore. ---------- nosy: +georg.brandl Added file: http://bugs.python.org/file8800/py3k_remove_unbound_2.patch __________________________________ Tracker __________________________________ -------------- next part -------------- A non-text attachment was scrubbed... Name: py3k_remove_unbound_2.patch Type: application/octet-stream Size: 17060 bytes Desc: not available Url : http://mail.python.org/pipermail/python-bugs-list/attachments/20071124/4979a531/attachment-0001.obj From report at bugs.python.org Sat Nov 24 21:29:00 2007 From: report at bugs.python.org (Georg Brandl) Date: Sat, 24 Nov 2007 20:29:00 -0000 Subject: [issue1493] Patch to remove unbound methods Message-ID: <1195936140.35.0.506709727349.issue1493@psf.upfronthosting.co.za> Georg Brandl added the comment: Got test_typechecks too - the test is simply not applicable anymore. Added file: http://bugs.python.org/file8801/py3k_remove_unbound_3.patch __________________________________ Tracker __________________________________ -------------- next part -------------- A non-text attachment was scrubbed... Name: py3k_remove_unbound_3.patch Type: application/octet-stream Size: 18029 bytes Desc: not available Url : http://mail.python.org/pipermail/python-bugs-list/attachments/20071124/dfc79e8c/attachment.obj From report at bugs.python.org Sat Nov 24 21:53:12 2007 From: report at bugs.python.org (Georg Brandl) Date: Sat, 24 Nov 2007 20:53:12 -0000 Subject: [issue1493] Patch to remove unbound methods Message-ID: <1195937592.91.0.720366923651.issue1493@psf.upfronthosting.co.za> Georg Brandl added the comment: Okay, got test_descr too -- the problem was introduced by the patch itself :) Added file: http://bugs.python.org/file8802/py3k_remove_unbound_4.patch __________________________________ Tracker __________________________________ -------------- next part -------------- A non-text attachment was scrubbed... Name: py3k_remove_unbound_4.patch Type: application/octet-stream Size: 17967 bytes Desc: not available Url : http://mail.python.org/pipermail/python-bugs-list/attachments/20071124/80a34924/attachment-0001.obj From report at bugs.python.org Sat Nov 24 21:53:16 2007 From: report at bugs.python.org (Georg Brandl) Date: Sat, 24 Nov 2007 20:53:16 -0000 Subject: [issue1493] Patch to remove unbound methods Message-ID: <1195937596.72.0.155914487739.issue1493@psf.upfronthosting.co.za> Changes by Georg Brandl: Removed file: http://bugs.python.org/file8800/py3k_remove_unbound_2.patch __________________________________ Tracker __________________________________ From report at bugs.python.org Sat Nov 24 21:53:19 2007 From: report at bugs.python.org (Georg Brandl) Date: Sat, 24 Nov 2007 20:53:19 -0000 Subject: [issue1493] Patch to remove unbound methods Message-ID: <1195937599.81.0.694962967419.issue1493@psf.upfronthosting.co.za> Changes by Georg Brandl: Removed file: http://bugs.python.org/file8801/py3k_remove_unbound_3.patch __________________________________ Tracker __________________________________ From report at bugs.python.org Sat Nov 24 22:00:40 2007 From: report at bugs.python.org (Magnus Valle) Date: Sat, 24 Nov 2007 21:00:40 -0000 Subject: [issue1495] Unicode in a comment. Message-ID: <1195938040.58.0.768947830961.issue1495@psf.upfronthosting.co.za> New submission from Magnus Valle: My script reports this problem: """ $ python bug.py File "bug.py", line 4 SyntaxError: Non-ASCII character '\xc2' in file bug.py on line 4, but no encoding declared; see http://www.python.org/peps/pep-0263.html for details """ This error looks fine and all, but the problem is that the non-ASCII character (in this case '?') is in a comment, not in the script itself. If I remove it the non-ASCII character from the comment, it runs perfectly. I always assumed that comment didn't effect the script. This isn't exactly a big problem, but I don't think it should be this way. I included the demo script. PS. $ python -V Python 2.5.1 ---------- components: Unicode files: bug.py messages: 57817 nosy: wiscados severity: minor status: open title: Unicode in a comment. versions: Python 2.5 Added file: http://bugs.python.org/file8803/bug.py __________________________________ Tracker __________________________________ -------------- next part -------------- A non-text attachment was scrubbed... Name: bug.py Type: text/x-python Size: 93 bytes Desc: not available Url : http://mail.python.org/pipermail/python-bugs-list/attachments/20071124/c6b09051/attachment.py From report at bugs.python.org Sat Nov 24 22:04:32 2007 From: report at bugs.python.org (Facundo Batista) Date: Sat, 24 Nov 2007 21:04:32 -0000 Subject: [issue1495] Unicode in a comment. Message-ID: <1195938272.89.0.705340478017.issue1495@psf.upfronthosting.co.za> Facundo Batista added the comment: This is the way it's supposed to work, read the PEP. ---------- nosy: +facundobatista resolution: -> invalid status: open -> closed __________________________________ Tracker __________________________________ From report at bugs.python.org Sat Nov 24 22:14:40 2007 From: report at bugs.python.org (Christian Heimes) Date: Sat, 24 Nov 2007 21:14:40 -0000 Subject: [issue1493] Patch to remove unbound methods In-Reply-To: <1195937592.91.0.720366923651.issue1493@psf.upfronthosting.co.za> Message-ID: <4748943C.2050806@cheimes.de> Christian Heimes added the comment: Georg Brandl wrote: > Okay, got test_descr too -- the problem was introduced by the patch > itself :) Yes, I introduced the problem because I thought that sometimes is wrong here. The question mark in > doesn't look right. Christian __________________________________ Tracker __________________________________ From report at bugs.python.org Sat Nov 24 22:34:12 2007 From: report at bugs.python.org (Dave Hughes) Date: Sat, 24 Nov 2007 21:34:12 -0000 Subject: [issue1222] locale.format bug if thousand separator is space (french separator as example) Message-ID: <1195940052.51.0.166527394948.issue1222@psf.upfronthosting.co.za> Changes by Dave Hughes: ---------- nosy: +waveform __________________________________ Tracker __________________________________ From report at bugs.python.org Sat Nov 24 23:01:18 2007 From: report at bugs.python.org (Georg Brandl) Date: Sat, 24 Nov 2007 22:01:18 -0000 Subject: [issue1493] Patch to remove unbound methods Message-ID: <1195941678.74.0.369253966789.issue1493@psf.upfronthosting.co.za> Georg Brandl added the comment: I think it is correct -- normally the __get__ call gets a second argument of C. __________________________________ Tracker __________________________________ From report at bugs.python.org Sun Nov 25 01:27:37 2007 From: report at bugs.python.org (Georg Brandl) Date: Sun, 25 Nov 2007 00:27:37 -0000 Subject: [issue1391] Adds the .compact() method to bsddb db.DB objects Message-ID: <1195950457.8.0.0582705598283.issue1391@psf.upfronthosting.co.za> Changes by Georg Brandl: ---------- keywords: -rfe type: -> rfe __________________________________ Tracker __________________________________ From report at bugs.python.org Sun Nov 25 01:27:50 2007 From: report at bugs.python.org (Georg Brandl) Date: Sun, 25 Nov 2007 00:27:50 -0000 Subject: [issue1342] Crash on Windows if Python runs from a directory with umlauts Message-ID: <1195950470.5.0.886366537446.issue1342@psf.upfronthosting.co.za> Changes by Georg Brandl: ---------- keywords: -rfe __________________________________ Tracker __________________________________ From report at bugs.python.org Sun Nov 25 01:45:20 2007 From: report at bugs.python.org (Georg Brandl) Date: Sun, 25 Nov 2007 00:45:20 -0000 Subject: [issue1480] sqlite module is leaking lots of references Message-ID: <1195951520.47.0.172255143202.issue1480@psf.upfronthosting.co.za> Georg Brandl added the comment: Fixed in r59180. ---------- nosy: +georg.brandl resolution: -> fixed status: open -> closed __________________________________ Tracker __________________________________ From report at bugs.python.org Sun Nov 25 01:52:30 2007 From: report at bugs.python.org (Georg Brandl) Date: Sun, 25 Nov 2007 00:52:30 -0000 Subject: [issue1479] csv module is leaking references Message-ID: <1195951950.93.0.70760541139.issue1479@psf.upfronthosting.co.za> Georg Brandl added the comment: Fixed in r59181. ---------- nosy: +georg.brandl resolution: -> fixed status: open -> closed __________________________________ Tracker __________________________________ From report at bugs.python.org Sun Nov 25 02:24:45 2007 From: report at bugs.python.org (Georg Brandl) Date: Sun, 25 Nov 2007 01:24:45 -0000 Subject: [issue1496] add str.maketrans() Message-ID: <1195953885.52.0.314966183764.issue1496@psf.upfronthosting.co.za> New submission from Georg Brandl: This patch restores old behavior of str.translate() and adds the str.maketrans() static method. Docs and tests will follow if this is the right way to go. ---------- assignee: gvanrossum files: str-maketrans.diff messages: 57823 nosy: georg.brandl, gvanrossum priority: normal severity: normal status: open title: add str.maketrans() type: behavior versions: Python 3.0 Added file: http://bugs.python.org/file8804/str-maketrans.diff __________________________________ Tracker __________________________________ -------------- next part -------------- A non-text attachment was scrubbed... Name: str-maketrans.diff Type: application/pgp-signature Size: 7371 bytes Desc: not available Url : http://mail.python.org/pipermail/python-bugs-list/attachments/20071125/f87bc167/attachment-0001.pgp From report at bugs.python.org Sun Nov 25 04:17:08 2007 From: report at bugs.python.org (Mark Dickinson) Date: Sun, 25 Nov 2007 03:17:08 -0000 Subject: [issue1516613] Decimal should allow leading or trailing spaces. Message-ID: <1195960628.75.0.464180178981.issue1516613@psf.upfronthosting.co.za> Mark Dickinson added the comment: This is a feature request rather than a bug. There's a least one good reason not to do this, namely that the specification on which the decimal module is based specifically disallows this: At http://www2.hursley.ibm.com/decimal/daconvs.html it says: "No blanks or other white space characters are permitted in a numeric string.", and the "to-number" operation of the specification, which converts strings to Decimal instances, is expected only to accept numeric strings. Of course, all the specification requires is that the functionality of to- number is present in the Decimal module *somewhere*: currently it's implemented by Decimal.__new__, but it would be possible to alter Decimal.__new__ to allow leading and trailing spaces, and have a strictly conforming to-number implementation elsewhere in the Decimal module. I don't think there's any real benefit to this. It's easy enough to add a call to strip() to the Decimal argument. I recommend closing this issue as a "won't fix". ---------- nosy: +marketdickinson type: -> rfe _____________________________________ Tracker _____________________________________ From report at bugs.python.org Sun Nov 25 10:40:05 2007 From: report at bugs.python.org (Christian Heimes) Date: Sun, 25 Nov 2007 09:40:05 -0000 Subject: [issue1493] Patch to remove unbound methods Message-ID: <1195983605.83.0.813912130883.issue1493@psf.upfronthosting.co.za> Christian Heimes added the comment: Fixed in r59183 unittest was pretty tricky. ---------- resolution: -> fixed status: open -> closed __________________________________ Tracker __________________________________ From report at bugs.python.org Sun Nov 25 11:32:38 2007 From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=) Date: Sun, 25 Nov 2007 10:32:38 -0000 Subject: [issue1468] MSI installer does not include SSL test .pem files Message-ID: <1195986758.05.0.445341761774.issue1468@psf.upfronthosting.co.za> Martin v. L?wis added the comment: I verified the installer; this problem is now fixed. ---------- resolution: -> fixed status: open -> closed __________________________________ Tracker __________________________________ From report at bugs.python.org Sun Nov 25 12:09:12 2007 From: report at bugs.python.org (vila) Date: Sun, 25 Nov 2007 11:09:12 -0000 Subject: [issue1348] httplib closes socket, then tries to read from it Message-ID: <1195988952.87.0.798567054166.issue1348@psf.upfronthosting.co.za> vila added the comment: The title of this bug is scary. httplib rightly close the socket because that's the way to transfer the responsibility of the close to the user of the HttpResponse object. The close MUST stays there. I do encounter a bug related to that close while trying to use the ssl module in python2.6. I'm willing to help fixing it but *this* bug may not be the right place to do so (even if related). I'm a bit lost on how to help right now since the involved changes seems to occur in both python3.0 and python2.6 and I'm currently targeting 2.4 and 2.5. ---------- nosy: +vila __________________________________ Tracker __________________________________ From report at bugs.python.org Sun Nov 25 12:31:41 2007 From: report at bugs.python.org (Christian Heimes) Date: Sun, 25 Nov 2007 11:31:41 -0000 Subject: [issue1497] Patch to remove API to create new unbound methods Message-ID: <1195990301.82.0.071232495691.issue1497@psf.upfronthosting.co.za> Changes by Christian Heimes: ---------- components: Interpreter Core files: py3k_remove_newunbound.patch keywords: patch, py3k nosy: georg.brandl, tiran priority: high severity: normal status: open title: Patch to remove API to create new unbound methods versions: Python 3.0 Added file: http://bugs.python.org/file8805/py3k_remove_newunbound.patch __________________________________ Tracker __________________________________ From report at bugs.python.org Sun Nov 25 14:31:01 2007 From: report at bugs.python.org (Georg Brandl) Date: Sun, 25 Nov 2007 13:31:01 -0000 Subject: [issue1497] Patch to remove API to create new unbound methods Message-ID: <1195997461.2.0.11686782236.issue1497@psf.upfronthosting.co.za> New submission from Georg Brandl: Perhaps it would be good to move the rest of classobject.c into methodobject.c after that. ---------- assignee: -> gvanrossum nosy: +gvanrossum __________________________________ Tracker __________________________________ From report at bugs.python.org Sun Nov 25 15:55:15 2007 From: report at bugs.python.org (Thomas Herve) Date: Sun, 25 Nov 2007 14:55:15 -0000 Subject: [issue1269] Exception in pstats print_callers() Message-ID: <1196002515.8.0.463894119852.issue1269@psf.upfronthosting.co.za> Thomas Herve added the comment: Here's my patch against trunk, with one test. Please review! ---------- versions: +Python 2.6 Added file: http://bugs.python.org/file8806/1269.diff __________________________________ Tracker __________________________________ -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: 1269.diff Url: http://mail.python.org/pipermail/python-bugs-list/attachments/20071125/f6509a56/attachment.txt From report at bugs.python.org Sun Nov 25 16:29:09 2007 From: report at bugs.python.org (Thomas Herve) Date: Sun, 25 Nov 2007 15:29:09 -0000 Subject: [issue1117670] profiler: Bad return and Bad call errors with exceptions Message-ID: <1196004549.66.0.856254300341.issue1117670@psf.upfronthosting.co.za> Thomas Herve added the comment: Ping to close this? ---------- nosy: +therve _____________________________________ Tracker _____________________________________ From report at bugs.python.org Sun Nov 25 18:06:01 2007 From: report at bugs.python.org (Georg Brandl) Date: Sun, 25 Nov 2007 17:06:01 -0000 Subject: [issue1117670] profiler: Bad return and Bad call errors with exceptions Message-ID: <1196010361.78.0.766836900824.issue1117670@psf.upfronthosting.co.za> Georg Brandl added the comment: With pleasure. ---------- nosy: +georg.brandl resolution: -> fixed status: open -> closed _____________________________________ Tracker _____________________________________ From report at bugs.python.org Sun Nov 25 18:44:43 2007 From: report at bugs.python.org (=?utf-8?q?Gerhard_H=C3=A4ring?=) Date: Sun, 25 Nov 2007 17:44:43 -0000 Subject: [issue1734164] sqlite3 causes memory read error Message-ID: <1196012683.6.0.938075522594.issue1734164@psf.upfronthosting.co.za> Gerhard H?ring added the comment: Fixed in revision 59184. ---------- resolution: -> fixed status: open -> closed _____________________________________ Tracker _____________________________________ From report at bugs.python.org Sun Nov 25 21:21:10 2007 From: report at bugs.python.org (Christian Heimes) Date: Sun, 25 Nov 2007 20:21:10 -0000 Subject: [issue1412] test_subprocess fails on SuSE 10 Message-ID: <1196022070.2.0.84489703018.issue1412@psf.upfronthosting.co.za> Christian Heimes added the comment: I've fixed a bug in py3k and 2.6 where a test in test_shutil has removed an empty TMP directory. I regard the issue as a minor inconvenience. We can't work around every edge case. ---------- resolution: -> works for me status: open -> closed __________________________________ Tracker __________________________________ From report at bugs.python.org Sun Nov 25 23:52:36 2007 From: report at bugs.python.org (Skip Montanaro) Date: Sun, 25 Nov 2007 22:52:36 -0000 Subject: [issue1067] test_smtplib failures (caused by asyncore) Message-ID: <1196031156.81.0.0719055444459.issue1067@psf.upfronthosting.co.za> Changes by Skip Montanaro: ---------- nosy: +skip.montanaro __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Nov 26 00:49:37 2007 From: report at bugs.python.org (ita) Date: Sun, 25 Nov 2007 23:49:37 -0000 Subject: [issue1225584] crash in gcmodule.c on python reinitialization Message-ID: <1196034576.95.0.943716411725.issue1225584@psf.upfronthosting.co.za> ita added the comment: The following still crashes (python 2.5.1): for (int i=0; i<1000; ++i) { Py_Initialize(); PyRun_SimpleString("import tarfile\n"); Py_Finalize(); } Bindings such as Swig are adding weird hacks just for avoiding the finalize call and resetting the variables. Not being able to start from a clean interpreter is unacceptable. ---------- nosy: +ita _____________________________________ Tracker _____________________________________ From report at bugs.python.org Mon Nov 26 03:18:53 2007 From: report at bugs.python.org (Mark Dickinson) Date: Mon, 26 Nov 2007 02:18:53 -0000 Subject: [issue1381] cmath is numerically unsound Message-ID: <1196043533.82.0.898223530446.issue1381@psf.upfronthosting.co.za> Mark Dickinson added the comment: Here is (quite a large) patch, cmath.patch, that fixes a variety of problems in the current cmath module. A summary of the changes: * sqrt, log, acos, acosh, asin, asinh, atan, atanh no longer produce overflow errors for very large inputs * exp, cos, sin, tan, cosh, sinh, tanh produce valid answers in some cases where they incorrectly overflowed before. * sqrt and log are more accurate for tiny numbers * numeric problems in some functions (especially asinh and asin) should have been fixed * the branch cuts for asinh have been moved to the standard positions * the direction of continuity for the branch cuts of tan, tanh have been fixed * on systems with full hardware and system support for signed zeros (most modern systems), functions with a branch cut are continuous on both sides of the branch cut. (As recommended by the C99 standard, amongst others.) The patch includes documentation updates, but there are still no tests. (My current tests make heavy use of the MPFR library, and assume IEEE-754 format doubles, so need to be seriously reworked.) The tests are on my to- do list, but I'm unlikely to find time for them before the new year. In the meantime, I'd very much appreciate any feedback on this patch, if anyone has the time/energy/inclination to look at it. (Andreas: are you in a position to give this a test-run?) Added file: http://bugs.python.org/file8807/cmath.patch __________________________________ Tracker __________________________________ -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: cmath.patch Url: http://mail.python.org/pipermail/python-bugs-list/attachments/20071126/835bb498/attachment-0001.txt From report at bugs.python.org Mon Nov 26 03:57:34 2007 From: report at bugs.python.org (Guido van Rossum) Date: Mon, 26 Nov 2007 02:57:34 -0000 Subject: [issue1358] Compile error on OS X 10.5 Message-ID: <1196045854.8.0.133703821674.issue1358@psf.upfronthosting.co.za> Guido van Rossum added the comment: IMO it should be set to 10.4 since we want binaries that run on that platform too. Is this something we can fix in the configure script? __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Nov 26 05:16:17 2007 From: report at bugs.python.org (Guido van Rossum) Date: Mon, 26 Nov 2007 04:16:17 -0000 Subject: [issue765228] Subclassing from Modules Message-ID: <1196050577.32.0.264998587768.issue765228@psf.upfronthosting.co.za> Guido van Rossum added the comment: I don't see an issue to be fixed here; adding special tests in order to provide more detailed error messages is rarely a good idea. Also, PEP 8 has said for years now that modules should *not* be named the same as classes. Yes, there are a few such modules in the standard library. They're historical mistakes that will be fixed in 3.0. ---------- status: pending -> closed ____________________________________ Tracker ____________________________________ From report at bugs.python.org Mon Nov 26 05:22:08 2007 From: report at bugs.python.org (Guido van Rossum) Date: Mon, 26 Nov 2007 04:22:08 -0000 Subject: [issue1496] add str.maketrans() Message-ID: <1196050928.35.0.169795983271.issue1496@psf.upfronthosting.co.za> Guido van Rossum added the comment: Looks good from a functionality POV. I wonder if we couldn't change the dict though to always map ordinals to strings? Deletions can be mapped to "". We could warn about non-string values in the 2.6 version of this code, and make it a (lazy) error in 3.0. __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Nov 26 05:24:27 2007 From: report at bugs.python.org (Guido van Rossum) Date: Mon, 26 Nov 2007 04:24:27 -0000 Subject: [issue1493] Patch to remove unbound methods In-Reply-To: <1195933066.06.0.390510608395.issue1493@psf.upfronthosting.co.za> Message-ID: Guido van Rossum added the comment: On Nov 24, 2007 11:37 AM, Christian Heimes wrote: > Do you still believe in the tooth fairy, too? :p Yes, and in the Easter Bunny, Santa Claus, and Sinterklaas. But in this particular case I believe in Kaboutertjes. (Dutch gnomes.) And it turns out I was right. :-) __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Nov 26 18:05:05 2007 From: report at bugs.python.org (Christian Heimes) Date: Mon, 26 Nov 2007 17:05:05 -0000 Subject: [issue1497] Patch to remove API to create new unbound methods Message-ID: <1196096705.95.0.709237389698.issue1497@psf.upfronthosting.co.za> Christian Heimes added the comment: The new patch adds new.boundcfunction as a replacement for new.instancemethod(id, None, cls). I'm going to add docs if you like the approach. Added file: http://bugs.python.org/file8810/py3k_remove_newunbound2.patch __________________________________ Tracker __________________________________ -------------- next part -------------- A non-text attachment was scrubbed... Name: py3k_remove_newunbound2.patch Type: text/x-diff Size: 6871 bytes Desc: not available Url : http://mail.python.org/pipermail/python-bugs-list/attachments/20071126/f64e9f77/attachment.patch From report at bugs.python.org Mon Nov 26 18:20:48 2007 From: report at bugs.python.org (Adam Olsen) Date: Mon, 26 Nov 2007 17:20:48 -0000 Subject: [issue1225584] crash in gcmodule.c on python reinitialization Message-ID: <1196097648.11.0.0946187842546.issue1225584@psf.upfronthosting.co.za> Changes by Adam Olsen: ---------- nosy: +rhamphoryncus _____________________________________ Tracker _____________________________________ From report at bugs.python.org Mon Nov 26 18:50:43 2007 From: report at bugs.python.org (Guido van Rossum) Date: Mon, 26 Nov 2007 17:50:43 -0000 Subject: [issue1498] Rename __builtins__ to __root_namespace__? Message-ID: <1196099443.21.0.514185525416.issue1498@psf.upfronthosting.co.za> New submission from Guido van Rossum: In http://bugs.python.org/issue1774369 I mentioned that I wanted to rename __builtins__ to __rootns__. Though right now I think something longer and less cryptic might be better. The reason is to avoid for once and for all the confusion between __builtin__, which is a module, and __builtins__, a feature mainly used by sandboxing to pass the set of builtins to be used via the global namespace. This lay at the heart of the referenced bug. I'm still in favor of this but haven't had the time to investigate how much work it would be. ---------- messages: 57842 nosy: gvanrossum priority: normal severity: normal status: open title: Rename __builtins__ to __root_namespace__? versions: Python 3.0 __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Nov 26 19:21:30 2007 From: report at bugs.python.org (Christian Heimes) Date: Mon, 26 Nov 2007 18:21:30 -0000 Subject: [issue1498] Rename __builtins__ to __root_namespace__? Message-ID: <1196101290.46.0.803770440591.issue1498@psf.upfronthosting.co.za> Changes by Christian Heimes: ---------- keywords: +py3k nosy: +tiran __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Nov 26 19:30:07 2007 From: report at bugs.python.org (Christian Heimes) Date: Mon, 26 Nov 2007 18:30:07 -0000 Subject: [issue1498] Rename __builtins__ to __root_namespace__? Message-ID: <1196101807.83.0.480311096611.issue1498@psf.upfronthosting.co.za> Christian Heimes added the comment: A simple replace with sed -i works just fine. Afterwards the code needs only minor adjustments and cleanups. find -name \*.py -or -name \*.c -or -name \*.h | xargs sed -i 's/__builtins__/__root__/g' __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Nov 26 19:32:13 2007 From: report at bugs.python.org (Guido van Rossum) Date: Mon, 26 Nov 2007 18:32:13 -0000 Subject: [issue1498] Rename __builtins__ to __root_namespace__? In-Reply-To: <1196101807.83.0.480311096611.issue1498@psf.upfronthosting.co.za> Message-ID: Guido van Rossum added the comment: OK, then we need to agree on a new name. I find __root__ too short, __rootns__ too cryptic, and __root_namespace__ too long. :-) What else have we got? __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Nov 26 19:44:42 2007 From: report at bugs.python.org (Christian Heimes) Date: Mon, 26 Nov 2007 18:44:42 -0000 Subject: [issue1498] Rename __builtins__ to __root_namespace__? Message-ID: <1196102682.47.0.90986405468.issue1498@psf.upfronthosting.co.za> Christian Heimes added the comment: __origin__ __footing__ __radix__ __namespace__ __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Nov 26 19:49:10 2007 From: report at bugs.python.org (Georg Brandl) Date: Mon, 26 Nov 2007 18:49:10 -0000 Subject: [issue1497] Patch to remove API to create new unbound methods Message-ID: <1196102950.32.0.759292297812.issue1497@psf.upfronthosting.co.za> Georg Brandl added the comment: Note though that the "new" module was deprecated once... __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Nov 26 20:04:02 2007 From: report at bugs.python.org (Guido van Rossum) Date: Mon, 26 Nov 2007 19:04:02 -0000 Subject: [issue1497] Patch to remove API to create new unbound methods Message-ID: <1196103842.79.0.269157789666.issue1497@psf.upfronthosting.co.za> Guido van Rossum added the comment: OK. Some code review comments: - Please clean up the comment in classobject.c starting with "Method objects are used for one purposes:" -- to begin with, "one purposes" is ungrammatical. Best to remove the (a) bullet and rephrase the whole thing more like "Method objects are used for bound instance methods (...)" - The error "unbound methods are not supported" sounds a bit strange; better rephrase more positive as "self must not be None" - There is still a comment left "No, it is an unbound method". Is this code still reachable? I though all ways to set im_self to NULL/None are blocked? - Is bug 1202533 still worth testing for in test_descr.py? I don't know that using a lambda reproduces the error condition that once existed. Functional suggestions: - Do we really need im_class for anything any more? ISTM that the one place where it is still used (in method_repr), we could as well use the class of im_self. (And before you think of super() as a counter-argument: super() passes the object's class in rather than the class where the method is found (though this may be considered a bug). - I think that, like func_code -> __code__, the im_xxx attributes should be renamed __xxx__. The 'new' module claims to exist solely for backwards compatibility. If that's true, why are we adding to it? In any case, the _BoundCFunction() class is redundant -- you can just use the "method" type, which is easily accessed as any bound method's __class__ attribute. And is there a use case for an *unbound* C function? If not, you could replace boundcfunction() with just a call to the method type. __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Nov 26 20:04:51 2007 From: report at bugs.python.org (Guido van Rossum) Date: Mon, 26 Nov 2007 19:04:51 -0000 Subject: [issue1498] Rename __builtins__ to __root_namespace__? In-Reply-To: <1196102682.47.0.90986405468.issue1498@psf.upfronthosting.co.za> Message-ID: Guido van Rossum added the comment: Time for a quick poll on the list. __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Nov 26 20:08:40 2007 From: report at bugs.python.org (Guido van Rossum) Date: Mon, 26 Nov 2007 19:08:40 -0000 Subject: [issue1496] add str.maketrans() Message-ID: <1196104120.92.0.363269978623.issue1496@psf.upfronthosting.co.za> Guido van Rossum added the comment: BTW I'm okay with submitting this as is (plus docs and tests) and tighten the spec later. ---------- assignee: gvanrossum -> georg.brandl keywords: +patch, py3k __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Nov 26 20:23:00 2007 From: report at bugs.python.org (Achim Gaedke) Date: Mon, 26 Nov 2007 19:23:00 -0000 Subject: [issue1499] failure behaviour of compile() is missing Message-ID: <1196104980.32.0.085401481115.issue1499@psf.upfronthosting.co.za> New submission from Achim Gaedke: Regarding the compile() function in html/lib/built-in-funcs.html: Please add a note about the exceptions raised by this function. ---------- components: Documentation messages: 57850 nosy: AchimGaedke severity: minor status: open title: failure behaviour of compile() is missing versions: Python 2.4, Python 2.5 __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Nov 26 20:42:59 2007 From: report at bugs.python.org (Bill Janssen) Date: Mon, 26 Nov 2007 19:42:59 -0000 Subject: [issue1348] httplib closes socket, then tries to read from it In-Reply-To: <1195988952.87.0.798567054166.issue1348@psf.upfronthosting.co.za> Message-ID: <4b3e516a0711261142y315ffe5bv31aeb33a4bf00bbd@mail.gmail.com> Bill Janssen added the comment: No, the close must be removed. It's the wrong *way* to "transfer responsibility". Close means "close", not "I wash my hands of responsibility here". What's hidden here is that the open socket is transferred to the response, which continues to use it. In fact, the close() should happen when the caller is finished with the response, probably as effect of the GC of the "response" object. On Nov 25, 2007 3:09 AM, vila wrote: > > vila added the comment: > > The title of this bug is scary. > > httplib rightly close the socket because that's the way to transfer the > responsibility of the close to the user of the HttpResponse object. > > The close MUST stays there. > > I do encounter a bug related to that close while trying to use the ssl > module in python2.6. > > I'm willing to help fixing it but *this* bug may not be the right place > to do so (even if related). > > I'm a bit lost on how to help right now since the involved changes seems > to occur in both python3.0 and python2.6 and I'm currently targeting 2.4 > and 2.5. > > ---------- > nosy: +vila > > __________________________________ > Tracker > > __________________________________ > __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Nov 26 21:51:30 2007 From: report at bugs.python.org (Steve Jones) Date: Mon, 26 Nov 2007 20:51:30 -0000 Subject: [issue1500] Example using range doesn't give claimed results Message-ID: <1196110290.45.0.0321063926451.issue1500@psf.upfronthosting.co.za> New submission from Steve Jones: See for yourself, on http://docs.python.org/tut/node6.html ************************************* >>> for n in range(2, 10): ... for x in range(2, n): ... if n % x == 0: ... print n, 'equals', x, '*', n/x ... break ... else: ... # loop fell through without finding a factor ... print n, 'is a prime number' ... 2 is a prime number ----- this bit is wrong 3 is a prime number 4 equals 2 * 2 5 is a prime number 6 equals 2 * 3 7 is a prime number 8 equals 2 * 4 9 equals 3 * 3 ---------- components: Documentation messages: 57852 nosy: basingwerk severity: minor status: open title: Example using range doesn't give claimed results type: behavior versions: Python 3.0 __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Nov 26 22:11:27 2007 From: report at bugs.python.org (Guido van Rossum) Date: Mon, 26 Nov 2007 21:11:27 -0000 Subject: [issue1348] httplib closes socket, then tries to read from it Message-ID: <1196111487.18.0.820544504517.issue1348@psf.upfronthosting.co.za> Guido van Rossum added the comment: Bill, is there a code example that should work but breaks because of that close()? ATM, there doesn't seem to be anything in the tests that breaks... __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Nov 26 22:14:16 2007 From: report at bugs.python.org (Guido van Rossum) Date: Mon, 26 Nov 2007 21:14:16 -0000 Subject: [issue1500] Example using range doesn't give claimed results Message-ID: <1196111656.25.0.211891540575.issue1500@psf.upfronthosting.co.za> Guido van Rossum added the comment: 2 *is* a prime number. ---------- nosy: +gvanrossum resolution: -> invalid status: open -> closed __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Nov 26 22:19:32 2007 From: report at bugs.python.org (Jim Jewett) Date: Mon, 26 Nov 2007 21:19:32 -0000 Subject: [issue1501] 0 ** 0 documentation Message-ID: <1196111972.15.0.594136146103.issue1501@psf.upfronthosting.co.za> New submission from Jim Jewett: http://docs.python.org/lib/typesnumeric.html contains a table listing the mathematical operators. Please add a note to the final row (x ** y meaning x to the power y) indicating that Python has chosen to define 0**0==1 Note 6: Python defines 0**0 to be 1. For background, please see http:// en.wikipedia.org/wiki/Exponentiation#Zero_to_the_zero_power This doc change should have prevented issue 1461; I *think* there have been similar issues in the past. ---------- components: Documentation messages: 57855 nosy: jimjjewett severity: minor status: open title: 0 ** 0 documentation type: rfe versions: Python 2.5 __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Nov 26 23:03:10 2007 From: report at bugs.python.org (Guido van Rossum) Date: Mon, 26 Nov 2007 22:03:10 -0000 Subject: [issue1402] Interpreter cleanup: order of _PyGILState_Fini and PyInterpreterState_Clear Message-ID: <1196114590.63.0.166339536117.issue1402@psf.upfronthosting.co.za> Guido van Rossum added the comment: So is this a Mac-only issue? And couldn't the GIL state cleanup also invoke user code, which might be abused to create more threads, wreaking havoc that way? I'm kind of worried about putting this into 2.5.2 and breaking somebody's working code (that's always worse than fixing somebody's broken code... :-). __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Nov 26 23:05:07 2007 From: report at bugs.python.org (Guido van Rossum) Date: Mon, 26 Nov 2007 22:05:07 -0000 Subject: [issue1501] 0 ** 0 documentation Message-ID: <1196114707.83.0.554376440085.issue1501@psf.upfronthosting.co.za> Guido van Rossum added the comment: (Can you also submit a doc fix that would have prevented issue 1500? :-) ---------- nosy: +gvanrossum priority: -> low __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Nov 26 23:08:16 2007 From: report at bugs.python.org (Guido van Rossum) Date: Mon, 26 Nov 2007 22:08:16 -0000 Subject: [issue1492] BaseHTTPServer hard-codes Content-Type for error messages Message-ID: <1196114896.25.0.735605640123.issue1492@psf.upfronthosting.co.za> Guido van Rossum added the comment: I'm okay with adding this to 2.6 (and hence 3.0) but not with doing this to 2.5. ---------- nosy: +gvanrossum priority: -> low resolution: -> accepted versions: -Python 2.4, Python 2.5, Python 3.0 __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Nov 26 23:14:39 2007 From: report at bugs.python.org (Guido van Rossum) Date: Mon, 26 Nov 2007 22:14:39 -0000 Subject: [issue1491] BaseHTTPServer incorrectly implements response code 100 Message-ID: <1196115279.77.0.135631839505.issue1491@psf.upfronthosting.co.za> Guido van Rossum added the comment: I'm not sure I understand why anyone would ever want to send a 100 response anyway. If I were to add support for this, I'd probably refactor send_response() so that there's a lower-level function send_response_only() that *only* sends the response header and change send_response() to call that followed by sending the headers. I'm not sure where the request logging code should go but I suspect it should be in send_response(), not in send_response_only(). Speaking of send_response(), I wonder if it is correct to send the Server: and Date: headers when the request version is HTTP/0.9? I don't think we should add the paranoid version to the code; in general this code is not sufficiently aware of all the quirks of HTTP to prevent nonsensical things from happening. ---------- nosy: +gvanrossum priority: -> low versions: -Python 2.4, Python 2.5, Python 3.0 __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Nov 27 00:13:53 2007 From: report at bugs.python.org (Guido van Rossum) Date: Mon, 26 Nov 2007 23:13:53 -0000 Subject: [issue718532] inspect, class instances and __getattr__ Message-ID: <1196118833.22.0.610923899691.issue718532@psf.upfronthosting.co.za> Guido van Rossum added the comment: Obviously Ping isn't listening, so waiting for him is not productive. Looking at the issue more, I can't really see a bug in inspect -- it's the class definitions that are broken. So closing as "rejected". > Due to this bug, 'pydoc modulename' is not working. Can you be more specific? I can't reproduce this. > And this case is also not working (same issue): > > class X: > __bases__ = () > > x = X() Again, this is just a malformed class. ---------- assignee: ping -> priority: high -> normal resolution: -> rejected status: open -> closed versions: -Python 2.4, Python 2.6, Python 3.0 ____________________________________ Tracker ____________________________________ From report at bugs.python.org Tue Nov 27 00:42:24 2007 From: report at bugs.python.org (Chris Mellon) Date: Mon, 26 Nov 2007 23:42:24 -0000 Subject: [issue1502] itertools should grow chunkify Message-ID: <1196120544.69.0.372337623499.issue1502@psf.upfronthosting.co.za> New submission from Chris Mellon: One of the most common requests in c.l.p and #python is a way to break an iterable up into some particular size chunks. For example, "abcdef" -> "ab", "cd", "ef". It's pretty easy to write one, but there are a few subtleties to it (like if you want padding or partial results) and it's so common that having it in the stdlib would be nice. Attached is a patch which implements itertools.chunkify. It can optionally discard, pad, or return any leftovers in the source iterable. Tests and docstrings are included, but it needs to be documented in the manual. One thing it does not do, but maybe it should, is guess what type the yielded values should have based on the input sequence - it always returns lists. Patch is against trunk, r59186. ---------- components: Library (Lib) files: chunkify.patch messages: 57861 nosy: arkanes severity: normal status: open title: itertools should grow chunkify type: behavior versions: Python 2.6 Added file: http://bugs.python.org/file8811/chunkify.patch __________________________________ Tracker __________________________________ -------------- next part -------------- A non-text attachment was scrubbed... Name: chunkify.patch Type: application/octet-stream Size: 8257 bytes Desc: not available Url : http://mail.python.org/pipermail/python-bugs-list/attachments/20071126/c50f5f4a/attachment.obj From report at bugs.python.org Tue Nov 27 01:22:29 2007 From: report at bugs.python.org (Raymond Hettinger) Date: Tue, 27 Nov 2007 00:22:29 -0000 Subject: [issue1502] itertools should grow chunkify Message-ID: <1196122949.74.0.355598419401.issue1502@psf.upfronthosting.co.za> Raymond Hettinger added the comment: Sorry, this has been proposed and rejected previously. One of the reasons was that the docs already have a C-speed recipe, grouper(), that shows how to do it with padding and it is even simpler to do it without padding using only zip() or izip(). Another was a lack of compelling use cases. It was more fun to write and discuss than actually use in real code. Also, I'm not happy with the given implementation. The name is weak and the "partial" argument complexifies the function (its often better to have separate function than two combine two behaviors with a flag variable). Even if cleaned-up and a use case or two is demonstrated, am not willing to clutter the module with more functions like this. That being said, I do want to compliment the submission of a working patch with unittests. Nice work. ---------- assignee: -> rhettinger nosy: +rhettinger resolution: -> rejected status: open -> closed __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Nov 27 01:30:39 2007 From: report at bugs.python.org (Raymond Hettinger) Date: Tue, 27 Nov 2007 00:30:39 -0000 Subject: [issue1498] Rename __builtins__ to __root_namespace__? Message-ID: <1196123439.53.0.84847225873.issue1498@psf.upfronthosting.co.za> Raymond Hettinger added the comment: FWIW, I find __root__ to be just right. It is not subject misspelling. It is distinct enough to serve as a mental link to a specific concept. The leading and trailing underscores cause just enough typing pain that I wouldn't want anything longer. ---------- nosy: +rhettinger __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Nov 27 02:23:19 2007 From: report at bugs.python.org (Guido van Rossum) Date: Tue, 27 Nov 2007 01:23:19 -0000 Subject: [issue1503] test_xmlrpc is still flakey Message-ID: <1196126599.89.0.0637627606597.issue1503@psf.upfronthosting.co.za> New submission from Guido van Rossum: See e.g.: http://www.python.org/dev/buildbot/3.0/ppc%20Debian%20unstable%203.0/builds/303/step-test/0 Note how it fails the first time and passes on the re-run. I've seen this before (just not on any of my own systems). I've also seen it fail twice (on buildbot machines). ---------- messages: 57864 nosy: gvanrossum priority: normal severity: normal status: open title: test_xmlrpc is still flakey versions: Python 3.0 __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Nov 27 06:38:44 2007 From: report at bugs.python.org (Ronald Oussoren) Date: Tue, 27 Nov 2007 05:38:44 -0000 Subject: [issue1402] Interpreter cleanup: order of _PyGILState_Fini and PyInterpreterState_Clear Message-ID: <1196141924.44.0.277011101078.issue1402@psf.upfronthosting.co.za> Ronald Oussoren added the comment: This is not a mac-specific issue, the script happens to be mac-specific because that's how I found the issue. Amaury's patch adds a unittest that reproduces the problem in a platform-indepenent way using ctypes. The _PyGILState_Fini function might cause user code to run as well, it removes the thread-local variable that contains the PyThreadState for threads, and that contains some Python objects that might contain arbitrary values (such as the last exception value). I guess that means that a variation on Amaury's patch would cause a patched interpreter to crash (create on instance of 'C' as an attribute on an exception, e.g. raise ValueError(C()) in the second thread). BTW. I would be very uncomfortable if my patch were applied without review from someone that knows his way around the threading code. BTW2. I have a workaround for my initial issue (the crash in threads.py): if I add an atexit handler that performs some cleanup in PyObjC the problem goes away. __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Nov 27 09:20:27 2007 From: report at bugs.python.org (Amaury Forgeot d'Arc) Date: Tue, 27 Nov 2007 08:20:27 -0000 Subject: [issue1402] Interpreter cleanup: order of _PyGILState_Fini and PyInterpreterState_Clear Message-ID: <1196151627.19.0.803306755318.issue1402@psf.upfronthosting.co.za> Amaury Forgeot d'Arc added the comment: > The _PyGILState_Fini function might cause user code to run as well, > it removes the thread-local variable that contains the PyThreadState > for threads, and that contains some Python objects that might contain > arbitrary values (such as the last exception value). No, _PyGILState_Fini does not invoke any python code; it only clears C variables. The last exception value is deleted during the call to PyInterpreterState_Clear() (inside PyThreadState_Clear). __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Nov 27 10:49:21 2007 From: report at bugs.python.org (synx) Date: Tue, 27 Nov 2007 09:49:21 -0000 Subject: [issue756982] mailbox should use email not rfc822 Message-ID: <1196156961.77.0.715915253685.issue756982@psf.upfronthosting.co.za> synx added the comment: I dunno if this is helpful, but in the 2.5 module, it parses mailboxes into rfc822 messages, but then expects them to be email.Message messages when unparsing them back to a mailbox. mbox2.add(mbox1.popitem()[1]) fails with rfc822 as the default factory. Since the "factory" is the only thing still using rfc822, it's easy to remove the use of rfc822 from this module entirely, which also eliminates the parsing/unparsing disconnect. ---------- nosy: +synx Added file: http://bugs.python.org/file8812/mailbox.py.patch ____________________________________ Tracker ____________________________________ -------------- next part -------------- A non-text attachment was scrubbed... Name: mailbox.py.patch Type: text/x-patch Size: 1364 bytes Desc: not available Url : http://mail.python.org/pipermail/python-bugs-list/attachments/20071127/46824235/attachment.bin From report at bugs.python.org Tue Nov 27 11:37:06 2007 From: report at bugs.python.org (Christian Heimes) Date: Tue, 27 Nov 2007 10:37:06 -0000 Subject: [issue1497] Patch to remove API to create new unbound methods In-Reply-To: <1196103842.79.0.269157789666.issue1497@psf.upfronthosting.co.za> Message-ID: <474BF344.9060601@cheimes.de> Christian Heimes added the comment: Guido van Rossum wrote: > - Please clean up the comment in classobject.c starting with "Method > objects are used for one purposes:" -- to begin with, "one purposes" is > ungrammatical. Best to remove the (a) bullet and rephrase the whole > thing more like "Method objects are used for bound instance methods (...)" Done > - The error "unbound methods are not supported" sounds a bit strange; > better rephrase more positive as "self must not be None" Done. Didn't I say that I'm not good with short, precise error messages? :) > - There is still a comment left "No, it is an unbound method". Is this > code still reachable? I though all ways to set im_self to NULL/None are > blocked? It's not longer reachable but I left it there to catch problems. It's gone now. > > - Is bug 1202533 still worth testing for in test_descr.py? I don't know > that using a lambda reproduces the error condition that once existed. Removed > - Do we really need im_class for anything any more? ISTM that the one > place where it is still used (in method_repr), we could as well use the > class of im_self. (And before you think of super() as a > counter-argument: super() passes the object's class in rather than the > class where the method is found (though this may be considered a bug). You are right. im_class can be substituted with __self__.__class__. I've also removed the class argument from PyMethod_New(). It's not required anymore. > - I think that, like func_code -> __code__, the im_xxx attributes should > be renamed __xxx__. Done im_func -> __func__ im_self -> __self__ im_class -> removed I've left the names in the struct untouched. > The 'new' module claims to exist solely for backwards compatibility. If > that's true, why are we adding to it? In any case, the > _BoundCFunction() class is redundant -- you can just use the "method" > type, which is easily accessed as any bound method's __class__ > attribute. And is there a use case for an *unbound* C function? If not, > you could replace boundcfunction() with just a call to the method type. How could a bind a builtin method to a class so that instance().builtin() gets self as first argument? In one unit test the builtin function id() is bound to a class: class Example: id = somemagic(id) Example().id() results in id(Example()) I can't get the same effect with MethodType because it binds only to instances, not to classes. Christian __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Nov 27 11:42:38 2007 From: report at bugs.python.org (Christian Heimes) Date: Tue, 27 Nov 2007 10:42:38 -0000 Subject: [issue1497] Patch to remove API to create new unbound methods Message-ID: <1196160158.4.0.159841482216.issue1497@psf.upfronthosting.co.za> Christian Heimes added the comment: I've committed the changes in r59189. The documentation still needs updates. I had only time to fix some of the docs. ---------- resolution: -> fixed status: open -> pending __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Nov 27 12:18:41 2007 From: report at bugs.python.org (Christian Heimes) Date: Tue, 27 Nov 2007 11:18:41 -0000 Subject: [issue1504] Add 2to3 fixer for (un)bound methods Message-ID: <1196162321.58.0.597340041678.issue1504@psf.upfronthosting.co.za> New submission from Christian Heimes: Todo: im_self -> __self__ im_func -> __func__ im_class -> __self__.__class__ instancemethod(func, self, cls) -> instancemethod(func, self) ---------- assignee: collinwinter components: 2to3 (2.x to 3.0 conversion tool) keywords: py3k messages: 57870 nosy: collinwinter, tiran severity: normal status: open title: Add 2to3 fixer for (un)bound methods versions: Python 3.0 __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Nov 27 14:02:37 2007 From: report at bugs.python.org (Christian Heimes) Date: Tue, 27 Nov 2007 13:02:37 -0000 Subject: [issue1505] Changes to PyMethod_New breaks ctypes on Windows Message-ID: <1196168557.19.0.782884662226.issue1505@psf.upfronthosting.co.za> New submission from Christian Heimes: The problem is in _ctypes.c:create_comerror() around line 4620. ---------- assignee: theller components: Extension Modules, Windows keywords: py3k messages: 57871 nosy: theller, tiran priority: high severity: normal status: open title: Changes to PyMethod_New breaks ctypes on Windows versions: Python 3.0 __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Nov 27 15:21:58 2007 From: report at bugs.python.org (vila) Date: Tue, 27 Nov 2007 14:21:58 -0000 Subject: [issue1348] httplib closes socket, then tries to read from it Message-ID: <1196173318.73.0.236618351417.issue1348@psf.upfronthosting.co.za> vila added the comment: Well I was confused. In fact, I have a working http/1.1 client which indeed works around that close. HTTPConnection.close() must be called once the response has been processed or the next request can't be handled since HTTPConnection.__state is not _CS_IDLE. That may be a different problem than the one Bill is after though. I work around it by saving the sock attribute before the call in a class inherited from HTTPConnection: # Preserve our preciousss sock = self.sock self.sock = None # Let httplib.HTTPConnection do its housekeeping self.close() # Restore our preciousss self.sock = sock So not doing the close() is harmless but doing self.sock = None in HTTPConnection.close() still break hopes of persistent connections. May be that method should be splitted... __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Nov 27 15:43:42 2007 From: report at bugs.python.org (Christian Heimes) Date: Tue, 27 Nov 2007 14:43:42 -0000 Subject: [issue1455] VS2008, quick hack for distutils.msvccompiler Message-ID: <1196174622.87.0.702401879535.issue1455@psf.upfronthosting.co.za> Christian Heimes added the comment: I've created another patch to add VS 2008 support to distutils. The new patch requires you to copy the msvccompiler.py first: $ cd Lib/distutils $ svn copy msvccompiler.py msvc9compiler.py $ cd ../.. $ patch -p0 < py3k_vs2008_4.patch Martin, if you are going to build Python 3.0a2 with VS 2008 then this patch should be applied. I've tested it with VS 2008 and it *may* be compatible with VS 2005, too. ---------- priority: normal -> high Added file: http://bugs.python.org/file8813/py3k_vs2008_4.patch __________________________________ Tracker __________________________________ -------------- next part -------------- A non-text attachment was scrubbed... Name: py3k_vs2008_4.patch Type: text/x-diff Size: 19578 bytes Desc: not available Url : http://mail.python.org/pipermail/python-bugs-list/attachments/20071127/4187b874/attachment-0001.patch From report at bugs.python.org Tue Nov 27 18:33:05 2007 From: report at bugs.python.org (Raymond Hettinger) Date: Tue, 27 Nov 2007 17:33:05 -0000 Subject: [issue1746088] long.__str__ is quadratic time Message-ID: <1196184785.7.0.466385809461.issue1746088@psf.upfronthosting.co.za> Changes by Raymond Hettinger: ---------- assignee: -> rhettinger nosy: +rhettinger versions: +Python 2.6 -Python 2.5 _____________________________________ Tracker _____________________________________ From report at bugs.python.org Tue Nov 27 18:37:18 2007 From: report at bugs.python.org (Raymond Hettinger) Date: Tue, 27 Nov 2007 17:37:18 -0000 Subject: [issue1045] Performance regression in 2.5 Message-ID: <1196185038.25.0.342114928872.issue1045@psf.upfronthosting.co.za> Changes by Raymond Hettinger: ---------- assignee: tim_one -> rhettinger nosy: +rhettinger __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Nov 27 19:02:43 2007 From: report at bugs.python.org (Guido van Rossum) Date: Tue, 27 Nov 2007 18:02:43 -0000 Subject: [issue1504] Add 2to3 fixer for (un)bound methods Message-ID: <1196186563.45.0.854078642248.issue1504@psf.upfronthosting.co.za> Guido van Rossum added the comment: Crys, why don't you give it a try yourself? It's quite easy to write such a simple substitution. ---------- nosy: +gvanrossum __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Nov 27 19:04:18 2007 From: report at bugs.python.org (Amaury Forgeot d'Arc) Date: Tue, 27 Nov 2007 18:04:18 -0000 Subject: [issue1045] Performance regression in 2.5 Message-ID: <1196186657.6.0.698765727839.issue1045@psf.upfronthosting.co.za> Amaury Forgeot d'Arc added the comment: The slowdown is due to the new function _PyObject_LengthHint: on my Win2K machine, the command python -m timeit "tuple(1 for _ in xrange(3))" answers: 100000 loops, best of 3: 4.14 usec per loop By adding a line "return rv;" on the second line of _PyObject_LengthHint, I get: 100000 loops, best of 3: 2.71 usec per loop Should we disable this function for some known built-in types? ---------- nosy: +amaury.forgeotdarc __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Nov 27 19:12:26 2007 From: report at bugs.python.org (Raymond Hettinger) Date: Tue, 27 Nov 2007 18:12:26 -0000 Subject: [issue1045] Performance regression in 2.5 Message-ID: <1196187146.36.0.16880878568.issue1045@psf.upfronthosting.co.za> Raymond Hettinger added the comment: I'll take a look at it next week -- want to think through the various cases. The current setup provides nice speedups when the length_hint is available. Possibly, it may be worthwhile to skip that check when the input is a generator. For the most part, I'm more concerned about the inner-loop time than the constant startup time outside the loop. __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Nov 27 19:39:41 2007 From: report at bugs.python.org (Guido van Rossum) Date: Tue, 27 Nov 2007 18:39:41 -0000 Subject: [issue1402] Interpreter cleanup: order of _PyGILState_Fini and PyInterpreterState_Clear Message-ID: <1196188781.59.0.520499001391.issue1402@psf.upfronthosting.co.za> Guido van Rossum added the comment: > No, _PyGILState_Fini does not invoke any python code You're right. It calls PyThread_delete_key(). I thought this would delete entries from a dictionary (thereby potentially invoking Python code via Py_DECREF()), but it doesn't -- it just frees some memory. So I'm okay with swapping the order in 2.6 and 3.0. I'm still not 100% comfortable with doing this in 2.5, especially since Ronald found a work-around for his immediate issue. __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Nov 27 19:41:58 2007 From: report at bugs.python.org (Raymond Hettinger) Date: Tue, 27 Nov 2007 18:41:58 -0000 Subject: [issue1045] Performance regression in 2.5 Message-ID: <1196188918.5.0.0303547731685.issue1045@psf.upfronthosting.co.za> Raymond Hettinger added the comment: FWIW, the 2.4 to 2.5 timing difference came from renaming __len__ to __length_hint__. This was at Guido's request so that the value of bool (iter(obj)) would always be True. The consequence of the change was that we lost the fast slot lookup for __len__ and instead have to do a dictionary based attribute lookup. For the most part, I don't care about the overhead as it is constant. The inner-loop cost dominates. If you do care, the choices are to add some ugly, hackish specific type checks to bypass the attribute lookup in cases like generator objects where we know the type is absent. A more general, cleaner solution is to add a new slot for a length hint. Personally, I would rather leave this as is and live with the small constant lookup time. If you concur, please close this report. If not, please submit a patch for adding a new slot (model the code after that in PyObject_Size()). __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Nov 27 19:50:42 2007 From: report at bugs.python.org (Facundo Batista) Date: Tue, 27 Nov 2007 18:50:42 -0000 Subject: [issue1755179] Deadlocks with fork() and multithreading Message-ID: <1196189442.61.0.0998813889436.issue1755179@psf.upfronthosting.co.za> Facundo Batista added the comment: Fixed in the trunk, rev 59195. _____________________________________ Tracker _____________________________________ From report at bugs.python.org Tue Nov 27 20:15:48 2007 From: report at bugs.python.org (Christian Heimes) Date: Tue, 27 Nov 2007 19:15:48 -0000 Subject: [issue1504] Add 2to3 fixer for (un)bound methods Message-ID: <1196190948.47.0.405056742666.issue1504@psf.upfronthosting.co.za> Christian Heimes added the comment: Added fix_methodattrs with an unit test in r59196. Can you check it please. By the way how do you know my IRC nick? Are you lurking in #python? :) __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Nov 27 20:16:43 2007 From: report at bugs.python.org (Thomas Heller) Date: Tue, 27 Nov 2007 19:16:43 -0000 Subject: [issue1505] Changes to PyMethod_New breaks ctypes on Windows In-Reply-To: <1196168557.19.0.782884662226.issue1505@psf.upfronthosting.co.za> Message-ID: <474C6D14.5010604@ctypes.org> Thomas Heller added the comment: Christian Heimes schrieb: > > New submission from Christian Heimes: > > > > The problem is in _ctypes.c:create_comerror() around line 4620. The code tries to populate a dict with methods and finally pass them to PyErr_NewException("_ctypes.COMError", NULL, dict); I have no idea what to do. What do I have to put into the dict? __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Nov 27 21:15:11 2007 From: report at bugs.python.org (Guido van Rossum) Date: Tue, 27 Nov 2007 20:15:11 -0000 Subject: [issue1504] Add 2to3 fixer for (un)bound methods Message-ID: <1196194511.32.0.659511738913.issue1504@psf.upfronthosting.co.za> Guido van Rossum added the comment: It works, though the "__self__.__class__" substitution is technically wrong -- it creates a single NAME node whose contents is that string, while in the parse tree it should really be three tokens. But as it works, I wouldn't worry about it. I saw you sign a bug with 'Crys' once and I believe you mentioned it in your intro to python-dev. :-) ---------- resolution: -> accepted status: open -> closed __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Nov 27 21:19:14 2007 From: report at bugs.python.org (Bill Janssen) Date: Tue, 27 Nov 2007 20:19:14 -0000 Subject: [issue1348] httplib closes socket, then tries to read from it In-Reply-To: <1196111487.18.0.820544504517.issue1348@psf.upfronthosting.co.za> Message-ID: <4b3e516a0711271219h30af29c8v463a1d3285363b92@mail.gmail.com> Bill Janssen added the comment: That's because the socket.py code has been adapted (the first word I wrote there was "perverted" :--) to deal with this case. That is, the close() has been rendered meaningless because of the explicit reference counting in socket.py. But the right solution is to not close the socket till the application is done with it; that is, transfer the responsibility for the socket to the part of the application which is still using it. I'm not sure that just fixing this one case will remove the need for the explicit reference counting in socket.py, but this is the case that I noticed. On Nov 26, 2007 1:11 PM, Guido van Rossum wrote: > > Guido van Rossum added the comment: > > Bill, is there a code example that should work but breaks because of > that close()? ATM, there doesn't seem to be anything in the tests that > breaks... > > __________________________________ > Tracker > > __________________________________ > Added file: http://bugs.python.org/file8814/unnamed __________________________________ Tracker __________________________________ -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: unnamed Url: http://mail.python.org/pipermail/python-bugs-list/attachments/20071127/87897d54/attachment-0001.txt From report at bugs.python.org Tue Nov 27 21:27:48 2007 From: report at bugs.python.org (Christian Heimes) Date: Tue, 27 Nov 2007 20:27:48 -0000 Subject: [issue1504] Add 2to3 fixer for (un)bound methods Message-ID: <1196195268.65.0.826713861531.issue1504@psf.upfronthosting.co.za> Christian Heimes added the comment: You are too fast. I haven't written a fixer for new.instancemethod yet. Do we need one? ---------- status: closed -> open __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Nov 27 21:36:55 2007 From: report at bugs.python.org (Guido van Rossum) Date: Tue, 27 Nov 2007 20:36:55 -0000 Subject: [issue1504] Add 2to3 fixer for (un)bound methods Message-ID: <1196195815.37.0.598022369659.issue1504@psf.upfronthosting.co.za> Guido van Rossum added the comment: A fixer for new.instancemethod would be nice, though I doubt that there will be many uses. We could also go a different way: since new.py has a comment stating it is deprecated (in 2.5 already), perhaps we should just kill in in 3.0 and add an explicit 3.0 warning to it in 2.6. (This is really part of the library reorg, but we might as well take care of it now rather than making a temporary change to it.) __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Nov 27 22:14:25 2007 From: report at bugs.python.org (Christian Heimes) Date: Tue, 27 Nov 2007 21:14:25 -0000 Subject: [issue1504] Add 2to3 fixer for (un)bound methods Message-ID: <1196198065.76.0.0313275688014.issue1504@psf.upfronthosting.co.za> Christian Heimes added the comment: How should I issue a warning in the new module? Should and can I check for the -3 warning option or should I warn w/o checks for the -3 option? from warnings import warn as _warn _warn("The 'new' module is not supported in 3.x", DeprecationWarning, 2) __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Nov 27 22:15:14 2007 From: report at bugs.python.org (Maarten Thibaut) Date: Tue, 27 Nov 2007 21:15:14 -0000 Subject: [issue1506] func alloca inside ctypes lib needs #include on solaris Message-ID: <1196198113.99.0.416874193784.issue1506@psf.upfronthosting.co.za> Changes by Maarten Thibaut: ---------- components: Library (Lib) nosy: mthibaut severity: normal status: open title: func alloca inside ctypes lib needs #include on solaris type: compile error versions: Python 2.5 __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Nov 27 22:19:39 2007 From: report at bugs.python.org (Maarten Thibaut) Date: Tue, 27 Nov 2007 21:19:39 -0000 Subject: [issue1506] func alloca inside ctypes lib needs #include on solaris Message-ID: <1196198379.38.0.240170599355.issue1506@psf.upfronthosting.co.za> New submission from Maarten Thibaut: On Solaris, alloca() is a #define which is inside . Ctypes fails to compile because the #define is missing. Please fix by adding the following at the front of these 2 files: #if defined (__SVR4) && defined (__sun) # include #endif __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Nov 27 22:19:51 2007 From: report at bugs.python.org (Maarten Thibaut) Date: Tue, 27 Nov 2007 21:19:51 -0000 Subject: [issue1506] func alloca inside ctypes lib needs #include on solaris Message-ID: <1196198391.99.0.848677139277.issue1506@psf.upfronthosting.co.za> Changes by Maarten Thibaut: ---------- components: +Extension Modules -Library (Lib) __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Nov 27 22:30:55 2007 From: report at bugs.python.org (Tom Culliton) Date: Tue, 27 Nov 2007 21:30:55 -0000 Subject: [issue1731717] race condition in subprocess module Message-ID: <1196199055.51.0.460667757721.issue1731717@psf.upfronthosting.co.za> Tom Culliton added the comment: Looking at the subprocess.py code it occurred to me that it never checks if the value of self.pid returned by os.fork is -1, this would mean that later it runs waitpid with -1 as the first argument, putting it into promiscuous (wait for any process in the group) mode. This seems like a bad idea... _____________________________________ Tracker _____________________________________ From report at bugs.python.org Tue Nov 27 23:21:26 2007 From: report at bugs.python.org (Guido van Rossum) Date: Tue, 27 Nov 2007 22:21:26 -0000 Subject: [issue1504] Add 2to3 fixer for (un)bound methods Message-ID: <1196202086.88.0.616889144497.issue1504@psf.upfronthosting.co.za> Guido van Rossum added the comment: There's C code like this: if (Py_Py3kWarningFlag && PyErr_Warn(PyExc_DeprecationWarning, "apply() not supported in 3.x") < 0) return NULL; I don't know how to check for that flag in Python though -- we should really export all flags via the sys module... __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Nov 27 23:22:57 2007 From: report at bugs.python.org (Guido van Rossum) Date: Tue, 27 Nov 2007 22:22:57 -0000 Subject: [issue1506] func alloca inside ctypes lib needs #include on solaris Message-ID: <1196202177.13.0.901380474005.issue1506@psf.upfronthosting.co.za> Changes by Guido van Rossum: ---------- assignee: -> theller nosy: +theller __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Nov 27 23:24:22 2007 From: report at bugs.python.org (Guido van Rossum) Date: Tue, 27 Nov 2007 22:24:22 -0000 Subject: [issue1731717] race condition in subprocess module Message-ID: <1196202262.82.0.00996419099839.issue1731717@psf.upfronthosting.co.za> Guido van Rossum added the comment: > Looking at the subprocess.py code it occurred to me that it never > checks if the value of self.pid returned by os.fork is -1 What makes you think os.fork(0 can return -1? It's not C you know... _____________________________________ Tracker _____________________________________ From report at bugs.python.org Tue Nov 27 23:25:12 2007 From: report at bugs.python.org (Mark Dickinson) Date: Tue, 27 Nov 2007 22:25:12 -0000 Subject: [issue1507] complex constructor loses signs of zeros Message-ID: <1196202312.79.0.339731037994.issue1507@psf.upfronthosting.co.za> New submission from Mark Dickinson: In Python2.5 and the current trunk, construction of a complex number from two floats loses the negative sign of a negative zero in the imaginary part. >>> complex(-0., 0.).real # behaves as expected -0.0 >>> complex(0., -0.).imag # loses sign of zero 0.0 There are situations where it's important to preserve the sign of zero (typically when doing calculations involving functions with branch cuts); there are probably platforms where this is difficult for one reason or another, but on a platform that complies with all the usual standards I can't see any reason for Python not to preserve the signs of zeros, provided that it's straightforward to do so. The attached patch changes the complex constructor so that if x and y are numeric and neither x nor y is complex (or a subclass of complex) then complex(x, y) simply places x into the real part of the complex number and y into the imaginary part. For someone who doesn't care about the sign of zeros, this patch will have no noticeable effect. Similarly, on a system that does not have full hardware or system support for signed zeros, this patch should be harmless. Note that the patch does *not* change the feature that complex(z1, z2) returns z1 + 1j*z2 when z1 and/or z2 is itself complex. There was some previous discussion of this on python-dev earlier this year. See http://mail.python.org/pipermail/python-dev/2007-January/070770.html ---------- files: complex_new.patch messages: 57891 nosy: marketdickinson severity: normal status: open title: complex constructor loses signs of zeros versions: Python 2.5, Python 2.6 Added file: http://bugs.python.org/file8815/complex_new.patch __________________________________ Tracker __________________________________ -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: complex_new.patch Url: http://mail.python.org/pipermail/python-bugs-list/attachments/20071127/e3e69a97/attachment-0001.txt From report at bugs.python.org Tue Nov 27 23:33:43 2007 From: report at bugs.python.org (Tom Culliton) Date: Tue, 27 Nov 2007 22:33:43 -0000 Subject: [issue1731717] race condition in subprocess module In-Reply-To: <1196202262.82.0.00996419099839.issue1731717@psf.upfronthosting.co.za> Message-ID: <474C9AFC.4020803@oracle.com> Tom Culliton added the comment: Good question. The documentation I was reading was mute on the subject so I made a "reasonable" guess. Does it throw an exception instead? Guido van Rossum wrote: > Guido van Rossum added the comment: > > >> Looking at the subprocess.py code it occurred to me that it never >> checks if the value of self.pid returned by os.fork is -1 >> > > What makes you think os.fork(0 can return -1? It's not C you know... > > _____________________________________ > Tracker > > _____________________________________ > _____________________________________ Tracker _____________________________________ From report at bugs.python.org Tue Nov 27 23:39:15 2007 From: report at bugs.python.org (Guido van Rossum) Date: Tue, 27 Nov 2007 22:39:15 -0000 Subject: [issue1507] complex constructor loses signs of zeros Message-ID: <1196203155.4.0.0708978264077.issue1507@psf.upfronthosting.co.za> Guido van Rossum added the comment: Committed revision 59203. Anthony, is this OK to backport to 2.5.2? ---------- assignee: -> anthonybaxter nosy: +anthonybaxter, gvanrossum resolution: -> accepted __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Nov 27 23:39:52 2007 From: report at bugs.python.org (Guido van Rossum) Date: Tue, 27 Nov 2007 22:39:52 -0000 Subject: [issue1731717] race condition in subprocess module Message-ID: <1196203192.22.0.671677558148.issue1731717@psf.upfronthosting.co.za> Guido van Rossum added the comment: Yes, like all system calls in the os module. _____________________________________ Tracker _____________________________________ From report at bugs.python.org Wed Nov 28 00:09:58 2007 From: report at bugs.python.org (Joseph Armbruster) Date: Tue, 27 Nov 2007 23:09:58 -0000 Subject: [issue1508] Removal of stale code in _csv.c / pyexpat.c Message-ID: <1196204998.62.0.0437576024742.issue1508@psf.upfronthosting.co.za> New submission from Joseph Armbruster: I found two code blocks that look as if they can be safely removed: >From _csv.c: /* begin 2.2 compatibility macros */ #ifndef PyDoc_STRVAR /* Define macros for inline documentation. */ #define PyDoc_VAR(name) static char name[] #define PyDoc_STRVAR(name,str) PyDoc_VAR(name) = PyDoc_STR(str) #ifdef WITH_DOC_STRINGS #define PyDoc_STR(str) str #else #define PyDoc_STR(str) "" #endif #endif /* ifndef PyDoc_STRVAR */ >From pyexpat.c: #ifndef PyDoc_STRVAR /* * fdrake says: * Don't change the PyDoc_STR macro definition to (str), because * '''the parentheses cause compile failures * ("non-constant static initializer" or something like that) * on some platforms (Irix?)''' */ #define PyDoc_STR(str) str #define PyDoc_VAR(name) static char name[] #define PyDoc_STRVAR(name,str) PyDoc_VAR(name) = PyDoc_STR(str) #endif ---------- components: Extension Modules messages: 57895 nosy: JosephArmbruster severity: minor status: open title: Removal of stale code in _csv.c / pyexpat.c versions: Python 3.0 __________________________________ Tracker __________________________________ From report at bugs.python.org Wed Nov 28 00:17:56 2007 From: report at bugs.python.org (Christian Heimes) Date: Tue, 27 Nov 2007 23:17:56 -0000 Subject: [issue1504] Add 2to3 fixer for (un)bound methods In-Reply-To: <1196202086.88.0.616889144497.issue1504@psf.upfronthosting.co.za> Message-ID: <474CA5A2.4050900@cheimes.de> Christian Heimes added the comment: Guido van Rossum wrote: > Guido van Rossum added the comment: > > There's C code like this: > > if (Py_Py3kWarningFlag && > PyErr_Warn(PyExc_DeprecationWarning, > "apply() not supported in 3.x") < 0) > return NULL; > > I don't know how to check for that flag in Python though -- we should > really export all flags via the sys module... I've exposed the flag in r59204 as sys.py3kwarning. I've also added a method warnings.warnpy3k(). Christian __________________________________ Tracker __________________________________ From report at bugs.python.org Wed Nov 28 00:27:34 2007 From: report at bugs.python.org (Maarten Thibaut) Date: Tue, 27 Nov 2007 23:27:34 -0000 Subject: [issue1506] func alloca inside ctypes lib needs #include on solaris Message-ID: <1196206054.95.0.568135673137.issue1506@psf.upfronthosting.co.za> Maarten Thibaut added the comment: forgot to mention the files: Modules/_ctypes/callproc.c Modules/_ctypes/libffi/src/sparc/ffi.c __________________________________ Tracker __________________________________ From report at bugs.python.org Wed Nov 28 00:48:29 2007 From: report at bugs.python.org (Georg Brandl) Date: Tue, 27 Nov 2007 23:48:29 -0000 Subject: [issue1496] add str.maketrans() Message-ID: <1196207309.38.0.368148904289.issue1496@psf.upfronthosting.co.za> Georg Brandl added the comment: Okay, checked in as r59205. ---------- resolution: -> accepted status: open -> closed __________________________________ Tracker __________________________________ From report at bugs.python.org Wed Nov 28 00:56:10 2007 From: report at bugs.python.org (Georg Brandl) Date: Tue, 27 Nov 2007 23:56:10 -0000 Subject: [issue1755179] Deadlocks with fork() and multithreading Message-ID: <1196207770.27.0.785384355158.issue1755179@psf.upfronthosting.co.za> Georg Brandl added the comment: Will it be backported? ---------- nosy: +georg.brandl _____________________________________ Tracker _____________________________________ From report at bugs.python.org Wed Nov 28 03:10:42 2007 From: report at bugs.python.org (Peter Mawhorter) Date: Wed, 28 Nov 2007 02:10:42 -0000 Subject: [issue1509] Documentation lacking for the sqlite3 module. Message-ID: <1196215842.85.0.855394455026.issue1509@psf.upfronthosting.co.za> New submission from Peter Mawhorter: The current documentation for the sqlite3 module on the web fails to make any mention of the fetch* functions posessed by the Cursor class of that module. It in fact gives no indication of how one should extract results from sql queries. The docstrings in the module (viewed using the help() function) are woefully incomplete, and are inconsistent with the function names: | fetchall(...) | Fetches one row from the resultset. | | fetchmany(...) | Fetches all rows from the resultset. | | fetchone(...) | Fetches several rows from the resultset. | Both of these things need to be fixed in order for this module to be useful for someone who doesn't already know how to use it. ---------- components: Extension Modules messages: 57900 nosy: pmawhorter severity: minor status: open title: Documentation lacking for the sqlite3 module. versions: Python 2.5 __________________________________ Tracker __________________________________ From report at bugs.python.org Wed Nov 28 06:00:44 2007 From: report at bugs.python.org (cfk) Date: Wed, 28 Nov 2007 05:00:44 -0000 Subject: [issue1510] help for file/open should state which is prefered. Message-ID: <1196226044.27.0.136551028633.issue1510@psf.upfronthosting.co.za> New submission from cfk: bltinmodule.c: PyDoc_STRVAR(open_doc, "open(name[, mode[, buffering]]) -> file object\n\ \n\ Open a file using the file() type, returns a file object."); Help for file() is detailed, which would lead people to use file over open. given that file() is removed in py3k, I think that should be mentioned in the current file() docstring, and swap the help for file/open. ---------- components: Documentation messages: 57901 nosy: carlfk severity: minor status: open title: help for file/open should state which is prefered. versions: Python 2.6 __________________________________ Tracker __________________________________ From report at bugs.python.org Wed Nov 28 06:15:17 2007 From: report at bugs.python.org (Bill Fenner) Date: Wed, 28 Nov 2007 05:15:17 -0000 Subject: [issue1511] csv input converts \r\n to \n but csv output does not when a field has internal line breaks Message-ID: <1196226917.03.0.0879630569127.issue1511@psf.upfronthosting.co.za> New submission from Bill Fenner: When a field has internal line breaks, e.g., foo,"bar baz biff",boo that is actually 3 lines, but one csv-file row. csv.reader() converts this to ['foo', 'bar\nbaz\nbiff', 'boo']. This is a reasonable behavior. Unfortunately, csv.writer() does not use the dialect's lineterminator setting for values with such internal linebreaks. This means that the resulting file will have a mix of line-termination styles: foo,"bar\n baz\n biff",boo\r\n If the reading csv implementation is strict about its line termination, these line breaks will not be read properly. ---------- messages: 57902 nosy: fenner severity: normal status: open title: csv input converts \r\n to \n but csv output does not when a field has internal line breaks type: behavior versions: Python 2.4 __________________________________ Tracker __________________________________ From report at bugs.python.org Wed Nov 28 06:18:53 2007 From: report at bugs.python.org (Bill Fenner) Date: Wed, 28 Nov 2007 05:18:53 -0000 Subject: [issue1511] csv input converts \r\n to \n but csv output does not when a field has internal line breaks Message-ID: <1196227133.69.0.487272761888.issue1511@psf.upfronthosting.co.za> Changes by Bill Fenner: ---------- components: +Library (Lib) __________________________________ Tracker __________________________________ From report at bugs.python.org Wed Nov 28 06:19:39 2007 From: report at bugs.python.org (Bill Fenner) Date: Wed, 28 Nov 2007 05:19:39 -0000 Subject: [issue1511] csv input converts \r\n to \n but csv output does not when a field has internal line breaks Message-ID: <1196227179.09.0.863786574313.issue1511@psf.upfronthosting.co.za> Bill Fenner added the comment: I realized that my description was not crystal clear - the file being read has \r\n line terminators - in the format that I used later, the input file is foo,"bar\r\n baz\r\n biff",boo\r\n __________________________________ Tracker __________________________________ From report at bugs.python.org Wed Nov 28 06:33:03 2007 From: report at bugs.python.org (Gregory P. Smith) Date: Wed, 28 Nov 2007 05:33:03 -0000 Subject: [issue1511] csv input converts \r\n to \n but csv output does not when a field has internal line breaks Message-ID: <1196227983.67.0.214604237913.issue1511@psf.upfronthosting.co.za> Gregory P. Smith added the comment: release25-maint and trunk (2.6) appear to do the correct thing when testing on my ubuntu gutsy linux x86 box. test script and file attached. The problem is reproducable in a release24-maint build compiled 2007-11-05. ---------- nosy: +gregory.p.smith Added file: http://bugs.python.org/file8816/issue1511.py __________________________________ Tracker __________________________________ -------------- next part -------------- A non-text attachment was scrubbed... Name: issue1511.py Type: application/octet-stream Size: 183 bytes Desc: not available Url : http://mail.python.org/pipermail/python-bugs-list/attachments/20071128/a0fe805e/attachment.obj From report at bugs.python.org Wed Nov 28 06:36:15 2007 From: report at bugs.python.org (Gregory P. Smith) Date: Wed, 28 Nov 2007 05:36:15 -0000 Subject: [issue1511] csv input converts \r\n to \n but csv output does not when a field has internal line breaks Message-ID: <1196228175.24.0.0936547175825.issue1511@psf.upfronthosting.co.za> Gregory P. Smith added the comment: attaching the test input file. use od -x or similar to compare the new.csv output with issue1511.csv to see if the problem happened. its 2.4.. that may be old enough to be considered dead Added file: http://bugs.python.org/file8817/issue1511.csv __________________________________ Tracker __________________________________ -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: issue1511.csv Url: http://mail.python.org/pipermail/python-bugs-list/attachments/20071128/897060fd/attachment.txt From report at bugs.python.org Wed Nov 28 10:46:24 2007 From: report at bugs.python.org (Christian Heimes) Date: Wed, 28 Nov 2007 09:46:24 -0000 Subject: [issue1510] help for file/open should state which is prefered. Message-ID: <1196243184.48.0.794311582206.issue1510@psf.upfronthosting.co.za> Christian Heimes added the comment: I agree! Can you provide a patch please? ---------- assignee: -> tiran nosy: +tiran priority: -> normal __________________________________ Tracker __________________________________ From report at bugs.python.org Wed Nov 28 10:48:39 2007 From: report at bugs.python.org (Christian Heimes) Date: Wed, 28 Nov 2007 09:48:39 -0000 Subject: [issue1509] Documentation lacking for the sqlite3 module. Message-ID: <1196243319.95.0.87610360113.issue1509@psf.upfronthosting.co.za> Christian Heimes added the comment: Are you able to provide a patch? Please use a snapshot or svn checkout of 2.5 for the patch. We have a new documentation system. ---------- nosy: +tiran __________________________________ Tracker __________________________________ From report at bugs.python.org Wed Nov 28 11:06:35 2007 From: report at bugs.python.org (Christian Heimes) Date: Wed, 28 Nov 2007 10:06:35 -0000 Subject: [issue1508] Removal of stale code in _csv.c / pyexpat.c Message-ID: <1196244395.0.0.991903614759.issue1508@psf.upfronthosting.co.za> Christian Heimes added the comment: Fixed in r59214 Thanks Joseph! Can you find more? ---------- keywords: +py3k nosy: +tiran resolution: -> fixed status: open -> closed __________________________________ Tracker __________________________________ From report at bugs.python.org Wed Nov 28 11:30:41 2007 From: report at bugs.python.org (Peter Mawhorter) Date: Wed, 28 Nov 2007 10:30:41 -0000 Subject: [issue1509] Documentation lacking for the sqlite3 module. In-Reply-To: <1196243319.95.0.87610360113.issue1509@psf.upfronthosting.co.za> Message-ID: <3442bf5a0711280230m1d3a2002t2a0df084104d9cf0@mail.gmail.com> Peter Mawhorter added the comment: I could try, but I honestly don't know exactly how the fetch* functions work. It would probably take me a good couple of hours of reading before I could write decent documentation, and as much as that would be great, I'm not about to squeeze that into my college schedule. I don't actually have a 2.5 checkout, but I thought that at one point those methods were documented. Is there a way to check the history of the online documentation and revert those pages? -Peter Mawhorter On 11/28/07, Christian Heimes wrote: > > Christian Heimes added the comment: > > Are you able to provide a patch? Please use a snapshot or svn checkout > of 2.5 for the patch. We have a new documentation system. > > ---------- > nosy: +tiran > > __________________________________ > Tracker > > __________________________________ > __________________________________ Tracker __________________________________ From report at bugs.python.org Wed Nov 28 11:37:28 2007 From: report at bugs.python.org (Amaury Forgeot d'Arc) Date: Wed, 28 Nov 2007 10:37:28 -0000 Subject: [issue1509] Documentation lacking for the sqlite3 module. Message-ID: <1196246248.71.0.885071311117.issue1509@psf.upfronthosting.co.za> Amaury Forgeot d'Arc added the comment: > I thought that at one point those methods were documented sqlite3 implements the DB-API: http://www.python.org/dev/peps/pep-0249/ is it the documentation you had in mind? ---------- nosy: +amaury.forgeotdarc __________________________________ Tracker __________________________________ From report at bugs.python.org Wed Nov 28 13:17:10 2007 From: report at bugs.python.org (Peter Mawhorter) Date: Wed, 28 Nov 2007 12:17:10 -0000 Subject: [issue1509] Documentation lacking for the sqlite3 module. In-Reply-To: <1196246248.71.0.885071311117.issue1509@psf.upfronthosting.co.za> Message-ID: <3442bf5a0711280417ofd5f69ewae3f1aa201e0d048@mail.gmail.com> Peter Mawhorter added the comment: Yes actually... the fetch documentation there is a sufficient explanation of the functions provided. If it could be added to docs.python.org, that would be great. There still remains the fact that the docstrings in the sqlite3 module don't agree with their function names, but that's a very minor issue, and wouldn't normally impact usability of the module. -Peter Mawhorter On 11/28/07, Amaury Forgeot d'Arc wrote: > > Amaury Forgeot d'Arc added the comment: > > > I thought that at one point those methods were documented > > sqlite3 implements the DB-API: > http://www.python.org/dev/peps/pep-0249/ > is it the documentation you had in mind? > > ---------- > nosy: +amaury.forgeotdarc > > __________________________________ > Tracker > > __________________________________ > __________________________________ Tracker __________________________________ From report at bugs.python.org Wed Nov 28 13:45:53 2007 From: report at bugs.python.org (Skip Montanaro) Date: Wed, 28 Nov 2007 12:45:53 -0000 Subject: [issue1511] csv input converts \r\n to \n but csv output does not when a field has internal line breaks Message-ID: <1196253953.72.0.684206256559.issue1511@psf.upfronthosting.co.za> Changes by Skip Montanaro: ---------- assignee: -> skip.montanaro nosy: +skip.montanaro __________________________________ Tracker __________________________________ From report at bugs.python.org Wed Nov 28 14:43:48 2007 From: report at bugs.python.org (Christian Heimes) Date: Wed, 28 Nov 2007 13:43:48 -0000 Subject: [issue1505] Changes to PyMethod_New breaks ctypes on Windows Message-ID: <1196257428.28.0.63703233571.issue1505@psf.upfronthosting.co.za> Christian Heimes added the comment: The removal of unbound methods made it hard to bind CFunctions. I rewrote the code in r59215. ---------- resolution: -> fixed status: open -> closed __________________________________ Tracker __________________________________ From report at bugs.python.org Wed Nov 28 15:14:07 2007 From: report at bugs.python.org (Joseph Armbruster) Date: Wed, 28 Nov 2007 14:14:07 -0000 Subject: [issue1512] Removal of stale code in pyconfig.h Message-ID: <1196259247.47.0.175425290011.issue1512@psf.upfronthosting.co.za> New submission from Joseph Armbruster: Question: Is there any harm in removing this block from pyconfig.h? #ifndef PY_LONG_LONG # define PY_LONG_LONG __int64 # define PY_LLONG_MAX _I64_MAX # define PY_LLONG_MIN _I64_MIN # define PY_ULLONG_MAX _UI64_MAX #endif pyconfig.h contains this small snippet: /* 64 bit ints are usually spelt __int64 unless compiler has overridden */ #define HAVE_LONG_LONG 1 #ifndef PY_LONG_LONG # define PY_LONG_LONG __int64 # define PY_LLONG_MAX _I64_MAX # define PY_LLONG_MIN _I64_MIN # define PY_ULLONG_MAX _UI64_MAX #endif However, in pyport.h, I can see that PY_LONG_LONG may also be defined here, except the tokens are slightly different: #ifdef HAVE_LONG_LONG #ifndef PY_LONG_LONG #define PY_LONG_LONG long long #if defined(LLONG_MAX) /* If LLONG_MAX is defined in limits.h, use that. */ #define PY_LLONG_MIN LLONG_MIN #define PY_LLONG_MAX LLONG_MAX #define PY_ULLONG_MAX ULLONG_MAX #elif defined(__LONG_LONG_MAX__) /* Otherwise, if GCC has a builtin define, use that. */ #define PY_LLONG_MAX __LONG_LONG_MAX__ #define PY_LLONG_MIN (-PY_LLONG_MAX-1) #define PY_ULLONG_MAX (__LONG_LONG_MAX__*2ULL + 1ULL) #else /* Otherwise, rely on two's complement. */ #define PY_ULLONG_MAX (~0ULL) #define PY_LLONG_MAX ((long long)(PY_ULLONG_MAX>>1)) #define PY_LLONG_MIN (-PY_LLONG_MAX-1) #endif /* LLONG_MAX */ #endif #endif /* HAVE_LONG_LONG */ ---------- components: Build messages: 57913 nosy: JosephArmbruster, tiran severity: minor status: open title: Removal of stale code in pyconfig.h versions: Python 3.0 __________________________________ Tracker __________________________________ From report at bugs.python.org Wed Nov 28 15:23:11 2007 From: report at bugs.python.org (Christian Heimes) Date: Wed, 28 Nov 2007 14:23:11 -0000 Subject: [issue1512] Removal of stale code in pyconfig.h Message-ID: <1196259791.76.0.638769924113.issue1512@psf.upfronthosting.co.za> Changes by Christian Heimes: ---------- assignee: -> loewis nosy: +loewis priority: -> low __________________________________ Tracker __________________________________ From report at bugs.python.org Wed Nov 28 16:12:55 2007 From: report at bugs.python.org (mathieu Clabaut) Date: Wed, 28 Nov 2007 15:12:55 -0000 Subject: [issue1160] Medium size regexp crashes python Message-ID: <1196262775.27.0.440583212143.issue1160@psf.upfronthosting.co.za> Changes by mathieu Clabaut: ---------- nosy: +mathieu.clabaut __________________________________ Tracker __________________________________ From report at bugs.python.org Wed Nov 28 17:25:10 2007 From: report at bugs.python.org (Joseph Armbruster) Date: Wed, 28 Nov 2007 16:25:10 -0000 Subject: [issue1513] object.c do_compare comparison ordering error Message-ID: <1196267109.95.0.653970377186.issue1513@psf.upfronthosting.co.za> New submission from Joseph Armbruster: URL: http://svn.python.org/projects/python/branches/py3k Rev: 59215 Session illustrating issue: >>> a = None [40667 refs] >>> cmp(a,None) Traceback (most recent call last): File "", line 1, in TypeError: unorderable types: NoneType() < NoneType() [40715 refs] Resolution: It appears the equality comparison in do_compare should take place first, otherwise a TypeError thwarts the desired comparison. rt.bat Results (I can only test core, since I do not have the third party libs here): Failed tests before change: test_ctypes test_mailbox Failed tests after change: test_copy test_ctypes test_mailbox test_copy is failing because of this block: def test_deepcopy_reflexive_dict(self): x = {} x['foo'] = x y = copy.deepcopy(x) self.assertRaises(TypeError, cmp, y, x) self.assert_(y is not x) self.assert_(y['foo'] is y) self.assertEqual(len(y), 1) A RuntimeError now occurs instead. self.assertRaises(RuntimeError, cmp, y, x) Additional Patch Note: If this is a valid patch, please add a comment prior to the code change that indicates the EQ test is first for a good reason. ---------- components: Interpreter Core files: noneEquality.patch messages: 57914 nosy: JosephArmbruster, loewis, tiran severity: normal status: open title: object.c do_compare comparison ordering error type: behavior versions: Python 3.0 Added file: http://bugs.python.org/file8818/noneEquality.patch __________________________________ Tracker __________________________________ -------------- next part -------------- A non-text attachment was scrubbed... Name: noneEquality.patch Type: text/x-diff Size: 844 bytes Desc: not available Url : http://mail.python.org/pipermail/python-bugs-list/attachments/20071128/4214730e/attachment.patch From report at bugs.python.org Wed Nov 28 18:43:42 2007 From: report at bugs.python.org (Christian Heimes) Date: Wed, 28 Nov 2007 17:43:42 -0000 Subject: [issue1513] object.c do_compare comparison ordering error Message-ID: <1196271822.43.0.379801173594.issue1513@psf.upfronthosting.co.za> Christian Heimes added the comment: Guido, do we want cmp(None, None) to return a value or is the exception expected? ---------- assignee: -> gvanrossum nosy: +gvanrossum __________________________________ Tracker __________________________________ From report at bugs.python.org Wed Nov 28 19:05:07 2007 From: report at bugs.python.org (Guido van Rossum) Date: Wed, 28 Nov 2007 18:05:07 -0000 Subject: [issue1513] object.c do_compare comparison ordering error Message-ID: <1196273107.82.0.822818200846.issue1513@psf.upfronthosting.co.za> Guido van Rossum added the comment: This is not a bug. There's not much point is supporting cmp(None, None) when cmp(None, ) would still fail. cmp() should only be used when you know that the arguments belong to an orderable type. ---------- resolution: -> rejected status: open -> closed __________________________________ Tracker __________________________________ From report at bugs.python.org Wed Nov 28 19:13:40 2007 From: report at bugs.python.org (Joseph Armbruster) Date: Wed, 28 Nov 2007 18:13:40 -0000 Subject: [issue1513] object.c do_compare comparison ordering error Message-ID: <1196273620.9.0.468858434273.issue1513@psf.upfronthosting.co.za> Joseph Armbruster added the comment: I had looked at the behavior in 2.5 and did not know if this would still be the case: >>> cmp(None,'a') -1 >>> cmp('a',None) 1 >>> cmp(None,None) 0 __________________________________ Tracker __________________________________ From report at bugs.python.org Wed Nov 28 19:18:32 2007 From: report at bugs.python.org (Greg Couch) Date: Wed, 28 Nov 2007 18:18:32 -0000 Subject: [issue1506] func alloca inside ctypes lib needs #include on solaris Message-ID: <1196273912.48.0.583349517015.issue1506@psf.upfronthosting.co.za> Greg Couch added the comment: A better solution would be to use the HAVE_ALLOCA and HAVE_ALLOCA_H defines that fficonfig.h provides to decide whether or not to include alloca.h. And in callproc.c whether or not to provide a workaround using malloc (I'm assuming non-gcc sparc compilers also support alloca for sparc/ffi.c, but I don't know for sure). ---------- nosy: +gregcouch __________________________________ Tracker __________________________________ From report at bugs.python.org Wed Nov 28 19:47:17 2007 From: report at bugs.python.org (Guido van Rossum) Date: Wed, 28 Nov 2007 18:47:17 -0000 Subject: [issue1513] object.c do_compare comparison ordering error Message-ID: <1196275637.24.0.479005670441.issue1513@psf.upfronthosting.co.za> Guido van Rossum added the comment: All three of those are errors in 3.0. __________________________________ Tracker __________________________________ From report at bugs.python.org Wed Nov 28 19:52:53 2007 From: report at bugs.python.org (Georg Brandl) Date: Wed, 28 Nov 2007 18:52:53 -0000 Subject: [issue1513] object.c do_compare comparison ordering error Message-ID: <1196275973.03.0.372570074636.issue1513@psf.upfronthosting.co.za> Georg Brandl added the comment: Well, the cmp() docs say that cmp(x, y) is "zero if ``x == y``", so at least the docs must be changed to explain the new behavior (which I can't specify). ---------- nosy: +georg.brandl __________________________________ Tracker __________________________________ From report at bugs.python.org Wed Nov 28 22:07:32 2007 From: report at bugs.python.org (David Binger) Date: Wed, 28 Nov 2007 21:07:32 -0000 Subject: [issue1514] missing constants in socket module Message-ID: <1196284052.76.0.985131774299.issue1514@psf.upfronthosting.co.za> New submission from David Binger: TCP_NODELAY and some constants are not present in the socket module. I think maybe "#include " should appear somewhere, perhaps at the top of socketmodule.c? (This is on OS X 10.5.1 with py3k revision 59215). ---------- components: Library (Lib), Macintosh messages: 57921 nosy: dbinger severity: normal status: open title: missing constants in socket module type: behavior versions: Python 3.0 __________________________________ Tracker __________________________________ From report at bugs.python.org Thu Nov 29 00:42:01 2007 From: report at bugs.python.org (Greg Couch) Date: Wed, 28 Nov 2007 23:42:01 -0000 Subject: [issue1506] func alloca inside ctypes lib needs #include on solaris Message-ID: <1196293321.21.0.637598341341.issue1506@psf.upfronthosting.co.za> Greg Couch added the comment: Turns out callproc.c forgot to include after which conditionally includes alloca.h. So it's a one-line fix. __________________________________ Tracker __________________________________ From report at bugs.python.org Thu Nov 29 01:41:00 2007 From: report at bugs.python.org (Michael Van Biesbrouck) Date: Thu, 29 Nov 2007 00:41:00 -0000 Subject: [issue1515] deepcopy doesn't copy instance methods Message-ID: <1196296860.13.0.0113919656838.issue1515@psf.upfronthosting.co.za> New submission from Michael Van Biesbrouck: Currently, using deepcopy on instance methods causes an exception to be thrown. This can be fixed by adding one line to copy.py: d[types.MethodType] = _deepcopy_atomic This will not make duplicate copies of mutable values referenced within the instance method (such as its associated instance), but it will be the same as the handling of other function types (which have the same problem). ---------- messages: 57923 nosy: mlvanbie severity: normal status: open title: deepcopy doesn't copy instance methods type: behavior versions: Python 2.5 __________________________________ Tracker __________________________________ From report at bugs.python.org Thu Nov 29 01:52:59 2007 From: report at bugs.python.org (Greg Couch) Date: Thu, 29 Nov 2007 00:52:59 -0000 Subject: [issue1516] make _ctypes work with non-gcc compilers Message-ID: <1196297579.57.0.775741892495.issue1516@psf.upfronthosting.co.za> New submission from Greg Couch: To get _ctypes to sucessfully compile with native UNIX compilers (i.e., not gcc), several modifications need to be made: (1) use the equivalent of the Py_GCC_ATTRIBUTE macro for __attribute__ (in ffi.h), (2) include in callproc.c to conditionally include , and (3) modify distutils to know something about assembly language files. The attached patch is a starting point for the proper patch. It fixes bugs (1) and (2), but I was unable to figure out the last tweek to get distutils to work with gcc and native compilers. The problem with _ctypes comes from the use of gcc's libffi. And libffi uses assembly language source files for the various supported platforms and distutils blindly compiles the .S files. Native UNIX compilers want a .s suffix and if the files are renamed, distutils skips the file. I tried modifying distutils to compile .s files and give the '-x assembler-with-cpp' flag to gcc so gcc would still work, but the right tweek evaded me. So I'm hoping someone can take this and turn it into something better or make helpful suggestions (other than switching to gcc!). ---------- files: _ctypes.diffs messages: 57924 nosy: gregcouch severity: normal status: open title: make _ctypes work with non-gcc compilers versions: Python 2.6 Added file: http://bugs.python.org/file8819/_ctypes.diffs __________________________________ Tracker __________________________________ -------------- next part -------------- A non-text attachment was scrubbed... Name: _ctypes.diffs Type: application/octet-stream Size: 8031 bytes Desc: not available Url : http://mail.python.org/pipermail/python-bugs-list/attachments/20071129/b0afaf1b/attachment.obj From report at bugs.python.org Thu Nov 29 02:41:10 2007 From: report at bugs.python.org (Adam Olsen) Date: Thu, 29 Nov 2007 01:41:10 -0000 Subject: [issue1517] lookdict should INCREF/DECREF startkey around PyObject_RichCompareBool Message-ID: <1196300470.07.0.800454639703.issue1517@psf.upfronthosting.co.za> New submission from Adam Olsen: (thanks go to my partner in crime, jorendorff, for helping flesh this out.) lookdict calls PyObject_RichCompareBool without using INCREF/DECREF on the key passed. It's possible for the comparison to delete the key from the dict, causing its own argument to be deallocated. This can lead to bogus results or a crash. A custom type with its own __eq__ method will implicitly INCREF the key when passing it as an argument, which prevents incorrect behaviour from manifesting. There are a couple ways around this though, as shown in my attachment. ---------- components: Interpreter Core files: dictbug.py messages: 57925 nosy: rhamphoryncus severity: normal status: open title: lookdict should INCREF/DECREF startkey around PyObject_RichCompareBool Added file: http://bugs.python.org/file8820/dictbug.py __________________________________ Tracker __________________________________ -------------- next part -------------- A non-text attachment was scrubbed... Name: dictbug.py Type: text/x-python Size: 2071 bytes Desc: not available Url : http://mail.python.org/pipermail/python-bugs-list/attachments/20071129/68ebbf6f/attachment-0001.py From report at bugs.python.org Thu Nov 29 06:38:48 2007 From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=) Date: Thu, 29 Nov 2007 05:38:48 -0000 Subject: [issue1516] make _ctypes work with non-gcc compilers Message-ID: <1196314728.82.0.761690239985.issue1516@psf.upfronthosting.co.za> Martin v. L?wis added the comment: Can you please be specific what compilers and systems you are talking about? I doubt your statements hold for *all* native UNIX compilers. In particular, .s files should be compiled with as, not cc, on the UNIX systems I'm familiar with, but that won't involve the C preprocessor. ---------- assignee: -> theller nosy: +loewis, theller __________________________________ Tracker __________________________________ From report at bugs.python.org Thu Nov 29 11:49:44 2007 From: report at bugs.python.org (Christian Heimes) Date: Thu, 29 Nov 2007 10:49:44 -0000 Subject: [issue1517] lookdict should INCREF/DECREF startkey around PyObject_RichCompareBool Message-ID: <1196333384.08.0.152165478762.issue1517@psf.upfronthosting.co.za> Christian Heimes added the comment: Two questions: * Which versions of Python are vulnerable to the problem? You forgot to fill in the version list. * How do we fix the problem? Is it enough to incref the key or must startkey be protected, too? ---------- nosy: +tiran __________________________________ Tracker __________________________________ From report at bugs.python.org Thu Nov 29 13:46:37 2007 From: report at bugs.python.org (Christian Heimes) Date: Thu, 29 Nov 2007 12:46:37 -0000 Subject: [issue1518] Fast globals/builtins access (patch) Message-ID: <1196340397.37.0.625911263501.issue1518@psf.upfronthosting.co.za> Christian Heimes added the comment: When I run the code of test_gc.py test_function() in a shell I'm getting the expected result of 2 collected items: gc: collectable gc: collectable However the same code embedded in the test suite collects two additional objects: gc: collectable gc: collectable gc: collectable gc: collectable I've used gc.set_debug(gc.DEBUG_LEAK) to get the information ---------- nosy: +tiran __________________________________ Tracker __________________________________ From report at bugs.python.org Thu Nov 29 15:20:58 2007 From: report at bugs.python.org (Nadeem Vawda) Date: Thu, 29 Nov 2007 14:20:58 -0000 Subject: [issue1519] async_chat.__init__() parameters Message-ID: <1196346058.65.0.25106672712.issue1519@psf.upfronthosting.co.za> New submission from Nadeem Vawda: The __init__() function for asynchat.async_chat doesn't allow the caller to specify a channel map. I thought it would make sense to add an optional 'map' parameter, for consistency with asyncore.dispatcher. If the parameter is not specified, asyncore.dispatcher.__init__() will default to using the global map, which is the current behaviour. ---------- components: Library (Lib) files: asynchat.patch messages: 57930 nosy: nvawda severity: minor status: open title: async_chat.__init__() parameters type: behavior versions: Python 2.5 Added file: http://bugs.python.org/file8822/asynchat.patch __________________________________ Tracker __________________________________ -------------- next part -------------- A non-text attachment was scrubbed... Name: asynchat.patch Type: application/octet-stream Size: 666 bytes Desc: not available Url : http://mail.python.org/pipermail/python-bugs-list/attachments/20071129/3531fb02/attachment.obj From report at bugs.python.org Thu Nov 29 16:15:31 2007 From: report at bugs.python.org (Joseph Armbruster) Date: Thu, 29 Nov 2007 15:15:31 -0000 Subject: [issue1520] 'without make' documentation build anomaly Message-ID: <1196349331.67.0.490031647679.issue1520@psf.upfronthosting.co.za> New submission from Joseph Armbruster: When I run the following from a windows command line, the resulting html can not be browsed stand-alone: python tools/sphinx-build.py -bhtml . build/htmlwin It looks like the paths are getting hosed up; for example: htmlcygwin/c-api/index.html contains: htmlcmd/c-api/index.html contains: Notes: These seemed to work fine: - building target html it in cygwin using make - building target html in cygwin without make - building target htmlhelp in cmd without make then generating chm ---------- components: Documentation, Documentation tools (Sphinx) messages: 57931 nosy: JosephArmbruster severity: minor status: open title: 'without make' documentation build anomaly type: behavior versions: Python 3.0 __________________________________ Tracker __________________________________ From report at bugs.python.org Thu Nov 29 16:33:06 2007 From: report at bugs.python.org (Andreas Eisele) Date: Thu, 29 Nov 2007 15:33:06 -0000 Subject: [issue1521] string.decode() fails on long strings Message-ID: <1196350386.46.0.0641290280607.issue1521@psf.upfronthosting.co.za> New submission from Andreas Eisele: s.decode("utf-8") sometimes silently truncates the result if s has more than 2E9 Bytes, sometimes raises a fairly incomprehensible exception: Traceback (most recent call last): File "", line 2, in File "/usr/lib64/python2.5/encodings/utf_8.py", line 16, in decode return codecs.utf_8_decode(input, errors, True) TypeError: utf_8_decode() argument 1 must be (unspecified), not str ---------- components: Unicode messages: 57932 nosy: eisele severity: normal status: open title: string.decode() fails on long strings type: behavior versions: Python 2.5 __________________________________ Tracker __________________________________ From report at bugs.python.org Thu Nov 29 17:07:37 2007 From: report at bugs.python.org (Chris Mellon) Date: Thu, 29 Nov 2007 16:07:37 -0000 Subject: [issue1518] Fast globals/builtins access (patch) Message-ID: <1196352457.71.0.275579090544.issue1518@psf.upfronthosting.co.za> Chris Mellon added the comment: In funcobject.c:PyFunction_New, the declarations of op and __name__ need to be moved to the top of the function to compile in MSVC, and if accepted the fastglobals.c file needs to be added to PCBuild. In the test script, the use of import * generates syntax warnings that make the output awkward to read, and the benchmark for dict_get is actually running dict_set. I'm attaching the fixed copy of the test script I used. I see roughly the same speed ups (MSVC 7.1, Windows XP, Intel Core2 Duo @ 2.13Ghz), but I see a 10% slowdown in the dict-insert/delete and dict-set benchmarks which I find very troubling. Test Trunk fastglobals Time difference -------------------------------------------------- Dict insert/del 2.002495495 2.207409125 1.102329134 Dict get 0.750253205 0.745576662 0.993766714 Dict set 0.982695921 1.114997766 1.13463152 Local get 0.533387029 0.51337118 0.96247406 Local set 0.596565774 0.614124914 1.029433703 Global get 0.935605073 0.731136584 0.78145855 Global set 1.48638532 1.03868462 0.69879903 Builtin get 1.392606367 0.735180673 0.52791707 Function call 1.938705781 1.716233004 0.885246756 List comp 1.547780105 1.188215756 0.767690289 PyBench shows an overall slowdown - String mappings in particular, string/unicode predicates, and new instance creation all show significant slowdowns. The results are fairly verbose so I've uploaded them as a google docs spreadsheet at http://spreadsheets.google.com/ccc?key=p7g0z40g_NpvH5UpPTpr-Ag&hl=en I notice that you create a new PyFastGlobals object in every call to PyEval_EvalCode. This might explain some of the general case slowdown, is this really what you want to do? ---------- nosy: +arkanes Added file: http://bugs.python.org/file8823/fastglobals_test.py __________________________________ Tracker __________________________________ -------------- next part -------------- A non-text attachment was scrubbed... Name: fastglobals_test.py Type: text/x-python Size: 12364 bytes Desc: not available Url : http://mail.python.org/pipermail/python-bugs-list/attachments/20071129/9a157d5e/attachment-0001.py From report at bugs.python.org Thu Nov 29 17:11:20 2007 From: report at bugs.python.org (=?utf-8?q?Walter_D=C3=B6rwald?=) Date: Thu, 29 Nov 2007 16:11:20 -0000 Subject: [issue1521] string.decode() fails on long strings Message-ID: <1196352680.04.0.649963458063.issue1521@psf.upfronthosting.co.za> Walter D?rwald added the comment: Can you attach a (small) example that demonstrates the bug? ---------- nosy: +doerwalter __________________________________ Tracker __________________________________ From report at bugs.python.org Thu Nov 29 17:15:22 2007 From: report at bugs.python.org (Andreas Eisele) Date: Thu, 29 Nov 2007 16:15:22 -0000 Subject: [issue1521] string.decode() fails on long strings Message-ID: <1196352922.94.0.335711497485.issue1521@psf.upfronthosting.co.za> Andreas Eisele added the comment: For instance: Python 2.5.1 (r251:54863, Aug 30 2007, 16:15:51) [GCC 4.1.0 (SUSE Linux)] on linux2 Type "help", "copyright", "credits" or "license" for more information. __[1] >>> s=" "*int(5E9) 6.050000 sec __[1] >>> u=s.decode("utf-8") 4.710000 sec __[1] >>> len(u) 705032704 __[2] >>> len(s) 5000000000 __[3] >>> I would have expected both lengths to be 5E9 __________________________________ Tracker __________________________________ From report at bugs.python.org Thu Nov 29 17:20:57 2007 From: report at bugs.python.org (Andreas Eisele) Date: Thu, 29 Nov 2007 16:20:57 -0000 Subject: [issue1521] string.decode() fails on long strings Message-ID: <1196353257.23.0.0798884281724.issue1521@psf.upfronthosting.co.za> Andreas Eisele added the comment: An instance of the other problem: Python 2.5.1 (r251:54863, Aug 30 2007, 16:15:51) [GCC 4.1.0 (SUSE Linux)] on linux2 Type "help", "copyright", "credits" or "license" for more information. __[1] >>> s=" "*int(25E8) 2.990000 sec __[1] >>> u=s.decode("utf-8") Traceback (most recent call last): File "", line 1, in File "/home/cl-home/eisele/lns-root-07/lib/python2.5/encodings/utf_8.py", line 16, in decode return codecs.utf_8_decode(input, errors, True) TypeError: utf_8_decode() argument 1 must be (unspecified), not str __[1] >>> __________________________________ Tracker __________________________________ From report at bugs.python.org Thu Nov 29 17:27:34 2007 From: report at bugs.python.org (Christian Heimes) Date: Thu, 29 Nov 2007 16:27:34 -0000 Subject: [issue1522] pyvm module patch Message-ID: <1196353654.85.0.895576631974.issue1522@psf.upfronthosting.co.za> New submission from Christian Heimes: I've created a pyvm module for Python 3.0. So far it just contains a bunch of internal types. What methods do you like to add to pyvm? Somebody suggested internal functions from sys like the check internal. ---------- components: Extension Modules, Interpreter Core files: py3k_pyvm.patch keywords: patch, py3k messages: 57937 nosy: gvanrossum, tiran priority: normal severity: normal status: open title: pyvm module patch versions: Python 3.0 Added file: http://bugs.python.org/file8824/py3k_pyvm.patch __________________________________ Tracker __________________________________ -------------- next part -------------- A non-text attachment was scrubbed... Name: py3k_pyvm.patch Type: text/x-diff Size: 4175 bytes Desc: not available Url : http://mail.python.org/pipermail/python-bugs-list/attachments/20071129/3c20bc98/attachment.patch From report at bugs.python.org Thu Nov 29 18:14:52 2007 From: report at bugs.python.org (Amaury Forgeot d'Arc) Date: Thu, 29 Nov 2007 17:14:52 -0000 Subject: [issue1521] string.decode() fails on long strings Message-ID: <1196356492.96.0.815315507765.issue1521@psf.upfronthosting.co.za> Amaury Forgeot d'Arc added the comment: I don't have any 64bit machine to test with, but it seems to me that there is a problem in the function getargs.c::convertsimple(): the t# and w# formats use the buffer interface, but the code uses an int to store its length! Look for the variables declared as "int count;". I suggest to replace it with a Py_ssize_t in both places. Shouldn't the compiler emit some warning in this case? ---------- nosy: +amaury.forgeotdarc __________________________________ Tracker __________________________________ From report at bugs.python.org Thu Nov 29 18:15:12 2007 From: report at bugs.python.org (Jack Lloyd) Date: Thu, 29 Nov 2007 17:15:12 -0000 Subject: [issue1523] xdrlib fails to detect overflow (struct bug?) Message-ID: <1196356512.02.0.767950905039.issue1523@psf.upfronthosting.co.za> New submission from Jack Lloyd: The XDR format requires integers to fit into 4 byte values. However (at least on x86-64) xdrlib will silently accept (and truncate) values larger than this (up to 2**64-1). Taking a (very brief) look at the xdrlib code, it appears this is actually a problem in the struct module, but I don't have the time (or interest) to trace through the _struct module code. An example on an x86-64 machine (Python 2.4.3) of encoding 2**32 (which will not fit in an XDR field) being silently truncated: $ ./xdr.py 4294967296 -> 00000000 -> 0 An example of struct itself not detecting overflow: >>> struct.pack("!I", 2**32) '\x00\x00\x00\x00' struct.pack will only throw an overflow error if a value >= 2**64 is used, even if it is encoding into a field that is much smaller. ---------- components: Extension Modules files: xdr.py messages: 57939 nosy: lloyd severity: normal status: open title: xdrlib fails to detect overflow (struct bug?) type: behavior versions: Python 2.4 Added file: http://bugs.python.org/file8825/xdr.py __________________________________ Tracker __________________________________ -------------- next part -------------- A non-text attachment was scrubbed... Name: xdr.py Type: application/octet-stream Size: 417 bytes Desc: not available Url : http://mail.python.org/pipermail/python-bugs-list/attachments/20071129/48bdbeb1/attachment.obj From report at bugs.python.org Thu Nov 29 18:22:04 2007 From: report at bugs.python.org (Guido van Rossum) Date: Thu, 29 Nov 2007 17:22:04 -0000 Subject: [issue1522] pyvm module patch In-Reply-To: <1196353654.85.0.895576631974.issue1522@psf.upfronthosting.co.za> Message-ID: Guido van Rossum added the comment: Hm... What if we just put these names in sys? __________________________________ Tracker __________________________________ From report at bugs.python.org Thu Nov 29 19:05:55 2007 From: report at bugs.python.org (Chris Mellon) Date: Thu, 29 Nov 2007 18:05:55 -0000 Subject: [issue1518] Fast globals/builtins access (patch) Message-ID: <1196359555.93.0.712715430407.issue1518@psf.upfronthosting.co.za> Chris Mellon added the comment: I may have had some old code in the build or something - I did a clean rebuild to look at some of the slowdowns and the fastglobals_test benchmarks are now even better than Neils. Pybench is still overall slower but it's mostly in float operations, which seems odd and I'd discount it unless someone else can recreate it. I've updated the spreadsheet I linked before with the updated timings, along with my microbenchmark and pystone results. Very impressive speedup on pystone, no doubt because of the heavy use of globals. __________________________________ Tracker __________________________________ From report at bugs.python.org Thu Nov 29 19:19:33 2007 From: report at bugs.python.org (Guido van Rossum) Date: Thu, 29 Nov 2007 18:19:33 -0000 Subject: [issue1517] lookdict should INCREF/DECREF startkey around PyObject_RichCompareBool Message-ID: <1196360373.38.0.711630190602.issue1517@psf.upfronthosting.co.za> Guido van Rossum added the comment: I can reproduce the segfault in 2.2 through 2.4; in 2.5 and 2.6 the output is this instead: Test 1, using __eq__(a, b).__nonzero__() this is never the right answer ***** Test 2, using tuple's tp_richcompare New Watch 0xf7f8cbac New Watch 0xf7f8cc0c Deleting Watch 0xf7f8cbac Deleting Watch 0xf7f8cbac Deleting Watch 0xf7f8cc0c Traceback (most recent call last): File "/tmp/db3.py", line 72, in print(d[(Bar(), Watch())]) TypeError: __eq__() takes exactly 1 argument (2 given) which suggests it's still there ("this is never the right answer"). In 3.0 the output from the 1st test is "this is an acceptable answer" suggesting it's no longer there; but I suspect it's there in 3.0 as well but due to the unicode transition the dict code there is different enough that the example doesn't trigger it. The key that needs to be INCREF'ed is actually startkey. Patch attached. ---------- nosy: +gvanrossum versions: +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 Added file: http://bugs.python.org/file8826/fix1517.diff __________________________________ Tracker __________________________________ -------------- next part -------------- A non-text attachment was scrubbed... Name: fix1517.diff Type: text/x-patch Size: 506 bytes Desc: not available Url : http://mail.python.org/pipermail/python-bugs-list/attachments/20071129/dcc96195/attachment-0001.bin From report at bugs.python.org Thu Nov 29 19:22:36 2007 From: report at bugs.python.org (Guido van Rossum) Date: Thu, 29 Nov 2007 18:22:36 -0000 Subject: [issue1517] lookdict should INCREF/DECREF startkey around PyObject_RichCompareBool Message-ID: <1196360556.14.0.277452079773.issue1517@psf.upfronthosting.co.za> Guido van Rossum added the comment: Oops, the same code appeared twice. The new fix fixes both places. Added file: http://bugs.python.org/file8827/fix1517.diff __________________________________ Tracker __________________________________ -------------- next part -------------- A non-text attachment was scrubbed... Name: fix1517.diff Type: text/x-patch Size: 863 bytes Desc: not available Url : http://mail.python.org/pipermail/python-bugs-list/attachments/20071129/9e459748/attachment.bin From report at bugs.python.org Thu Nov 29 19:22:41 2007 From: report at bugs.python.org (Guido van Rossum) Date: Thu, 29 Nov 2007 18:22:41 -0000 Subject: [issue1517] lookdict should INCREF/DECREF startkey around PyObject_RichCompareBool Message-ID: <1196360561.7.0.00480965332289.issue1517@psf.upfronthosting.co.za> Changes by Guido van Rossum: Removed file: http://bugs.python.org/file8826/fix1517.diff __________________________________ Tracker __________________________________ From report at bugs.python.org Thu Nov 29 19:24:01 2007 From: report at bugs.python.org (Christian Heimes) Date: Thu, 29 Nov 2007 18:24:01 -0000 Subject: [issue1517] lookdict should INCREF/DECREF startkey around PyObject_RichCompareBool In-Reply-To: <1196360373.38.0.711630190602.issue1517@psf.upfronthosting.co.za> Message-ID: <474F03BF.1020806@cheimes.de> Christian Heimes added the comment: Guido van Rossum wrote: > The key that needs to be INCREF'ed is actually startkey. Patch attached. What about the second PyObject_RichCompareBool(startkey, key, Py_EQ) a few lines below inside the for loop? Christian __________________________________ Tracker __________________________________ From report at bugs.python.org Thu Nov 29 19:26:19 2007 From: report at bugs.python.org (Guido van Rossum) Date: Thu, 29 Nov 2007 18:26:19 -0000 Subject: [issue1517] lookdict should INCREF/DECREF startkey around PyObject_RichCompareBool Message-ID: <1196360779.54.0.0722082818962.issue1517@psf.upfronthosting.co.za> Guido van Rossum added the comment: Committed revision 59222 (2.5.2). Committed revision 59223 (2.6). Thanks rhamporyncus and jorendorff!! ---------- keywords: +patch resolution: -> fixed status: open -> closed __________________________________ Tracker __________________________________ From report at bugs.python.org Thu Nov 29 19:48:18 2007 From: report at bugs.python.org (Thomas Heller) Date: Thu, 29 Nov 2007 18:48:18 -0000 Subject: [issue1506] func alloca inside ctypes lib needs #include on solaris In-Reply-To: <1196293321.21.0.637598341341.issue1506@psf.upfronthosting.co.za> Message-ID: <474F096A.5060306@ctypes.org> Thomas Heller added the comment: > Greg Couch added the comment: > > Turns out callproc.c forgot to include after > which conditionally includes alloca.h. So it's a one-line fix. > This would not work. is a file private to libffi; when Python is configured to use the system ffi-library (--with-systemffi) this file is not available. I would tend to replace the three alloca() calls in the function _CallProc() in callbacks.c with calls to malloc(). All the other occurrences of alloca() are only compiled on windows. __________________________________ Tracker __________________________________ From report at bugs.python.org Thu Nov 29 20:14:07 2007 From: report at bugs.python.org (Christian Heimes) Date: Thu, 29 Nov 2007 19:14:07 -0000 Subject: [issue1522] pyvm module patch Message-ID: <1196363647.86.0.616442780666.issue1522@psf.upfronthosting.co.za> Christian Heimes added the comment: I don't see it as an option. I'd rather keep the types in the 'types' module than to add them to the sys module. __________________________________ Tracker __________________________________ From report at bugs.python.org Thu Nov 29 20:24:38 2007 From: report at bugs.python.org (Georg Brandl) Date: Thu, 29 Nov 2007 19:24:38 -0000 Subject: [issue1522] pyvm module patch Message-ID: <1196364278.79.0.98841802512.issue1522@psf.upfronthosting.co.za> Georg Brandl added the comment: If there's a new "pyvm" module, there are a few things in sys that should be moved there, I expect. ---------- nosy: +georg.brandl __________________________________ Tracker __________________________________ From report at bugs.python.org Thu Nov 29 20:29:29 2007 From: report at bugs.python.org (Guido van Rossum) Date: Thu, 29 Nov 2007 19:29:29 -0000 Subject: [issue1522] pyvm module patch In-Reply-To: <1196363647.86.0.616442780666.issue1522@psf.upfronthosting.co.za> Message-ID: Guido van Rossum added the comment: > I don't see it as an option. I'd rather keep the types in the 'types' > module than to add them to the sys module. Why such a strong opinion? 'sys' is pretty close to the VM too... __________________________________ Tracker __________________________________ From report at bugs.python.org Thu Nov 29 20:31:47 2007 From: report at bugs.python.org (Greg Couch) Date: Thu, 29 Nov 2007 19:31:47 -0000 Subject: [issue1506] func alloca inside ctypes lib needs #include on solaris Message-ID: <1196364707.93.0.873257729806.issue1506@psf.upfronthosting.co.za> Greg Couch added the comment: That's a disappointment. has the right logic in it already. Perhaps it should be copied to callproc.c. I'm less concerned about alloca not being there at all because it seems to be a pervasive extension in non-gcc compilers, but using malloc is fine too. Please go ahead and fix this as you see fit. I've started issue 1516 about using non-gcc compilers to compile _ctypes/libffi. __________________________________ Tracker __________________________________ From report at bugs.python.org Thu Nov 29 20:46:17 2007 From: report at bugs.python.org (Greg Couch) Date: Thu, 29 Nov 2007 19:46:17 -0000 Subject: [issue1516] make _ctypes work with non-gcc compilers Message-ID: <1196365577.47.0.12148374867.issue1516@psf.upfronthosting.co.za> Greg Couch added the comment: The modications work on Tru64 and IRIX. cc has understood .s suffixes for a long time. You use cc instead of as because it knows how to run the C preprocessor (often /lib/cpp, but not on all systems). Looking at the Solaris cc manual page (via google), I see that its cc has the same .S and .s distinction that gcc has, so my patch will not work with Solaris either. IRIX has a separate issue in that it has libffi support for n32 binaries, but doesn't have the ffi_closure support, so while libffi compiles, _ctypes still fails to compile (same would be true if gcc were used). __________________________________ Tracker __________________________________ From report at bugs.python.org Thu Nov 29 21:16:57 2007 From: report at bugs.python.org (Guy Mott) Date: Thu, 29 Nov 2007 20:16:57 -0000 Subject: [issue1524] os.system() fails for commands with multiple quoted file names Message-ID: <1196367416.9.0.40290581495.issue1524@psf.upfronthosting.co.za> New submission from Guy Mott: Given a call to os.system() with a command string like this: os.system('"TheCommand" > "MyOutput"') # fails then the call fails with the following error message on the console: 'TheCommand" > "MyOutput' is not recognized as an internal or external command, operable program or batch file. Note that both the executable file name and the redirected output file name are quoted. Apparently the command string is being parsed and the first quote is incorrectly being matched with the last quote. A more general statement of this bug might say that multiple quoted fields on a command line cause os.system() to fail. I have not done enough research to better characterize the problem. By contrast, if only one of the file names is quoted then the call to os.system() succeeds. E.g., these calls succeed: os.system('TheCommand > "MyOutput"') # succeeds os.system('"TheCommand" > MyOutput') # succeeds Of course this is a simplified example where it is not necessary to quote either file name. Real world examples include 2 file names with imbedded spaces. E.g.: os.system('"The Command" > "My Output"') # fails 'The' is not recognized as an internal or external command, operable program or batch file. A further real-world example is a command line with full path specifications for both the executable file and the output file. Such path specifications may include imbedded spaces so both need to be quoted. However, quoting both causes os.system() to fail. E.g.: os.system(r'"C:\New Folder\TheCommand" > "C:\New Folder\MyOutput"') # fails 'C:\New' is not recognized as an internal or external command, operable program or batch file. The above described scenario is the situation in the attached script that includes logic for finding an executable file that may not be found on the system path but is co-located with the Python script file. Thus the script and its companion file(s) may be moved from machine to machine and will work correctly even if not in a directory that is included on the system path. The script fails because the command line that it constructs, with executable and output file specifications quoted, fails in os.system(). Here is output from running the attached script: ----------------------------------------------- C:\New Folder>buggy.py strCmdLine=["ListMetadata" > "20071129Metadata.txt"] 'ListMetadata" > "20071129Metadata.txt' is not recognized as an internal or external command, operable program or batch file. Could not find "ListMetadata" on path, looking in script directory strCmdLine=["C:\New Folder\ListMetadata" > "20071129Metadata.txt"] 'C:\New' is not recognized as an internal or external command, operable program or batch file. Traceback (most recent call last): File "C:\New Folder\buggy.py", line 16, in raise Exception("Could not locate command") Exception: Could not locate command ----------------------------------------------- Note that the command line that is constructed by the attached script runs just fine and produces the desired result if it is executed directly at a command line prompt. It is when executed via os.system() that the command line fails. Testing environment: OS = Windows XP Professional Python = 2.5 (r25:51908, Sep 19 2006, 09:52:17) [MSC v.1310 32 bit (Intel)] ---------- components: Extension Modules, Windows files: buggy.py messages: 57952 nosy: Quigon severity: major status: open title: os.system() fails for commands with multiple quoted file names type: crash versions: Python 2.5 Added file: http://bugs.python.org/file8828/buggy.py __________________________________ Tracker __________________________________ -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: buggy.py Url: http://mail.python.org/pipermail/python-bugs-list/attachments/20071129/6b47f572/attachment-0001.txt From report at bugs.python.org Thu Nov 29 21:45:27 2007 From: report at bugs.python.org (Christian Heimes) Date: Thu, 29 Nov 2007 20:45:27 -0000 Subject: [issue1522] pyvm module patch Message-ID: <1196369127.92.0.881517193378.issue1522@psf.upfronthosting.co.za> Christian Heimes added the comment: > Why such a strong opinion? 'sys' is pretty close to the VM too... sys is a very important and often used module, too. I don't like the idea to remove one module (types) and clutter an important module with its content. The list of types has grown pretty long and most of the types can't be instantiated in Python. I fear that the types are going to confuse too many people. However the types are useful for type checking and ABCs. ['PyCObject', '__doc__', '__name__', 'builtin_function', 'builtin_method', 'bytearray_iterator', 'bytes_iterator', 'callable_iterator', 'cell', 'classmethod_descriptor', 'cmpwrapper', 'code', 'dict_itemiterator', 'dict_items', 'dict_keyiterator', 'dict_keys', 'dict_valueiterator', 'dict_values', 'dictproxy', 'enumerate', 'frame', 'function', 'generator', 'getset_descriptor', 'instance_method', 'iterator', 'list_iterator', 'list_reverseiterator', 'longrange_iterator', 'member_descriptor', 'method_descriptor', 'module', 'range_iterator', 'reversed', 'set_iterator', 'sortwrapper', 'str_iterator', 'traceback', 'tuple_iterator', 'wrapper_descriptor'] Added file: http://bugs.python.org/file8829/py3k_pyvm2.patch __________________________________ Tracker __________________________________ -------------- next part -------------- A non-text attachment was scrubbed... Name: py3k_pyvm2.patch Type: text/x-diff Size: 17059 bytes Desc: not available Url : http://mail.python.org/pipermail/python-bugs-list/attachments/20071129/f120e763/attachment.patch From report at bugs.python.org Thu Nov 29 21:52:40 2007 From: report at bugs.python.org (Guido van Rossum) Date: Thu, 29 Nov 2007 20:52:40 -0000 Subject: [issue1522] pyvm module patch In-Reply-To: <1196369127.92.0.881517193378.issue1522@psf.upfronthosting.co.za> Message-ID: Guido van Rossum added the comment: > sys is a very important and often used module, too. I don't like the > idea to remove one module (types) and clutter an important module with > its content. Well, it is already pretty cluttered -- it contains many items that *I* don't recognize... :-) > The list of types has grown pretty long and most of the types can't be > instantiated in Python. I fear that the types are going to confuse too > many people. However the types are useful for type checking and ABCs. Stuff in sys that people don't use doesn't really confuse anyone IMO. I really don't think that this warrants a new module. Many of the datatype-related types (e.g. dict_keys) should not go there but in _collections anyway. __________________________________ Tracker __________________________________ From report at bugs.python.org Thu Nov 29 22:11:32 2007 From: report at bugs.python.org (Christian Heimes) Date: Thu, 29 Nov 2007 21:11:32 -0000 Subject: [issue1522] pyvm module patch In-Reply-To: Message-ID: <474F2AA6.4090800@cheimes.de> Christian Heimes added the comment: Guido van Rossum wrote: > Stuff in sys that people don't use doesn't really confuse anyone IMO. > > I really don't think that this warrants a new module. > > Many of the datatype-related types (e.g. dict_keys) should not go > there but in _collections anyway. I really think we should postpone the decision until after the next alpha. For now I like to commit the part of the patch that adds all types to the appropriate header files. A lot of internal types aren't available from other C files. Christian __________________________________ Tracker __________________________________ From report at bugs.python.org Thu Nov 29 22:16:27 2007 From: report at bugs.python.org (Brett Cannon) Date: Thu, 29 Nov 2007 21:16:27 -0000 Subject: [issue1522] pyvm module patch Message-ID: <1196370987.33.0.384072387518.issue1522@psf.upfronthosting.co.za> Brett Cannon added the comment: There has been talk in the past of cleaning up the sys module by splitting it up into a package, although I don't know how that would work for a built-in module, though. ---------- nosy: +brett.cannon __________________________________ Tracker __________________________________ From report at bugs.python.org Thu Nov 29 23:25:34 2007 From: report at bugs.python.org (Christian Heimes) Date: Thu, 29 Nov 2007 22:25:34 -0000 Subject: [issue1522] pyvm module patch Message-ID: <1196375134.17.0.0323710172425.issue1522@psf.upfronthosting.co.za> Christian Heimes added the comment: I've split the patch into two tasks. The first patch adds all types in Objects/ to the appropriate header files. I've renamed some types, too. The second patch contains the new pyvm.c module plus a modification to Modules/Setup.dist. Added file: http://bugs.python.org/file8830/py3k_add_types_to_h.patch __________________________________ Tracker __________________________________ -------------- next part -------------- A non-text attachment was scrubbed... Name: py3k_add_types_to_h.patch Type: text/x-diff Size: 13935 bytes Desc: not available Url : http://mail.python.org/pipermail/python-bugs-list/attachments/20071129/4e8b4005/attachment.patch From report at bugs.python.org Thu Nov 29 23:26:25 2007 From: report at bugs.python.org (Christian Heimes) Date: Thu, 29 Nov 2007 22:26:25 -0000 Subject: [issue1522] pyvm module patch Message-ID: <1196375185.61.0.639108157801.issue1522@psf.upfronthosting.co.za> Christian Heimes added the comment: I like to apply the py3k_add_types_to_h.patch before the next alpha and discuss the fate of pyvm after the alpha. Added file: http://bugs.python.org/file8831/py3k_pyvm3.patch __________________________________ Tracker __________________________________ -------------- next part -------------- A non-text attachment was scrubbed... Name: py3k_pyvm3.patch Type: text/x-diff Size: 3127 bytes Desc: not available Url : http://mail.python.org/pipermail/python-bugs-list/attachments/20071129/004c8dd2/attachment-0001.patch From report at bugs.python.org Thu Nov 29 23:27:15 2007 From: report at bugs.python.org (Christian Heimes) Date: Thu, 29 Nov 2007 22:27:15 -0000 Subject: [issue1522] pyvm module patch Message-ID: <1196375235.84.0.79933843566.issue1522@psf.upfronthosting.co.za> Changes by Christian Heimes: Removed file: http://bugs.python.org/file8824/py3k_pyvm.patch __________________________________ Tracker __________________________________ From report at bugs.python.org Thu Nov 29 23:27:20 2007 From: report at bugs.python.org (Christian Heimes) Date: Thu, 29 Nov 2007 22:27:20 -0000 Subject: [issue1522] pyvm module patch Message-ID: <1196375240.75.0.921828224096.issue1522@psf.upfronthosting.co.za> Changes by Christian Heimes: Removed file: http://bugs.python.org/file8829/py3k_pyvm2.patch __________________________________ Tracker __________________________________ From report at bugs.python.org Thu Nov 29 23:29:01 2007 From: report at bugs.python.org (Guido van Rossum) Date: Thu, 29 Nov 2007 22:29:01 -0000 Subject: [issue1518] Fast globals/builtins access (patch) Message-ID: <1196375341.63.0.159135070188.issue1518@psf.upfronthosting.co.za> Changes by Guido van Rossum: ---------- keywords: +patch nosy: +gvanrossum __________________________________ Tracker __________________________________ From report at bugs.python.org Thu Nov 29 23:30:21 2007 From: report at bugs.python.org (Guido van Rossum) Date: Thu, 29 Nov 2007 22:30:21 -0000 Subject: [issue1522] pyvm module patch In-Reply-To: <1196375185.61.0.639108157801.issue1522@psf.upfronthosting.co.za> Message-ID: Guido van Rossum added the comment: > I like to apply the py3k_add_types_to_h.patch before the next alpha and > discuss the fate of pyvm after the alpha. Sure, go ahead and submit the uncontroversial part. __________________________________ Tracker __________________________________ From report at bugs.python.org Thu Nov 29 23:32:51 2007 From: report at bugs.python.org (Christian Heimes) Date: Thu, 29 Nov 2007 22:32:51 -0000 Subject: [issue1524] os.system() fails for commands with multiple quoted file names Message-ID: <1196375571.43.0.483803267142.issue1524@psf.upfronthosting.co.za> Christian Heimes added the comment: I don't think that we can do anything about your problem. The user of os.system() is responsible to do the quoting himself. os.system() is just a tiny wrapper around the low level C function. We don't plan to chance the fact that os.system() doesn't handling quoting. However the subprocess module is clever enough to do the quoting for you. ---------- nosy: +tiran __________________________________ Tracker __________________________________ From report at bugs.python.org Thu Nov 29 23:36:12 2007 From: report at bugs.python.org (Christian Heimes) Date: Thu, 29 Nov 2007 22:36:12 -0000 Subject: [issue1522] pyvm module patch In-Reply-To: Message-ID: <474F3EDA.3080405@cheimes.de> Christian Heimes added the comment: Guido van Rossum wrote: > Sure, go ahead and submit the uncontroversial part. Applied py3k_add_types_to_h.patch in r59229 __________________________________ Tracker __________________________________ From report at bugs.python.org Thu Nov 29 23:56:16 2007 From: report at bugs.python.org (Amaury Forgeot d'Arc) Date: Thu, 29 Nov 2007 22:56:16 -0000 Subject: [issue1521] string.decode() fails on long strings Message-ID: <1196376976.73.0.395904051108.issue1521@psf.upfronthosting.co.za> Amaury Forgeot d'Arc added the comment: Here is a patch, with a unit test (I was surprised that test_bigmem.py already contained a test_decode function, which was left empty). But I still don't have access to any 64bit machine. Can someone try and see if the new tests in test_bigmem.py fail, and that the patch in getargs.c corrects the problem? Added file: http://bugs.python.org/file8832/getargs.patch __________________________________ Tracker __________________________________ -------------- next part -------------- A non-text attachment was scrubbed... Name: getargs.patch Type: application/octet-stream Size: 1751 bytes Desc: not available Url : http://mail.python.org/pipermail/python-bugs-list/attachments/20071129/16fe1fc5/attachment.obj From report at bugs.python.org Fri Nov 30 00:06:26 2007 From: report at bugs.python.org (Georg Brandl) Date: Thu, 29 Nov 2007 23:06:26 -0000 Subject: [issue1524] os.system() fails for commands with multiple quoted file names Message-ID: <1196377586.09.0.72316641024.issue1524@psf.upfronthosting.co.za> Georg Brandl added the comment: Are you sure that the exact command line works in a Windows shell? Python does no processing on the string, it just hands it to the platform system() function, so if MS decided that to work different from a command prompt there's nothing we can do about. ---------- nosy: +georg.brandl __________________________________ Tracker __________________________________ From report at bugs.python.org Fri Nov 30 00:22:28 2007 From: report at bugs.python.org (Heikki Toivonen) Date: Thu, 29 Nov 2007 23:22:28 -0000 Subject: [issue1443504] locale.getpreferredencoding() dies when setlocale fails Message-ID: <1196378548.81.0.954251860612.issue1443504@psf.upfronthosting.co.za> Heikki Toivonen added the comment: We noticed this too in Chandler. We worked around this issue with the patch I am attaching. Maybe not a correct fix, though. ---------- nosy: +heikki versions: +Python 2.5 Added file: http://bugs.python.org/file8833/patches-2.5.1-Linux _____________________________________ Tracker _____________________________________ -------------- next part -------------- A non-text attachment was scrubbed... Name: patches-2.5.1-Linux Type: application/octet-stream Size: 609 bytes Desc: not available Url : http://mail.python.org/pipermail/python-bugs-list/attachments/20071129/4412a060/attachment.obj From report at bugs.python.org Fri Nov 30 00:27:26 2007 From: report at bugs.python.org (Neil Toronto) Date: Thu, 29 Nov 2007 23:27:26 -0000 Subject: [issue1518] Fast globals/builtins access (patch) Message-ID: <1196378846.57.0.458134550995.issue1518@psf.upfronthosting.co.za> Neil Toronto added the comment: Christian: Thanks for that, I'll have to remember DEBUG_LEAK in the future. :) It looks like it may be acting correctly since there *is* now a fastglobals object that needs collecting, and also a new tuple built from co_names + "__builtins__". I don't know why it wouldn't collect those in the shell, though. The shell does create a new stack frame for every command (where a function's commands are all run in a single stack frame), but I don't know why that would matter. I'll look further into it. Chris: The build problems should be fixed in the next patch. Thanks for spending so much time on benchmarking this. Regarding PyEval_EvalCode creating a PyFastGlobalsObject: I'm not sure whether it's right thing to do, but I think it is. PyEval_EvalCode gets called for eval, exec, running an imported module's code, and everything in the interactive prompt - basically, running any code that's not in a function or generator. (I think that covers everything.) It seems like the patch has PyEval_EvalCode doing the right thing in general, but it may suffer a bit in benchmarks. __________________________________ Tracker __________________________________ From report at bugs.python.org Fri Nov 30 00:36:30 2007 From: report at bugs.python.org (Amaury Forgeot d'Arc) Date: Thu, 29 Nov 2007 23:36:30 -0000 Subject: [issue1402] Interpreter cleanup: order of _PyGILState_Fini and PyInterpreterState_Clear Message-ID: <1196379389.99.0.63534654372.issue1402@psf.upfronthosting.co.za> Amaury Forgeot d'Arc added the comment: Committed revision 59231 in trunk. ---------- resolution: -> fixed status: open -> closed __________________________________ Tracker __________________________________ From report at bugs.python.org Fri Nov 30 01:35:54 2007 From: report at bugs.python.org (Guy Mott) Date: Fri, 30 Nov 2007 00:35:54 -0000 Subject: [issue1524] os.system() fails for commands with multiple quoted file names Message-ID: <1196382954.11.0.811496262727.issue1524@psf.upfronthosting.co.za> Guy Mott added the comment: > Are you sure that the exact command line works in a Windows shell? Yes, I tried running the exact same command line in a Windows shell and it worked fine. Note that the buggy.py script echoes the command line and then immediately calls os.system with it. E.g.: print "strCmdLine=[%s]" % strCmdLine nRtn = os.system(strCmdLine) I tried running the script in a shell window, watched it fail, then immediately cut and pasted the command line that had been echoed out by the script to the command line prompt in the same shell, ran it and it succeeded. __________________________________ Tracker __________________________________ From report at bugs.python.org Fri Nov 30 07:47:48 2007 From: report at bugs.python.org (Georg Brandl) Date: Fri, 30 Nov 2007 06:47:48 -0000 Subject: [issue1269] Exception in pstats print_callers() Message-ID: <1196405268.61.0.493076521943.issue1269@psf.upfronthosting.co.za> Changes by Georg Brandl: ---------- assignee: -> georg.brandl nosy: +georg.brandl __________________________________ Tracker __________________________________ From report at bugs.python.org Fri Nov 30 07:50:48 2007 From: report at bugs.python.org (Georg Brandl) Date: Fri, 30 Nov 2007 06:50:48 -0000 Subject: [issue1705362] cannot change cursor color in IDLE Message-ID: <1196405448.07.0.625902892041.issue1705362@psf.upfronthosting.co.za> Changes by Georg Brandl: ---------- resolution: -> fixed status: open -> closed superseder: -> IDLE - cursor color configuration bug _____________________________________ Tracker _____________________________________ From report at bugs.python.org Fri Nov 30 07:52:09 2007 From: report at bugs.python.org (Georg Brandl) Date: Fri, 30 Nov 2007 06:52:09 -0000 Subject: [issue1774369] Unify __builtins__ -> __builtin__ Message-ID: <1196405529.76.0.693694605883.issue1774369@psf.upfronthosting.co.za> Changes by Georg Brandl: ---------- superseder: -> Rename __builtins__ to __root_namespace__? _____________________________________ Tracker _____________________________________ From report at bugs.python.org Fri Nov 30 08:57:07 2007 From: report at bugs.python.org (Brett Cannon) Date: Fri, 30 Nov 2007 07:57:07 -0000 Subject: [issue1631171] implement warnings module in C Message-ID: <1196409427.0.0.769312490478.issue1631171@psf.upfronthosting.co.za> Brett Cannon added the comment: I see two ways of implementing the fetching of a source code line from __loader__.get_source(). One is to do it in Python. We have a function provided that can suppress the second line of output from a warning and just handle it in Python code. That has the requirement that Python code be available to import, but if you are using Lib/warnings.py instead of Python/_warnings.c that is pretty much guaranteed. The other option is to rely on the fact that get_source() is supposed to use universal newlines. Then we can find the index of the x and x-1 newlines and print the substring between the two. That can be done in C code by checking for the loader, checking for get_source(), calling it, getting the char buffer, and then just looping through looking for the needed newlines to find the needed indexes. Otherwise we can use the Python API on strings to do what would have been done in pure Python, but that is a lot of PyObject_Call() usage and seems overly inefficient if one bothers with coding it in C. =) _____________________________________ Tracker _____________________________________ From report at bugs.python.org Fri Nov 30 10:36:05 2007 From: report at bugs.python.org (Andreas Eisele) Date: Fri, 30 Nov 2007 09:36:05 -0000 Subject: [issue1521] string.decode() fails on long strings Message-ID: <1196415365.57.0.0174897297606.issue1521@psf.upfronthosting.co.za> Andreas Eisele added the comment: Thanks a lot for the patch, which indeed seems to solve the issue. Alas, the extended test code still does not catch the problem, at least in my installation. Someone with a better understanding of how these tests work and with access to a 64bit machine should still have a look. __________________________________ Tracker __________________________________ From report at bugs.python.org Fri Nov 30 10:58:56 2007 From: report at bugs.python.org (Amaury Forgeot d'Arc) Date: Fri, 30 Nov 2007 09:58:56 -0000 Subject: [issue1521] string.decode() fails on long strings Message-ID: <1196416736.27.0.0997163182274.issue1521@psf.upfronthosting.co.za> Amaury Forgeot d'Arc added the comment: > Alas, the extended test code still does not catch the problem Can you please try again by changing in the tests: minsize=_2G into minsize=_2G * 2 + 2 The length has to be greater than 4G for an int to loose digits. __________________________________ Tracker __________________________________ From report at bugs.python.org Fri Nov 30 11:00:44 2007 From: report at bugs.python.org (canhuth) Date: Fri, 30 Nov 2007 10:00:44 -0000 Subject: [issue1525] Executing Python script using subprocess.Popen twice interactively fails without error the second time Message-ID: <1196416844.07.0.705173497041.issue1525@psf.upfronthosting.co.za> New submission from canhuth: Executing script using subprocess.Popen twice interactively fails without error the second time. File a.py: print "start" import subprocess print "first call" process = subprocess.Popen( args = "cmd.exe /c echo 1", stdout = subprocess.PIPE) for line in process.stdout: if not line: break; print line; print "second call" process = subprocess.Popen( args = "cmd.exe /c echo 2", stdout = subprocess.PIPE) for line in process.stdout: if not line: break; print line; print "end" Executing it in Python on Windows, interactively: 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 a start first call 1 second call 2 end >>> import a >>> ---------- components: Windows messages: 57971 nosy: canhuth severity: normal status: open title: Executing Python script using subprocess.Popen twice interactively fails without error the second time type: behavior versions: Python 2.5 __________________________________ Tracker __________________________________ From report at bugs.python.org Fri Nov 30 11:21:01 2007 From: report at bugs.python.org (Andreas Eisele) Date: Fri, 30 Nov 2007 10:21:01 -0000 Subject: [issue1521] string.decode() fails on long strings Message-ID: <1196418061.15.0.698234352054.issue1521@psf.upfronthosting.co.za> Andreas Eisele added the comment: Tried @bigmemtest(minsize=_2G*2+2, memuse=3) but no change; the test is done only once with a small size (5147). Apparently something does not work as expected here. I'm trying this with 2.6 (Revision 59231). __________________________________ Tracker __________________________________ From report at bugs.python.org Fri Nov 30 12:00:03 2007 From: report at bugs.python.org (Amaury Forgeot d'Arc) Date: Fri, 30 Nov 2007 11:00:03 -0000 Subject: [issue1521] string.decode() fails on long strings Message-ID: <1196420403.38.0.0152629624443.issue1521@psf.upfronthosting.co.za> Amaury Forgeot d'Arc added the comment: > the test is done only once with a small size (5147) How do you run the test? Do you specify a maximum available size? If you run test_bigmem.py directly, try to run it with an additional argument like this: ./test_bigmem.py 7G If you run regrtest.py, you should add an option like "-M 7G". (assuming you have enough RAM...) __________________________________ Tracker __________________________________ From report at bugs.python.org Fri Nov 30 12:11:09 2007 From: report at bugs.python.org (Amaury Forgeot d'Arc) Date: Fri, 30 Nov 2007 11:11:09 -0000 Subject: [issue1525] Executing Python script using subprocess.Popen twice interactively fails without error the second time Message-ID: <1196421069.8.0.927643507471.issue1525@psf.upfronthosting.co.za> Amaury Forgeot d'Arc added the comment: Top-level statements are executed only the first time the module is imported: http://docs.python.org/tut/node8.html#moreModules To execute a script from python, you should consider the execfile() function instead. ---------- nosy: +amaury.forgeotdarc resolution: -> invalid status: open -> closed __________________________________ Tracker __________________________________ From report at bugs.python.org Fri Nov 30 12:28:46 2007 From: report at bugs.python.org (Christian Heimes) Date: Fri, 30 Nov 2007 11:28:46 -0000 Subject: [issue1514] missing constants in socket module Message-ID: <1196422126.69.0.0407731170046.issue1514@psf.upfronthosting.co.za> Christian Heimes added the comment: On my Linux box (Ubuntu 7.10, i386, 2.6.22) the TCP_* constants are also missing. This patch solves the bug. Index: Modules/socketmodule.h =================================================================== --- Modules/socketmodule.h (revision 59228) +++ Modules/socketmodule.h (working copy) @@ -8,9 +8,7 @@ # include # endif # include -# if defined(__CYGWIN__) || (defined(PYOS_OS2) && defined(PYCC_VACPP)) -# include -# endif +# include #else /* MS_WINDOWS */ #if _MSC_VER >= 1300 ---------- assignee: -> lemburg components: +Extension Modules -Library (Lib), Macintosh keywords: +patch, py3k nosy: +lemburg, tiran priority: -> normal __________________________________ Tracker __________________________________ From report at bugs.python.org Fri Nov 30 12:29:39 2007 From: report at bugs.python.org (canhuth) Date: Fri, 30 Nov 2007 11:29:39 -0000 Subject: [issue1525] Executing Python script using subprocess.Popen twice interactively fails without error the second time Message-ID: <1196422179.1.0.2941935516.issue1525@psf.upfronthosting.co.za> canhuth added the comment: Bah, silly me, I apologize, and thank you for the quick feedback. __________________________________ Tracker __________________________________ From report at bugs.python.org Fri Nov 30 12:31:27 2007 From: report at bugs.python.org (Christian Heimes) Date: Fri, 30 Nov 2007 11:31:27 -0000 Subject: [issue1514] missing constants in socket module Message-ID: <1196422287.68.0.798865269853.issue1514@psf.upfronthosting.co.za> Christian Heimes added the comment: I've added Lemburg, L?wis and Skip to the nosy list. svn ann shows their names frequently. ---------- nosy: +loewis, skip.montanaro __________________________________ Tracker __________________________________ From report at bugs.python.org Fri Nov 30 12:49:52 2007 From: report at bugs.python.org (Marc-Andre Lemburg) Date: Fri, 30 Nov 2007 11:49:52 -0000 Subject: [issue1514] missing constants in socket module Message-ID: <1196423392.31.0.423634329049.issue1514@psf.upfronthosting.co.za> Marc-Andre Lemburg added the comment: While the patch looks right (can't say for sure whether netinet/tcp.h is always available), I think the approach itself of adding these constants to the socket module is wrong. Instead of adding these constants to the socket module, they should go into a new TCP.py module and get generated by the h2py script much like IN.py is already for each platform. __________________________________ Tracker __________________________________ From report at bugs.python.org Fri Nov 30 14:26:20 2007 From: report at bugs.python.org (Alexander Belchenko) Date: Fri, 30 Nov 2007 13:26:20 -0000 Subject: [issue1526] DeprecationWarning in zipfile.py while zipping 113000 files Message-ID: <1196429180.06.0.658057999985.issue1526@psf.upfronthosting.co.za> Changes by Alexander Belchenko: ---------- nosy: bialix severity: normal status: open title: DeprecationWarning in zipfile.py while zipping 113000 files type: behavior versions: Python 2.5 __________________________________ Tracker __________________________________ From report at bugs.python.org Fri Nov 30 14:26:57 2007 From: report at bugs.python.org (Alexander Belchenko) Date: Fri, 30 Nov 2007 13:26:57 -0000 Subject: [issue1526] DeprecationWarning in zipfile.py while zipping 113000 files Message-ID: <1196429217.61.0.167287216759.issue1526@psf.upfronthosting.co.za> New submission from Alexander Belchenko: C:\Python\2.5.1\lib\zipfile.py:719: DeprecationWarning: 'H' format requires 0 <= number <= 65535 0, 0, count, count, pos2 - pos1, pos1, 0) ---------- components: +Library (Lib) __________________________________ Tracker __________________________________ From report at bugs.python.org Fri Nov 30 14:43:22 2007 From: report at bugs.python.org (Christian Heimes) Date: Fri, 30 Nov 2007 13:43:22 -0000 Subject: [issue1109] Warning required when calling register() on an ABCMeta subclass Message-ID: <1196430202.43.0.311695577054.issue1109@psf.upfronthosting.co.za> Christian Heimes added the comment: Are you fine with the error message or do you have a better one? Index: Lib/abc.py =================================================================== --- Lib/abc.py (Revision 59228) +++ Lib/abc.py (Arbeitskopie) @@ -137,8 +137,12 @@ cls._abc_negative_cache_version = ABCMeta._abc_invalidation_counter return cls - def register(cls, subclass): + def register(cls, subclass=None): """Register a virtual subclass of an ABC.""" + if subclass is None: + raise TypeError("register() cannot be called on an ABCMeta " + "subclass. Maybe you forgot the metaclass keyword argument " + "when declaring the class?") if not isinstance(cls, type): raise TypeError("Can only register classes") if issubclass(subclass, cls): ---------- components: +Library (Lib) -Interpreter Core keywords: +patch, py3k nosy: +tiran __________________________________ Tracker __________________________________ From report at bugs.python.org Fri Nov 30 14:56:06 2007 From: report at bugs.python.org (Georg Brandl) Date: Fri, 30 Nov 2007 13:56:06 -0000 Subject: [issue467924] Improve the ZipFile Interface Message-ID: <1196430966.4.0.53184248403.issue467924@psf.upfronthosting.co.za> Georg Brandl added the comment: Alan's patch has since been committed. Is there any more work on this item? ---------- nosy: +georg.brandl ____________________________________ Tracker ____________________________________ From report at bugs.python.org Fri Nov 30 14:57:13 2007 From: report at bugs.python.org (Georg Brandl) Date: Fri, 30 Nov 2007 13:57:13 -0000 Subject: [issue469773] Write 'Using Python on Platform X' documents Message-ID: <1196431033.51.0.880190234292.issue469773@psf.upfronthosting.co.za> Georg Brandl added the comment: This will hopefully be done in GHOP. ---------- assignee: -> georg.brandl status: open -> pending ____________________________________ Tracker ____________________________________ From report at bugs.python.org Fri Nov 30 15:33:35 2007 From: report at bugs.python.org (Christian Heimes) Date: Fri, 30 Nov 2007 14:33:35 -0000 Subject: [issue1109] Warning required when calling register() on an ABCMeta subclass Message-ID: <1196433215.68.0.539189590917.issue1109@psf.upfronthosting.co.za> Christian Heimes added the comment: Fixed in r59233. Please adjust the error message if you don't like it. TypeError: register() cannot be called on an ABCMeta subclass, use class Example(metaclass=abc.ABCMeta) instead. ---------- resolution: -> fixed status: open -> closed __________________________________ Tracker __________________________________ From report at bugs.python.org Fri Nov 30 16:02:57 2007 From: report at bugs.python.org (Christian Heimes) Date: Fri, 30 Nov 2007 15:02:57 -0000 Subject: [issue1138] Fixer needed for __future__ imports Message-ID: <1196434977.37.0.541526599231.issue1138@psf.upfronthosting.co.za> Christian Heimes added the comment: Fixed in r59235 It was easier to add a new fixer for the problem. ---------- nosy: +tiran resolution: -> fixed status: open -> closed __________________________________ Tracker __________________________________ From report at bugs.python.org Fri Nov 30 16:07:49 2007 From: report at bugs.python.org (Guido van Rossum) Date: Fri, 30 Nov 2007 15:07:49 -0000 Subject: [issue1109] Warning required when calling register() on an ABCMeta subclass Message-ID: <1196435269.0.0.229137508895.issue1109@psf.upfronthosting.co.za> Guido van Rossum added the comment: Please roll this back. The error message you added is inappropriate when the parameter to a legitimate register() call is omitted, e.g. collections.Sequence.register() Since we got rid of unbound methods, the infinite recursion is gone; that's a good enough fix, there are tons of other situations where confusion between class and instance (or between metaclass and class) causes confusing error messages. ---------- assignee: gvanrossum -> tiran status: closed -> open __________________________________ Tracker __________________________________ From report at bugs.python.org Fri Nov 30 16:29:49 2007 From: report at bugs.python.org (Mark Summerfield) Date: Fri, 30 Nov 2007 15:29:49 -0000 Subject: [issue1109] Warning required when calling register() on an ABCMeta subclass In-Reply-To: <1196433215.68.0.539189590917.issue1109@psf.upfronthosting.co.za> Message-ID: <200711301528.04727.mark@qtrac.eu> Mark Summerfield added the comment: On 2007-11-30, Christian Heimes wrote: > Christian Heimes added the comment: > > Fixed in r59233. Please adjust the error message if you don't like it. > > TypeError: register() cannot be called on an ABCMeta subclass, use class > Example(metaclass=abc.ABCMeta) instead. I think it is fine---but seems that GvR doesn't want it! __________________________________ Tracker __________________________________ From report at bugs.python.org Fri Nov 30 16:32:52 2007 From: report at bugs.python.org (Christian Heimes) Date: Fri, 30 Nov 2007 15:32:52 -0000 Subject: [issue1109] Warning required when calling register() on an ABCMeta subclass Message-ID: <1196436772.9.0.227301862724.issue1109@psf.upfronthosting.co.za> Christian Heimes added the comment: I've reverted the changes. ---------- status: open -> closed __________________________________ Tracker __________________________________ From report at bugs.python.org Fri Nov 30 16:53:26 2007 From: report at bugs.python.org (billiejoex) Date: Fri, 30 Nov 2007 15:53:26 -0000 Subject: [issue1519] async_chat.__init__() parameters Message-ID: <1196438006.04.0.139182209618.issue1519@psf.upfronthosting.co.za> billiejoex added the comment: +1. Another inconsistency are the argument names used in __init__ methods, one called "sock" and the other called "conn": asyncore: def __init__(self, sock=None, map=None): asynchat: def __init__ (self, conn=None): ---------- nosy: +billiejoex __________________________________ Tracker __________________________________ From report at bugs.python.org Fri Nov 30 17:06:13 2007 From: report at bugs.python.org (Nadeem Vawda) Date: Fri, 30 Nov 2007 16:06:13 -0000 Subject: [issue1519] async_chat.__init__() parameters Message-ID: <1196438773.87.0.864522201587.issue1519@psf.upfronthosting.co.za> Nadeem Vawda added the comment: Thanks for pointing that out; I've uploaded a second patch that changes async_chat.__init__() to use 'sock' instead of 'conn'. This change shouldn't affect anything either, since the argument is simply passed to asyncore.dispatcher.__init__(). Added file: http://bugs.python.org/file8834/asynchat.2.patch __________________________________ Tracker __________________________________ -------------- next part -------------- A non-text attachment was scrubbed... Name: asynchat.2.patch Type: text/x-patch Size: 666 bytes Desc: not available Url : http://mail.python.org/pipermail/python-bugs-list/attachments/20071130/8b32ca07/attachment.bin From report at bugs.python.org Fri Nov 30 17:21:47 2007 From: report at bugs.python.org (Alan McIntyre) Date: Fri, 30 Nov 2007 16:21:47 -0000 Subject: [issue467924] Improve the ZipFile Interface Message-ID: <1196439707.32.0.86184182485.issue467924@psf.upfronthosting.co.za> Alan McIntyre added the comment: There was another issue that also asked for an extract feature, and if I recall correctly I said I'd try to work on it (I think I have some code somewhere for it but I'll have to look). Tonight or tomorrow I will see if I can find that other issue and let you know about it, and maybe take a look around at the various zipfile improvement/change requests to see if they've been completely addressed. ____________________________________ Tracker ____________________________________ From report at bugs.python.org Fri Nov 30 18:12:28 2007 From: report at bugs.python.org (Christian Heimes) Date: Fri, 30 Nov 2007 17:12:28 -0000 Subject: [issue1527] Problem with static libs on Windows Message-ID: <1196442748.41.0.438893728508.issue1527@psf.upfronthosting.co.za> New submission from Christian Heimes: patrickkidd (IRC nick) has reported a problem with creating a static libraries on Windows. He suggested the appended patch. ---------- assignee: loewis components: Windows files: trunk_staticlib.patch keywords: patch, py3k messages: 57991 nosy: loewis, tiran severity: normal status: open title: Problem with static libs on Windows versions: Python 2.6, Python 3.0 Added file: http://bugs.python.org/file8835/trunk_staticlib.patch __________________________________ Tracker __________________________________ -------------- next part -------------- A non-text attachment was scrubbed... Name: trunk_staticlib.patch Type: text/x-diff Size: 434 bytes Desc: not available Url : http://mail.python.org/pipermail/python-bugs-list/attachments/20071130/a813e5ea/attachment.patch From report at bugs.python.org Fri Nov 30 18:33:23 2007 From: report at bugs.python.org (Guido van Rossum) Date: Fri, 30 Nov 2007 17:33:23 -0000 Subject: [issue1526] DeprecationWarning in zipfile.py while zipping 113000 files Message-ID: <1196444003.24.0.796603615955.issue1526@psf.upfronthosting.co.za> Guido van Rossum added the comment: Hmm... Seems there's a 16-bit-wide field somewhere. How do other ZIP implementation deal with this? ---------- nosy: +gvanrossum __________________________________ Tracker __________________________________ From report at bugs.python.org Fri Nov 30 18:49:40 2007 From: report at bugs.python.org (Andreas Eisele) Date: Fri, 30 Nov 2007 17:49:40 -0000 Subject: [issue1521] string.decode() fails on long strings Message-ID: <1196444980.06.0.733269580298.issue1521@psf.upfronthosting.co.za> Andreas Eisele added the comment: > How do you run the test? Do you specify a maximum available size? I naively assumed that running "make test" from the toplevel would be clever about finding plausible parameters. However, it runs the bigmem tests in a minimalistic way, skipping essentially all interesting bits. Thanks for the hints on giving the maximal available size explicitly, which work in principle, but make testing rather slow. Also, if the encode/decode test are decorated with @bigmemtest(minsize=_2G*2+2, memuse=3) one needs to specify at least -M 15g, otherwise the tests are still skipped. No wonder that people do not normally run them... __________________________________ Tracker __________________________________ From report at bugs.python.org Fri Nov 30 18:56:07 2007 From: report at bugs.python.org (Amaury Forgeot d'Arc) Date: Fri, 30 Nov 2007 17:56:07 -0000 Subject: [issue1521] string.decode() fails on long strings Message-ID: <1196445367.56.0.893804583925.issue1521@psf.upfronthosting.co.za> Amaury Forgeot d'Arc added the comment: > @bigmemtest(minsize=_2G*2+2, memuse=3) minsize=_2G + 2 should trigger your second problem (where the size wraps to a negative number). Then 7G is "enough" for the test to run. __________________________________ Tracker __________________________________ From report at bugs.python.org Fri Nov 30 19:05:49 2007 From: report at bugs.python.org (Andreas Eisele) Date: Fri, 30 Nov 2007 18:05:49 -0000 Subject: [issue1521] string.decode() fails on long strings Message-ID: <1196445949.8.0.488197676149.issue1521@psf.upfronthosting.co.za> Andreas Eisele added the comment: > Then 7G is "enough" for the test to run. yes, indeed, thanks for pointing this out. It runs and detects an ERROR, and after applying your patch it succeeds. What else needs to be done to make sure your patch finds it's way to the Python core? __________________________________ Tracker __________________________________ From report at bugs.python.org Fri Nov 30 19:15:50 2007 From: report at bugs.python.org (Amaury Forgeot d'Arc) Date: Fri, 30 Nov 2007 18:15:50 -0000 Subject: [issue1521] string.decode() fails on long strings Message-ID: <1196446550.74.0.470442445966.issue1521@psf.upfronthosting.co.za> Amaury Forgeot d'Arc added the comment: > What else needs to be done to make sure your patch finds it's way > to the Python core? Nothing I suppose. It appears like an inconsistency in the source code, and it happens to correct a real problem. I will commit it in a few hours. __________________________________ Tracker __________________________________ From report at bugs.python.org Fri Nov 30 20:17:35 2007 From: report at bugs.python.org (Guido van Rossum) Date: Fri, 30 Nov 2007 19:17:35 -0000 Subject: [issue1528] Add os.fchmod Message-ID: <1196450255.5.0.78965588115.issue1528@psf.upfronthosting.co.za> New submission from Guido van Rossum: Modern Unix systems have a fchmod() system call, which is like chmod() but takes a file descriptor instead of a filename. Python's os module (via the posix module) should support this if it exists on the target platform. ---------- messages: 57997 nosy: gvanrossum severity: normal status: open title: Add os.fchmod versions: Python 2.6, Python 3.0 __________________________________ Tracker __________________________________ From report at bugs.python.org Fri Nov 30 20:17:50 2007 From: report at bugs.python.org (Guido van Rossum) Date: Fri, 30 Nov 2007 19:17:50 -0000 Subject: [issue1528] Add os.fchmod Message-ID: <1196450270.13.0.404385611018.issue1528@psf.upfronthosting.co.za> Changes by Guido van Rossum: ---------- priority: -> normal __________________________________ Tracker __________________________________ From report at bugs.python.org Fri Nov 30 20:19:21 2007 From: report at bugs.python.org (Guido van Rossum) Date: Fri, 30 Nov 2007 19:19:21 -0000 Subject: [issue1504] Add 2to3 fixer for (un)bound methods Message-ID: <1196450361.18.0.00304236110714.issue1504@psf.upfronthosting.co.za> Guido van Rossum added the comment: Does this still need to remain open? ---------- priority: -> normal __________________________________ Tracker __________________________________ From report at bugs.python.org Fri Nov 30 20:20:26 2007 From: report at bugs.python.org (Guido van Rossum) Date: Fri, 30 Nov 2007 19:20:26 -0000 Subject: [issue1520] 'without make' documentation build anomaly Message-ID: <1196450426.82.0.219878504998.issue1520@psf.upfronthosting.co.za> Changes by Guido van Rossum: ---------- assignee: -> georg.brandl nosy: +georg.brandl priority: -> low __________________________________ Tracker __________________________________ From report at bugs.python.org Fri Nov 30 20:21:59 2007 From: report at bugs.python.org (Guido van Rossum) Date: Fri, 30 Nov 2007 19:21:59 -0000 Subject: [issue1527] Problem with static libs on Windows Message-ID: <1196450519.59.0.775552789192.issue1527@psf.upfronthosting.co.za> Changes by Guido van Rossum: ---------- priority: -> low __________________________________ Tracker __________________________________ From report at bugs.python.org Fri Nov 30 20:27:13 2007 From: report at bugs.python.org (Guido van Rossum) Date: Fri, 30 Nov 2007 19:27:13 -0000 Subject: [issue1414] Fix for refleak tests Message-ID: <1196450833.66.0.528923259283.issue1414@psf.upfronthosting.co.za> Guido van Rossum added the comment: ping? __________________________________ Tracker __________________________________ From report at bugs.python.org Fri Nov 30 20:29:13 2007 From: report at bugs.python.org (Guido van Rossum) Date: Fri, 30 Nov 2007 19:29:13 -0000 Subject: [issue1497] Patch to remove API to create new unbound methods Message-ID: <1196450953.29.0.469794404359.issue1497@psf.upfronthosting.co.za> Guido van Rossum added the comment: Reducing priority and changing assignee since this is now just waiting for a doc update. ---------- assignee: gvanrossum -> tiran priority: high -> low __________________________________ Tracker __________________________________ From report at bugs.python.org Fri Nov 30 20:39:18 2007 From: report at bugs.python.org (Guido van Rossum) Date: Fri, 30 Nov 2007 19:39:18 -0000 Subject: [issue1487] PEP 366 implementation Message-ID: <1196451558.88.0.91938224001.issue1487@psf.upfronthosting.co.za> Changes by Guido van Rossum: ---------- assignee: -> gvanrossum nosy: +gvanrossum __________________________________ Tracker __________________________________ From report at bugs.python.org Fri Nov 30 21:23:29 2007 From: report at bugs.python.org (Christian Heimes) Date: Fri, 30 Nov 2007 20:23:29 -0000 Subject: [issue1504] Add 2to3 fixer for (un)bound methods Message-ID: <1196454209.34.0.587982775237.issue1504@psf.upfronthosting.co.za> Christian Heimes added the comment: Some cases aren't covered by the fixer. I'm not sure if we need fixers for two cases: Python 2.x: Cls.method = types.MethodType(function, None, Cls) Python 3.0: Cls.method = function Python 2.x: instance.method = types.MethodType(function, instance, instance.__class__) Python 3.0: instance.method = types.MethodType(function, instance) __________________________________ Tracker __________________________________ From report at bugs.python.org Fri Nov 30 21:34:19 2007 From: report at bugs.python.org (Georg Brandl) Date: Fri, 30 Nov 2007 20:34:19 -0000 Subject: [issue1528] Add os.fchmod Message-ID: <1196454859.63.0.798891329174.issue1528@psf.upfronthosting.co.za> Georg Brandl added the comment: Attached is a patch against trunk that adds fchmod() and fchown() calls where available. I hope I did the configure magic correctly. ---------- nosy: +georg.brandl Added file: http://bugs.python.org/file8836/fchmod-fchown.diff __________________________________ Tracker __________________________________ -------------- next part -------------- A non-text attachment was scrubbed... Name: fchmod-fchown.diff Type: application/pgp-signature Size: 4949 bytes Desc: not available Url : http://mail.python.org/pipermail/python-bugs-list/attachments/20071130/c76592a3/attachment.pgp From report at bugs.python.org Fri Nov 30 21:39:11 2007 From: report at bugs.python.org (Guido van Rossum) Date: Fri, 30 Nov 2007 20:39:11 -0000 Subject: [issue1487] PEP 366 implementation Message-ID: <1196455151.89.0.313857305752.issue1487@psf.upfronthosting.co.za> Guido van Rossum added the comment: I think the implementation is fine too (others will have to check it more carefully) but I noticed that the promised functionality of -m doesn't work yet: I created a file Lib/test/foo.py whose sole contents was "from . import test_support". Then I tried to import this using -m: $ ./python.exe -m test.foo Traceback (most recent call last): File "/Users/guido/p/Lib/runpy.py", line 104, in _run_module_as_main "__main__", fname, loader) File "/Users/guido/p/Lib/runpy.py", line 34, in _run_code exec code in run_globals File "/Users/guido/p/Lib/test/foo.py", line 1, in from . import test_support ValueError: Attempted relative import in non-package $ What's missing here? ---------- assignee: gvanrossum -> ncoghlan resolution: -> accepted __________________________________ Tracker __________________________________ From report at bugs.python.org Fri Nov 30 21:40:05 2007 From: report at bugs.python.org (Christian Heimes) Date: Fri, 30 Nov 2007 20:40:05 -0000 Subject: [issue1528] Add os.fchmod Message-ID: <1196455205.58.0.385226860071.issue1528@psf.upfronthosting.co.za> Christian Heimes added the comment: I'm adding lchmod, too. ---------- nosy: +tiran __________________________________ Tracker __________________________________ From report at bugs.python.org Fri Nov 30 21:44:29 2007 From: report at bugs.python.org (Guido van Rossum) Date: Fri, 30 Nov 2007 20:44:29 -0000 Subject: [issue1504] Add 2to3 fixer for (un)bound methods In-Reply-To: <1196454209.34.0.587982775237.issue1504@psf.upfronthosting.co.za> Message-ID: Guido van Rossum added the comment: Aren't there equivalent ways to spell those with the "new" module? How about a fixer for that code (which may be easier to write)? __________________________________ Tracker __________________________________ From report at bugs.python.org Fri Nov 30 21:48:47 2007 From: report at bugs.python.org (Guido van Rossum) Date: Fri, 30 Nov 2007 20:48:47 -0000 Subject: [issue1528] Add os.fchmod Message-ID: <1196455727.53.0.0184410228929.issue1528@psf.upfronthosting.co.za> Guido van Rossum added the comment: Just check these into the trunk, guys! Great! __________________________________ Tracker __________________________________ From report at bugs.python.org Fri Nov 30 21:50:13 2007 From: report at bugs.python.org (Chris AtLee) Date: Fri, 30 Nov 2007 20:50:13 -0000 Subject: [issue1673409] datetime module missing some important methods Message-ID: <1196455813.18.0.221248141219.issue1673409@psf.upfronthosting.co.za> Chris AtLee added the comment: I keep needing to know the number of seconds that a timedelta represents, so I implemented the following patch. This returns only the integer portion, but could be modified to return a floating point value. ---------- nosy: +catlee Added file: http://bugs.python.org/file8837/timedelta.diff _____________________________________ Tracker _____________________________________ -------------- next part -------------- A non-text attachment was scrubbed... Name: timedelta.diff Type: text/x-patch Size: 2426 bytes Desc: not available Url : http://mail.python.org/pipermail/python-bugs-list/attachments/20071130/0a11126d/attachment.bin From report at bugs.python.org Fri Nov 30 21:55:31 2007 From: report at bugs.python.org (Amaury Forgeot d'Arc) Date: Fri, 30 Nov 2007 20:55:31 -0000 Subject: [issue1521] string.decode() fails on long strings Message-ID: <1196456130.93.0.970333830399.issue1521@psf.upfronthosting.co.za> Amaury Forgeot d'Arc added the comment: Committed revision 59241. Will backport after the buildbots run the test. ---------- assignee: -> amaury.forgeotdarc __________________________________ Tracker __________________________________ From report at bugs.python.org Fri Nov 30 22:13:21 2007 From: report at bugs.python.org (Skip Montanaro) Date: Fri, 30 Nov 2007 21:13:21 -0000 Subject: [issue1673409] datetime module missing some important methods In-Reply-To: <1196455813.18.0.221248141219.issue1673409@psf.upfronthosting.co.za> Message-ID: <18256.31950.932849.827310@montanaro.dyndns.org> Skip Montanaro added the comment: Chris> I keep needing to know the number of seconds that a timedelta Chris> represents, so I implemented the following patch. I can sympathize, but if we accept this patch, for symmetry reasons shouldn't we also add .todays, .tomicroseconds and maybe even .toweeks? Skip _____________________________________ Tracker _____________________________________ From report at bugs.python.org Fri Nov 30 22:16:11 2007 From: report at bugs.python.org (Christian Heimes) Date: Fri, 30 Nov 2007 21:16:11 -0000 Subject: [issue1528] Add os.fchmod Message-ID: <1196457371.33.0.0822743387287.issue1528@psf.upfronthosting.co.za> Christian Heimes added the comment: I've applied the combined patch in r59242. I've tested Georg's fchmod/fchown on my Linux system. They functions are working as expected. However lchmod is not available on my system although it is in the header files. It should be available on Mac and some other flavors of Unix. __________________________________ Tracker __________________________________ From report at bugs.python.org Fri Nov 30 22:16:52 2007 From: report at bugs.python.org (George Notaras) Date: Fri, 30 Nov 2007 21:16:52 -0000 Subject: [issue1529] Error when passing a file object to tarfile.open() Message-ID: <1196457412.25.0.63807751084.issue1529@psf.upfronthosting.co.za> New submission from George Notaras: Assume a healthy uncompressed tar file: a.tar When trying to open the tarfile using a fileobject, there is always an exception: >>> f_raw = open("a.tar", "rb") >>> import tarfile >>> f_tar = tarfile.open(mode="r:", fileobj=f_raw) Traceback (most recent call last): File "", line 1, in File "/usr/lib/python2.5/tarfile.py", line 1157, in open return func(name, filemode, fileobj) File "/usr/lib/python2.5/tarfile.py", line 1183, in taropen return cls(name, mode, fileobj) File "/usr/lib/python2.5/tarfile.py", line 1047, in __init__ self.name = os.path.abspath(name) File "/usr/lib/python2.5/posixpath.py", line 402, in abspath if not isabs(path): File "/usr/lib/python2.5/posixpath.py", line 49, in isabs return s.startswith('/') AttributeError: 'NoneType' object has no attribute 'startswith' ---------- components: Extension Modules messages: 58011 nosy: GeorgeNotaras severity: normal status: open title: Error when passing a file object to tarfile.open() type: crash versions: Python 2.5 __________________________________ Tracker __________________________________ From report at bugs.python.org Fri Nov 30 22:18:36 2007 From: report at bugs.python.org (Christian Heimes) Date: Fri, 30 Nov 2007 21:18:36 -0000 Subject: [issue1504] Add 2to3 fixer for (un)bound methods Message-ID: <1196457516.43.0.850662317369.issue1504@psf.upfronthosting.co.za> Christian Heimes added the comment: The 'new' module is already gone. I've ripped it out a couple of days ago and added deprecation warnings in 2.6 __________________________________ Tracker __________________________________ From report at bugs.python.org Fri Nov 30 22:29:08 2007 From: report at bugs.python.org (Guido van Rossum) Date: Fri, 30 Nov 2007 21:29:08 -0000 Subject: [issue1504] Add 2to3 fixer for (un)bound methods In-Reply-To: <1196457516.43.0.850662317369.issue1504@psf.upfronthosting.co.za> Message-ID: Guido van Rossum added the comment: Exactly. I'm proposing that we don't bother with people who call types.MethodType(), but we *do* bother converting code that calls new.method(). __________________________________ Tracker __________________________________ From report at bugs.python.org Fri Nov 30 22:33:06 2007 From: report at bugs.python.org (Amaury Forgeot d'Arc) Date: Fri, 30 Nov 2007 21:33:06 -0000 Subject: [issue1529] Error when passing a file object to tarfile.open() Message-ID: <1196458386.12.0.204163796589.issue1529@psf.upfronthosting.co.za> Amaury Forgeot d'Arc added the comment: This problem was fixed in r57617. Can you check with a more recent build? ---------- nosy: +amaury.forgeotdarc resolution: -> works for me __________________________________ Tracker __________________________________ From report at bugs.python.org Fri Nov 30 22:33:59 2007 From: report at bugs.python.org (Christian Heimes) Date: Fri, 30 Nov 2007 21:33:59 -0000 Subject: [issue1528] Add os.fchmod Message-ID: <1196458439.89.0.602040231223.issue1528@psf.upfronthosting.co.za> Changes by Christian Heimes: ---------- resolution: -> fixed status: open -> closed __________________________________ Tracker __________________________________ From report at bugs.python.org Fri Nov 30 22:55:07 2007 From: report at bugs.python.org (Amaury Forgeot d'Arc) Date: Fri, 30 Nov 2007 21:55:07 -0000 Subject: [issue1521] string.decode() fails on long strings Message-ID: <1196459707.48.0.292890224455.issue1521@psf.upfronthosting.co.za> Amaury Forgeot d'Arc added the comment: Committed revision 59244 in release25-maint. ---------- resolution: -> fixed status: open -> closed __________________________________ Tracker __________________________________ From report at bugs.python.org Fri Nov 30 23:03:06 2007 From: report at bugs.python.org (Christian Heimes) Date: Fri, 30 Nov 2007 22:03:06 -0000 Subject: [issue1414] Fix for refleak tests Message-ID: <1196460186.3.0.639698605989.issue1414@psf.upfronthosting.co.za> Christian Heimes added the comment: I don't know how to fix the problem. You have to assign the bug to somebody who has experience with Tcl/Tk. __________________________________ Tracker __________________________________ From report at bugs.python.org Fri Nov 30 23:07:20 2007 From: report at bugs.python.org (George Notaras) Date: Fri, 30 Nov 2007 22:07:20 -0000 Subject: [issue1529] Error when passing a file object to tarfile.open() Message-ID: <1196460440.79.0.611169251454.issue1529@psf.upfronthosting.co.za> George Notaras added the comment: Indeed, I have downloaded the latest tarfile module from svn and it works as expected. I should have done this in the first place. __________________________________ Tracker __________________________________ From report at bugs.python.org Fri Nov 30 23:08:51 2007 From: report at bugs.python.org (Guido van Rossum) Date: Fri, 30 Nov 2007 22:08:51 -0000 Subject: [issue1414] Fix for refleak tests Message-ID: <1196460531.83.0.632363577538.issue1414@psf.upfronthosting.co.za> Guido van Rossum added the comment: Can you open a separate item for the Tkinter leak so you can close this one? __________________________________ Tracker __________________________________ From report at bugs.python.org Fri Nov 30 23:13:14 2007 From: report at bugs.python.org (Amaury Forgeot d'Arc) Date: Fri, 30 Nov 2007 22:13:14 -0000 Subject: [issue1529] Error when passing a file object to tarfile.open() Message-ID: <1196460794.25.0.329484309646.issue1529@psf.upfronthosting.co.za> Amaury Forgeot d'Arc added the comment: The fix is already included in the future 2.5.2 release. ---------- status: open -> closed __________________________________ Tracker __________________________________ From report at bugs.python.org Fri Nov 30 23:25:29 2007 From: report at bugs.python.org (Miki Tebeka) Date: Fri, 30 Nov 2007 22:25:29 -0000 Subject: [issue1530] doctest should return error if not all tests passed Message-ID: <1196461529.28.0.0768640953007.issue1530@psf.upfronthosting.co.za> New submission from Miki Tebeka: python -mdoctest mymodule should return an error to the OS when a test fails. See patch. ---------- components: Library (Lib) files: doctest.py.diff messages: 58020 nosy: tebeka severity: normal status: open title: doctest should return error if not all tests passed type: behavior versions: Python 2.6 Added file: http://bugs.python.org/file8838/doctest.py.diff __________________________________ Tracker __________________________________ -------------- next part -------------- A non-text attachment was scrubbed... Name: doctest.py.diff Type: text/x-patch Size: 991 bytes Desc: not available Url : http://mail.python.org/pipermail/python-bugs-list/attachments/20071130/ce8ebc64/attachment.bin From report at bugs.python.org Fri Nov 30 23:44:59 2007 From: report at bugs.python.org (Christian Heimes) Date: Fri, 30 Nov 2007 22:44:59 -0000 Subject: [issue1504] Add 2to3 fixer for (un)bound methods Message-ID: <1196462699.92.0.118593005345.issue1504@psf.upfronthosting.co.za> Christian Heimes added the comment: Whatever you say. But shouldn't we make people to use types.MethodType() or whatever we use as the new module for PyMethod_Type()? People are going to use types.MethodType() when they see the deprecation warning. By the way I've updated the docs in r59248. __________________________________ Tracker __________________________________ From report at bugs.python.org Fri Nov 30 23:47:12 2007 From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=) Date: Fri, 30 Nov 2007 22:47:12 -0000 Subject: [issue1514] missing constants in socket module Message-ID: <1196462832.51.0.081875720118.issue1514@psf.upfronthosting.co.za> Martin v. L?wis added the comment: I disagree. h2py is much too unreliable, and should be phased out over time. __________________________________ Tracker __________________________________ From report at bugs.python.org Fri Nov 30 23:51:12 2007 From: report at bugs.python.org (Guido van Rossum) Date: Fri, 30 Nov 2007 22:51:12 -0000 Subject: [issue1504] Add 2to3 fixer for (un)bound methods In-Reply-To: <1196462699.92.0.118593005345.issue1504@psf.upfronthosting.co.za> Message-ID: Guido van Rossum added the comment: > Whatever you say. But shouldn't we make people to use types.MethodType() > or whatever we use as the new module for PyMethod_Type()? People are > going to use types.MethodType() when they see the deprecation warning. Well, if new.method is deprecated, then types.MethodType should be doubly deprecated. The types module was only ever intended for type checking, not for creating new instances. The correct solution will be to use whatever we end up deciding about pyvm. Certainly the types module will go. Maybe new in 2.6 should be a -3 deprecation only? __________________________________ Tracker __________________________________ From report at bugs.python.org Fri Nov 30 23:56:10 2007 From: report at bugs.python.org (Marc-Andre Lemburg) Date: Fri, 30 Nov 2007 22:56:10 -0000 Subject: [issue1514] missing constants in socket module Message-ID: <1196463370.36.0.72282036455.issue1514@psf.upfronthosting.co.za> Marc-Andre Lemburg added the comment: If you think we need a better tool, that's a different story, but not an argument for cluttering up the socket module with a more or less complete list of C constants. It's much easier to maintain this outside the socket module in a separate, platform specific module. This also has the advantage of being able to see whether a constant is available on a specific platform or not and also provides access to platform specific constants that would otherwise not be available. BTW: Can you point me to a bug report where an h2py generated IN.py has failed to include important symbols ? __________________________________ Tracker __________________________________ From report at bugs.python.org Fri Nov 30 23:57:05 2007 From: report at bugs.python.org (Marc-Andre Lemburg) Date: Fri, 30 Nov 2007 22:57:05 -0000 Subject: [issue1514] missing constants in socket module Message-ID: <1196463425.56.0.138615478175.issue1514@psf.upfronthosting.co.za> Marc-Andre Lemburg added the comment: Doesn't this bug report also refer to Python 2.5 and 2.6 ? __________________________________ Tracker __________________________________