From report at bugs.python.org Sat Sep 1 00:05:53 2007 From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=) Date: Fri, 31 Aug 2007 22:05:53 -0000 Subject: [issue1076] py3 patch: full Unicode version for winreg module Message-ID: <1188597953.14.0.616597627343.issue1076@psf.upfronthosting.co.za> Martin v. L?wis added the comment: While I agree with the principle (use wide APIs where possible), I'd like to point out that they don't work on Windows 95 (at least some don't; if you link with MSLU, you get some more to work); that was the major reason not to use them in the past. This is no issue for Python 3000, of course, since Windows 1995 is not supported anymore. ---------- nosy: +loewis __________________________________ Tracker __________________________________ From report at bugs.python.org Sat Sep 1 00:21:02 2007 From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=) Date: Fri, 31 Aug 2007 22:21:02 -0000 Subject: [issue1073] Mysterious failure under Windows Message-ID: <1188598862.14.0.220787621274.issue1073@psf.upfronthosting.co.za> Martin v. L?wis added the comment: I don't see the problem. When open() reports that the file does not exist, the most likely reason is that it really does not exist. Perhaps it has not been created, yet, and you need to wait until it has been created before you can open it? ---------- nosy: +loewis __________________________________ Tracker __________________________________ From report at bugs.python.org Sat Sep 1 00:55:25 2007 From: report at bugs.python.org (Aki) Date: Fri, 31 Aug 2007 22:55:25 -0000 Subject: [issue1073] Mysterious failure under Windows Message-ID: <1188600925.82.0.510400834394.issue1073@psf.upfronthosting.co.za> Aki added the comment: I know it is hard to believe. I spent days to try out many things. For example, I added the following: try: print os.path.isfile(fn) <<<--- fd = open(fn, 'rb') crypted = fd.read() fd.close() idx = crypted.index('\n') except (IOError, OSError, ValueError,): raise When I run, I got following cases randomly: (1) True, Open successfully (2) True, Open failed (3) False, Open failed (4) False, Open successfully The file is a binary data file and is already sitting in the directory before the execution of the program. I know that for other people it is very difficult to work on such case. But this is something to do with threading under windows. Aki- __________________________________ Tracker __________________________________ From report at bugs.python.org Sat Sep 1 03:00:07 2007 From: report at bugs.python.org (Matthew Russell) Date: Sat, 01 Sep 2007 01:00:07 -0000 Subject: [issue1077] itertools missing, causes interactive help to break Message-ID: <1188608407.47.0.483489642185.issue1077@psf.upfronthosting.co.za> Changes by Matthew Russell: ---------- components: Interpreter Core, Library (Lib) files: py3k_bug1.txt severity: urgent status: open title: itertools missing, causes interactive help to break type: behavior versions: Python 3.0 __________________________________ Tracker __________________________________ From report at bugs.python.org Sat Sep 1 03:03:04 2007 From: report at bugs.python.org (Gabriel Genellina) Date: Sat, 01 Sep 2007 01:03:04 -0000 Subject: [issue1073] Mysterious failure under Windows Message-ID: <1188608584.24.0.734643317822.issue1073@psf.upfronthosting.co.za> Gabriel Genellina added the comment: Does the file exist before program is started, and remains after program finishes? If it is your program which creates the file, you may have a race condition. Maybe some delays/retries will be enough, or perhaps you will have to use some other syncronization mechanisms. Also, I see you use a relative path. Do you change the current directory (with os.chdir or similar)? ---------- nosy: +gagenellina __________________________________ Tracker __________________________________ From report at bugs.python.org Sat Sep 1 03:11:14 2007 From: report at bugs.python.org (Aki) Date: Sat, 01 Sep 2007 01:11:14 -0000 Subject: [issue1073] Mysterious failure under Windows Message-ID: <1188609074.34.0.935474487869.issue1073@psf.upfronthosting.co.za> Aki added the comment: Sorry to disappoint you but ... (1) Does the file exist before program is started, and remains after program finishes? Yes and Yes (2) Do you change the current directory (with os.chdir or similar)? No. The file is in the current directory where the program was invoked. // Probably, only way to settle this is to create a small test case. But I'm not sure if that is easy. (For example, this problem won't occur if no activity in the main thread.) Aki- __________________________________ Tracker __________________________________ From report at bugs.python.org Sat Sep 1 03:22:45 2007 From: report at bugs.python.org (jinok) Date: Sat, 01 Sep 2007 01:22:45 -0000 Subject: [issue1078] cachersrc.py using tuple unpacking args Message-ID: <1188609765.52.0.267937101138.issue1078@psf.upfronthosting.co.za> New submission from jinok: Mac/scripts/cachersrc.py contains tuple unpacking in handler function args definition, causing "make frameworkinstall" to complain and exit early. ---------- components: Macintosh messages: 55546 nosy: jinok severity: normal status: open title: cachersrc.py using tuple unpacking args type: compile error versions: Python 3.0 __________________________________ Tracker __________________________________ From report at bugs.python.org Sat Sep 1 03:22:45 2007 From: report at bugs.python.org (jinok) Date: Sat, 01 Sep 2007 01:22:45 -0000 Subject: [issue1078] cachersrc.py using tuple unpacking args Message-ID: <1188609765.52.0.267937101138.issue1078@psf.upfronthosting.co.za> New submission from jinok: Mac/scripts/cachersrc.py contains tuple unpacking in handler function args definition, causing "make frameworkinstall" to complain and exit early. ---------- components: Macintosh messages: 55546 nosy: jinok severity: normal status: open title: cachersrc.py using tuple unpacking args type: compile error versions: Python 3.0 __________________________________ Tracker __________________________________ From report at bugs.python.org Sat Sep 1 04:01:49 2007 From: report at bugs.python.org (Gabriel Genellina) Date: Sat, 01 Sep 2007 02:01:49 -0000 Subject: [issue1045] Performance regression in 2.5 Message-ID: <1188612109.5.0.491793802821.issue1045@psf.upfronthosting.co.za> Gabriel Genellina added the comment: I've narrowed the problem to the usage of generator expressions. Generator expressions appear to be MUCH slower on 2.5 than on 2.4. >python -m timeit "tuple([1 for _ in xrange(3)])" 2.4 -> 2.23us 2.5 -> 2.31us (a bit slower, but not so much) >python -m timeit "tuple(1 for _ in xrange(3))" 2.4 -> 3.32us 2.5 -> 8.03us (240% slower than 2.4) It appears to be a fixed cost, or startup cost, of the generator expression; differences get smaller when building large tuples (but always Python 2.5 runs slower than 2.4) ---------- components: -Library (Lib) nosy: +gagenellina __________________________________ Tracker __________________________________ From report at bugs.python.org Sat Sep 1 04:19:58 2007 From: report at bugs.python.org (Guido van Rossum) Date: Sat, 01 Sep 2007 02:19:58 -0000 Subject: [issue1067] test_smtplib failures (caused by asyncore) Message-ID: <1188613198.43.0.844570464544.issue1067@psf.upfronthosting.co.za> Guido van Rossum added the comment: (Reopening given recent discussion.) ---------- resolution: fixed -> status: closed -> open __________________________________ Tracker __________________________________ From report at bugs.python.org Sat Sep 1 04:21:35 2007 From: report at bugs.python.org (Gabriel Genellina) Date: Sat, 01 Sep 2007 02:21:35 -0000 Subject: [issue1027] uudecoding (uu.py) does not supprt base64, patch attached Message-ID: <1188613295.43.0.965776030757.issue1027@psf.upfronthosting.co.za> Gabriel Genellina added the comment: I think the 2.4 version is in maintenance mode, so no new features are added. You may target 2.5 or 2.6. But the patch is incorrect: the base64 name is undefined. You should include test cases and documentation changes also; please read http://www.python.org/dev/patches/ ---------- components: +Library (Lib) -Extension Modules nosy: +gagenellina __________________________________ Tracker __________________________________ From report at bugs.python.org Sat Sep 1 07:34:55 2007 From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=) Date: Sat, 01 Sep 2007 05:34:55 -0000 Subject: [issue1073] Mysterious failure under Windows Message-ID: <1188624895.61.0.86676578122.issue1073@psf.upfronthosting.co.za> Martin v. L?wis added the comment: I'm closing this as "works for me" now. It cannot possibly be a bug in Python, since the error was created by the operating system; Python does not make it up randomly. I also doubt that the operating system will arbitrarily report that a file is not present if the calling process uses threads. So if you can come up with a reproducible test case, please submit a new bug report. Otherwise, you are on your own figuring out what's going on. ---------- resolution: -> works for me status: open -> closed __________________________________ Tracker __________________________________ From report at bugs.python.org Sat Sep 1 08:39:30 2007 From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=) Date: Sat, 01 Sep 2007 06:39:30 -0000 Subject: =?utf-8?q?[issue1737210]_Add/Remove_programs_shows_Martin_v_L=C3=B6wis?= Message-ID: <1188628770.29.0.333307756651.issue1737210@psf.upfronthosting.co.za> Martin v. L?wis added the comment: I have now changed the string to "Python Software Foundation" in r57859, r57860, and r57861. ---------- resolution: -> fixed status: open -> closed versions: +Python 2.6, Python 3.0 _____________________________________ Tracker _____________________________________ From report at bugs.python.org Sat Sep 1 09:29:03 2007 From: report at bugs.python.org (Georg Brandl) Date: Sat, 01 Sep 2007 07:29:03 -0000 Subject: [issue1074] python3.0-config script does not run on py3k In-Reply-To: <1188589871.51.0.0440948032602.issue1074@psf.upfronthosting.co.za> Message-ID: <46D914A6.6030301@gmx.net> Georg Brandl added the comment: Koen van de Sande schrieb: > New submission from Koen van de Sande: > > The python3.0-config script, installed into the py3k bin folder, does > not run on Python 3.0a1, because of the syntax change in the "print" > statement. Possibly there are other compatibility issues. Thanks, fixed in rev. 57862. ---------- assignee: -> georg.brandl nosy: +georg.brandl resolution: -> fixed status: open -> closed __________________________________ Tracker __________________________________ From report at bugs.python.org Sat Sep 1 09:38:51 2007 From: report at bugs.python.org (Georg Brandl) Date: Sat, 01 Sep 2007 07:38:51 -0000 Subject: [issue1072] Documentaion font size too small In-Reply-To: <1188587182.95.0.769269052906.issue1072@psf.upfronthosting.co.za> Message-ID: <46D9170C.7090308@gmx.net> Georg Brandl added the comment: Bill Janssen schrieb: > Bill Janssen added the comment: > > I agree. It shouldn't be an absolute size, and it is too small. Okay, should be fixed in SVN (rev. 57864) and be live on the page in the next 12 hours. ---------- resolution: -> fixed status: open -> closed __________________________________ Tracker __________________________________ From report at bugs.python.org Sat Sep 1 09:39:40 2007 From: report at bugs.python.org (Georg Brandl) Date: Sat, 01 Sep 2007 07:39:40 -0000 Subject: [issue1072] Documentaion font size too small In-Reply-To: <1188587182.95.0.769269052906.issue1072@psf.upfronthosting.co.za> Message-ID: <46D91740.1090705@gmx.net> Georg Brandl added the comment: Bill Janssen schrieb: > Bill Janssen added the comment: > > I agree. It shouldn't be an absolute size, and it is too small. Fixed in rev. 57864, should be live on the site in the next 12 hours. __________________________________ Tracker __________________________________ From report at bugs.python.org Sat Sep 1 10:56:59 2007 From: report at bugs.python.org (=?utf-8?q?Micka=C3=ABl_Gu=C3=A9rin?=) Date: Sat, 01 Sep 2007 08:56:59 -0000 Subject: [issue1079] decode_header does not follow RFC 2047 Message-ID: <1188637019.25.0.0476259625696.issue1079@psf.upfronthosting.co.za> New submission from Micka?l Gu?rin: email.header.decode_header expect a space or end of line after the end of an encoded word ("?="). There is nothing about that thing in RFC 2047. Python 2.5.1 ChangeLog seems to indicate that this bug has been solved. Unfortunately, the function still don't work. A visible effet of the bad regex used has the consequence found in Issue 1467619 it seems there are 2 different regex with the same purpose in two different files (ecre in header.py & ecre in utils.py). the one in utils.py seems to give better results. ---------- components: Library (Lib) messages: 55555 nosy: kael severity: normal status: open title: decode_header does not follow RFC 2047 versions: Python 2.5 __________________________________ Tracker __________________________________ From report at bugs.python.org Sat Sep 1 10:56:59 2007 From: report at bugs.python.org (=?utf-8?q?Micka=C3=ABl_Gu=C3=A9rin?=) Date: Sat, 01 Sep 2007 08:56:59 -0000 Subject: [issue1079] decode_header does not follow RFC 2047 Message-ID: <1188637019.25.0.0476259625696.issue1079@psf.upfronthosting.co.za> New submission from Micka?l Gu?rin: email.header.decode_header expect a space or end of line after the end of an encoded word ("?="). There is nothing about that thing in RFC 2047. Python 2.5.1 ChangeLog seems to indicate that this bug has been solved. Unfortunately, the function still don't work. A visible effet of the bad regex used has the consequence found in Issue 1467619 it seems there are 2 different regex with the same purpose in two different files (ecre in header.py & ecre in utils.py). the one in utils.py seems to give better results. ---------- components: Library (Lib) messages: 55555 nosy: kael severity: normal status: open title: decode_header does not follow RFC 2047 versions: Python 2.5 __________________________________ Tracker __________________________________ From report at bugs.python.org Sat Sep 1 14:15:40 2007 From: report at bugs.python.org (Nir Soffer) Date: Sat, 01 Sep 2007 12:15:40 -0000 Subject: [issue1072] Documentaion font size too small Message-ID: <1188648940.29.0.349662479925.issue1072@psf.upfronthosting.co.za> Nir Soffer added the comment: The body font size is good now, but now lot of elements are too big. Here are list of issues in typical pages related to the font change: Module page: (e.g. http://docs.python.org/dev/library/bisect.html) - content headings - the bread-crumbs navigation flow to out of its div when the using narrow window or huge font in the browser - previous|next... links in the header - headings in the sidebar are huge - text in the sidebar can be smaller then the body text - copyright line - can by tiny Main page (http://docs.python.org/dev/index.html): - The main titles (e.g. What's new in ...) are huge - 100-120% should be fine. (CSS class biglink) - The links description may be smaller then the regular body text __________________________________ Tracker __________________________________ From report at bugs.python.org Sat Sep 1 14:23:58 2007 From: report at bugs.python.org (Nir Soffer) Date: Sat, 01 Sep 2007 12:23:58 -0000 Subject: [issue1080] Search broken Message-ID: <1188649438.83.0.0963732407749.issue1080@psf.upfronthosting.co.za> New submission from Nir Soffer: http://docs.python.org/dev/search.html In Safari: - does not find anything. e.g. search for print. - The sections selection do not remember the user selection. e.g. select Language Reference, search, the page comes out with Language Reference deselected. - The search term is not remembered - the search box is always empty - There are not search results In Firefox: - Search interface remember the search term and the sections selection, but the search results are always empty ---------- components: Documentation messages: 55557 nosy: nirs severity: normal status: open title: Search broken type: behavior versions: Python 2.6, Python 3.0 __________________________________ Tracker __________________________________ From report at bugs.python.org Sat Sep 1 14:23:59 2007 From: report at bugs.python.org (Nir Soffer) Date: Sat, 01 Sep 2007 12:23:59 -0000 Subject: [issue1080] Search broken Message-ID: <1188649438.83.0.0963732407749.issue1080@psf.upfronthosting.co.za> New submission from Nir Soffer: http://docs.python.org/dev/search.html In Safari: - does not find anything. e.g. search for print. - The sections selection do not remember the user selection. e.g. select Language Reference, search, the page comes out with Language Reference deselected. - The search term is not remembered - the search box is always empty - There are not search results In Firefox: - Search interface remember the search term and the sections selection, but the search results are always empty ---------- components: Documentation messages: 55557 nosy: nirs severity: normal status: open title: Search broken type: behavior versions: Python 2.6, Python 3.0 __________________________________ Tracker __________________________________ From report at bugs.python.org Sat Sep 1 15:34:52 2007 From: report at bugs.python.org (Georg Brandl) Date: Sat, 01 Sep 2007 13:34:52 -0000 Subject: [issue1081] file.seek allows float arguments Message-ID: <1188653692.21.0.272026502521.issue1081@psf.upfronthosting.co.za> New submission from Georg Brandl: Although documented as deprecated, file.seek accepts float arguments in 3.0. ---------- keywords: py3k messages: 55558 nosy: georg.brandl severity: normal status: open title: file.seek allows float arguments type: behavior versions: Python 3.0 __________________________________ Tracker __________________________________ From report at bugs.python.org Sat Sep 1 15:34:52 2007 From: report at bugs.python.org (Georg Brandl) Date: Sat, 01 Sep 2007 13:34:52 -0000 Subject: [issue1081] file.seek allows float arguments Message-ID: <1188653692.21.0.272026502521.issue1081@psf.upfronthosting.co.za> New submission from Georg Brandl: Although documented as deprecated, file.seek accepts float arguments in 3.0. ---------- keywords: py3k messages: 55558 nosy: georg.brandl severity: normal status: open title: file.seek allows float arguments type: behavior versions: Python 3.0 __________________________________ Tracker __________________________________ From report at bugs.python.org Sat Sep 1 16:05:12 2007 From: report at bugs.python.org (Georg Brandl) Date: Sat, 01 Sep 2007 14:05:12 -0000 Subject: [issue1080] Search broken In-Reply-To: <1188649438.83.0.0963732407749.issue1080@psf.upfronthosting.co.za> Message-ID: <46D9719A.2030505@gmx.net> Georg Brandl added the comment: This is currently expected; the non-dev version will include a different search function. ---------- nosy: +georg.brandl resolution: -> later status: open -> closed __________________________________ Tracker __________________________________ From report at bugs.python.org Sat Sep 1 17:32:24 2007 From: report at bugs.python.org (Georg Brandl) Date: Sat, 01 Sep 2007 15:32:24 -0000 Subject: [issue1071] unicode.translate() doesn't error out on invalid translation table Message-ID: <1188660744.6.0.615587494264.issue1071@psf.upfronthosting.co.za> Georg Brandl added the comment: Here's a patch that should make unicode.translate() more robust, and also allows unicode characters to be passed in the mapping. __________________________________ Tracker __________________________________ -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: uni_xlate.diff Url: http://mail.python.org/pipermail/python-bugs-list/attachments/20070901/7a21b450/attachment.txt From report at bugs.python.org Sat Sep 1 17:34:23 2007 From: report at bugs.python.org (Pat LaVarre) Date: Sat, 01 Sep 2007 15:34:23 -0000 Subject: [issue1082] platform system may be Windows or Microsoft since Vista Message-ID: <1188660863.15.0.271391863647.issue1082@psf.upfronthosting.co.za> New submission from Pat LaVarre: SUMMARY: 'Microsoft' is the platform.system() of Vista Windows, whereas 'Windows' was the platform.system() of XP Windows, whoops. STEPS TO REPRODUCE & ACTUAL RESULTS: Run 2.5.1 Python in a Vista and see: >>> import platform >>> platform.system() >>> 'Microsoft' >>> EXPECTED RESULTS: >>> import platform >>> platform.system() 'Windows' >>> WORKAROUND: Write new Python source code like: if platform.system() in ('Windows', 'Microsoft'): if not (platform.system() in ('Windows', 'Microsoft')): in place of obsolete Python source code like: if platform.system() == 'Windows': # Microsoft if platform.system() != 'Windows': # Microsoft REGRESSION/ ISOLATION: Seen by me in an Enterprise Vista. Indexed by Google as reported by Martin v. L?wis (loewis) circa 2007-05-29 07:11 as: http://mail.python.org/pipermail/patches/2007-June/022947.html ... Patches item #1726668, was opened at 2007-05-28 03:23 On Microsoft Vista platform.system() returns 'Microsoft' and platform.release() returns 'Windows' Under Microsoft Windows XP SP2 platform.system() returns 'Windows' and platform.release() returns 'XP'. This is problem was caused by a change in the output of the "ver" command. In Windows XP SP2 "ver" outputted 'Microsoft Windows XP [Version 5.1.2600]' In Microsoft Vista "ver" outputted 'Microsoft Windows [Version 6.0.6000]'. The lack of the 3rd word before version causes _syscmd_ver(...) in platform.py to return 'Microsoft' for system instead of 'Microsoft Windows'. This causes uname() to return the incorrect values. Both system() and release() call uname(). NOTES: There is no fixing all of this? Cross-platform scripts actually will misbehave across the large population that is 2.5 Python in Vista unless those scripts change to implement something like the suggested workaround, that's now an accomplished fact. Question: Is it better to leave this feature as is, so that everyone eventually learns to workaround it, or is it better to fix it late now in 2007-09, so that many people never have to learn to workaround it? Question: Why are we screen-scraping the Ver command, instead of calling Win kernel32.getVersionEx? And how can any code for screen-scraping the Ver command be in doubt about whether the platform.system underneath is 'Windows'? ---------- components: Windows messages: 55561 nosy: p.lavarre at ieee.org severity: major status: open title: platform system may be Windows or Microsoft since Vista type: behavior versions: Python 2.5 __________________________________ Tracker __________________________________ From report at bugs.python.org Sat Sep 1 17:34:23 2007 From: report at bugs.python.org (Pat LaVarre) Date: Sat, 01 Sep 2007 15:34:23 -0000 Subject: [issue1082] platform system may be Windows or Microsoft since Vista Message-ID: <1188660863.15.0.271391863647.issue1082@psf.upfronthosting.co.za> New submission from Pat LaVarre: SUMMARY: 'Microsoft' is the platform.system() of Vista Windows, whereas 'Windows' was the platform.system() of XP Windows, whoops. STEPS TO REPRODUCE & ACTUAL RESULTS: Run 2.5.1 Python in a Vista and see: >>> import platform >>> platform.system() >>> 'Microsoft' >>> EXPECTED RESULTS: >>> import platform >>> platform.system() 'Windows' >>> WORKAROUND: Write new Python source code like: if platform.system() in ('Windows', 'Microsoft'): if not (platform.system() in ('Windows', 'Microsoft')): in place of obsolete Python source code like: if platform.system() == 'Windows': # Microsoft if platform.system() != 'Windows': # Microsoft REGRESSION/ ISOLATION: Seen by me in an Enterprise Vista. Indexed by Google as reported by Martin v. L?wis (loewis) circa 2007-05-29 07:11 as: http://mail.python.org/pipermail/patches/2007-June/022947.html ... Patches item #1726668, was opened at 2007-05-28 03:23 On Microsoft Vista platform.system() returns 'Microsoft' and platform.release() returns 'Windows' Under Microsoft Windows XP SP2 platform.system() returns 'Windows' and platform.release() returns 'XP'. This is problem was caused by a change in the output of the "ver" command. In Windows XP SP2 "ver" outputted 'Microsoft Windows XP [Version 5.1.2600]' In Microsoft Vista "ver" outputted 'Microsoft Windows [Version 6.0.6000]'. The lack of the 3rd word before version causes _syscmd_ver(...) in platform.py to return 'Microsoft' for system instead of 'Microsoft Windows'. This causes uname() to return the incorrect values. Both system() and release() call uname(). NOTES: There is no fixing all of this? Cross-platform scripts actually will misbehave across the large population that is 2.5 Python in Vista unless those scripts change to implement something like the suggested workaround, that's now an accomplished fact. Question: Is it better to leave this feature as is, so that everyone eventually learns to workaround it, or is it better to fix it late now in 2007-09, so that many people never have to learn to workaround it? Question: Why are we screen-scraping the Ver command, instead of calling Win kernel32.getVersionEx? And how can any code for screen-scraping the Ver command be in doubt about whether the platform.system underneath is 'Windows'? ---------- components: Windows messages: 55561 nosy: p.lavarre at ieee.org severity: major status: open title: platform system may be Windows or Microsoft since Vista type: behavior versions: Python 2.5 __________________________________ Tracker __________________________________ From report at bugs.python.org Sat Sep 1 17:41:10 2007 From: report at bugs.python.org (Georg Brandl) Date: Sat, 01 Sep 2007 15:41:10 -0000 Subject: [issue1072] Documentaion font size too small Message-ID: <1188661270.34.0.97491990981.issue1072@psf.upfronthosting.co.za> Georg Brandl added the comment: Okay, next try. I think the sizes are more balanced now. __________________________________ Tracker __________________________________ From report at bugs.python.org Sat Sep 1 19:42:19 2007 From: report at bugs.python.org (Skip Montanaro) Date: Sat, 01 Sep 2007 17:42:19 -0000 Subject: [issue852532] ^$ won't split on empty line Message-ID: <1188668539.11.0.738040780347.issue852532@psf.upfronthosting.co.za> Skip Montanaro added the comment: Doc note checked in as r57878. Can we conclude based upon Tim's and Fredrik's comments that this behavior is to be expected and won't change? If so, I'll close this item. ---------- assignee: fdrake -> skip.montanaro nosy: +skip.montanaro resolution: postponed -> wont fix status: open -> pending ____________________________________ Tracker ____________________________________ From report at bugs.python.org Sat Sep 1 19:44:59 2007 From: report at bugs.python.org (Skip Montanaro) Date: Sat, 01 Sep 2007 17:44:59 -0000 Subject: [issue1330538] datetime/xmlrpclib.DateTime comparison Message-ID: <1188668699.1.0.253544630297.issue1330538@psf.upfronthosting.co.za> Skip Montanaro added the comment: Fred, can we move this forward? _____________________________________ Tracker _____________________________________ From report at bugs.python.org Sat Sep 1 21:17:56 2007 From: report at bugs.python.org (Bill Janssen) Date: Sat, 01 Sep 2007 19:17:56 -0000 Subject: [issue1082] platform system may be Windows or Microsoft since Vista Message-ID: <1188674276.57.0.378133816389.issue1082@psf.upfronthosting.co.za> Bill Janssen added the comment: Wow. I think that platform.system() should return "Windows" for both XP and Vista, and platform.release() should return either "Vista" or "XP". Seems like a patch to make this happen would be a good idea. ---------- nosy: +janssen __________________________________ Tracker __________________________________ From report at bugs.python.org Sat Sep 1 21:19:34 2007 From: report at bugs.python.org (Skip Montanaro) Date: Sat, 01 Sep 2007 19:19:34 -0000 Subject: [issue1083] Confusing error message when dividing timedelta using / Message-ID: <1188674374.08.0.925919990107.issue1083@psf.upfronthosting.co.za> New submission from Skip Montanaro: I discovered the hard way today that this won't work: >>> import datetime >>> d = datetime.timedelta(1) >>> d / 2 Traceback (most recent call last): File "", line 1, in TypeError: unsupported operand type(s) for /: 'datetime.timedelta' and 'int' The error message is misleading, because in fact timedelta objects *do* support division by ints, just not with the / operator: >>> d // 2 datetime.timedelta(0, 43200) Is there some way the error message can be improved, perhaps by identifying the denominator as effectively a float? ---------- components: Interpreter Core messages: 55566 nosy: skip.montanaro severity: normal status: open title: Confusing error message when dividing timedelta using / type: behavior __________________________________ Tracker __________________________________ From report at bugs.python.org Sat Sep 1 21:19:34 2007 From: report at bugs.python.org (Skip Montanaro) Date: Sat, 01 Sep 2007 19:19:34 -0000 Subject: [issue1083] Confusing error message when dividing timedelta using / Message-ID: <1188674374.08.0.925919990107.issue1083@psf.upfronthosting.co.za> New submission from Skip Montanaro: I discovered the hard way today that this won't work: >>> import datetime >>> d = datetime.timedelta(1) >>> d / 2 Traceback (most recent call last): File "", line 1, in TypeError: unsupported operand type(s) for /: 'datetime.timedelta' and 'int' The error message is misleading, because in fact timedelta objects *do* support division by ints, just not with the / operator: >>> d // 2 datetime.timedelta(0, 43200) Is there some way the error message can be improved, perhaps by identifying the denominator as effectively a float? ---------- components: Interpreter Core messages: 55566 nosy: skip.montanaro severity: normal status: open title: Confusing error message when dividing timedelta using / type: behavior __________________________________ Tracker __________________________________ From report at bugs.python.org Sun Sep 2 00:57:14 2007 From: report at bugs.python.org (Simon Anders) Date: Sat, 01 Sep 2007 22:57:14 -0000 Subject: [issue1084] ''.find() gives wrong result in Python built with ICC Message-ID: <1188687434.77.0.430311083782.issue1084@psf.upfronthosting.co.za> Changes by Simon Anders: ---------- components: Build, Interpreter Core severity: normal status: open title: ''.find() gives wrong result in Python built with ICC versions: Python 2.5 __________________________________ Tracker __________________________________ From report at bugs.python.org Sun Sep 2 00:59:20 2007 From: report at bugs.python.org (Simon Anders) Date: Sat, 01 Sep 2007 22:59:20 -0000 Subject: [issue1084] ''.find() gives wrong result in Python built with ICC Message-ID: <1188687560.78.0.47124407802.issue1084@psf.upfronthosting.co.za> New submission from Simon Anders: I have just encountered a strange bug affecting Python 2.5.1 on an x86_64 Linux, but only when compiled with the Intel C Compiler (ICC) 10.0, not a GCC-compiled Python. On my Intel-compiled one, which otherwise seems to work fine, ''.find() works incorrectly. I have narrowed down the issue to the simple test case "foo2/**bar**/".find ("/**bar**/") Observe: On a GCC-compiled Python 2.5.1, the command works as expected by returning 4: [c705213 at hc-ma tmp]$ /usr/site/hc-2.6/python/gnu/2.5.1/bin/python2.5 Python 2.5.1 (r251:54863, Aug 30 2007, 16:21:23) [GCC 3.4.6 20060404 (Red Hat 3.4.6-8)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> print "foo2/**bar**/".find ("/**bar**/") 4 On my Python 2.5.1 installation which was compiled from source with the Intel C Compiler (ICC) for Linux, version 10.0, '-1' is returned: [c705213 at hc-ma tmp]$ /usr/site/hc-2.6/python/intel/2.5.1/bin/python2.5 Python 2.5.1 (r251:54863, Aug 30 2007, 16:20:06) [GCC Intel(R) C++ gcc 3.4 mode] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> print "foo2/**bar**/".find ("/**bar**/") -1 What could have possibly gone wrong here? Admittedly, this smacks more of a bug in icc than in Python, but I report it here, as I feel at loss of what else to do with it. Obvious first question: Does anyone else out here have an ICC-compiled Python handy to check whether the bug reproduces elsewhere? Any idea what kind of oddity I have stumbled over here? Obviously, it could simply be that something went wrong when compiling Python from source with ICC, but it should not happen that the interpreter nebertheless starts up and fails only silently. Additional information: - I have stumbled over the problem when trying to install Numpy 1.0.3.1, as the built failed at the point where a script 'conv_template.py', which is part of NumPy's installtion system, is started to do some pattern replacements in a file called 'scalartypes.inc.src'. My test case is reduced from this script. - The system is the master node of a compute cluster with AMD Opteron CPUs. The cluster is not involved, all was done on the master node. The box runs RedHat Enterprise Linux 4.0 Advanced Server. It replies to 'uname -a' with: Linux hc-ma.uibk.ac.at 2.6.9-42.0.10.ELsmp #1 SMP Fri Feb 16 17:13:42 EST 2007 x86_64 x86_64 x86_64 GNU/Linux - The dynamic dependencies of the GCC-compiled and the ICC-compiled Python binaries are: [c705213 at hc-ma tmp]$ ldd /usr/site/hc-2.6/python/gnu/2.5.1/bin/python2.5 libpthread.so.0 => /lib64/tls/libpthread.so.0 (0x0000003702900000) libdl.so.2 => /lib64/libdl.so.2 (0x0000003701d00000) libutil.so.1 => /lib64/libutil.so.1 (0x0000003703900000) libm.so.6 => /lib64/tls/libm.so.6 (0x0000003701b00000) libc.so.6 => /lib64/tls/libc.so.6 (0x0000003701800000) /lib64/ld-linux-x86-64.so.2 (0x0000003701600000) [c705213 at hc-ma tmp]$ ldd /usr/site/hc-2.6/python/intel/2.5.1/bin/python2.5 libpthread.so.0 => /lib64/tls/libpthread.so.0 (0x0000003702900000) libdl.so.2 => /lib64/libdl.so.2 (0x0000003701d00000) libutil.so.1 => /lib64/libutil.so.1 (0x0000003703900000) libimf.so => /usr/site/hc-2.6/intel/10.0/cc/lib/libimf.so (0x0000002a95579000) libm.so.6 => /lib64/tls/libm.so.6 (0x0000003701b00000) libgcc_s.so.1 => /lib64/libgcc_s.so.1 (0x0000003705800000) libc.so.6 => /lib64/tls/libc.so.6 (0x0000003701800000) /lib64/ld-linux-x86-64.so.2 (0x0000003701600000) - The precise revision of Python is "Python 2.5.1 (r251:54863)". - The test case ceases to show failure if the string is only slightly altered, e.g. if the word 'foo', the word 'bar' or the one of the asterisks or one of the slashes is cut out in both search and target string. ---------- nosy: +sanders_muc __________________________________ Tracker __________________________________ From report at bugs.python.org Sun Sep 2 03:11:01 2007 From: report at bugs.python.org (Marc-Andre Lemburg) Date: Sun, 02 Sep 2007 01:11:01 -0000 Subject: [issue1071] unicode.translate() doesn't error out on invalid translation table Message-ID: <1188695461.37.0.0537489189594.issue1071@psf.upfronthosting.co.za> Marc-Andre Lemburg added the comment: Nice idea, but why don't you use a dictionary iterator (PyDict_Next()) for the fixup ? __________________________________ Tracker __________________________________ From report at bugs.python.org Sun Sep 2 03:54:54 2007 From: report at bugs.python.org (Skip Montanaro) Date: Sun, 02 Sep 2007 01:54:54 -0000 Subject: [issue1289118] timedelta multiply and divide by floating point Message-ID: <1188698094.58.0.204062098209.issue1289118@psf.upfronthosting.co.za> Skip Montanaro added the comment: Attached is a diff to the datetime module that implements floating point division. Comments? Is it worthwhile to pursue? If so, I'll implement the other floating point arithmetic operations. ---------- versions: +Python 2.6 _____________________________________ Tracker _____________________________________ -------------- next part -------------- A non-text attachment was scrubbed... Name: dt.diff Type: text/x-diff Size: 3566 bytes Desc: not available Url : http://mail.python.org/pipermail/python-bugs-list/attachments/20070902/a0f27d57/attachment-0001.diff From report at bugs.python.org Sun Sep 2 04:59:53 2007 From: report at bugs.python.org (Skip Montanaro) Date: Sun, 02 Sep 2007 02:59:53 -0000 Subject: [issue1289118] timedelta multiply and divide by floating point Message-ID: <1188701993.63.0.454630852689.issue1289118@psf.upfronthosting.co.za> Skip Montanaro added the comment: Ummm... make that: "I'll implement multiplication." _____________________________________ Tracker _____________________________________ From report at bugs.python.org Sun Sep 2 05:13:12 2007 From: report at bugs.python.org (Skip Montanaro) Date: Sun, 02 Sep 2007 03:13:12 -0000 Subject: [issue1118748] enable time + timedelta Message-ID: <1188702792.96.0.658091358917.issue1118748@psf.upfronthosting.co.za> Skip Montanaro added the comment: This has come up and been rejected because there are so many end cases. Here's an item from a thread I believe you started on comp.lang.python: http://mail.python.org/pipermail/python-list/2005-January/303023.html If you want to add time and timedelta objects, use datetime objects and extract their times. The behavior is well-defined. >>> t = datetime.time(11, 47, 00) >>> td = datetime.timedelta(0, 40000, 1234) >>> dt = datetime.datetime.now().replace(hour=t.hour, minute=t.minute, second=t.second) >>> dt datetime.datetime(2007, 9, 1, 11, 47, 0, 147616) >>> for i in range(1, 10): ... print (dt + i * td).time() ... 22:53:40.148850 10:00:20.150084 21:07:00.151318 08:13:40.152552 19:20:20.153786 06:27:00.155020 17:33:40.156254 04:40:20.157488 15:47:00.158722 ---------- nosy: +skip.montanaro resolution: -> rejected status: open -> closed _____________________________________ Tracker _____________________________________ From report at bugs.python.org Sun Sep 2 05:15:28 2007 From: report at bugs.python.org (Skip Montanaro) Date: Sun, 02 Sep 2007 03:15:28 -0000 Subject: [issue1487389] datetime.time and datetime.timedelta Message-ID: <1188702928.04.0.935600490993.issue1487389@psf.upfronthosting.co.za> Skip Montanaro added the comment: See this other issue I just closed: http://bugs.python.org/issue1118748 ---------- nosy: +skip.montanaro _____________________________________ Tracker _____________________________________ From report at bugs.python.org Sun Sep 2 05:16:07 2007 From: report at bugs.python.org (Skip Montanaro) Date: Sun, 02 Sep 2007 03:16:07 -0000 Subject: [issue1487389] datetime.time and datetime.timedelta Message-ID: <1188702967.34.0.0350568793526.issue1487389@psf.upfronthosting.co.za> Changes by Skip Montanaro: ---------- resolution: -> rejected status: open -> closed _____________________________________ Tracker _____________________________________ From report at bugs.python.org Sun Sep 2 05:22:52 2007 From: report at bugs.python.org (Skip Montanaro) Date: Sun, 02 Sep 2007 03:22:52 -0000 Subject: [issue1673409] datetime module missing some important methods Message-ID: <1188703372.8.0.174601033133.issue1673409@psf.upfronthosting.co.za> Skip Montanaro added the comment: There is no datetime.totimestamp because the range of time represented by a datetime object far exceeds the range of a normal int-based Unix timestamp (roughly 1970-2038). Datetime objects before the start of the Unix epoch would be represented by negative numbers. As far as I know, the common Unix library functions which accept epoch times wouldn't know what to do with a negative number. That said, you stated these missing methods were important. Can you offer some use cases which would support that contention? I personally don't think a argument for symmetry would be a convincing use case and that's the only one I can think of. ---------- nosy: +skip.montanaro _____________________________________ Tracker _____________________________________ From report at bugs.python.org Sun Sep 2 05:37:50 2007 From: report at bugs.python.org (Skip Montanaro) Date: Sun, 02 Sep 2007 03:37:50 -0000 Subject: [issue1074462] Irregular behavior of datetime.__str__() Message-ID: <1188704270.35.0.868744232726.issue1074462@psf.upfronthosting.co.za> Skip Montanaro added the comment: I'm going to offer one more argument here, then close the ticket. (Tim already told you the behavior wasn't going to change.) str() is a convenience function intended to give conveniently human-readable output. It's not intended to be a one-size-fits- all routine. Humans are used to not seeing fractions of a second in times when there are none. In those situations where you unambiguously need microseconds displayed, use something like this: >>> str(dt.replace(microsecond=0)) + ".%06d" % dt.microsecond '2007-09-01 22:30:36.000032' >>> dt.strftime("%H:%M:%S") + ".%06d" % dt.microsecond '22:30:36.000032' ---------- nosy: +skip.montanaro resolution: -> rejected status: open -> closed _____________________________________ Tracker _____________________________________ From report at bugs.python.org Sun Sep 2 07:20:15 2007 From: report at bugs.python.org (Noah Gift) Date: Sun, 02 Sep 2007 05:20:15 -0000 Subject: [issue1085] OS X 10.5.x Build Problems Message-ID: <1188710415.73.0.736529785286.issue1085@psf.upfronthosting.co.za> Changes by Noah Gift: ---------- components: Tests severity: major status: open title: OS X 10.5.x Build Problems type: compile error versions: Python 3.0 __________________________________ Tracker __________________________________ From report at bugs.python.org Sun Sep 2 07:44:38 2007 From: report at bugs.python.org (Noah Gift) Date: Sun, 02 Sep 2007 05:44:38 -0000 Subject: [issue1085] OS X 10.5.x Build Problems Message-ID: <1188711878.16.0.853603505837.issue1085@psf.upfronthosting.co.za> New submission from Noah Gift: Compile problem on: System Software Overview: System Version: Mac OS X 10.5 (9A527) Kernel Version: Darwin 9.0.0b5 Temporary Fix was to go into Modules/posixmodule.c and at line: 3767 Take out function and create empty function. I was then able to get make to run, but still got these non-critical errors: Failed to find the necessary bits to build these modules: _bsddb gdbm ossaudiodev readline spwd To find the necessary bits, look in setup.py in detect_modules() for the module's name. Failed to build these modules: _OSA Running make test I get: running sudo make test, some errors are: Traceback (most recent call last): File "/Users/ngift/Desktop/Python-3.0a1/Lib/SocketServer.py", line 222, in handle_request self.process_request(request, client_address) File "/Users/ngift/Desktop/Python-3.0a1/Lib/SocketServer.py", line 241, in process_request self.finish_request(request, client_address) File "/Users/ngift/Desktop/Python-3.0a1/Lib/SocketServer.py", line 254, in finish_request self.RequestHandlerClass(request, client_address, self) File "/Users/ngift/Desktop/Python-3.0a1/Lib/SocketServer.py", line 522, in __init__ self.handle() File "/Users/ngift/Desktop/Python-3.0a1/Lib/BaseHTTPServer.py", line 330, in handle self.handle_one_request() File "/Users/ngift/Desktop/Python-3.0a1/Lib/BaseHTTPServer.py", line 313, in handle_one_request self.raw_requestline = self.rfile.readline() File "/Users/ngift/Desktop/Python-3.0a1/Lib/io.py", line 380, in readline b = self.read(nreadahead()) File "/Users/ngift/Desktop/Python-3.0a1/Lib/io.py", line 366, in nreadahead readahead = self.peek(1, unsafe=True) File "/Users/ngift/Desktop/Python-3.0a1/Lib/io.py", line 758, in peek current = self.raw.read(to_read) File "/Users/ngift/Desktop/Python-3.0a1/Lib/io.py", line 442, in read n = self.readinto(b) File "/Users/ngift/Desktop/Python-3.0a1/Lib/socket.py", line 292, in readinto return self._sock.recv_into(b) socket.error: (35, 'Resource temporarily unavailable') test test_xmlrpc failed -- errors occurred; run in verbose mode for details test_xmlrpc_net test_xmlrpc_net skipped -- Use of the `network' resource not enabled test_zipfile test_zipfile64 test_zipfile64 skipped -- test requires loads of disk-space bytes and a long time to run test_zipimport test_zlib 295 tests OK. 2 tests failed: test__locale test_xmlrpc 25 tests skipped: test_bsddb test_bsddb3 test_codecmaps_cn test_codecmaps_hk test_codecmaps_jp test_codecmaps_kr test_codecmaps_tw test_curses test_gdbm test_largefile test_locale test_normalization test_ossaudiodev test_pep277 test_socket_ssl test_socketserver test_ssl test_startfile test_timeout test_urllib2net test_urllibnet test_winreg test_winsound test_xmlrpc_net test_zipfile64 1 skip unexpected on darwin: test_ssl make: *** [test] Error 1 Then when I run make install it *almost* works but I get: Writing /Library/Frameworks/Python.framework/Versions/3.0/lib/python3.0/lib- dynload/Python-3.0a1-py3.0.egg-info ln -fs "../../../Python" "/Library/Frameworks/Python.framework/Versions/3.0/lib/python3.0/config/ libpython3.0.a" cd Mac && make installmacsubtree DESTDIR="" Creating directory /Library/Frameworks/Python.framework/Versions/3.0/Mac/Tools DYLD_FRAMEWORK_PATH=/Users/ngift/Desktop/Python-3.0a1: ../python.exe ./scripts/cachersrc.py -v /Library/Frameworks/Python.framework/Versions/3.0/lib/python3.0/plat-mac /Library/Frameworks/Python.framework/Versions/3.0/Mac/Tools File "./scripts/cachersrc.py", line 15 def handler((verbose, force), dirname, fnames): ^ SyntaxError: invalid syntax make[1]: *** [installmacsubtree] Error 1 make: *** [frameworkinstallmaclib] Error 2 ---------- nosy: +noahgift __________________________________ Tracker __________________________________ From report at bugs.python.org Sun Sep 2 09:08:36 2007 From: report at bugs.python.org (Georg Brandl) Date: Sun, 02 Sep 2007 07:08:36 -0000 Subject: [issue1071] unicode.translate() doesn't error out on invalid translation table In-Reply-To: <1188695461.37.0.0537489189594.issue1071@psf.upfronthosting.co.za> Message-ID: <46DA616E.8050304@python.org> Georg Brandl added the comment: Marc-Andre Lemburg schrieb: > Marc-Andre Lemburg added the comment: > > Nice idea, but why don't you use a dictionary iterator (PyDict_Next()) > for the fixup ? I thought that is unsafe to use when the dictionary is mutated while iterating. __________________________________ Tracker __________________________________ From report at bugs.python.org Sun Sep 2 09:08:58 2007 From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=) Date: Sun, 02 Sep 2007 07:08:58 -0000 Subject: [issue1084] ''.find() gives wrong result in Python built with ICC Message-ID: <1188716938.32.0.97605127155.issue1084@psf.upfronthosting.co.za> Martin v. L?wis added the comment: It definitely sounds like a compiler bug. Unless you can provide further details to the specific error in the C code of Python, it's likely that we can do little about it. If you want to analyze this further, here is a number of things you can try: - compile Python at various optimization levels. A compiler bug often manifests itself only at a specific set of optimization flags. - try tracing this invocation of .find() in a debugger. Doing so at a lower optimization level is easier, since the compiler may have inlined the various functions that form .find() under optimization. - if the debugger does not allow to pinpoint the erroneous function, add printf statements. Most of the code to study is in Objects/stringobject.c and Objects/stringlib/find.h. ---------- nosy: +loewis __________________________________ Tracker __________________________________ From report at bugs.python.org Sun Sep 2 09:15:32 2007 From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=) Date: Sun, 02 Sep 2007 07:15:32 -0000 Subject: [issue1085] OS X 10.5.x Build Problems Message-ID: <1188717332.85.0.612721059545.issue1085@psf.upfronthosting.co.za> Martin v. L?wis added the comment: This is a duplicate of #1078. ---------- nosy: +loewis resolution: -> duplicate status: open -> closed superseder: -> cachersrc.py using tuple unpacking args __________________________________ Tracker __________________________________ From report at bugs.python.org Sun Sep 2 11:31:40 2007 From: report at bugs.python.org (Simon Anders) Date: Sun, 02 Sep 2007 09:31:40 -0000 Subject: [issue1084] ''.find() gives wrong result in Python built with ICC Message-ID: <1188725500.46.0.384977575245.issue1084@psf.upfronthosting.co.za> Simon Anders added the comment: Martin, you are right: is is related to compiler optimization. I have boiled it down to a call of stringlib_find (defined in Python-2.5.1/Objects/stringlib/find.h) and this runs fine with 'icc -O2' but incorrectly for 'icc -O3'. (The test code is attached.) So, it seems that the lesson is simply once again: Do not use '-O3' with Intel's C compiler. (At least, for me, it is not the first time that this caused trouble.) On the other hand, Python's ./configure script is quite clear in its preference of GCC, anyway: It more or less ignores with option '--without-gcc' and uses the content of the CC environment variable only very occasionally. __________________________________ Tracker __________________________________ -------------- next part -------------- A non-text attachment was scrubbed... Name: findtest.c Type: text/x-csrc Size: 727 bytes Desc: not available Url : http://mail.python.org/pipermail/python-bugs-list/attachments/20070902/ee7b7139/attachment.c From report at bugs.python.org Sun Sep 2 11:58:13 2007 From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=) Date: Sun, 02 Sep 2007 09:58:13 -0000 Subject: [issue1084] ''.find() gives wrong result in Python built with ICC Message-ID: <1188727093.35.0.922207385719.issue1084@psf.upfronthosting.co.za> Martin v. L?wis added the comment: If you are curious, we could now try to find out what precisely goes wrong. The procedure would be this * after each step, check whether the problem still occurs a) resolve the includes manually, then strip everything that isn't needed. This could start with fastsearch.h and find.h; then remove everything that refers to Python.h (i.e. replace Py_ssize_t with ssize_t, Py_LOCAL_INLINE with static inline, and so on), then remove Python.h b) try simplifying the code, e.g. replace str_len and sub_len with their (constant) values, drop the sub_len == 0 block, and so on. c) when further simplification is not possible (while keeping the actual error), start looking at the assembler code. Alternatively, sent this or some further-simplified version to Intel (assuming they have some kind of bug-reporting channel for icc). With my compiler-vendor's hat on, I'd like to get a test case for bad code generation that comes as a single file, with no includes; for gcc, the request is to submit preprocessor output. Assuming this is too much effort, I'll close this as "won't fix - third party". ---------- resolution: -> wont fix status: open -> closed versions: +3rd party -Python 2.5 __________________________________ Tracker __________________________________ From report at bugs.python.org Sun Sep 2 12:15:54 2007 From: report at bugs.python.org (Marc-Andre Lemburg) Date: Sun, 02 Sep 2007 10:15:54 -0000 Subject: [issue1071] unicode.translate() doesn't error out on invalid translation table Message-ID: <1188728154.43.0.315927716509.issue1071@psf.upfronthosting.co.za> Marc-Andre Lemburg added the comment: Ah, I hadn't noticed that you're actually manipulating the input dictionary. You should create a copy and fix that instead of changing the dict that the user passed in to the function. You can then use PyDict_Next() for fast iteration over the original dictionary. __________________________________ Tracker __________________________________ From report at bugs.python.org Sun Sep 2 12:47:23 2007 From: report at bugs.python.org (Simon Anders) Date: Sun, 02 Sep 2007 10:47:23 -0000 Subject: [issue1084] ''.find() gives wrong result in Python built with ICC Message-ID: <1188730043.8.0.383546553677.issue1084@psf.upfronthosting.co.za> Simon Anders added the comment: Martin: I've boiled down the test case a bit more and removed all Python-specific types and macros, so that it can now be compiled stand-alone. (Updated test case 'findtest.c' attached.) I didn't feel like diving into the code much deeper, and so I have sent it to Intel Premier Support as Issue #448807. Let's see if they bother to investigate it further. __________________________________ Tracker __________________________________ -------------- next part -------------- A non-text attachment was scrubbed... Name: findtest.c Type: text/x-csrc Size: 3175 bytes Desc: not available Url : http://mail.python.org/pipermail/python-bugs-list/attachments/20070902/eb8c18f8/attachment.c From report at bugs.python.org Sun Sep 2 14:14:29 2007 From: report at bugs.python.org (xyb) Date: Sun, 02 Sep 2007 12:14:29 -0000 Subject: [issue1086] test_email failed Message-ID: <1188735269.69.0.0628982068821.issue1086@psf.upfronthosting.co.za> New submission from xyb: test test_email failed -- Traceback (most recent call last): File "/home/xyb/Python-3.0a1/Lib/email/test/test_email.py", line 1445, in test_same_boundary_inner_outer msg = self._msgobj('msg_15.txt') File "/home/xyb/Python-3.0a1/Lib/email/test/test_email.py", line 67, in _msgobj return email.message_from_file(fp) File "/home/xyb/Python-3.0a1/Lib/email/__init__.py", line 46, in message_from_file return Parser(*args, **kws).parse(fp) File "/home/xyb/Python-3.0a1/Lib/email/parser.py", line 68, in parse data = fp.read(8192) File "/home/xyb/Python-3.0a1/Lib/io.py", line 1231, in read readahead, pending = self._read_chunk() File "/home/xyb/Python-3.0a1/Lib/io.py", line 1127, in _read_chunk pending = self._decoder.decode(readahead, not readahead) File "/home/xyb/Python-3.0a1/Lib/codecs.py", line 291, in decode (result, consumed) = self._buffer_decode(data, self.errors, final) UnicodeDecodeError: 'utf8' codec can't decode byte 0xbe in position 86: unexpected code byte ---------- messages: 55583 nosy: xyb severity: normal status: open title: test_email failed versions: Python 3.0 __________________________________ Tracker __________________________________ From report at bugs.python.org Sun Sep 2 14:14:29 2007 From: report at bugs.python.org (xyb) Date: Sun, 02 Sep 2007 12:14:29 -0000 Subject: [issue1086] test_email failed Message-ID: <1188735269.69.0.0628982068821.issue1086@psf.upfronthosting.co.za> New submission from xyb: test test_email failed -- Traceback (most recent call last): File "/home/xyb/Python-3.0a1/Lib/email/test/test_email.py", line 1445, in test_same_boundary_inner_outer msg = self._msgobj('msg_15.txt') File "/home/xyb/Python-3.0a1/Lib/email/test/test_email.py", line 67, in _msgobj return email.message_from_file(fp) File "/home/xyb/Python-3.0a1/Lib/email/__init__.py", line 46, in message_from_file return Parser(*args, **kws).parse(fp) File "/home/xyb/Python-3.0a1/Lib/email/parser.py", line 68, in parse data = fp.read(8192) File "/home/xyb/Python-3.0a1/Lib/io.py", line 1231, in read readahead, pending = self._read_chunk() File "/home/xyb/Python-3.0a1/Lib/io.py", line 1127, in _read_chunk pending = self._decoder.decode(readahead, not readahead) File "/home/xyb/Python-3.0a1/Lib/codecs.py", line 291, in decode (result, consumed) = self._buffer_decode(data, self.errors, final) UnicodeDecodeError: 'utf8' codec can't decode byte 0xbe in position 86: unexpected code byte ---------- messages: 55583 nosy: xyb severity: normal status: open title: test_email failed versions: Python 3.0 __________________________________ Tracker __________________________________ From report at bugs.python.org Sun Sep 2 15:34:08 2007 From: report at bugs.python.org (Peter van Kampen) Date: Sun, 02 Sep 2007 13:34:08 -0000 Subject: [issue1086] test_email failed Message-ID: <1188740048.21.0.929012001541.issue1086@psf.upfronthosting.co.za> Peter van Kampen added the comment: Attached is msg_15.txt encoded in utf-8. >>> f = codecs.open('Lib/email/test/data/msg_15.txt', 'r', encoding='iso-8859-1') >>> s = f.read() >>> f.close() >>> f = open('Lib/email/test/data/msg_15.txt','w') >>> f.write(s) >>> f.close() $ ./python Lib/test/regrtest.py test_email test_email 1 test OK. ---------- nosy: +pterk __________________________________ Tracker __________________________________ -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: msg_15.txt Url: http://mail.python.org/pipermail/python-bugs-list/attachments/20070902/24e90f02/attachment.txt From report at bugs.python.org Sun Sep 2 16:03:10 2007 From: report at bugs.python.org (Jon Ribbens) Date: Sun, 02 Sep 2007 14:03:10 -0000 Subject: [issue1673409] datetime module missing some important methods Message-ID: <1188741790.25.0.67967017151.issue1673409@psf.upfronthosting.co.za> Jon Ribbens added the comment: Almost everything you just said about time_t is wrong. time_t is signed, and always has been (otherwise the 'end of time' for 32-bit time_t would be 2106, not 2038). Also, time_t does not end at 2038 because nothing says it must be 32 bits. Also, Python has 'long integers' which do not overflow. Also, I don't understand what you mean about use cases. The "use case" is "dealing with anything which expects standard Unix time_t, for example the Python standard library". The use case I have personally is the program I was working on when I encountered the problem described in this bug report. Also I think symmetry is a darn good argument. Why does fromtimestamp exist if, as you claim, nobody uses time_t? _____________________________________ Tracker _____________________________________ From report at bugs.python.org Sun Sep 2 18:07:11 2007 From: report at bugs.python.org (Skip Montanaro) Date: Sun, 02 Sep 2007 16:07:11 -0000 Subject: [issue1673409] datetime module missing some important methods In-Reply-To: <1188741790.25.0.67967017151.issue1673409@psf.upfronthosting.co.za> Message-ID: <18138.57258.603974.168649@montanaro.dyndns.org> Skip Montanaro added the comment: Jon> Almost everything you just said about time_t is wrong. time_t is Jon> signed, and always has been (otherwise the 'end of time' for 32-bit Jon> time_t would be 2106, not 2038). Also, time_t does not end at 2038 Jon> because nothing says it must be 32 bits. Also, Python has 'long Jon> integers' which do not overflow. My apologies about goofing up on the signedness of time_t. What are you going to do with a long integer that you can't do with a datetime object? You clearly can't pass it directly to any Unix library functions which expect time_t. Converting it can overflow. Jon> Also, I don't understand what you mean about use cases. The "use Jon> case" is "dealing with anything which expects standard Unix time_t, Jon> for example the Python standard library". The use case I have Jon> personally is the program I was working on when I encountered the Jon> problem described in this bug report. Also I think symmetry is a Jon> darn good argument. Why does fromtimestamp exist if, as you claim, Jon> nobody uses time_t? What should datetime.datetime(9999, 1, 1).totimestamp() return? How would you pass it to something which accepts a time_t? The fromtimestamp functions work simply because the range of time_t is a proper subset of the range of Python's datetime objects. Symmetry gets you little. In situations where you need Unix timestamps and you know your datetime objects are within the bounds representable by time_t, you can define a convenience function: def totimestamp(dt): return time.mktime(dt.timetuple()) + dt.microsecond/1e6 This will, of course, fail if the year is too big or too small (and will fail in platform-dependent ways if the underlying platform's range of representable dates has different bounds than Unix does). Doing it without resorting to calling time.mktime is also nontrivial. Under the covers the datetime module currently uses platform functions to get time information anyway. It doesn't do a lot of low-level time arithmethic itself. Implementing fromtimestamp would require a fair amount of effort unless you were willing to punt and just raise OverflowError for dates outside the system's range. Skip _____________________________________ Tracker _____________________________________ From report at bugs.python.org Sun Sep 2 18:20:40 2007 From: report at bugs.python.org (Georg Brandl) Date: Sun, 02 Sep 2007 16:20:40 -0000 Subject: [issue1078] cachersrc.py using tuple unpacking args Message-ID: <1188750040.68.0.685759817552.issue1078@psf.upfronthosting.co.za> Changes by Georg Brandl: ---------- assignee: -> collinwinter nosy: +collinwinter __________________________________ Tracker __________________________________ From report at bugs.python.org Sun Sep 2 19:37:24 2007 From: report at bugs.python.org (Carsten Haese) Date: Sun, 02 Sep 2007 17:37:24 -0000 Subject: [issue1087] py3k os.popen result is not iterable, patch attached Message-ID: <1188754644.67.0.0984966588015.issue1087@psf.upfronthosting.co.za> Changes by Carsten Haese: ---------- components: Library (Lib) severity: normal status: open title: py3k os.popen result is not iterable, patch attached type: behavior versions: Python 3.0 __________________________________ Tracker __________________________________ From report at bugs.python.org Sun Sep 2 19:38:48 2007 From: report at bugs.python.org (Carsten Haese) Date: Sun, 02 Sep 2007 17:38:48 -0000 Subject: [issue1087] py3k os.popen result is not iterable, patch attached Message-ID: <1188754728.4.0.144083242247.issue1087@psf.upfronthosting.co.za> Changes by Carsten Haese: __________________________________ Tracker __________________________________ From report at bugs.python.org Sun Sep 2 21:02:34 2007 From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=) Date: Sun, 02 Sep 2007 19:02:34 -0000 Subject: [issue1746880] AMD64 installer does not place python25.dll in system dir Message-ID: <1188759754.97.0.165376233328.issue1746880@psf.upfronthosting.co.za> Martin v. L?wis added the comment: Mark Hammond has now confirmed it worked for 3.0a1, so closing it. ---------- status: open -> closed _____________________________________ Tracker _____________________________________ From report at bugs.python.org Sun Sep 2 21:14:52 2007 From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=) Date: Sun, 02 Sep 2007 19:14:52 -0000 Subject: [issue1759169] clean up Solaris port and allow C99 extension modules Message-ID: <1188760492.94.0.458636525679.issue1759169@psf.upfronthosting.co.za> Martin v. L?wis added the comment: I don't understand the problem. What Solaris version are you using? Why do you want to remove _XOPEN_SOURCE? Solaris considers this as a request for XPG 4.2 only _XOPEN_SOURCE_EXTENDED is defined, which it shouldn't be on Solaris 10. _____________________________________ Tracker _____________________________________ From report at bugs.python.org Sun Sep 2 21:51:07 2007 From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=) Date: Sun, 02 Sep 2007 19:51:07 -0000 Subject: [issue1722225] Build on QNX Message-ID: <1188762667.16.0.975572678167.issue1722225@psf.upfronthosting.co.za> Martin v. L?wis added the comment: A 2.5 patch would not be accepted; there won't be any new features for 2.5 , and new port would be a new feature. Procedurally, are you willing to support a QNX port for the coming years (say, 5 years)? Otherwise, there is little point in accepting such a port if there is no maintenance to it. In general, I would prefer if the things this patch corrects were detected through autoconf, rather than being hard-coded by system name. For example, if using TCGETA and TCSETA requires sys/termio.h to be included, there should be an autoconf test that checks whether TCGETA can be used without sys/termio.h being included, and, if not, defines a macro that says so. However, I don't understand this entire point: What do you mean by "using TCGETA requires that struct termio be defined"? How is TCGETA defined to produce such a dependency? TCGETA is a constant, right? py_curses.h: Can you explain what stdlib.h and ncurses.h define to guard definition of wchar_t? Why do you have two cases: _XOPEN_SOURCE_EXTENDED and not? Surely only one of them applies to Python. Can you come up with an autoconf test that checks whether stdlib.h defines wchar_t and has a guard and that ncurses also defines wchar_t and fails to compile if it is guarded differently? stack size: it would be good if it was sized by default such that the default recursion limit won't cause crashes (but proper stack overflows). If 2MiB are sufficient for the default recursion limit, it's fine - otherwise, either reserver more stack, or reduce the default recursion limit. malloc_closure should use _SC_PAGESIZE when it is defined, and fall back to getpagesize only otherwise. _____________________________________ Tracker _____________________________________ From report at bugs.python.org Sun Sep 2 21:52:52 2007 From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=) Date: Sun, 02 Sep 2007 19:52:52 -0000 Subject: [issue1694155] Python 2.5 installer ended prematurely Message-ID: <1188762772.22.0.240430649177.issue1694155@psf.upfronthosting.co.za> Martin v. L?wis added the comment: Closing because of lack of feedback. (it may be that I got feedback in private mail off-tracker; I don't remember). ---------- resolution: -> works for me status: open -> closed _____________________________________ Tracker _____________________________________ From report at bugs.python.org Sun Sep 2 21:53:51 2007 From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=) Date: Sun, 02 Sep 2007 19:53:51 -0000 Subject: [issue1654408] Installer should split tcl/tk and tkinter install options. Message-ID: <1188762831.79.0.685384877754.issue1654408@psf.upfronthosting.co.za> Changes by Martin v. L?wis: ---------- severity: normal -> minor _____________________________________ Tracker _____________________________________ From report at bugs.python.org Sun Sep 2 21:57:55 2007 From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=) Date: Sun, 02 Sep 2007 19:57:55 -0000 Subject: [issue1752184] PyHeapTypeObject fix Message-ID: <1188763075.47.0.518351469478.issue1752184@psf.upfronthosting.co.za> Martin v. L?wis added the comment: The source of make_type is in Parser/asdl_c.py. ---------- nosy: +loewis _____________________________________ Tracker _____________________________________ From report at bugs.python.org Sun Sep 2 21:58:41 2007 From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=) Date: Sun, 02 Sep 2007 19:58:41 -0000 Subject: [issue1087] py3k os.popen result is not iterable, patch attached Message-ID: <1188763121.22.0.929481970629.issue1087@psf.upfronthosting.co.za> Changes by Martin v. L?wis: ---------- keywords: +patch __________________________________ Tracker __________________________________ From report at bugs.python.org Sun Sep 2 22:02:17 2007 From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=) Date: Sun, 02 Sep 2007 20:02:17 -0000 Subject: [issue1006] Refactor test_winreg.py to use unittest. Message-ID: <1188763337.55.0.321735568666.issue1006@psf.upfronthosting.co.za> Changes by Martin v. L?wis: ---------- keywords: +patch __________________________________ Tracker __________________________________ From report at bugs.python.org Sun Sep 2 22:02:27 2007 From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=) Date: Sun, 02 Sep 2007 20:02:27 -0000 Subject: [issue1007] [py3k] Fix dumbdbm, which fixes test_shelve (for me); instrument other tests so we catch this sooner (and more directly) Message-ID: <1188763347.13.0.627744881219.issue1007@psf.upfronthosting.co.za> Changes by Martin v. L?wis: ---------- keywords: +patch __________________________________ Tracker __________________________________ From report at bugs.python.org Sun Sep 2 22:04:29 2007 From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=) Date: Sun, 02 Sep 2007 20:04:29 -0000 Subject: [issue1012] Broken URL at Doc/install/index.rst Message-ID: <1188763469.51.0.330673158672.issue1012@psf.upfronthosting.co.za> Changes by Martin v. L?wis: ---------- keywords: +patch __________________________________ Tracker __________________________________ From report at bugs.python.org Sun Sep 2 22:04:37 2007 From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=) Date: Sun, 02 Sep 2007 20:04:37 -0000 Subject: [issue1015] [PATCH] Updated patch for rich dict view (dict().keys()) comparisons Message-ID: <1188763477.93.0.674574598342.issue1015@psf.upfronthosting.co.za> Changes by Martin v. L?wis: ---------- keywords: +patch __________________________________ Tracker __________________________________ From report at bugs.python.org Sun Sep 2 22:04:44 2007 From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=) Date: Sun, 02 Sep 2007 20:04:44 -0000 Subject: [issue1016] [PATCH] Updated fix for string to unicode fixes in time and datetime Message-ID: <1188763484.99.0.4150909935.issue1016@psf.upfronthosting.co.za> Changes by Martin v. L?wis: ---------- keywords: +patch __________________________________ Tracker __________________________________ From report at bugs.python.org Sun Sep 2 22:04:52 2007 From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=) Date: Sun, 02 Sep 2007 20:04:52 -0000 Subject: [issue1017] [PATCH] Add set operations (and, or, xor, subtract) to dict views Message-ID: <1188763492.35.0.141929885757.issue1017@psf.upfronthosting.co.za> Changes by Martin v. L?wis: ---------- keywords: +patch __________________________________ Tracker __________________________________ From report at bugs.python.org Sun Sep 2 22:05:03 2007 From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=) Date: Sun, 02 Sep 2007 20:05:03 -0000 Subject: [issue1023] [PATCH] Unicode fixes in floatobject and moduleobject Message-ID: <1188763503.5.0.674705716368.issue1023@psf.upfronthosting.co.za> Changes by Martin v. L?wis: ---------- keywords: +patch __________________________________ Tracker __________________________________ From report at bugs.python.org Sun Sep 2 22:05:22 2007 From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=) Date: Sun, 02 Sep 2007 20:05:22 -0000 Subject: [issue1029] py3k: io.StringIO.getvalue() returns \r\n Message-ID: <1188763522.07.0.5991646862.issue1029@psf.upfronthosting.co.za> Changes by Martin v. L?wis: ---------- keywords: +patch __________________________________ Tracker __________________________________ From report at bugs.python.org Sun Sep 2 22:05:31 2007 From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=) Date: Sun, 02 Sep 2007 20:05:31 -0000 Subject: [issue1030] py3k: Adapt _winreg.c to the new buffer API Message-ID: <1188763531.31.0.410082030312.issue1030@psf.upfronthosting.co.za> Changes by Martin v. L?wis: ---------- keywords: +patch __________________________________ Tracker __________________________________ From report at bugs.python.org Sun Sep 2 22:06:12 2007 From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=) Date: Sun, 02 Sep 2007 20:06:12 -0000 Subject: [issue1000] Patch to rename *Server modules to lower-case Message-ID: <1188763572.3.0.215245739005.issue1000@psf.upfronthosting.co.za> Changes by Martin v. L?wis: ---------- keywords: +patch __________________________________ Tracker __________________________________ From report at bugs.python.org Sun Sep 2 22:06:23 2007 From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=) Date: Sun, 02 Sep 2007 20:06:23 -0000 Subject: [issue1002] Patch to rename HTMLParser module to lower_case Message-ID: <1188763583.26.0.0112596827491.issue1002@psf.upfronthosting.co.za> Changes by Martin v. L?wis: ---------- keywords: +patch __________________________________ Tracker __________________________________ From report at bugs.python.org Sun Sep 2 22:07:33 2007 From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=) Date: Sun, 02 Sep 2007 20:07:33 -0000 Subject: [issue1004] MultiMethods with type annotations in 3000 Message-ID: <1188763653.31.0.573567573546.issue1004@psf.upfronthosting.co.za> Changes by Martin v. L?wis: ---------- keywords: +patch __________________________________ Tracker __________________________________ From report at bugs.python.org Sun Sep 2 22:07:42 2007 From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=) Date: Sun, 02 Sep 2007 20:07:42 -0000 Subject: [issue1005] Patches to rename Queue module to queue Message-ID: <1188763662.24.0.0410005208069.issue1005@psf.upfronthosting.co.za> Changes by Martin v. L?wis: ---------- keywords: +patch __________________________________ Tracker __________________________________ From report at bugs.python.org Sun Sep 2 22:08:07 2007 From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=) Date: Sun, 02 Sep 2007 20:08:07 -0000 Subject: [issue1019] Cleanup pass on _curses and _curses_panel Message-ID: <1188763687.21.0.896164927498.issue1019@psf.upfronthosting.co.za> Changes by Martin v. L?wis: ---------- keywords: +patch __________________________________ Tracker __________________________________ From report at bugs.python.org Sun Sep 2 22:08:29 2007 From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=) Date: Sun, 02 Sep 2007 20:08:29 -0000 Subject: [issue1022] use bytes for code objects Message-ID: <1188763709.76.0.364334575068.issue1022@psf.upfronthosting.co.za> Changes by Martin v. L?wis: ---------- keywords: +patch __________________________________ Tracker __________________________________ From report at bugs.python.org Sun Sep 2 22:08:40 2007 From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=) Date: Sun, 02 Sep 2007 20:08:40 -0000 Subject: [issue1026] Backport ABC to 2.6 Message-ID: <1188763720.44.0.697335150134.issue1026@psf.upfronthosting.co.za> Changes by Martin v. L?wis: ---------- keywords: +patch __________________________________ Tracker __________________________________ From report at bugs.python.org Sun Sep 2 22:08:49 2007 From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=) Date: Sun, 02 Sep 2007 20:08:49 -0000 Subject: [issue1027] uudecoding (uu.py) does not supprt base64, patch attached Message-ID: <1188763729.16.0.398763181528.issue1027@psf.upfronthosting.co.za> Changes by Martin v. L?wis: ---------- keywords: +patch __________________________________ Tracker __________________________________ From report at bugs.python.org Sun Sep 2 22:09:03 2007 From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=) Date: Sun, 02 Sep 2007 20:09:03 -0000 Subject: [issue1032] Improve the hackish runtime_library_dirs support for gcc Message-ID: <1188763743.17.0.546485998773.issue1032@psf.upfronthosting.co.za> Changes by Martin v. L?wis: ---------- keywords: +patch __________________________________ Tracker __________________________________ From report at bugs.python.org Sun Sep 2 22:09:16 2007 From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=) Date: Sun, 02 Sep 2007 20:09:16 -0000 Subject: [issue1034] [patch] Add 2to3 support for displaying warnings as Python comments Message-ID: <1188763756.12.0.532597732721.issue1034@psf.upfronthosting.co.za> Changes by Martin v. L?wis: ---------- keywords: +patch __________________________________ Tracker __________________________________ From report at bugs.python.org Sun Sep 2 22:09:31 2007 From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=) Date: Sun, 02 Sep 2007 20:09:31 -0000 Subject: [issue1043] test_builtin failure on Windows Message-ID: <1188763771.92.0.86699948924.issue1043@psf.upfronthosting.co.za> Changes by Martin v. L?wis: ---------- keywords: +patch __________________________________ Tracker __________________________________ From report at bugs.python.org Sun Sep 2 22:09:55 2007 From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=) Date: Sun, 02 Sep 2007 20:09:55 -0000 Subject: [issue1047] py3k: corrections for test_subprocess on windows Message-ID: <1188763795.63.0.239103712711.issue1047@psf.upfronthosting.co.za> Changes by Martin v. L?wis: ---------- keywords: +patch __________________________________ Tracker __________________________________ From report at bugs.python.org Sun Sep 2 22:11:25 2007 From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=) Date: Sun, 02 Sep 2007 20:11:25 -0000 Subject: [issue1061] ABC caches should use weak refs Message-ID: <1188763885.12.0.130759499262.issue1061@psf.upfronthosting.co.za> Changes by Martin v. L?wis: ---------- keywords: +patch __________________________________ Tracker __________________________________ From report at bugs.python.org Sun Sep 2 22:11:39 2007 From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=) Date: Sun, 02 Sep 2007 20:11:39 -0000 Subject: [issue1071] unicode.translate() doesn't error out on invalid translation table Message-ID: <1188763899.62.0.86264355851.issue1071@psf.upfronthosting.co.za> Changes by Martin v. L?wis: ---------- keywords: +patch __________________________________ Tracker __________________________________ From report at bugs.python.org Sun Sep 2 22:11:48 2007 From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=) Date: Sun, 02 Sep 2007 20:11:48 -0000 Subject: [issue1075] py3k: Unicode error in os.stat on Windows Message-ID: <1188763908.69.0.94418920173.issue1075@psf.upfronthosting.co.za> Changes by Martin v. L?wis: ---------- keywords: +patch __________________________________ Tracker __________________________________ From report at bugs.python.org Sun Sep 2 22:11:57 2007 From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=) Date: Sun, 02 Sep 2007 20:11:57 -0000 Subject: [issue1076] py3 patch: full Unicode version for winreg module Message-ID: <1188763917.5.0.441330558643.issue1076@psf.upfronthosting.co.za> Changes by Martin v. L?wis: ---------- keywords: +patch __________________________________ Tracker __________________________________ From report at bugs.python.org Sun Sep 2 22:16:46 2007 From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=) Date: Sun, 02 Sep 2007 20:16:46 -0000 Subject: [issue1086] test_email failed Message-ID: <1188764206.92.0.562049473364.issue1086@psf.upfronthosting.co.za> Martin v. L?wis added the comment: I don't think recoding the message is the right thing to do. Instead, the email package should be fixed to not treat the bytes before the first part of a multipart message as text, or else assume that it is Latin-1 encoded (it's certainly not *meant* to be text to be shown to the user - it's a fallback for MUAs which don't support MIME (whether it then is a smart thing to Danish with Latin-1 is a different question)) ---------- assignee: -> barry nosy: +barry, loewis __________________________________ Tracker __________________________________ From report at bugs.python.org Sun Sep 2 23:00:13 2007 From: report at bugs.python.org (Graham Horler) Date: Sun, 02 Sep 2007 21:00:13 -0000 Subject: [issue1088] News page broken link to 3.0a1 Message-ID: <1188766813.17.0.0415268003113.issue1088@psf.upfronthosting.co.za> New submission from Graham Horler: The news page: http://www.python.org/news/ ...has a relative link: first alpha release ...which resolves to: http://www.python.org/news/download/releases/3.0 ...which does not exist. It should be absolute: http://www.python.org/download/releases/3.0/ ---------- messages: 55593 nosy: grahamh severity: normal status: open title: News page broken link to 3.0a1 type: behavior versions: Python 3.0 __________________________________ Tracker __________________________________ From report at bugs.python.org Sun Sep 2 23:00:13 2007 From: report at bugs.python.org (Graham Horler) Date: Sun, 02 Sep 2007 21:00:13 -0000 Subject: [issue1088] News page broken link to 3.0a1 Message-ID: <1188766813.17.0.0415268003113.issue1088@psf.upfronthosting.co.za> New submission from Graham Horler: The news page: http://www.python.org/news/ ...has a relative link: first alpha release ...which resolves to: http://www.python.org/news/download/releases/3.0 ...which does not exist. It should be absolute: http://www.python.org/download/releases/3.0/ ---------- messages: 55593 nosy: grahamh severity: normal status: open title: News page broken link to 3.0a1 type: behavior versions: Python 3.0 __________________________________ Tracker __________________________________ From report at bugs.python.org Sun Sep 2 23:13:59 2007 From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=) Date: Sun, 02 Sep 2007 21:13:59 -0000 Subject: [issue1088] News page broken link to 3.0a1 Message-ID: <1188767639.19.0.579381831278.issue1088@psf.upfronthosting.co.za> Martin v. L?wis added the comment: Thanks for the report. This is now fixed. ---------- nosy: +loewis resolution: -> fixed status: open -> closed __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Sep 3 00:53:44 2007 From: report at bugs.python.org (Adam Wieckowski) Date: Sun, 02 Sep 2007 22:53:44 -0000 Subject: [issue1089] ever considered adding static typing to python? Message-ID: <1188773624.26.0.970551796215.issue1089@psf.upfronthosting.co.za> Changes by Adam Wieckowski: ---------- components: Interpreter Core severity: minor status: open title: ever considered adding static typing to python? type: rfe versions: 3rd party __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Sep 3 00:53:54 2007 From: report at bugs.python.org (Adam Wieckowski) Date: Sun, 02 Sep 2007 22:53:54 -0000 Subject: [issue1089] ever considered adding static typing to python? Message-ID: <1188773634.41.0.349121289649.issue1089@psf.upfronthosting.co.za> Changes by Adam Wieckowski: ---------- type: rfe -> __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Sep 3 04:02:01 2007 From: report at bugs.python.org (Waldemar Osuch) Date: Mon, 03 Sep 2007 02:02:01 -0000 Subject: [issue1090] doctools/sphinx/web/application.py does not start on windows Message-ID: <1188784920.26.0.259040643961.issue1090@psf.upfronthosting.co.za> New submission from Waldemar Osuch: Loading pickles on windows without specifying 'rb' does not work in http://svn.python.org/projects/doctools/trunk/sphinx/web/application.py A simple patch attached ---------- components: Documentation tools (Sphinx) files: sphinx_web_application.patch messages: 55595 nosy: osuchw severity: normal status: open title: doctools/sphinx/web/application.py does not start on windows type: crash __________________________________ Tracker __________________________________ -------------- next part -------------- A non-text attachment was scrubbed... Name: sphinx_web_application.patch Type: application/octet-stream Size: 1059 bytes Desc: not available Url : http://mail.python.org/pipermail/python-bugs-list/attachments/20070903/ac884085/attachment-0001.obj From report at bugs.python.org Mon Sep 3 04:02:00 2007 From: report at bugs.python.org (Waldemar Osuch) Date: Mon, 03 Sep 2007 02:02:00 -0000 Subject: [issue1090] doctools/sphinx/web/application.py does not start on windows Message-ID: <1188784920.26.0.259040643961.issue1090@psf.upfronthosting.co.za> New submission from Waldemar Osuch: Loading pickles on windows without specifying 'rb' does not work in http://svn.python.org/projects/doctools/trunk/sphinx/web/application.py A simple patch attached ---------- components: Documentation tools (Sphinx) files: sphinx_web_application.patch messages: 55595 nosy: osuchw severity: normal status: open title: doctools/sphinx/web/application.py does not start on windows type: crash __________________________________ Tracker __________________________________ -------------- next part -------------- A non-text attachment was scrubbed... Name: sphinx_web_application.patch Type: application/octet-stream Size: 1059 bytes Desc: not available Url : http://mail.python.org/pipermail/python-bugs-list/attachments/20070903/ac884085/attachment-0002.obj From report at bugs.python.org Mon Sep 3 04:12:56 2007 From: report at bugs.python.org (Humberto Diogenes) Date: Mon, 03 Sep 2007 02:12:56 -0000 Subject: [issue1091] [patch] py3k Mac installation errors Message-ID: <1188785576.14.0.654103723066.issue1091@psf.upfronthosting.co.za> New submission from Humberto Diogenes: This patch addresses 3 simple errors (1 syntax, 1 runtime, 1 import) when doing a "make altinstall" on Mac OS X, including the error listed in issue 1078. ---------- components: Installation, Macintosh files: py3k-mac-install-1.patch messages: 55596 nosy: hdiogenes severity: normal status: open title: [patch] py3k Mac installation errors type: compile error versions: Python 3.0 __________________________________ Tracker __________________________________ -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: py3k-mac-install-1.patch Url: http://mail.python.org/pipermail/python-bugs-list/attachments/20070903/28a21476/attachment.txt From report at bugs.python.org Mon Sep 3 04:12:56 2007 From: report at bugs.python.org (Humberto Diogenes) Date: Mon, 03 Sep 2007 02:12:56 -0000 Subject: [issue1091] [patch] py3k Mac installation errors Message-ID: <1188785576.14.0.654103723066.issue1091@psf.upfronthosting.co.za> New submission from Humberto Diogenes: This patch addresses 3 simple errors (1 syntax, 1 runtime, 1 import) when doing a "make altinstall" on Mac OS X, including the error listed in issue 1078. ---------- components: Installation, Macintosh files: py3k-mac-install-1.patch messages: 55596 nosy: hdiogenes severity: normal status: open title: [patch] py3k Mac installation errors type: compile error versions: Python 3.0 __________________________________ Tracker __________________________________ -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: py3k-mac-install-1.patch Url: http://mail.python.org/pipermail/python-bugs-list/attachments/20070903/28a21476/attachment-0001.txt From report at bugs.python.org Mon Sep 3 04:37:02 2007 From: report at bugs.python.org (Brett Cannon) Date: Mon, 03 Sep 2007 02:37:02 -0000 Subject: [issue1022] use bytes for code objects Message-ID: <1188787022.7.0.0232367543222.issue1022@psf.upfronthosting.co.za> Brett Cannon added the comment: I have security/stability issues with code objects having mutable bytecode. This would allow someone to possibly crash the interpreter with crappy bytecode. I also have a worry that someone might come up with some clever way of causing different code to execute through manipulating what LOAD_GLOBALS or STORE_GLOBALS accesses/sets. ---------- nosy: +brett.cannon __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Sep 3 05:36:47 2007 From: report at bugs.python.org (Vizcaynot) Date: Mon, 03 Sep 2007 03:36:47 -0000 Subject: [issue1092] Unexpected results in Tutorial about Unicode Message-ID: <1188790607.8.0.739401966069.issue1092@psf.upfronthosting.co.za> New submission from Vizcaynot: When trying the tutorial example about unicode I have: >>> "?pfel".encode('utf-8') File "", line 1 SyntaxError: (unicode error) unexpected code byte I live in a latin american country so I need to do: >>> "?pfel".decode('latin-1).encode('utf-8') File "", line 1 >>> but the indentation " >>>" is new for me, so I attempt the next: >>> a="?pfel".decode('latin-1).encode('utf-8') File "", line 1 >>> a b'\xc3\x84pfel' >>> print (a) ?pfel >>> Is this necessary to do correction to the tutorial? is this normal the presence of " >>>" that appears indented once I assign the value to variable a? Thanks!! ---------- components: Unicode messages: 55598 nosy: Viscaynot severity: normal status: open title: Unexpected results in Tutorial about Unicode type: behavior versions: Python 3.0 __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Sep 3 05:36:47 2007 From: report at bugs.python.org (Vizcaynot) Date: Mon, 03 Sep 2007 03:36:47 -0000 Subject: [issue1092] Unexpected results in Tutorial about Unicode Message-ID: <1188790607.8.0.739401966069.issue1092@psf.upfronthosting.co.za> New submission from Vizcaynot: When trying the tutorial example about unicode I have: >>> "?pfel".encode('utf-8') File "", line 1 SyntaxError: (unicode error) unexpected code byte I live in a latin american country so I need to do: >>> "?pfel".decode('latin-1).encode('utf-8') File "", line 1 >>> but the indentation " >>>" is new for me, so I attempt the next: >>> a="?pfel".decode('latin-1).encode('utf-8') File "", line 1 >>> a b'\xc3\x84pfel' >>> print (a) ?pfel >>> Is this necessary to do correction to the tutorial? is this normal the presence of " >>>" that appears indented once I assign the value to variable a? Thanks!! ---------- components: Unicode messages: 55598 nosy: Viscaynot severity: normal status: open title: Unexpected results in Tutorial about Unicode type: behavior versions: Python 3.0 __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Sep 3 06:27:01 2007 From: report at bugs.python.org (Ryan Freckleton) Date: Mon, 03 Sep 2007 04:27:01 -0000 Subject: [issue1093] product function patch Message-ID: <1188793621.44.0.829352690198.issue1093@psf.upfronthosting.co.za> New submission from Ryan Freckleton: This is a patch to implement a product() builtin function. It works behaves similarly to reduce(operator.mul,...) but is implemented in C. Tests and documentation are included in this patch. ---------- components: Documentation, Library (Lib), Tests files: product_function.diff messages: 55599 nosy: ryan.freckleton severity: normal status: open title: product function patch type: behavior versions: Python 2.6 __________________________________ Tracker __________________________________ -------------- next part -------------- A non-text attachment was scrubbed... Name: product_function.diff Type: text/x-patch Size: 3636 bytes Desc: not available Url : http://mail.python.org/pipermail/python-bugs-list/attachments/20070903/ad3b4154/attachment-0001.bin From report at bugs.python.org Mon Sep 3 06:27:02 2007 From: report at bugs.python.org (Ryan Freckleton) Date: Mon, 03 Sep 2007 04:27:02 -0000 Subject: [issue1093] product function patch Message-ID: <1188793621.44.0.829352690198.issue1093@psf.upfronthosting.co.za> New submission from Ryan Freckleton: This is a patch to implement a product() builtin function. It works behaves similarly to reduce(operator.mul,...) but is implemented in C. Tests and documentation are included in this patch. ---------- components: Documentation, Library (Lib), Tests files: product_function.diff messages: 55599 nosy: ryan.freckleton severity: normal status: open title: product function patch type: behavior versions: Python 2.6 __________________________________ Tracker __________________________________ -------------- next part -------------- A non-text attachment was scrubbed... Name: product_function.diff Type: text/x-patch Size: 3636 bytes Desc: not available Url : http://mail.python.org/pipermail/python-bugs-list/attachments/20070903/ad3b4154/attachment-0002.bin From report at bugs.python.org Mon Sep 3 07:22:24 2007 From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=) Date: Mon, 03 Sep 2007 05:22:24 -0000 Subject: [issue1093] product function patch Message-ID: <1188796944.13.0.931685795704.issue1093@psf.upfronthosting.co.za> Martin v. L?wis added the comment: -1. I doubt this is needed often enough to justify a builtin function. ---------- nosy: +loewis __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Sep 3 07:58:10 2007 From: report at bugs.python.org (Guido van Rossum) Date: Mon, 03 Sep 2007 05:58:10 -0000 Subject: [issue1093] product function patch Message-ID: <1188799090.23.0.321750116014.issue1093@psf.upfronthosting.co.za> Guido van Rossum added the comment: Thanks, but no thanks; I was quickly dissuaded from the need for this. ---------- nosy: +gvanrossum resolution: -> rejected status: open -> closed __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Sep 3 08:57:55 2007 From: report at bugs.python.org (Humberto Diogenes) Date: Mon, 03 Sep 2007 06:57:55 -0000 Subject: [issue1091] [patch] py3k Mac installation errors Message-ID: <1188802675.11.0.198859597515.issue1091@psf.upfronthosting.co.za> Humberto Diogenes added the comment: One more patch, for: 1. Writing str to binary file; 2. Using string exceptions. Traceback for #2: /usr/bin/install -c -s ../python.exe "/Library/Frameworks/Python.framework/Versions/3.0/Resources/Python.app/ Contents/MacOS/Python" DYLD_FRAMEWORK_PATH=/Users/humberto/src/open/py3k: ../python.exe ./scripts/BuildApplet.py \ --destroot "" \ --python /Library/Frameworks/Python.framework/Versions/3.0/Resources/Python.app/C ontents/MacOS/Python \ --output "/Applications/MacPython 3.0/Build Applet.app" \ ./scripts/BuildApplet.py ./scripts/BuildApplet.py:16: DeprecationWarning: the buildtools module is deprecated import buildtools Traceback (most recent call last): File "./scripts/BuildApplet.py", line 149, in main() File "./scripts/BuildApplet.py", line 34, in main except buildtools.BuildError as detail: TypeError: catching classes that do not inherit from BaseException is not allowed make[1]: *** [install_BuildApplet] Error 1 make: *** [frameworkinstallapps] Error 2 After applying those two attached patches, I was able to succesfully run "make altinstall" (not without some other warnings, though). __________________________________ Tracker __________________________________ -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: py3k-mac-install-2.patch Url: http://mail.python.org/pipermail/python-bugs-list/attachments/20070903/ace11c69/attachment.txt From report at bugs.python.org Mon Sep 3 09:08:04 2007 From: report at bugs.python.org (Georg Brandl) Date: Mon, 03 Sep 2007 07:08:04 -0000 Subject: [issue1092] Unexpected results in Tutorial about Unicode In-Reply-To: <1188790607.8.0.739401966069.issue1092@psf.upfronthosting.co.za> Message-ID: <46DBB2D4.5040908@gmx.net> Georg Brandl added the comment: Vizcaynot schrieb: > New submission from Vizcaynot: > > When trying the tutorial example about unicode I have: >>>> "?pfel".encode('utf-8') > File "", line 1 > SyntaxError: (unicode error) unexpected code byte This is definitely a bug. Assigning to Martin to investigate. ---------- assignee: -> loewis nosy: +georg.brandl, loewis __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Sep 3 09:12:37 2007 From: report at bugs.python.org (Georg Brandl) Date: Mon, 03 Sep 2007 07:12:37 -0000 Subject: [issue1090] doctools/sphinx/web/application.py does not start on windows In-Reply-To: <1188784920.26.0.259040643961.issue1090@psf.upfronthosting.co.za> Message-ID: <46DBB3E5.4080903@gmx.net> Georg Brandl added the comment: Waldemar Osuch schrieb: > New submission from Waldemar Osuch: > > Loading pickles on windows without specifying 'rb' does not work in > http://svn.python.org/projects/doctools/trunk/sphinx/web/application.py > A simple patch attached Thanks, applied in rev. 57924. If further Windows problems arise, let me know. ---------- nosy: +georg.brandl resolution: -> fixed status: open -> closed title: doctools/sphinx/web/application.py does not start on windows -> doctools/sphinx/web/application.py does not start on windows __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Sep 3 09:16:18 2007 From: report at bugs.python.org (Humberto Diogenes) Date: Mon, 03 Sep 2007 07:16:18 -0000 Subject: [issue1091] [patch] py3k Mac installation errors Message-ID: <1188803778.0.0.962433466931.issue1091@psf.upfronthosting.co.za> Humberto Diogenes added the comment: Patch 3: some more trivial fixes: new syntax for print() and octal numbers. __________________________________ Tracker __________________________________ -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: py3k-mac-install-3-trivial.patch Url: http://mail.python.org/pipermail/python-bugs-list/attachments/20070903/2060ed5e/attachment.txt From report at bugs.python.org Mon Sep 3 09:17:14 2007 From: report at bugs.python.org (Georg Brandl) Date: Mon, 03 Sep 2007 07:17:14 -0000 Subject: [issue883466] quopri encoding & Unicode Message-ID: <1188803834.07.0.146993285195.issue883466@psf.upfronthosting.co.za> Georg Brandl added the comment: Okay, changed in rev. 57925. Closing this as fixed. ---------- resolution: -> fixed status: open -> closed ____________________________________ Tracker ____________________________________ From report at bugs.python.org Mon Sep 3 09:22:33 2007 From: report at bugs.python.org (Georg Brandl) Date: Mon, 03 Sep 2007 07:22:33 -0000 Subject: [issue1078] cachersrc.py using tuple unpacking args In-Reply-To: <1188750040.68.0.685759817552.issue1078@psf.upfronthosting.co.za> Message-ID: <46DBB63B.104@gmx.net> Georg Brandl added the comment: Superseded by #1091 patches. ---------- nosy: +georg.brandl resolution: -> duplicate status: open -> closed superseder: -> [patch] py3k Mac installation errors __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Sep 3 09:30:45 2007 From: report at bugs.python.org (Georg Brandl) Date: Mon, 03 Sep 2007 07:30:45 -0000 Subject: [issue1043] test_builtin failure on Windows Message-ID: <1188804645.55.0.261921570832.issue1043@psf.upfronthosting.co.za> Georg Brandl added the comment: This was apparently fixed by Thomas with rev. 57828. ---------- nosy: +georg.brandl resolution: -> fixed status: open -> closed __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Sep 3 09:31:15 2007 From: report at bugs.python.org (Georg Brandl) Date: Mon, 03 Sep 2007 07:31:15 -0000 Subject: [issue1091] py3k Mac installation errors In-Reply-To: <1188803778.0.0.962433466931.issue1091@psf.upfronthosting.co.za> Message-ID: <46DBB841.1030301@gmx.net> Georg Brandl added the comment: Thanks for the patches, I've applied them as rev. 57926. ---------- nosy: +georg.brandl resolution: -> accepted status: open -> closed title: [patch] py3k Mac installation errors -> py3k Mac installation errors __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Sep 3 09:32:32 2007 From: report at bugs.python.org (Georg Brandl) Date: Mon, 03 Sep 2007 07:32:32 -0000 Subject: [issue1045] Performance regression in 2.5 In-Reply-To: <1188612109.5.0.491793802821.issue1045@psf.upfronthosting.co.za> Message-ID: <46DBB892.3040107@gmx.net> Georg Brandl added the comment: May this be a byproduct of the new generator features in 2.5? ---------- nosy: +georg.brandl __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Sep 3 09:34:17 2007 From: report at bugs.python.org (Georg Brandl) Date: Mon, 03 Sep 2007 07:34:17 -0000 Subject: [issue1077] itertools missing, causes interactive help to break In-Reply-To: <1188608407.47.0.483489642185.issue1077@psf.upfronthosting.co.za> Message-ID: <46DBB8FA.3090102@gmx.net> New submission from Georg Brandl: Python 3.0a1 includes itertools and normally builds it, so the interesting thing would be why it isn't present on your system :) Have you built Python yourself? If so, can you provide build logs and/or error messages? ---------- nosy: +georg.brandl __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Sep 3 09:42:28 2007 From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=) Date: Mon, 03 Sep 2007 07:42:28 -0000 Subject: [issue1075] py3k: Unicode error in os.stat on Windows Message-ID: <1188805348.1.0.380016442359.issue1075@psf.upfronthosting.co.za> Martin v. L?wis added the comment: I could not quite reproduce this on the German version (the error text reads " Das System kann die angegebene Datei nicht finden" on XP), however, the patch looks good and it fixes the same problem for the registry functions (where I get "Das Handle ist ung?ltig"), so I committed it as r57927. ---------- nosy: +loewis resolution: -> accepted status: open -> closed __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Sep 3 09:44:06 2007 From: report at bugs.python.org (Georg Brandl) Date: Mon, 03 Sep 2007 07:44:06 -0000 Subject: [issue1071] unicode.translate() doesn't error out on invalid translation table Message-ID: <1188805446.57.0.513641501061.issue1071@psf.upfronthosting.co.za> Georg Brandl added the comment: Yes, that makes sense. New patch attached, copying the dict and using PyDict_Next. __________________________________ Tracker __________________________________ -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: uni_xlate2.diff Url: http://mail.python.org/pipermail/python-bugs-list/attachments/20070903/eab7665b/attachment.txt From report at bugs.python.org Mon Sep 3 09:45:52 2007 From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=) Date: Mon, 03 Sep 2007 07:45:52 -0000 Subject: [issue1076] py3 patch: full Unicode version for winreg module Message-ID: <1188805552.83.0.957430571285.issue1076@psf.upfronthosting.co.za> Martin v. L?wis added the comment: Thanks for the patch. Committed as r57928 ---------- resolution: -> accepted status: open -> closed __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Sep 3 09:47:21 2007 From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=) Date: Mon, 03 Sep 2007 07:47:21 -0000 Subject: [issue1089] ever considered adding static typing to python? Message-ID: <1188805641.29.0.827860226533.issue1089@psf.upfronthosting.co.za> New submission from Martin v. L?wis: Yes. ---------- nosy: +loewis resolution: -> wont fix status: open -> closed __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Sep 3 09:47:27 2007 From: report at bugs.python.org (Humberto Diogenes) Date: Mon, 03 Sep 2007 07:47:27 -0000 Subject: [issue1091] py3k Mac installation errors Message-ID: <1188805647.25.0.30108262396.issue1091@psf.upfronthosting.co.za> Humberto Diogenes added the comment: And thanks for accepting them! (without complaining about my errors :-) __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Sep 3 11:07:07 2007 From: report at bugs.python.org (Serge Julien) Date: Mon, 03 Sep 2007 09:07:07 -0000 Subject: [issue1094] TypeError in poplib.py Message-ID: <1188810427.64.0.302486588482.issue1094@psf.upfronthosting.co.za> New submission from Serge Julien: In poplib.py, lines 137-138, bytes and str are compared, leading to a TypeError: [...] 137 while line != '.': 138 if line[:2] == '..': [...] where type(line) = ---------- components: Library (Lib) messages: 55617 nosy: serge.julien severity: normal status: open title: TypeError in poplib.py versions: Python 3.0 __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Sep 3 11:07:07 2007 From: report at bugs.python.org (Serge Julien) Date: Mon, 03 Sep 2007 09:07:07 -0000 Subject: [issue1094] TypeError in poplib.py Message-ID: <1188810427.64.0.302486588482.issue1094@psf.upfronthosting.co.za> New submission from Serge Julien: In poplib.py, lines 137-138, bytes and str are compared, leading to a TypeError: [...] 137 while line != '.': 138 if line[:2] == '..': [...] where type(line) = ---------- components: Library (Lib) messages: 55617 nosy: serge.julien severity: normal status: open title: TypeError in poplib.py versions: Python 3.0 __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Sep 3 11:37:30 2007 From: report at bugs.python.org (Serge Julien) Date: Mon, 03 Sep 2007 09:37:30 -0000 Subject: [issue1094] TypeError in poplib.py Message-ID: <1188812250.82.0.717054194519.issue1094@psf.upfronthosting.co.za> Serge Julien added the comment: Patch proposal. Tell me if it's right to submit it here: this is the first patch I submit __________________________________ Tracker __________________________________ -------------- next part -------------- A non-text attachment was scrubbed... Name: poplib.diff Type: application/octet-stream Size: 459 bytes Desc: not available Url : http://mail.python.org/pipermail/python-bugs-list/attachments/20070903/230ff790/attachment-0001.obj From report at bugs.python.org Mon Sep 3 11:46:09 2007 From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=) Date: Mon, 03 Sep 2007 09:46:09 -0000 Subject: [issue1094] TypeError in poplib.py Message-ID: <1188812769.25.0.0732199058875.issue1094@psf.upfronthosting.co.za> Changes by Martin v. L?wis: ---------- keywords: +patch __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Sep 3 14:32:22 2007 From: report at bugs.python.org (=?utf-8?q?=0A=09=09=09=09=09vila-sf=0A=09=09=09=09?=) Date: Mon, 03 Sep 2007 12:32:22 -0000 Subject: [issue1114345] Add SSL certificate validation In-Reply-To: <1188495728.66.0.356372628423.issue1114345@psf.upfronthosting.co.za> (Bill Janssen's message of "Thu, 30 Aug 2007 17:42:08 -0000") Message-ID: vila-sf added the comment: Using CERT_NONE or adding the cert covers my needs, thanks. Any hope this will be backported to python 2.5 ? _____________________________________ Tracker _____________________________________ From report at bugs.python.org Mon Sep 3 14:52:11 2007 From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=) Date: Mon, 03 Sep 2007 12:52:11 -0000 Subject: [issue1114345] Add SSL certificate validation Message-ID: <1188823931.16.0.189052747155.issue1114345@psf.upfronthosting.co.za> Martin v. L?wis added the comment: There definitely won't be any new features in 2.5.x. However, I think Bill said he might make this available separately. _____________________________________ Tracker _____________________________________ From report at bugs.python.org Mon Sep 3 17:25:44 2007 From: report at bugs.python.org (Thomas Heller) Date: Mon, 03 Sep 2007 15:25:44 -0000 Subject: [issue1777530] ctypes on Solaris Message-ID: <1188833144.06.0.661672424144.issue1777530@psf.upfronthosting.co.za> Thomas Heller added the comment: This is an experimental patch (solaris.patch). Can you please proofread it and try it out on the solaris machine? _____________________________________ Tracker _____________________________________ -------------- next part -------------- A non-text attachment was scrubbed... Name: solaris.patch Type: text/x-patch Size: 1046 bytes Desc: not available Url : http://mail.python.org/pipermail/python-bugs-list/attachments/20070903/0057622f/attachment.bin From report at bugs.python.org Mon Sep 3 18:49:55 2007 From: report at bugs.python.org (Bill Janssen) Date: Mon, 03 Sep 2007 16:49:55 -0000 Subject: [issue1114345] Add SSL certificate validation In-Reply-To: Message-ID: <7EA3C891-D4A1-419D-9DF9-DEAB281A92E6@gmail.com> Bill Janssen added the comment: I'm planning to do a package for 2.3... Sent from my iPhone On Sep 3, 2007, at 5:32 AM, vila-sf wrote: > > > vila-sf > added the comment: > > Using CERT_NONE or adding the cert covers my needs, thanks. > > Any hope this will be backported to python 2.5 ? > > _____________________________________ > Tracker > > _____________________________________ _____________________________________ Tracker _____________________________________ From report at bugs.python.org Mon Sep 3 18:55:46 2007 From: report at bugs.python.org (Aki) Date: Mon, 03 Sep 2007 16:55:46 -0000 Subject: [issue1777530] ctypes on Solaris Message-ID: <1188838546.56.0.706514912322.issue1777530@psf.upfronthosting.co.za> Aki added the comment: Hello Thomas, Thank you for creating the patch. Unfortunately, it didn't work. (I rerun the whole installation process) You used the following to check if the os is Solaris: if sys.platform.startswith("solaris"): Under Solaris 2.x sys.platform returns "sunos5". You could use ...startswith("sunos") but things may be different under "sunos6" so I usually prefer to use sys.platform == "sunos5". After fixing this, my application with ctypes works okay. I'm happy to try out if you create another patch. Thank you, Aki- _____________________________________ Tracker _____________________________________ From report at bugs.python.org Mon Sep 3 19:09:15 2007 From: report at bugs.python.org (Aki) Date: Mon, 03 Sep 2007 17:09:15 -0000 Subject: [issue1095] make install failed Message-ID: <1188839355.89.0.39344138919.issue1095@psf.upfronthosting.co.za> New submission from Aki: I thought this was already reported but I didn't see it in the list. If this issue is already addressed, please discard. The 'make install' failed if I re-run the installation again because python-config under /usr/local/bin was already there. Removing /usr/local/lib/python2.5/lib-dynload/Python-2.5.1-py2.5.egg-info Writing /usr/local/lib/python2.5/lib-dynload/Python-2.5.1-py2.5.egg-info if test -f /usr/local/bin/python -o -h /usr/local/bin/python; \ then rm -f /usr/local/bin/python; \ else true; \ fi (cd /usr/local/bin; ln python2.5 python) (cd /usr/local/bin; ln -sf python2.5-config python-config) ln: cannot create python-config: File exists make: *** [bininstall] Error 2 I didn't see such problem under 2.4. Aki- ---------- components: Installation messages: 55624 nosy: akineko severity: normal status: open title: make install failed versions: Python 2.5 __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Sep 3 19:09:16 2007 From: report at bugs.python.org (Aki) Date: Mon, 03 Sep 2007 17:09:16 -0000 Subject: [issue1095] make install failed Message-ID: <1188839355.89.0.39344138919.issue1095@psf.upfronthosting.co.za> New submission from Aki: I thought this was already reported but I didn't see it in the list. If this issue is already addressed, please discard. The 'make install' failed if I re-run the installation again because python-config under /usr/local/bin was already there. Removing /usr/local/lib/python2.5/lib-dynload/Python-2.5.1-py2.5.egg-info Writing /usr/local/lib/python2.5/lib-dynload/Python-2.5.1-py2.5.egg-info if test -f /usr/local/bin/python -o -h /usr/local/bin/python; \ then rm -f /usr/local/bin/python; \ else true; \ fi (cd /usr/local/bin; ln python2.5 python) (cd /usr/local/bin; ln -sf python2.5-config python-config) ln: cannot create python-config: File exists make: *** [bininstall] Error 2 I didn't see such problem under 2.4. Aki- ---------- components: Installation messages: 55624 nosy: akineko severity: normal status: open title: make install failed versions: Python 2.5 __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Sep 3 23:22:29 2007 From: report at bugs.python.org (Mike Coleman) Date: Mon, 03 Sep 2007 21:22:29 -0000 Subject: [issue852532] ^$ won't split on empty line Message-ID: <1188854549.5.0.903815986295.issue852532@psf.upfronthosting.co.za> Mike Coleman added the comment: Well, I think we can conclude that it's expected by *them*. :-) I still find it surprising, and it somewhat lessens the utility of re.split for my use cases. (I think re.finditer may also suffer from the same problem, but I don't recall.) If you look at the comments attached to the patch for this bug, it looks like akuchling and rhettinger more or less saw this as being a bug worth fixing, though there were questions about exactly what the correct fix should be. http://bugs.python.org/issue988761 One comment about the your doc fix: You highlight a fairly useless zero-character match (e.g., "x*") to demonstrate the behavior, which might leave the user scratching his head. (I think this case was originally mentioned as a corner case, not one that would be useful.) It'd be nice to highlight a more useful case like '^(?=S)' or perhaps a little more generically something like '^(?=HEADER)' or '^(?=BEGIN)' which is a usage that tripped me up in the first place. Thanks for working on this! ____________________________________ Tracker ____________________________________ From report at bugs.python.org Tue Sep 4 04:21:41 2007 From: report at bugs.python.org (Sangpil Yoon) Date: Tue, 04 Sep 2007 02:21:41 -0000 Subject: [issue1097] input() should respect sys.stdin.encoding when in interactive mode Message-ID: <1188872501.42.0.387468131145.issue1097@psf.upfronthosting.co.za> New submission from Sangpil Yoon: Currently in interactive mode, when you try to input non-ascii characters using input() builtin function, you get UnicodeDecodeError. >>> print(input()) ??? Traceback (most recent call last): File "", line 1, in UnicodeDecodeError: 'utf8' codec can't decode bytes in position 0-1: illegal encoding The error says that input() function is trying to decode the byte string using the utf8 codec, when sys.stdin.encoding is not 'utf8'. >>> import sys; print(sys.stdin.encoding) cp949 In non-interactive mode, input() works just fine. ---------- components: Unicode messages: 55627 nosy: philyoon severity: normal status: open title: input() should respect sys.stdin.encoding when in interactive mode type: behavior versions: Python 3.0 __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Sep 4 04:21:42 2007 From: report at bugs.python.org (Sangpil Yoon) Date: Tue, 04 Sep 2007 02:21:42 -0000 Subject: [issue1097] input() should respect sys.stdin.encoding when in interactive mode Message-ID: <1188872501.42.0.387468131145.issue1097@psf.upfronthosting.co.za> New submission from Sangpil Yoon: Currently in interactive mode, when you try to input non-ascii characters using input() builtin function, you get UnicodeDecodeError. >>> print(input()) ??? Traceback (most recent call last): File "", line 1, in UnicodeDecodeError: 'utf8' codec can't decode bytes in position 0-1: illegal encoding The error says that input() function is trying to decode the byte string using the utf8 codec, when sys.stdin.encoding is not 'utf8'. >>> import sys; print(sys.stdin.encoding) cp949 In non-interactive mode, input() works just fine. ---------- components: Unicode messages: 55627 nosy: philyoon severity: normal status: open title: input() should respect sys.stdin.encoding when in interactive mode type: behavior versions: Python 3.0 __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Sep 4 05:01:01 2007 From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=) Date: Tue, 04 Sep 2007 03:01:01 -0000 Subject: [issue1762561] unable to serialize Infinity or NaN on ARM using marshal Message-ID: <1188874861.21.0.124969015951.issue1762561@psf.upfronthosting.co.za> Martin v. L?wis added the comment: I'm not sure like the naming of the format. "mixed-endian" could mean anything. I doubt IEEE specifies this as a possible byte representation (but then, I'm uncertain whether IEEE specifies big-endian and little-endian, either). One option would be to call it "ARM, mixed-endian", assuming this can be only found on ARM. Another option would be to call it "IEEE, bytes-big-words-little-endian", describing precisely how the format works (IIUC). Tim, any opinion? ---------- assignee: -> tim_one nosy: +loewis, tim_one _____________________________________ Tracker _____________________________________ From report at bugs.python.org Tue Sep 4 07:25:44 2007 From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=) Date: Tue, 04 Sep 2007 05:25:44 -0000 Subject: [issue1097] input() should respect sys.stdin.encoding when in interactive mode Message-ID: <1188883544.52.0.026566164648.issue1097@psf.upfronthosting.co.za> Martin v. L?wis added the comment: Thanks for the report. This is now fixed in r57947 ---------- nosy: +loewis resolution: -> fixed status: open -> closed __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Sep 4 07:38:55 2007 From: report at bugs.python.org (Adam Olsen) Date: Tue, 04 Sep 2007 05:38:55 -0000 Subject: [issue1098] decode_unicode doesn't nul-terminate Message-ID: <1188884335.29.0.623763077822.issue1098@psf.upfronthosting.co.za> New submission from Adam Olsen: In the large else branch in decode_unicode (if encoding is not NULL or "iso-8859-1"), the new string it produces is not nul-terminated. This then hits PyUnicode_DecodeUnicodeEscape's octal escape case, which reads past the end of the string (but would stop if there was a nul there.) I found this via valgrind. ---------- messages: 55630 nosy: rhamphoryncus severity: normal status: open title: decode_unicode doesn't nul-terminate __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Sep 4 07:38:55 2007 From: report at bugs.python.org (Adam Olsen) Date: Tue, 04 Sep 2007 05:38:55 -0000 Subject: [issue1098] decode_unicode doesn't nul-terminate Message-ID: <1188884335.29.0.623763077822.issue1098@psf.upfronthosting.co.za> New submission from Adam Olsen: In the large else branch in decode_unicode (if encoding is not NULL or "iso-8859-1"), the new string it produces is not nul-terminated. This then hits PyUnicode_DecodeUnicodeEscape's octal escape case, which reads past the end of the string (but would stop if there was a nul there.) I found this via valgrind. ---------- messages: 55630 nosy: rhamphoryncus severity: normal status: open title: decode_unicode doesn't nul-terminate __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Sep 4 08:17:02 2007 From: report at bugs.python.org (Humberto Diogenes) Date: Tue, 04 Sep 2007 06:17:02 -0000 Subject: [issue1099] Mac compile fails with pydebug and framework enabled Message-ID: <1188886622.31.0.867109013105.issue1099@psf.upfronthosting.co.za> New submission from Humberto Diogenes: Running this on Mac OS X: $ ./configure --with-pydebug --enable-framework $ make I get this: (...) ar cr libpython3.0.a Modules/config.o Modules/getpath.o Modules/main.o Modules/gcmodule.o ar cr libpython3.0.a Modules/threadmodule.o Modules/signalmodule.o Modules/posixmodule.o Modules/errnomodule.o Modules/pwdmodule.o Modules/_sre.o Modules/_codecsmodule.o Modules/_fileio.o Modules/zipimport.o Modules/symtablemodule.o Modules/xxsubtype.o ranlib libpython3.0.a /usr/bin/install -c -d -m 755 Python.framework/Versions/3.0 if test ""; then \ gcc -o Python.framework/Versions/3.0/Python -arch i386 -arch ppc -dynamiclib \ -isysroot "" \ -all_load libpython3.0.a -Wl,-single_module \ -install_name /Library/Frameworks/Python.framework/Versions/3.0/Python \ -compatibility_version 3.0 \ -current_version 3.0; \ else \ /usr/bin/libtool -o Python.framework/Versions/3.0/Python -dynamic libpython3.0.a \ -lSystem -lSystemStubs -arch_only i386 -install_name /Library/Frameworks/Python.framework/Versions/3.0/Python -compatibility_version 3.0 - current_version 3.0 ;\ fi ld: Undefined symbols: ___eprintf /usr/bin/libtool: internal link edit command failed make: *** [Python.framework/Versions/3.0/Python] Error 1 If using only --with-pydebug it works fine. ---------- components: Build, Macintosh messages: 55631 nosy: hdiogenes severity: normal status: open title: Mac compile fails with pydebug and framework enabled versions: Python 3.0 __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Sep 4 08:17:02 2007 From: report at bugs.python.org (Humberto Diogenes) Date: Tue, 04 Sep 2007 06:17:02 -0000 Subject: [issue1099] Mac compile fails with pydebug and framework enabled Message-ID: <1188886622.31.0.867109013105.issue1099@psf.upfronthosting.co.za> New submission from Humberto Diogenes: Running this on Mac OS X: $ ./configure --with-pydebug --enable-framework $ make I get this: (...) ar cr libpython3.0.a Modules/config.o Modules/getpath.o Modules/main.o Modules/gcmodule.o ar cr libpython3.0.a Modules/threadmodule.o Modules/signalmodule.o Modules/posixmodule.o Modules/errnomodule.o Modules/pwdmodule.o Modules/_sre.o Modules/_codecsmodule.o Modules/_fileio.o Modules/zipimport.o Modules/symtablemodule.o Modules/xxsubtype.o ranlib libpython3.0.a /usr/bin/install -c -d -m 755 Python.framework/Versions/3.0 if test ""; then \ gcc -o Python.framework/Versions/3.0/Python -arch i386 -arch ppc -dynamiclib \ -isysroot "" \ -all_load libpython3.0.a -Wl,-single_module \ -install_name /Library/Frameworks/Python.framework/Versions/3.0/Python \ -compatibility_version 3.0 \ -current_version 3.0; \ else \ /usr/bin/libtool -o Python.framework/Versions/3.0/Python -dynamic libpython3.0.a \ -lSystem -lSystemStubs -arch_only i386 -install_name /Library/Frameworks/Python.framework/Versions/3.0/Python -compatibility_version 3.0 - current_version 3.0 ;\ fi ld: Undefined symbols: ___eprintf /usr/bin/libtool: internal link edit command failed make: *** [Python.framework/Versions/3.0/Python] Error 1 If using only --with-pydebug it works fine. ---------- components: Build, Macintosh messages: 55631 nosy: hdiogenes severity: normal status: open title: Mac compile fails with pydebug and framework enabled versions: Python 3.0 __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Sep 4 08:50:40 2007 From: report at bugs.python.org (Sangpil Yoon) Date: Tue, 04 Sep 2007 06:50:40 -0000 Subject: [issue1100] Can't input non-ascii characters in interactive mode Message-ID: <1188888639.72.0.692708341889.issue1100@psf.upfronthosting.co.za> New submission from Sangpil Yoon: I'm not sure if this is a bug or a designed behavior, but I think it would be nice for beginners to be able to enter his/her local characters from an interactive prompt. As interactive mode lacks source code encoding declaration, the interpreter seems to assume that its input is encoded in UTF-8, when the actual characters you enter are not. Fix for issue #1097 doesn't seem to help. I'm using Microsoft Windows XP Korean. >>> print('???') File "", line 1 SyntaxError: (unicode error) illegal encoding ---------- components: Unicode messages: 55632 nosy: philyoon severity: normal status: open title: Can't input non-ascii characters in interactive mode versions: Python 3.0 __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Sep 4 08:50:39 2007 From: report at bugs.python.org (Sangpil Yoon) Date: Tue, 04 Sep 2007 06:50:39 -0000 Subject: [issue1100] Can't input non-ascii characters in interactive mode Message-ID: <1188888639.72.0.692708341889.issue1100@psf.upfronthosting.co.za> New submission from Sangpil Yoon: I'm not sure if this is a bug or a designed behavior, but I think it would be nice for beginners to be able to enter his/her local characters from an interactive prompt. As interactive mode lacks source code encoding declaration, the interpreter seems to assume that its input is encoded in UTF-8, when the actual characters you enter are not. Fix for issue #1097 doesn't seem to help. I'm using Microsoft Windows XP Korean. >>> print('???') File "", line 1 SyntaxError: (unicode error) illegal encoding ---------- components: Unicode messages: 55632 nosy: philyoon severity: normal status: open title: Can't input non-ascii characters in interactive mode versions: Python 3.0 __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Sep 4 08:50:52 2007 From: report at bugs.python.org (Sangpil Yoon) Date: Tue, 04 Sep 2007 06:50:52 -0000 Subject: [issue1100] Can't input non-ascii characters in interactive mode Message-ID: <1188888652.62.0.868826439665.issue1100@psf.upfronthosting.co.za> Changes by Sangpil Yoon: ---------- type: -> behavior __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Sep 4 11:18:53 2007 From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=) Date: Tue, 04 Sep 2007 09:18:53 -0000 Subject: [issue1100] Can't input non-ascii characters in interactive mode Message-ID: <1188897533.45.0.914313855961.issue1100@psf.upfronthosting.co.za> Martin v. L?wis added the comment: Thanks for the report. This is now fixed in r57957 (although I tested it only on Unix). ---------- nosy: +loewis resolution: -> fixed status: open -> closed __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Sep 4 11:23:43 2007 From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=) Date: Tue, 04 Sep 2007 09:23:43 -0000 Subject: [issue1092] Unexpected results in Tutorial about Unicode Message-ID: <1188897823.8.0.977038175798.issue1092@psf.upfronthosting.co.za> Martin v. L?wis added the comment: The first issue (non-ASCII characters won't work in interactive mode) was reported as issue 1100 also, and is now fixed in r57957. As for the other issues, I'm not quite sure what to make out of them - I see a different behavior: py> "?pfel".decode('latin-1).encode('utf-8') File "", line 1 "?pfel".decode('latin-1).encode('utf-8') ^ SyntaxError: invalid syntax This is not surprising - 'latin-1 is missig a closing quotation mark. I'm not sure where the indentation comes from, it is not supposed to be there, and I don't see it on my machine. What operating system, Python version, and interactive mode (shell or IDLE) are you using? [unassigning myself - the certain bug has been fixed] ---------- assignee: loewis -> __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Sep 4 11:38:39 2007 From: report at bugs.python.org (Sangpil Yoon) Date: Tue, 04 Sep 2007 09:38:39 -0000 Subject: [issue1100] Can't input non-ascii characters in interactive mode Message-ID: <1188898719.79.0.897869347207.issue1100@psf.upfronthosting.co.za> Sangpil Yoon added the comment: It's working fine on Windows XP. Thanks. __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Sep 4 11:47:49 2007 From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=) Date: Tue, 04 Sep 2007 09:47:49 -0000 Subject: [issue1374063] Broader iterable support for xmlrpclib Message-ID: <1188899269.49.0.323989780721.issue1374063@psf.upfronthosting.co.za> Martin v. L?wis added the comment: I have three problems with the current form of the patch: a) in the documentation, it should state that __dict__ is an attribute, not a method. b) why are you moving the subclassed-from-builtin types into the except block? It is there to reject things that have an __dict__, but are derived from a builtin class. c) Notice that your subclass-from-dict example is flawed. It does have an __dict__ attribute, but that is *not* the contents to be marshalled: py> class D(dict):pass ... py> d=D() py> d[1]=2 py> d.__dict__ {} py> Here, we would marshal an empty dict, however, the real dict has contents to be marshalled. IMO, it's correct to not be able to marshal dict subclasses. People created them on purpose, and we cannot guess what that purpose was. ---------- assignee: loewis -> skip.montanaro _____________________________________ Tracker _____________________________________ From report at bugs.python.org Tue Sep 4 11:52:17 2007 From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=) Date: Tue, 04 Sep 2007 09:52:17 -0000 Subject: [issue1626801] posixmodule.c leaks crypto context on Windows Message-ID: <1188899537.88.0.397874918524.issue1626801@psf.upfronthosting.co.za> Martin v. L?wis added the comment: Ok, I added a comment in r57958 ---------- resolution: -> fixed status: open -> closed _____________________________________ Tracker _____________________________________ From report at bugs.python.org Tue Sep 4 14:38:10 2007 From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=) Date: Tue, 04 Sep 2007 12:38:10 -0000 Subject: [issue1376361] Use 'seealso' to add examples to LibRef Message-ID: <1188909490.26.0.4918893766.issue1376361@psf.upfronthosting.co.za> Martin v. L?wis added the comment: I'm closing this as out-of-date, now that the documentation format is not based on TeX anymore. If you would like to port this to Sphinx, feel free to reopen it (or submit any such feature as a new patch). ---------- nosy: +loewis resolution: -> out of date status: open -> closed _____________________________________ Tracker _____________________________________ From report at bugs.python.org Tue Sep 4 15:14:06 2007 From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=) Date: Tue, 04 Sep 2007 13:14:06 -0000 Subject: [issue1388440] add more readline support Message-ID: <1188911646.24.0.467923610108.issue1388440@psf.upfronthosting.co.za> Martin v. L?wis added the comment: Thanks for the patch. Committed as r57960. ---------- nosy: +loewis versions: +Python 2.6 -Python 2.4 _____________________________________ Tracker _____________________________________ From report at bugs.python.org Tue Sep 4 15:14:58 2007 From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=) Date: Tue, 04 Sep 2007 13:14:58 -0000 Subject: [issue1388440] add more readline support Message-ID: <1188911698.14.0.792496929842.issue1388440@psf.upfronthosting.co.za> Changes by Martin v. L?wis: ---------- resolution: -> accepted status: open -> closed _____________________________________ Tracker _____________________________________ From report at bugs.python.org Tue Sep 4 15:28:54 2007 From: report at bugs.python.org (Skip Montanaro) Date: Tue, 04 Sep 2007 13:28:54 -0000 Subject: [issue1374063] Broader iterable support for xmlrpclib Message-ID: <1188912534.74.0.490155594385.issue1374063@psf.upfronthosting.co.za> Skip Montanaro added the comment: Thanks for the feedback. I will reexamine what I've got. _____________________________________ Tracker _____________________________________ From report at bugs.python.org Tue Sep 4 16:23:45 2007 From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=) Date: Tue, 04 Sep 2007 14:23:45 -0000 Subject: [issue1031213] Use correct encoding for printing SyntaxErrors Message-ID: <1188915825.47.0.126728855064.issue1031213@psf.upfronthosting.co.za> Martin v. L?wis added the comment: Thanks for the patch. It wouldn't work as-is, because it broke PGEN. I fixed that, and committed the change as r57961 and r57962. ---------- resolution: -> accepted status: open -> closed versions: +Python 2.5, Python 2.6 _____________________________________ Tracker _____________________________________ From report at bugs.python.org Tue Sep 4 16:46:11 2007 From: report at bugs.python.org (Guido van Rossum) Date: Tue, 04 Sep 2007 14:46:11 -0000 Subject: [issue1031213] Use correct encoding for printing SyntaxErrors Message-ID: <1188917171.54.0.670705443886.issue1031213@psf.upfronthosting.co.za> Guido van Rossum added the comment: We should make sure this is *not* merged into Py3k; there, things remain unicode until they're printed, at which point the only encoding that matters is the output file's encoding. _____________________________________ Tracker _____________________________________ From report at bugs.python.org Tue Sep 4 22:57:38 2007 From: report at bugs.python.org (Richard Katz) Date: Tue, 04 Sep 2007 20:57:38 -0000 Subject: [issue1101] Is there just no PRINT statement any more? Or it just doesn't work. Message-ID: <1188939458.07.0.206178975211.issue1101@psf.upfronthosting.co.za> New submission from Richard Katz: Is there supposed to be a way to do for x in 1,2,3: print x, If so, it's appears to be not working. Is it just not in this release? If not, I would think that leaving out the print statement (just because there is a print function) would represent a major problem for cross-platform books and training materials. Just a thought. How would one achieve this capability in Python 3.0? Was it the intention to remove this capability? Thank you. Regards, Rich ---------- components: Interpreter Core messages: 55643 nosy: richkatz severity: major status: open title: Is there just no PRINT statement any more? Or it just doesn't work. type: behavior versions: Python 3.0 __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Sep 4 22:57:38 2007 From: report at bugs.python.org (Richard Katz) Date: Tue, 04 Sep 2007 20:57:38 -0000 Subject: [issue1101] Is there just no PRINT statement any more? Or it just doesn't work. Message-ID: <1188939458.07.0.206178975211.issue1101@psf.upfronthosting.co.za> New submission from Richard Katz: Is there supposed to be a way to do for x in 1,2,3: print x, If so, it's appears to be not working. Is it just not in this release? If not, I would think that leaving out the print statement (just because there is a print function) would represent a major problem for cross-platform books and training materials. Just a thought. How would one achieve this capability in Python 3.0? Was it the intention to remove this capability? Thank you. Regards, Rich ---------- components: Interpreter Core messages: 55643 nosy: richkatz severity: major status: open title: Is there just no PRINT statement any more? Or it just doesn't work. type: behavior versions: Python 3.0 __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Sep 4 23:01:54 2007 From: report at bugs.python.org (=?utf-8?q?=0A=09=09=09=09=09Anthony_Tuininga=0A=09=09=09=09?=) Date: Tue, 04 Sep 2007 21:01:54 -0000 Subject: [issue1102] Add support for _msi.Record.GetString() and _msi.Record.GetInteger() Message-ID: <1188939714.65.0.826842920591.issue1102@psf.upfronthosting.co.za> Changes by Anthony Tuininga : ---------- components: Library (Lib) severity: normal status: open title: Add support for _msi.Record.GetString() and _msi.Record.GetInteger() type: behavior versions: Python 2.5 __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Sep 4 23:06:50 2007 From: report at bugs.python.org (=?utf-8?q?=0A=09=09=09=09=09Anthony_Tuininga=0A=09=09=09=09?=) Date: Tue, 04 Sep 2007 21:06:50 -0000 Subject: [issue1102] Add support for _msi.Record.GetString() and _msi.Record.GetInteger() Message-ID: <1188940010.27.0.383470464739.issue1102@psf.upfronthosting.co.za> New submission from Anthony Tuininga : Attached is a patch that adds the requested support. This is in relation to the thread at http://www.gossamer-threads.com/lists/python/python/584264 In addition to the two methods I also "fixed" Fetch() by ensuring that when the records are exhausted None is returned instead of an error. If something further is required of me or I submitted this patch incorrectly, please let me know so I don't screw it up next time. :-) ---------- nosy: +atuining __________________________________ Tracker __________________________________ -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: _msi.patch.txt Url: http://mail.python.org/pipermail/python-bugs-list/attachments/20070904/fb57ad8f/attachment.txt From report at bugs.python.org Tue Sep 4 23:10:28 2007 From: report at bugs.python.org (=?utf-8?q?=0A=09=09=09=09=09Anthony_Tuininga=0A=09=09=09=09?=) Date: Tue, 04 Sep 2007 21:10:28 -0000 Subject: [issue1102] Add support for _msi.Record.GetString() and _msi.Record.GetInteger() Message-ID: <1188940228.84.0.353730845882.issue1102@psf.upfronthosting.co.za> Changes by Anthony Tuininga : ---------- type: behavior -> __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Sep 4 23:29:36 2007 From: report at bugs.python.org (Dan Thomasset) Date: Tue, 04 Sep 2007 21:29:36 -0000 Subject: [issue1103] Typo in dummy_threading documentation Message-ID: <1188941375.76.0.679119193324.issue1103@psf.upfronthosting.co.za> New submission from Dan Thomasset: I believe that "thread" be "threading" in the line "...imported when the thread module is not provided..."? >From http://docs.python.org/lib/module-dummythreading.html ---------- components: Documentation messages: 55645 nosy: dthomasset severity: normal status: open title: Typo in dummy_threading documentation __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Sep 4 23:29:35 2007 From: report at bugs.python.org (Dan Thomasset) Date: Tue, 04 Sep 2007 21:29:35 -0000 Subject: [issue1103] Typo in dummy_threading documentation Message-ID: <1188941375.76.0.679119193324.issue1103@psf.upfronthosting.co.za> New submission from Dan Thomasset: I believe that "thread" be "threading" in the line "...imported when the thread module is not provided..."? >From http://docs.python.org/lib/module-dummythreading.html ---------- components: Documentation messages: 55645 nosy: dthomasset severity: normal status: open title: Typo in dummy_threading documentation __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Sep 4 23:31:46 2007 From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=) Date: Tue, 04 Sep 2007 21:31:46 -0000 Subject: [issue1101] Is there just no PRINT statement any more? Or it just doesn't work. Message-ID: <1188941506.34.0.652139709231.issue1101@psf.upfronthosting.co.za> Martin v. L?wis added the comment: What's wrong with py> for x in 1,2,3:print(x,end=" ") ... 1 2 3 Closing as invalid. ---------- nosy: +loewis resolution: -> invalid status: open -> closed __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Sep 4 23:35:29 2007 From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=) Date: Tue, 04 Sep 2007 21:35:29 -0000 Subject: [issue1103] Typo in dummy_threading documentation Message-ID: <1188941729.76.0.865954418746.issue1103@psf.upfronthosting.co.za> Martin v. L?wis added the comment: Why do you think so? The documentation is correct as it stands; dummy_threading should be used when thread is not present, not when threading is not present (as threading will always be present, it just won't import when thread is not present). ---------- nosy: +loewis resolution: -> invalid status: open -> closed __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Sep 4 23:35:57 2007 From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=) Date: Tue, 04 Sep 2007 21:35:57 -0000 Subject: [issue1102] Add support for _msi.Record.GetString() and _msi.Record.GetInteger() Message-ID: <1188941757.14.0.957423685782.issue1102@psf.upfronthosting.co.za> Changes by Martin v. L?wis: ---------- assignee: -> loewis nosy: +loewis __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Sep 4 23:43:59 2007 From: report at bugs.python.org (Dan Thomasset) Date: Tue, 04 Sep 2007 21:43:59 -0000 Subject: [issue1103] Typo in dummy_threading documentation In-Reply-To: <1188941729.76.0.865954418746.issue1103@psf.upfronthosting.co.za> Message-ID: Dan Thomasset added the comment: Ahh, my mistake then. I misunderstood what was going on. Thanks, Dan On 9/4/07, Martin v. L?wis wrote: > > > Martin v. L?wis added the comment: > > Why do you think so? The documentation is correct as it stands; > dummy_threading should be used when thread is not present, not when > threading is not present (as threading will always be present, it just > won't import when thread is not present). > > ---------- > nosy: +loewis > resolution: -> invalid > status: open -> closed > > __________________________________ > Tracker > > __________________________________ > __________________________________ Tracker __________________________________ -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: unnamed Url: http://mail.python.org/pipermail/python-bugs-list/attachments/20070904/789cc790/attachment.txt From report at bugs.python.org Wed Sep 5 00:03:41 2007 From: report at bugs.python.org (=?utf-8?q?=0A=09=09=09=09=09Anthony_Tuininga=0A=09=09=09=09?=) Date: Tue, 04 Sep 2007 22:03:41 -0000 Subject: [issue1104] msilib.SummaryInfo.GetProperty() truncates the string by one character Message-ID: <1188943421.22.0.776458935296.issue1104@psf.upfronthosting.co.za> New submission from Anthony Tuininga : Attached is a patch that fixes the truncation of the property values returned by msilib.SummaryInfo.GetProperty(). Unfortunately Microsoft has deemed it necessary to return the size of the string without the null termination character but insists upon the size including it when passing it in. Arggh! ---------- components: Library (Lib) files: _msi.patch2.txt messages: 55649 nosy: atuining severity: normal status: open title: msilib.SummaryInfo.GetProperty() truncates the string by one character versions: Python 2.5 __________________________________ Tracker __________________________________ -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: _msi.patch2.txt Url: http://mail.python.org/pipermail/python-bugs-list/attachments/20070904/626fde06/attachment.txt From report at bugs.python.org Wed Sep 5 00:03:41 2007 From: report at bugs.python.org (=?utf-8?q?=0A=09=09=09=09=09Anthony_Tuininga=0A=09=09=09=09?=) Date: Tue, 04 Sep 2007 22:03:41 -0000 Subject: [issue1104] msilib.SummaryInfo.GetProperty() truncates the string by one character Message-ID: <1188943421.22.0.776458935296.issue1104@psf.upfronthosting.co.za> New submission from Anthony Tuininga : Attached is a patch that fixes the truncation of the property values returned by msilib.SummaryInfo.GetProperty(). Unfortunately Microsoft has deemed it necessary to return the size of the string without the null termination character but insists upon the size including it when passing it in. Arggh! ---------- components: Library (Lib) files: _msi.patch2.txt messages: 55649 nosy: atuining severity: normal status: open title: msilib.SummaryInfo.GetProperty() truncates the string by one character versions: Python 2.5 __________________________________ Tracker __________________________________ -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: _msi.patch2.txt Url: http://mail.python.org/pipermail/python-bugs-list/attachments/20070904/626fde06/attachment-0001.txt From report at bugs.python.org Wed Sep 5 01:11:40 2007 From: report at bugs.python.org (Vizcaynot) Date: Tue, 04 Sep 2007 23:11:40 -0000 Subject: [issue1092] Unexpected results in Tutorial about Unicode Message-ID: <1188947500.32.0.842492702323.issue1092@psf.upfronthosting.co.za> Vizcaynot added the comment: Thanks about the fixing info. In relation to the second issue, I am afraid it is my fault, the value of variable "a" was asigned and filled with a previous valid operation. Please forgive me for the time you spent unnecessarily. I will attempt to be careful in the future. :-( __________________________________ Tracker __________________________________ From report at bugs.python.org Wed Sep 5 02:33:41 2007 From: report at bugs.python.org (Ty) Date: Wed, 05 Sep 2007 00:33:41 -0000 Subject: [issue1105] patch for readme.txt in PCbuild8 Message-ID: <1188952421.48.0.821192940412.issue1105@psf.upfronthosting.co.za> New submission from Ty: This update adds some comments to the readme.txt file for PCbuild8. When building subprojects VS2005 does not build the dependencies. I have included some text to alert the reader to this so they don't have the same trouble building subprojects as I did. I encountered this problem when building the pythoncore subproject. VS2005 did not build its dependencies (make_buildinfo, make_versioninfo) for me. ---------- components: Documentation files: pcbuild8_readme_txt.patch messages: 55651 nosy: chipped severity: normal status: open title: patch for readme.txt in PCbuild8 type: compile error __________________________________ Tracker __________________________________ -------------- next part -------------- A non-text attachment was scrubbed... Name: pcbuild8_readme_txt.patch Type: application/octet-stream Size: 854 bytes Desc: not available Url : http://mail.python.org/pipermail/python-bugs-list/attachments/20070905/d72b729a/attachment-0001.obj From report at bugs.python.org Wed Sep 5 02:33:41 2007 From: report at bugs.python.org (Ty) Date: Wed, 05 Sep 2007 00:33:41 -0000 Subject: [issue1105] patch for readme.txt in PCbuild8 Message-ID: <1188952421.48.0.821192940412.issue1105@psf.upfronthosting.co.za> New submission from Ty: This update adds some comments to the readme.txt file for PCbuild8. When building subprojects VS2005 does not build the dependencies. I have included some text to alert the reader to this so they don't have the same trouble building subprojects as I did. I encountered this problem when building the pythoncore subproject. VS2005 did not build its dependencies (make_buildinfo, make_versioninfo) for me. ---------- components: Documentation files: pcbuild8_readme_txt.patch messages: 55651 nosy: chipped severity: normal status: open title: patch for readme.txt in PCbuild8 type: compile error __________________________________ Tracker __________________________________ -------------- next part -------------- A non-text attachment was scrubbed... Name: pcbuild8_readme_txt.patch Type: application/octet-stream Size: 854 bytes Desc: not available Url : http://mail.python.org/pipermail/python-bugs-list/attachments/20070905/d72b729a/attachment-0002.obj From report at bugs.python.org Wed Sep 5 03:09:07 2007 From: report at bugs.python.org (Bill Janssen) Date: Wed, 05 Sep 2007 01:09:07 -0000 Subject: [issue1583946] SSL "issuer" and "server" names cannot be parsed Message-ID: <1188954547.63.0.797198020266.issue1583946@psf.upfronthosting.co.za> Bill Janssen added the comment: I've changed the return value of ssl.sslsocket.getpeercert() to return the "issuer" and "subject" names as tuples containing 2-element name-value tuples, in the same order that they appear in the certificate. This should complete the fulfillment of this issue. Please see the doc page on library/ssl.rst for more information. _____________________________________ Tracker _____________________________________ From report at bugs.python.org Wed Sep 5 04:20:44 2007 From: report at bugs.python.org (Vizcaynot) Date: Wed, 05 Sep 2007 02:20:44 -0000 Subject: [issue1106] Error in random.shuffle Message-ID: <1188958843.33.0.414139103758.issue1106@psf.upfronthosting.co.za> New submission from Vizcaynot: In python 3.0a1 under Win XP SP2: Typing next code: import random s=range(10) random.shuffle(s) I have next error: Traceback (most recent call last): File "", line 1, in File "C:\python30\lib\random.py", line 262, in shuffle x[i], x[j] = x[j], x[i] TypeError: 'range' object does not support item assignment It does not happen in python 2.5 ---------- components: Library (Lib) messages: 55653 nosy: Viscaynot severity: normal status: open title: Error in random.shuffle type: crash versions: Python 3.0 __________________________________ Tracker __________________________________ From report at bugs.python.org Wed Sep 5 04:20:43 2007 From: report at bugs.python.org (Vizcaynot) Date: Wed, 05 Sep 2007 02:20:43 -0000 Subject: [issue1106] Error in random.shuffle Message-ID: <1188958843.33.0.414139103758.issue1106@psf.upfronthosting.co.za> New submission from Vizcaynot: In python 3.0a1 under Win XP SP2: Typing next code: import random s=range(10) random.shuffle(s) I have next error: Traceback (most recent call last): File "", line 1, in File "C:\python30\lib\random.py", line 262, in shuffle x[i], x[j] = x[j], x[i] TypeError: 'range' object does not support item assignment It does not happen in python 2.5 ---------- components: Library (Lib) messages: 55653 nosy: Viscaynot severity: normal status: open title: Error in random.shuffle type: crash versions: Python 3.0 __________________________________ Tracker __________________________________ From report at bugs.python.org Wed Sep 5 07:52:58 2007 From: report at bugs.python.org (Jeong-Min Lee) Date: Wed, 05 Sep 2007 05:52:58 -0000 Subject: [issue1107] [patch] 2to3, lambda with non-tuple argument inside parenthesis Message-ID: <1188971578.16.0.124603302539.issue1107@psf.upfronthosting.co.za> New submission from Jeong-Min Lee: lambda (x): x should be transformed to lambda x: x not lambda x1: x1[0] ---------- components: Demos and Tools files: 2to3_lambda_nontuple_param.diff messages: 55654 nosy: falsetru, gvanrossum severity: normal status: open title: [patch] 2to3, lambda with non-tuple argument inside parenthesis __________________________________ Tracker __________________________________ -------------- next part -------------- A non-text attachment was scrubbed... Name: 2to3_lambda_nontuple_param.diff Type: text/x-patch Size: 1303 bytes Desc: not available Url : http://mail.python.org/pipermail/python-bugs-list/attachments/20070905/cf48ca68/attachment.bin From report at bugs.python.org Wed Sep 5 07:52:58 2007 From: report at bugs.python.org (Jeong-Min Lee) Date: Wed, 05 Sep 2007 05:52:58 -0000 Subject: [issue1107] [patch] 2to3, lambda with non-tuple argument inside parenthesis Message-ID: <1188971578.16.0.124603302539.issue1107@psf.upfronthosting.co.za> New submission from Jeong-Min Lee: lambda (x): x should be transformed to lambda x: x not lambda x1: x1[0] ---------- components: Demos and Tools files: 2to3_lambda_nontuple_param.diff messages: 55654 nosy: falsetru, gvanrossum severity: normal status: open title: [patch] 2to3, lambda with non-tuple argument inside parenthesis __________________________________ Tracker __________________________________ -------------- next part -------------- A non-text attachment was scrubbed... Name: 2to3_lambda_nontuple_param.diff Type: text/x-patch Size: 1303 bytes Desc: not available Url : http://mail.python.org/pipermail/python-bugs-list/attachments/20070905/cf48ca68/attachment-0001.bin From report at bugs.python.org Wed Sep 5 07:56:42 2007 From: report at bugs.python.org (Jeong-Min Lee) Date: Wed, 05 Sep 2007 05:56:42 -0000 Subject: [issue1107] [patch] 2to3, lambda with non-tuple argument inside parenthesis Message-ID: <1188971802.56.0.379412704986.issue1107@psf.upfronthosting.co.za> Jeong-Min Lee added the comment: I found this while 2to3ing BeautifulSoup.py. __________________________________ Tracker __________________________________ From report at bugs.python.org Wed Sep 5 08:16:24 2007 From: report at bugs.python.org (Georg Brandl) Date: Wed, 05 Sep 2007 06:16:24 -0000 Subject: [issue1092] Unexpected results in Tutorial about Unicode In-Reply-To: <1188947500.32.0.842492702323.issue1092@psf.upfronthosting.co.za> Message-ID: <46DE49B8.3030201@python.org> Georg Brandl added the comment: OK, closing. ---------- resolution: -> fixed status: open -> closed __________________________________ Tracker __________________________________ From report at bugs.python.org Wed Sep 5 08:20:19 2007 From: report at bugs.python.org (Georg Brandl) Date: Wed, 05 Sep 2007 06:20:19 -0000 Subject: [issue1106] Error in random.shuffle In-Reply-To: <1188958843.33.0.414139103758.issue1106@psf.upfronthosting.co.za> Message-ID: <46DE4AA5.3010402@gmx.net> Georg Brandl added the comment: Vizcaynot schrieb: > New submission from Vizcaynot: > > In python 3.0a1 under Win XP SP2: > Typing next code: > > import random > s=range(10) range() now returns an iterator, not a sequence, so random.shuffle() can't work on it. Use list(range()) if you want a list. Georg ---------- nosy: +georg.brandl resolution: -> invalid status: open -> closed __________________________________ Tracker __________________________________ From report at bugs.python.org Wed Sep 5 08:39:43 2007 From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=) Date: Wed, 05 Sep 2007 06:39:43 -0000 Subject: [issue1105] patch for readme.txt in PCbuild8 Message-ID: <1188974383.18.0.736777457887.issue1105@psf.upfronthosting.co.za> Martin v. L?wis added the comment: Thanks for the patch. Committed as r57984 and r57985. ---------- nosy: +loewis resolution: -> accepted status: open -> closed __________________________________ Tracker __________________________________ From report at bugs.python.org Wed Sep 5 08:47:09 2007 From: report at bugs.python.org (Georg Brandl) Date: Wed, 05 Sep 2007 06:47:09 -0000 Subject: [issue1107] 2to3, lambda with non-tuple argument inside parenthesis In-Reply-To: <1188971802.56.0.379412704986.issue1107@psf.upfronthosting.co.za> Message-ID: <46DE50EC.7070708@gmx.net> Georg Brandl added the comment: Assigned to Collin. ---------- assignee: -> collinwinter nosy: +collinwinter, georg.brandl title: [patch] 2to3, lambda with non-tuple argument inside parenthesis -> 2to3, lambda with non-tuple argument inside parenthesis __________________________________ Tracker __________________________________ From report at bugs.python.org Wed Sep 5 12:53:24 2007 From: report at bugs.python.org (Daniel Larsson) Date: Wed, 05 Sep 2007 10:53:24 -0000 Subject: [issue1108] Problem with doctest and decorated functions Message-ID: <1188989604.95.0.0786142357028.issue1108@psf.upfronthosting.co.za> New submission from Daniel Larsson: Seems like doctest won't recognize functions inside the module under test are actually in that module, if the function is decorated by a decorator that wraps the function in an externally defined function, such as in this silly example: # decorator.py import functools def simplelog(f): @functools.wraps(f) def new_f(*args, **kwds): print "Wrapper calling func" return f(*args, **kwds) return new_f # test.py from decorator import simplelog @simplelog def test(): """ This test should fail, since the decorator prints output. Seems I don't get called though >>> test() 'works!' """ return "works!" if __name__ == '__main__': import doctest doctest.testmod() -- The problem lies in DocTestFinder._from_module, which checks if the function's func_globals attribute is the same as the module's __dict__ attribute. I'd propose to do the __module__/inspect.getmodule() checks (aren't they both checking the same thing btw?) before the inspect.isfunction check. ---------- components: Library (Lib) messages: 55660 nosy: danilo severity: normal status: open title: Problem with doctest and decorated functions type: behavior versions: Python 2.5 __________________________________ Tracker __________________________________ From report at bugs.python.org Wed Sep 5 12:53:25 2007 From: report at bugs.python.org (Daniel Larsson) Date: Wed, 05 Sep 2007 10:53:25 -0000 Subject: [issue1108] Problem with doctest and decorated functions Message-ID: <1188989604.95.0.0786142357028.issue1108@psf.upfronthosting.co.za> New submission from Daniel Larsson: Seems like doctest won't recognize functions inside the module under test are actually in that module, if the function is decorated by a decorator that wraps the function in an externally defined function, such as in this silly example: # decorator.py import functools def simplelog(f): @functools.wraps(f) def new_f(*args, **kwds): print "Wrapper calling func" return f(*args, **kwds) return new_f # test.py from decorator import simplelog @simplelog def test(): """ This test should fail, since the decorator prints output. Seems I don't get called though >>> test() 'works!' """ return "works!" if __name__ == '__main__': import doctest doctest.testmod() -- The problem lies in DocTestFinder._from_module, which checks if the function's func_globals attribute is the same as the module's __dict__ attribute. I'd propose to do the __module__/inspect.getmodule() checks (aren't they both checking the same thing btw?) before the inspect.isfunction check. ---------- components: Library (Lib) messages: 55660 nosy: danilo severity: normal status: open title: Problem with doctest and decorated functions type: behavior versions: Python 2.5 __________________________________ Tracker __________________________________ From report at bugs.python.org Wed Sep 5 13:48:04 2007 From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=) Date: Wed, 05 Sep 2007 11:48:04 -0000 Subject: [issue786737] patch for build with read-only $srcdir Message-ID: <1188992884.04.0.963745692284.issue786737@psf.upfronthosting.co.za> Martin v. L?wis added the comment: Thanks for the patch. Committed as r57990 and r57991. ---------- resolution: -> accepted status: open -> closed versions: +Python 2.5, Python 2.6 -Python 2.3 ____________________________________ Tracker ____________________________________ From report at bugs.python.org Wed Sep 5 15:37:04 2007 From: report at bugs.python.org (Georg Brandl) Date: Wed, 05 Sep 2007 13:37:04 -0000 Subject: [issue1684991] Explain __method__ lookup semantics for new-style classes Message-ID: <1188999424.24.0.395533479778.issue1684991@psf.upfronthosting.co.za> Georg Brandl added the comment: Added a paragraph in rev. 57992, 57993. ---------- resolution: -> fixed status: open -> closed _____________________________________ Tracker _____________________________________ From report at bugs.python.org Wed Sep 5 17:22:18 2007 From: report at bugs.python.org (Mark Summerfield) Date: Wed, 05 Sep 2007 15:22:18 -0000 Subject: [issue1109] Warning required when calling register() on an ABCMeta subclass Message-ID: <1189005738.21.0.407633694929.issue1109@psf.upfronthosting.co.za> New submission from Mark Summerfield: GvR asked me to add this to the bug tracker. If you do this: class A(ABCMeta): pass A.register(list) you get this error message: Traceback (most recent call last): File "", line 1, in RuntimeError: maximum recursion depth exceeded in __instancecheck__ This is not very helpful. You probably meant to write: class A(metaclass=ABCMeta): pass Perhaps a warning message like this would be better: "register() should not be called on an ABCMeta subclass; maybe you forgot the metaclass keyword argument when declaring the class?" ---------- components: Interpreter Core messages: 55663 nosy: mark severity: normal status: open title: Warning required when calling register() on an ABCMeta subclass type: behavior versions: Python 3.0 __________________________________ Tracker __________________________________ From report at bugs.python.org Wed Sep 5 17:22:18 2007 From: report at bugs.python.org (Mark Summerfield) Date: Wed, 05 Sep 2007 15:22:18 -0000 Subject: [issue1109] Warning required when calling register() on an ABCMeta subclass Message-ID: <1189005738.21.0.407633694929.issue1109@psf.upfronthosting.co.za> New submission from Mark Summerfield: GvR asked me to add this to the bug tracker. If you do this: class A(ABCMeta): pass A.register(list) you get this error message: Traceback (most recent call last): File "", line 1, in RuntimeError: maximum recursion depth exceeded in __instancecheck__ This is not very helpful. You probably meant to write: class A(metaclass=ABCMeta): pass Perhaps a warning message like this would be better: "register() should not be called on an ABCMeta subclass; maybe you forgot the metaclass keyword argument when declaring the class?" ---------- components: Interpreter Core messages: 55663 nosy: mark severity: normal status: open title: Warning required when calling register() on an ABCMeta subclass type: behavior versions: Python 3.0 __________________________________ Tracker __________________________________ From report at bugs.python.org Wed Sep 5 19:47:28 2007 From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=) Date: Wed, 05 Sep 2007 17:47:28 -0000 Subject: [issue1777530] ctypes on Solaris Message-ID: <1189014448.17.0.47201000537.issue1777530@psf.upfronthosting.co.za> Martin v. L?wis added the comment: The patch looks fine to me (with the addition of checking for sunos5 instead). A few things to consider: - you could check the system at import time, rather than call time, of _get_soname() - notice that the file is located in /usr/ccs/bin, which may not be in everybody's path. So using an explicit path would be better. - Sun itself recommend dump(1) instead of elfdump(1) for use in "shell scripts". "/usr/ccs/bin/elfdump -Lpv /lib/libc.so.1" gives output including the line "[6]\tSONAME libc.so.1\n" ---------- nosy: +loewis _____________________________________ Tracker _____________________________________ From report at bugs.python.org Wed Sep 5 20:20:07 2007 From: report at bugs.python.org (Vlastimil Brom) Date: Wed, 05 Sep 2007 18:20:07 -0000 Subject: [issue1110] Problems with the msi installer - python-3.0a1.msi Message-ID: <1189016407.59.0.83312820482.issue1110@psf.upfronthosting.co.za> New submission from Vlastimil Brom: I encountered problems installing python 3.0 alpha 1 from the MSI installer supplied on the python download page (python-3.0a1.msi). If the advanced option of the installer ("compile .py files to bytecode after installation") is checked - the following message is shown "There is a problem with this Windows installer package. A program run as part of the setup did not finish as expected ..." If I don't choose the option to compile files, the installation finishes without any visible errors. The result is in both cases the same however. After calling python.exe it shows the version info etc. in the interactive prompt, but it doesn't "respond" in any way. e.g. >>> 1+1 object : RuntimeError('lost sys.stdout',) type : RuntimeError refcount: 4 address : 00A65BD0 lost sys.stderr >>> Running of any .py file doesn't work either. My system is Win XPh SP2 Czech (the same on Win XPp SP2 Czech). Could possibly the Czech windows version/ language setting/ locale/ timezone or whatever be the problem (as there were some problems reported with the manual compilation on German or Polish Winsows- systems)? Or am I missing something trivial? Thanks, Vlastimil Brom ---------- components: Windows messages: 55665 nosy: vbr severity: normal status: open title: Problems with the msi installer - python-3.0a1.msi versions: Python 3.0 __________________________________ Tracker __________________________________ From report at bugs.python.org Wed Sep 5 20:20:07 2007 From: report at bugs.python.org (Vlastimil Brom) Date: Wed, 05 Sep 2007 18:20:07 -0000 Subject: [issue1110] Problems with the msi installer - python-3.0a1.msi Message-ID: <1189016407.59.0.83312820482.issue1110@psf.upfronthosting.co.za> New submission from Vlastimil Brom: I encountered problems installing python 3.0 alpha 1 from the MSI installer supplied on the python download page (python-3.0a1.msi). If the advanced option of the installer ("compile .py files to bytecode after installation") is checked - the following message is shown "There is a problem with this Windows installer package. A program run as part of the setup did not finish as expected ..." If I don't choose the option to compile files, the installation finishes without any visible errors. The result is in both cases the same however. After calling python.exe it shows the version info etc. in the interactive prompt, but it doesn't "respond" in any way. e.g. >>> 1+1 object : RuntimeError('lost sys.stdout',) type : RuntimeError refcount: 4 address : 00A65BD0 lost sys.stderr >>> Running of any .py file doesn't work either. My system is Win XPh SP2 Czech (the same on Win XPp SP2 Czech). Could possibly the Czech windows version/ language setting/ locale/ timezone or whatever be the problem (as there were some problems reported with the manual compilation on German or Polish Winsows- systems)? Or am I missing something trivial? Thanks, Vlastimil Brom ---------- components: Windows messages: 55665 nosy: vbr severity: normal status: open title: Problems with the msi installer - python-3.0a1.msi versions: Python 3.0 __________________________________ Tracker __________________________________ From report at bugs.python.org Wed Sep 5 21:04:30 2007 From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=) Date: Wed, 05 Sep 2007 19:04:30 -0000 Subject: [issue1110] Problems with the msi installer - python-3.0a1.msi Message-ID: <1189019070.05.0.654314702696.issue1110@psf.upfronthosting.co.za> Martin v. L?wis added the comment: There are really two issues here; it is usually better to report them separately, so they can be analyzed, fixed, and closed separately: a) the compileall script apparently fails (not surprisingly so, I never tested it for 3.0), and b) Python does not work on your version of Windows. Please confirm that you use the Python console, not IDLE. As for issue b), yes, that's possibly a locale-related problem. How is "Program Files" called in your installation? What target directory did you set for Python? ---------- nosy: +loewis __________________________________ Tracker __________________________________ From report at bugs.python.org Wed Sep 5 21:05:05 2007 From: report at bugs.python.org (=?utf-8?q?Arkadiusz_Miskiewicz=09=09=09=09Arkadiusz_Miskiewicz?=) Date: Wed, 05 Sep 2007 19:05:05 -0000 Subject: [issue978833] SSL-ed sockets don't close correct? Message-ID: <1189019105.8.0.37558461591.issue978833@psf.upfronthosting.co.za> Arkadiusz Miskiewicz Arkadiusz Miskiewicz added the comment: How to deal with this on python 2.5.x? I assume that msg21288 means that fakeclose.diff isn't good way for python 2.5.x. Unfortunately there are web services that refuse to respond to second query if first wasn't properly ended (rare but I'm dealing with one). ---------- nosy: +arekm ____________________________________ Tracker ____________________________________ From report at bugs.python.org Wed Sep 5 21:12:27 2007 From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=) Date: Wed, 05 Sep 2007 19:12:27 -0000 Subject: [issue978833] SSL-ed sockets don't close correct? Message-ID: <1189019547.3.0.598563187672.issue978833@psf.upfronthosting.co.za> Martin v. L?wis added the comment: For 2.5, it reverts to the state of 2.4. You'll have to find a work-around on your own. ____________________________________ Tracker ____________________________________ From report at bugs.python.org Wed Sep 5 21:26:43 2007 From: report at bugs.python.org (Vlastimil Brom) Date: Wed, 05 Sep 2007 19:26:43 -0000 Subject: [issue1110] Problems with the msi installer - python-3.0a1.msi Message-ID: <1189020403.53.0.891818423528.issue1110@psf.upfronthosting.co.za> Vlastimil Brom added the comment: The path to the python executable on my system is: "C:\Python30\python.exe" The path to Program Files is "C:\Program Files", but it doesn't matter in that case, I guess. And yes, I use the console window (i.e. the cmd window in Windows) - the IDLE doesn't run either, as all other .py files (using python 3.0). __________________________________ Tracker __________________________________ From report at bugs.python.org Wed Sep 5 21:32:47 2007 From: report at bugs.python.org (Thomas Heller) Date: Wed, 05 Sep 2007 19:32:47 -0000 Subject: [issue1777530] ctypes on Solaris Message-ID: <1189020767.87.0.249972550715.issue1777530@psf.upfronthosting.co.za> Thomas Heller added the comment: Martin, here is a patch (solaris-2.patch), hopefully according to your comments. _____________________________________ Tracker _____________________________________ -------------- next part -------------- A non-text attachment was scrubbed... Name: solaris-2.patch Type: text/x-patch Size: 1418 bytes Desc: not available Url : http://mail.python.org/pipermail/python-bugs-list/attachments/20070905/186cd051/attachment.bin From report at bugs.python.org Wed Sep 5 23:13:08 2007 From: report at bugs.python.org (Maciej Piechorka) Date: Wed, 05 Sep 2007 21:13:08 -0000 Subject: [issue1111] Users' directories information Message-ID: <1189026788.84.0.0955213468627.issue1111@psf.upfronthosting.co.za> New submission from Maciej Piechorka: User directories varies along systems. On unikses all user data is kept in $HOME directory. Configuration is kept in dot-files. However on others systems places are different. Using predefined values would be most convinent. ---------- components: Library (Lib) messages: 55671 nosy: uzytkownik severity: minor status: open title: Users' directories information versions: Python 2.6 __________________________________ Tracker __________________________________ From report at bugs.python.org Wed Sep 5 23:13:08 2007 From: report at bugs.python.org (Maciej Piechorka) Date: Wed, 05 Sep 2007 21:13:08 -0000 Subject: [issue1111] Users' directories information Message-ID: <1189026788.84.0.0955213468627.issue1111@psf.upfronthosting.co.za> New submission from Maciej Piechorka: User directories varies along systems. On unikses all user data is kept in $HOME directory. Configuration is kept in dot-files. However on others systems places are different. Using predefined values would be most convinent. ---------- components: Library (Lib) messages: 55671 nosy: uzytkownik severity: minor status: open title: Users' directories information versions: Python 2.6 __________________________________ Tracker __________________________________ From report at bugs.python.org Thu Sep 6 01:00:42 2007 From: report at bugs.python.org (David Bolen) Date: Wed, 05 Sep 2007 23:00:42 -0000 Subject: [issue1112] Test debug assertion in bsddb test_1413192.py Message-ID: <1189033242.12.0.566103014662.issue1112@psf.upfronthosting.co.za> New submission from David Bolen: The change made to Lib/bsddb/test/test_1413192.py to clean up temporary files causes an abort in the DB library when trying to abort an open transaction at object destruction type - currently when the Python interpreter exits, because the transaction log file has been removed. In the Windows debug version this also causes an assertion pop-up dialog window. This has been seen on the 2.5 branch (r57311), trunk (r57286) and py3k branch (57285). The proposed change controls the object lifetime through a wrapper object so the transaction object is destroyed before cleaning up the filesystem. It has the added benefit of permitting the filesystem cleanup to work under Windows since the files are no longer in use. The test still generates a warning about a DBTxn aborted in destructor, but does not abort the interpreter. I have tried testing this without the original (issue 1413192, r42177) change to _bsddb that it was testing, but neither my modified version nor the original seem to crash in my environment, so I can't say absolutely whether or not the proposed change affects what the test was originally designed to test. I suspect subsequent changes to _bsddb.c are perhaps also satisfying the original problem. ---------- components: Tests files: test_1413192.py.diff messages: 55672 nosy: db3l severity: normal status: open title: Test debug assertion in bsddb test_1413192.py type: crash versions: Python 2.5, Python 2.6, Python 3.0 __________________________________ Tracker __________________________________ -------------- next part -------------- A non-text attachment was scrubbed... Name: test_1413192.py.diff Type: application/octet-stream Size: 1133 bytes Desc: not available Url : http://mail.python.org/pipermail/python-bugs-list/attachments/20070905/4678e970/attachment.obj From report at bugs.python.org Thu Sep 6 01:00:42 2007 From: report at bugs.python.org (David Bolen) Date: Wed, 05 Sep 2007 23:00:42 -0000 Subject: [issue1112] Test debug assertion in bsddb test_1413192.py Message-ID: <1189033242.12.0.566103014662.issue1112@psf.upfronthosting.co.za> New submission from David Bolen: The change made to Lib/bsddb/test/test_1413192.py to clean up temporary files causes an abort in the DB library when trying to abort an open transaction at object destruction type - currently when the Python interpreter exits, because the transaction log file has been removed. In the Windows debug version this also causes an assertion pop-up dialog window. This has been seen on the 2.5 branch (r57311), trunk (r57286) and py3k branch (57285). The proposed change controls the object lifetime through a wrapper object so the transaction object is destroyed before cleaning up the filesystem. It has the added benefit of permitting the filesystem cleanup to work under Windows since the files are no longer in use. The test still generates a warning about a DBTxn aborted in destructor, but does not abort the interpreter. I have tried testing this without the original (issue 1413192, r42177) change to _bsddb that it was testing, but neither my modified version nor the original seem to crash in my environment, so I can't say absolutely whether or not the proposed change affects what the test was originally designed to test. I suspect subsequent changes to _bsddb.c are perhaps also satisfying the original problem. ---------- components: Tests files: test_1413192.py.diff messages: 55672 nosy: db3l severity: normal status: open title: Test debug assertion in bsddb test_1413192.py type: crash versions: Python 2.5, Python 2.6, Python 3.0 __________________________________ Tracker __________________________________ -------------- next part -------------- A non-text attachment was scrubbed... Name: test_1413192.py.diff Type: application/octet-stream Size: 1133 bytes Desc: not available Url : http://mail.python.org/pipermail/python-bugs-list/attachments/20070905/4678e970/attachment-0001.obj From report at bugs.python.org Thu Sep 6 01:27:05 2007 From: report at bugs.python.org (Anand Patil) Date: Wed, 05 Sep 2007 23:27:05 -0000 Subject: [issue1113] interrupt_main() fails to interrupt raw_input() Message-ID: <1189034825.75.0.817794101989.issue1113@psf.upfronthosting.co.za> New submission from Anand Patil: Mac OS 10.4, Python 2.5 from pythonmac.org: The function listen() in the attached should be interrupted after a second, but it waits until return is pressed before catching the exception. ---------- components: Macintosh files: test.py messages: 55673 nosy: anand severity: normal status: open title: interrupt_main() fails to interrupt raw_input() type: behavior versions: Python 2.5 __________________________________ Tracker __________________________________ -------------- next part -------------- A non-text attachment was scrubbed... Name: test.py Type: text/x-python-script Size: 314 bytes Desc: not available Url : http://mail.python.org/pipermail/python-bugs-list/attachments/20070905/f097ef35/attachment.bin From report at bugs.python.org Thu Sep 6 01:27:06 2007 From: report at bugs.python.org (Anand Patil) Date: Wed, 05 Sep 2007 23:27:06 -0000 Subject: [issue1113] interrupt_main() fails to interrupt raw_input() Message-ID: <1189034825.75.0.817794101989.issue1113@psf.upfronthosting.co.za> New submission from Anand Patil: Mac OS 10.4, Python 2.5 from pythonmac.org: The function listen() in the attached should be interrupted after a second, but it waits until return is pressed before catching the exception. ---------- components: Macintosh files: test.py messages: 55673 nosy: anand severity: normal status: open title: interrupt_main() fails to interrupt raw_input() type: behavior versions: Python 2.5 __________________________________ Tracker __________________________________ -------------- next part -------------- A non-text attachment was scrubbed... Name: test.py Type: text/x-python-script Size: 314 bytes Desc: not available Url : http://mail.python.org/pipermail/python-bugs-list/attachments/20070905/f097ef35/attachment-0003.bin From report at bugs.python.org Thu Sep 6 02:10:17 2007 From: report at bugs.python.org (Richard Katz) Date: Thu, 06 Sep 2007 00:10:17 -0000 Subject: [issue1101] Is there just no PRINT statement any more? Or it just doesn't work. Message-ID: <31087179.1189037414470.JavaMail.root@elwamui-norfolk.atl.sa.earthlink.net> Richard Katz added the comment: "What's wrong with py> for x in 1,2,3:print(x,end=" ")" ------------------------- I'd like to suggest (for those of us just now focusing on Python 3.0) replacing the last 3 bullet points of the paragraph "Common Stumbling Blocks?" http://docs.python.org/dev/3.0/whatsnew/3.0.html With the following simple reference: "The print statement has been REMOVED and is replaced by a print() function. SEE PEP 3105." Rather than burying 3105 in the middle of "other language changes." That would do a lot to clear it up. A) Especially I'd like to suggest getting rid of the quite cryptic: "You?ll be finding yourself typing print x a lot in interactive mode." I had no idea that was a *warning message - meaning "it won't work..." And B) The rather misleading - "Also, print and print (x, y) behave differently without warning:" They certainly do... But not in the way explained. "print" now displays "" since it's a function... What they probably meant was print()? Where would I suggest (or make) these changes to What's New? Is there a Doc Wiki? Thanks! Regards, Rich -----Original Message----- >From: "=?utf-8?q?Martin_v._L=C3=B6wis?=" >Sent: Sep 4, 2007 5:31 PM >To: richkatz at acm.org >Subject: [issue1101] Is there just no PRINT statement any more? Or it just doesn't work. > > >Martin v. L?wis added the comment: > >What's wrong with > >py> for x in 1,2,3:print(x,end=" ") >... >1 2 3 > >Closing as invalid. > >---------- >nosy: +loewis >resolution: -> invalid >status: open -> closed > >__________________________________ >Tracker > >__________________________________ __________________________________ Tracker __________________________________ From report at bugs.python.org Thu Sep 6 05:32:34 2007 From: report at bugs.python.org (Luke Mewburn) Date: Thu, 06 Sep 2007 03:32:34 -0000 Subject: [issue1114] _curses issues on 64-bit big-endian (e.g, AIX) Message-ID: <1189049554.49.0.320613302462.issue1114@psf.upfronthosting.co.za> New submission from Luke Mewburn: Attempting to use curses attributes with python 2.3.5 on AIX (64bit powerpc) doesn't work, and occasionally results in exceptions being raised. _cursesmodule.c assumes that attr_t is a `long' and uses the "l" decoding of PyArg_ParseTuple() to read values from python to C. On platforms where sizeof(int) == sizeof(long), this isn't a problem. However, on LP64, especially big-endian LP64, this results in the wrong value being stored in the target address. My solution is to use ParseTuple("l") into a variable with an explicit type of 'long', and then assign that to the attr_t variable that the underlying curses(3) functions are called with. (I don't know if there's a different convention for dealing with reading numbers from python into underlying C types where the C type size isn't consistently an `int' or a `long', other that reading into an explicit int/long and then assigning/casting to the final type) The code in question doesn't appear to have changed much between python 2.3.5 and the svn trunk (as at 20070906), and my patch for the former applied fairly cleanly to my checkout of the latter. I've attached a diff from the svn checkout. ---------- components: Extension Modules files: curses-attr_t-long.diff messages: 55675 nosy: lukemewburn severity: normal status: open title: _curses issues on 64-bit big-endian (e.g, AIX) type: behavior versions: Python 2.3 __________________________________ Tracker __________________________________ -------------- next part -------------- A non-text attachment was scrubbed... Name: curses-attr_t-long.diff Type: text/x-patch Size: 10141 bytes Desc: not available Url : http://mail.python.org/pipermail/python-bugs-list/attachments/20070906/ac29ca65/attachment.bin From report at bugs.python.org Thu Sep 6 05:32:34 2007 From: report at bugs.python.org (Luke Mewburn) Date: Thu, 06 Sep 2007 03:32:34 -0000 Subject: [issue1114] _curses issues on 64-bit big-endian (e.g, AIX) Message-ID: <1189049554.49.0.320613302462.issue1114@psf.upfronthosting.co.za> New submission from Luke Mewburn: Attempting to use curses attributes with python 2.3.5 on AIX (64bit powerpc) doesn't work, and occasionally results in exceptions being raised. _cursesmodule.c assumes that attr_t is a `long' and uses the "l" decoding of PyArg_ParseTuple() to read values from python to C. On platforms where sizeof(int) == sizeof(long), this isn't a problem. However, on LP64, especially big-endian LP64, this results in the wrong value being stored in the target address. My solution is to use ParseTuple("l") into a variable with an explicit type of 'long', and then assign that to the attr_t variable that the underlying curses(3) functions are called with. (I don't know if there's a different convention for dealing with reading numbers from python into underlying C types where the C type size isn't consistently an `int' or a `long', other that reading into an explicit int/long and then assigning/casting to the final type) The code in question doesn't appear to have changed much between python 2.3.5 and the svn trunk (as at 20070906), and my patch for the former applied fairly cleanly to my checkout of the latter. I've attached a diff from the svn checkout. ---------- components: Extension Modules files: curses-attr_t-long.diff messages: 55675 nosy: lukemewburn severity: normal status: open title: _curses issues on 64-bit big-endian (e.g, AIX) type: behavior versions: Python 2.3 __________________________________ Tracker __________________________________ -------------- next part -------------- A non-text attachment was scrubbed... Name: curses-attr_t-long.diff Type: text/x-patch Size: 10141 bytes Desc: not available Url : http://mail.python.org/pipermail/python-bugs-list/attachments/20070906/ac29ca65/attachment-0003.bin From report at bugs.python.org Thu Sep 6 08:28:18 2007 From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=) Date: Thu, 06 Sep 2007 06:28:18 -0000 Subject: [issue1111] Users' directories information Message-ID: <1189060098.64.0.976870436332.issue1111@psf.upfronthosting.co.za> Martin v. L?wis added the comment: Can you please elaborate? What does that have to do with Python? ---------- nosy: +loewis __________________________________ Tracker __________________________________ From report at bugs.python.org Thu Sep 6 08:30:15 2007 From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=) Date: Thu, 06 Sep 2007 06:30:15 -0000 Subject: [issue1112] Test debug assertion in bsddb test_1413192.py Message-ID: <1189060215.39.0.0343566866562.issue1112@psf.upfronthosting.co.za> Changes by Martin v. L?wis: ---------- keywords: +patch __________________________________ Tracker __________________________________ From report at bugs.python.org Thu Sep 6 08:35:59 2007 From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=) Date: Thu, 06 Sep 2007 06:35:59 -0000 Subject: [issue1101] Is there just no PRINT statement any more? Or it just doesn't work. Message-ID: <1189060559.78.0.201063421464.issue1101@psf.upfronthosting.co.za> Martin v. L?wis added the comment: A plain "print" only results in output of "" in interactive mode, as interactive mode will not only perform the action, but also display the result. In a Python script, a plain "print" will have no effect. Guido, can you take a look at the proposed "what's new" changes? ---------- assignee: -> gvanrossum components: +Documentation -Interpreter Core nosy: +gvanrossum resolution: invalid -> status: closed -> open __________________________________ Tracker __________________________________ From report at bugs.python.org Thu Sep 6 08:47:35 2007 From: report at bugs.python.org (Zhang Zengbo) Date: Thu, 06 Sep 2007 06:47:35 -0000 Subject: [issue1115] Minor Change For Better cross compile Message-ID: <1189061255.17.0.84912008961.issue1115@psf.upfronthosting.co.za> New submission from Zhang Zengbo: Some test in configure.in is AC_TRY_RUN, which can be replaced by AC_TRY_COMPILE, achieve the same goal and give better support for cross compiling. This patch is for svn reversion 57996. ---------- files: autocheck.patch messages: 55678 nosy: zengbo severity: minor status: open title: Minor Change For Better cross compile versions: Python 2.6 __________________________________ Tracker __________________________________ -------------- next part -------------- A non-text attachment was scrubbed... Name: autocheck.patch Type: text/x-patch Size: 1596 bytes Desc: not available Url : http://mail.python.org/pipermail/python-bugs-list/attachments/20070906/fa316bc7/attachment.bin From report at bugs.python.org Thu Sep 6 08:47:35 2007 From: report at bugs.python.org (Zhang Zengbo) Date: Thu, 06 Sep 2007 06:47:35 -0000 Subject: [issue1115] Minor Change For Better cross compile Message-ID: <1189061255.17.0.84912008961.issue1115@psf.upfronthosting.co.za> New submission from Zhang Zengbo: Some test in configure.in is AC_TRY_RUN, which can be replaced by AC_TRY_COMPILE, achieve the same goal and give better support for cross compiling. This patch is for svn reversion 57996. ---------- files: autocheck.patch messages: 55678 nosy: zengbo severity: minor status: open title: Minor Change For Better cross compile versions: Python 2.6 __________________________________ Tracker __________________________________ -------------- next part -------------- A non-text attachment was scrubbed... Name: autocheck.patch Type: text/x-patch Size: 1596 bytes Desc: not available Url : http://mail.python.org/pipermail/python-bugs-list/attachments/20070906/fa316bc7/attachment-0001.bin From report at bugs.python.org Thu Sep 6 08:52:06 2007 From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=) Date: Thu, 06 Sep 2007 06:52:06 -0000 Subject: [issue1112] Test debug assertion in bsddb test_1413192.py Message-ID: <1189061526.45.0.419545877893.issue1112@psf.upfronthosting.co.za> Martin v. L?wis added the comment: Greg, can you take a look? If not, please unassign. ---------- assignee: -> gregory.p.smith nosy: +gregory.p.smith, loewis __________________________________ Tracker __________________________________ From report at bugs.python.org Thu Sep 6 09:45:03 2007 From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=) Date: Thu, 06 Sep 2007 07:45:03 -0000 Subject: [issue1115] Minor Change For Better cross compile Message-ID: <1189064703.32.0.260297204827.issue1115@psf.upfronthosting.co.za> Changes by Martin v. L?wis: ---------- keywords: +patch __________________________________ Tracker __________________________________ From report at bugs.python.org Thu Sep 6 09:45:49 2007 From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=) Date: Thu, 06 Sep 2007 07:45:49 -0000 Subject: [issue1104] msilib.SummaryInfo.GetProperty() truncates the string by one character Message-ID: <1189064749.83.0.290867766133.issue1104@psf.upfronthosting.co.za> Changes by Martin v. L?wis: ---------- assignee: -> loewis nosy: +loewis __________________________________ Tracker __________________________________ From report at bugs.python.org Thu Sep 6 09:54:43 2007 From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=) Date: Thu, 06 Sep 2007 07:54:43 -0000 Subject: [issue1505257] winerror module Message-ID: <1189065283.83.0.282994336059.issue1505257@psf.upfronthosting.co.za> Martin v. L?wis added the comment: Marc-Andre, what should we do about this patch? _____________________________________ Tracker _____________________________________ From report at bugs.python.org Thu Sep 6 10:36:01 2007 From: report at bugs.python.org (Armin Rigo) Date: Thu, 06 Sep 2007 08:36:01 -0000 Subject: [issue1733973] _lsprof.c:ptrace_enter_call assumes PyErr_* is clean Message-ID: <1189067761.21.0.244241777535.issue1733973@psf.upfronthosting.co.za> Armin Rigo added the comment: Thanks for the patch. Checked in: * r58004 (trunk) * r58005 (release25-maint) ---------- nosy: +arigo resolution: -> accepted status: open -> closed _____________________________________ Tracker _____________________________________ From report at bugs.python.org Thu Sep 6 11:10:11 2007 From: report at bugs.python.org (Anthon van der Neut) Date: Thu, 06 Sep 2007 09:10:11 -0000 Subject: [issue1116] reference in extending doc to non-existing file Message-ID: <1189069811.63.0.388251009768.issue1116@psf.upfronthosting.co.za> New submission from Anthon van der Neut: The extending Python doc for 2.5 (and 2.6) is still referring to Python/pythonmain.c to look up how to call the Python parser with a string. However the code (for the -c commandline option) is now in Modules/main.c See attached diff.txt fixes Doc/extending/extending.rst (it is probably quiker to make the change by hand than to check the diff). ---------- components: Documentation files: diff.txt messages: 55682 nosy: anthon severity: minor status: open title: reference in extending doc to non-existing file versions: Python 2.5, Python 2.6 __________________________________ Tracker __________________________________ -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: diff.txt Url: http://mail.python.org/pipermail/python-bugs-list/attachments/20070906/dbe14c34/attachment-0001.txt From report at bugs.python.org Thu Sep 6 11:10:12 2007 From: report at bugs.python.org (Anthon van der Neut) Date: Thu, 06 Sep 2007 09:10:12 -0000 Subject: [issue1116] reference in extending doc to non-existing file Message-ID: <1189069811.63.0.388251009768.issue1116@psf.upfronthosting.co.za> New submission from Anthon van der Neut: The extending Python doc for 2.5 (and 2.6) is still referring to Python/pythonmain.c to look up how to call the Python parser with a string. However the code (for the -c commandline option) is now in Modules/main.c See attached diff.txt fixes Doc/extending/extending.rst (it is probably quiker to make the change by hand than to check the diff). ---------- components: Documentation files: diff.txt messages: 55682 nosy: anthon severity: minor status: open title: reference in extending doc to non-existing file versions: Python 2.5, Python 2.6 __________________________________ Tracker __________________________________ -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: diff.txt Url: http://mail.python.org/pipermail/python-bugs-list/attachments/20070906/dbe14c34/attachment-0002.txt From report at bugs.python.org Thu Sep 6 11:35:59 2007 From: report at bugs.python.org (Marc-Andre Lemburg) Date: Thu, 06 Sep 2007 09:35:59 -0000 Subject: [issue1505257] winerror module Message-ID: <1189071359.45.0.175854016154.issue1505257@psf.upfronthosting.co.za> Marc-Andre Lemburg added the comment: The winerror module should really be coded in C. Otherwise you don't benefit from the lookup object approach. The files I uploaded only server as basis for such a C module. Would be great if you could find someone to write such a module - preferably using a generator that creates it from the header files. I'm not interested in this anymore, so feel free to drop the whole idea. _____________________________________ Tracker _____________________________________ From report at bugs.python.org Thu Sep 6 12:04:13 2007 From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=) Date: Thu, 06 Sep 2007 10:04:13 -0000 Subject: [issue1116] reference in extending doc to non-existing file Message-ID: <1189073053.34.0.421776023379.issue1116@psf.upfronthosting.co.za> Changes by Martin v. L?wis: ---------- keywords: +patch __________________________________ Tracker __________________________________ From report at bugs.python.org Thu Sep 6 12:04:47 2007 From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=) Date: Thu, 06 Sep 2007 10:04:47 -0000 Subject: [issue1505257] winerror module Message-ID: <1189073087.35.0.466373491287.issue1505257@psf.upfronthosting.co.za> Martin v. L?wis added the comment: Ok rejecting it. ---------- resolution: -> rejected status: open -> closed _____________________________________ Tracker _____________________________________ From report at bugs.python.org Thu Sep 6 12:15:40 2007 From: report at bugs.python.org (Thomas Herve) Date: Thu, 06 Sep 2007 10:15:40 -0000 Subject: [issue1686386] Python SEGFAULT on invalid superclass access Message-ID: <1189073740.71.0.695808142264.issue1686386@psf.upfronthosting.co.za> Thomas Herve added the comment: object.c is already inconsistent about tabs and space :). It may be better to fix it in the commit, not to clutter the patch. But I can provide a new patch if necessary. _____________________________________ Tracker _____________________________________ From report at bugs.python.org Thu Sep 6 12:51:21 2007 From: report at bugs.python.org (David Ripton) Date: Thu, 06 Sep 2007 10:51:21 -0000 Subject: [issue1117] Spurious warning about missing _sha256 and _sha512 when not needed Message-ID: <1189075881.9.0.366422086484.issue1117@psf.upfronthosting.co.za> New submission from David Ripton: Python 3.0a1, Gentoo Linux x86, with OpenSSL 0.9.8e installed. $ ./configure; make Failed to find the necessary bits to build these modules: _sha256 _sha512 To find the necessary bits, look in setup.py in detect_modules() for the module's name. setup.py says: if (openssl_ver < 0x00908000): # OpenSSL doesn't do these until 0.9.8 so we'll bring our own hash exts.append( Extension('_sha256', ['sha256module.c']) ) exts.append( Extension('_sha512', ['sha512module.c']) ) But I have openssl 0.9.8e. So openssl is new enough that I don't need the _sha256 and _sha512 modules. And the comment says that "these aren't strictly missing since they are unneeded", so the error message is spurious. ---------- components: Build messages: 55686 nosy: dripton severity: minor status: open title: Spurious warning about missing _sha256 and _sha512 when not needed type: behavior versions: Python 3.0 __________________________________ Tracker __________________________________ From report at bugs.python.org Thu Sep 6 12:51:22 2007 From: report at bugs.python.org (David Ripton) Date: Thu, 06 Sep 2007 10:51:22 -0000 Subject: [issue1117] Spurious warning about missing _sha256 and _sha512 when not needed Message-ID: <1189075881.9.0.366422086484.issue1117@psf.upfronthosting.co.za> New submission from David Ripton: Python 3.0a1, Gentoo Linux x86, with OpenSSL 0.9.8e installed. $ ./configure; make Failed to find the necessary bits to build these modules: _sha256 _sha512 To find the necessary bits, look in setup.py in detect_modules() for the module's name. setup.py says: if (openssl_ver < 0x00908000): # OpenSSL doesn't do these until 0.9.8 so we'll bring our own hash exts.append( Extension('_sha256', ['sha256module.c']) ) exts.append( Extension('_sha512', ['sha512module.c']) ) But I have openssl 0.9.8e. So openssl is new enough that I don't need the _sha256 and _sha512 modules. And the comment says that "these aren't strictly missing since they are unneeded", so the error message is spurious. ---------- components: Build messages: 55686 nosy: dripton severity: minor status: open title: Spurious warning about missing _sha256 and _sha512 when not needed type: behavior versions: Python 3.0 __________________________________ Tracker __________________________________ From report at bugs.python.org Thu Sep 6 12:54:58 2007 From: report at bugs.python.org (David Ripton) Date: Thu, 06 Sep 2007 10:54:58 -0000 Subject: [issue1118] hashlib module fails with TypeError Message-ID: <1189076097.81.0.41385534405.issue1118@psf.upfronthosting.co.za> New submission from David Ripton: The hashlib module seems not to work at all: $ python3.0 Python 3.0a1 (py3k, Sep 5 2007, 08:17:11) [GCC 4.1.2 (Gentoo 4.1.2)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> import hashlib >>> m = hashlib.md5() >>> m.update("Nobody inspects") Traceback (most recent call last): File "", line 1, in TypeError: object supporting the buffer API required (Same error with hashlib.sha1(), etc.) ---------- components: Library (Lib) messages: 55687 nosy: dripton severity: normal status: open title: hashlib module fails with TypeError type: crash versions: Python 3.0 __________________________________ Tracker __________________________________ From report at bugs.python.org Thu Sep 6 12:54:57 2007 From: report at bugs.python.org (David Ripton) Date: Thu, 06 Sep 2007 10:54:57 -0000 Subject: [issue1118] hashlib module fails with TypeError Message-ID: <1189076097.81.0.41385534405.issue1118@psf.upfronthosting.co.za> New submission from David Ripton: The hashlib module seems not to work at all: $ python3.0 Python 3.0a1 (py3k, Sep 5 2007, 08:17:11) [GCC 4.1.2 (Gentoo 4.1.2)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> import hashlib >>> m = hashlib.md5() >>> m.update("Nobody inspects") Traceback (most recent call last): File "", line 1, in TypeError: object supporting the buffer API required (Same error with hashlib.sha1(), etc.) ---------- components: Library (Lib) messages: 55687 nosy: dripton severity: normal status: open title: hashlib module fails with TypeError type: crash versions: Python 3.0 __________________________________ Tracker __________________________________ From report at bugs.python.org Thu Sep 6 13:37:27 2007 From: report at bugs.python.org (Maciej Piechorka) Date: Thu, 06 Sep 2007 11:37:27 -0000 Subject: [issue1111] Users' directories information Message-ID: <1189078647.29.0.783492746313.issue1111@psf.upfronthosting.co.za> Maciej Piechorka added the comment: It would allow to write in python more cross platform applications without writing it by hand and/or using special libraries. Something like: import sys import os import os.path # ... os.mkdir(os.path.join(sys.configdir(), ".myprogram")) # ... __________________________________ Tracker __________________________________ From report at bugs.python.org Thu Sep 6 15:11:27 2007 From: report at bugs.python.org (=?utf-8?q?Lars_Gust=C3=A4bel?=) Date: Thu, 06 Sep 2007 13:11:27 -0000 Subject: [issue1119] Search index is messed up after partial rebuilding Message-ID: <1189084286.84.0.1451286541.issue1119@psf.upfronthosting.co.za> New submission from Lars Gust?bel: When rebuilding parts of the documentation the search index is emptied. The problem is that the extensions are not stripped from the filenames that are given to IndexBuilder.prune() method. Therefore, the Search widget on http://docs.python.org/dev/3.0/ produces no results. ---------- components: Documentation tools (Sphinx) files: sphinx-index.diff keywords: patch messages: 55689 nosy: lars.gustaebel severity: normal status: open title: Search index is messed up after partial rebuilding __________________________________ Tracker __________________________________ -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: sphinx-index.diff Url: http://mail.python.org/pipermail/python-bugs-list/attachments/20070906/191d5e0f/attachment.txt From report at bugs.python.org Thu Sep 6 15:11:26 2007 From: report at bugs.python.org (=?utf-8?q?Lars_Gust=C3=A4bel?=) Date: Thu, 06 Sep 2007 13:11:26 -0000 Subject: [issue1119] Search index is messed up after partial rebuilding Message-ID: <1189084286.84.0.1451286541.issue1119@psf.upfronthosting.co.za> New submission from Lars Gust?bel: When rebuilding parts of the documentation the search index is emptied. The problem is that the extensions are not stripped from the filenames that are given to IndexBuilder.prune() method. Therefore, the Search widget on http://docs.python.org/dev/3.0/ produces no results. ---------- components: Documentation tools (Sphinx) files: sphinx-index.diff keywords: patch messages: 55689 nosy: lars.gustaebel severity: normal status: open title: Search index is messed up after partial rebuilding __________________________________ Tracker __________________________________ -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: sphinx-index.diff Url: http://mail.python.org/pipermail/python-bugs-list/attachments/20070906/191d5e0f/attachment-0001.txt From report at bugs.python.org Thu Sep 6 15:35:20 2007 From: report at bugs.python.org (toxik) Date: Thu, 06 Sep 2007 13:35:20 -0000 Subject: [issue1686386] Python SEGFAULT on invalid superclass access Message-ID: <1189085720.85.0.62826254786.issue1686386@psf.upfronthosting.co.za> toxik added the comment: Hm, may be so. Feel free to change title/severity if you'd like to. _____________________________________ Tracker _____________________________________ From report at bugs.python.org Thu Sep 6 15:49:56 2007 From: report at bugs.python.org (Georg Brandl) Date: Thu, 06 Sep 2007 13:49:56 -0000 Subject: [issue1118] hashlib module fails with TypeError In-Reply-To: <1189076097.81.0.41385534405.issue1118@psf.upfronthosting.co.za> Message-ID: <46E00586.3030703@gmx.net> Georg Brandl added the comment: David Ripton schrieb: > New submission from David Ripton: > > The hashlib module seems not to work at all: > > $ python3.0 > Python 3.0a1 (py3k, Sep 5 2007, 08:17:11) > [GCC 4.1.2 (Gentoo 4.1.2)] on linux2 > Type "help", "copyright", "credits" or "license" for more information. >>>> import hashlib >>>> m = hashlib.md5() >>>> m.update("Nobody inspects") > Traceback (most recent call last): > File "", line 1, in > TypeError: object supporting the buffer API required hashlib only accepts bytes for its digests, since the algorithms work on bytes, not characters. Unfortunately, this isn't documented yet, but I'll do that now. ---------- nosy: +georg.brandl resolution: -> invalid status: open -> closed __________________________________ Tracker __________________________________ From report at bugs.python.org Thu Sep 6 15:56:43 2007 From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=) Date: Thu, 06 Sep 2007 13:56:43 -0000 Subject: [issue1111] Users' directories information Message-ID: <1189087003.73.0.12245368196.issue1111@psf.upfronthosting.co.za> Martin v. L?wis added the comment: I don't think a uniform access to "configuration information" is possible, or even desirable. The requirements across applications and systems are too diverse to make this feasible. In any case, such a new feature should first be field-tested as a "special library" in a number of applications, and on a number of systems. Only then inclusion into the standard library could even be considered. Closing this as "won't fix". ---------- resolution: -> wont fix status: open -> closed __________________________________ Tracker __________________________________ From report at bugs.python.org Thu Sep 6 16:13:28 2007 From: report at bugs.python.org (Georg Brandl) Date: Thu, 06 Sep 2007 14:13:28 -0000 Subject: [issue1119] Search index is messed up after partial rebuilding In-Reply-To: <1189084286.84.0.1451286541.issue1119@psf.upfronthosting.co.za> Message-ID: <46E00B0A.1090100@gmx.net> Georg Brandl added the comment: Lars Gust?bel schrieb: > New submission from Lars Gust?bel: > > When rebuilding parts of the documentation the search index is emptied. > The problem is that the extensions are not stripped from the filenames > that are given to IndexBuilder.prune() method. > > Therefore, the Search widget on http://docs.python.org/dev/3.0/ produces > no results. Thanks, fixed in rev. 58009! Georg ---------- nosy: +georg.brandl resolution: -> accepted status: open -> closed __________________________________ Tracker __________________________________ From report at bugs.python.org Thu Sep 6 16:47:39 2007 From: report at bugs.python.org (Guido van Rossum) Date: Thu, 06 Sep 2007 14:47:39 -0000 Subject: [issue1101] Is there just no PRINT statement any more? Or it just doesn't work. Message-ID: <1189090059.85.0.821561454412.issue1101@psf.upfronthosting.co.za> Guido van Rossum added the comment: OK, I've added a big section about print to the front of the "common stumbling blocks section, with all the info about print together, and a few examples to clarify the most common changes. You can see the changes in subversion; they'll be live on docs.python.org/dev/3.0/ in half a day or less. ---------- resolution: -> fixed status: open -> closed __________________________________ Tracker __________________________________ From report at bugs.python.org Thu Sep 6 16:50:10 2007 From: report at bugs.python.org (Georg Brandl) Date: Thu, 06 Sep 2007 14:50:10 -0000 Subject: [issue1116] reference in extending doc to non-existing file In-Reply-To: <1189073053.34.0.421776023379.issue1116@psf.upfronthosting.co.za> Message-ID: <46E013A6.9080504@gmx.net> Georg Brandl added the comment: Fixed in rev. 58012, 58013. ---------- nosy: +georg.brandl resolution: -> accepted status: open -> closed __________________________________ Tracker __________________________________ From report at bugs.python.org Thu Sep 6 17:04:59 2007 From: report at bugs.python.org (Georg Brandl) Date: Thu, 06 Sep 2007 15:04:59 -0000 Subject: [issue1117] Spurious warning about missing _sha256 and _sha512 when not needed In-Reply-To: <1189075881.9.0.366422086484.issue1117@psf.upfronthosting.co.za> Message-ID: <46E0171E.8080500@gmx.net> Georg Brandl added the comment: Assigning to Skip. ---------- assignee: -> skip.montanaro nosy: +georg.brandl, skip.montanaro title: Spurious warning about missing _sha256 and _sha512 when not needed -> Spurious warning about missing _sha256 and _sha512 when not needed __________________________________ Tracker __________________________________ From report at bugs.python.org Thu Sep 6 17:13:23 2007 From: report at bugs.python.org (Georg Brandl) Date: Thu, 06 Sep 2007 15:13:23 -0000 Subject: [issue685846] raw_input defers alarm signal Message-ID: <1189091603.82.0.557202873695.issue685846@psf.upfronthosting.co.za> Georg Brandl added the comment: Setting patch as superseder ---------- nosy: +georg.brandl resolution: -> duplicate status: open -> closed superseder: -> fix bug #685846: raw_input defers signals ____________________________________ Tracker ____________________________________ From report at bugs.python.org Thu Sep 6 17:13:48 2007 From: report at bugs.python.org (Georg Brandl) Date: Thu, 06 Sep 2007 15:13:48 -0000 Subject: [issue706406] fix bug #685846: raw_input defers signals Message-ID: <1189091628.3.0.276669098123.issue706406@psf.upfronthosting.co.za> Georg Brandl added the comment: Set as superseder of #685846 and #1113. ---------- nosy: +georg.brandl ____________________________________ Tracker ____________________________________ From report at bugs.python.org Thu Sep 6 17:14:16 2007 From: report at bugs.python.org (Georg Brandl) Date: Thu, 06 Sep 2007 15:14:16 -0000 Subject: [issue1113] interrupt_main() fails to interrupt raw_input() Message-ID: <1189091656.97.0.352009723786.issue1113@psf.upfronthosting.co.za> Georg Brandl added the comment: This is ultimately the same as #685846, for which a patch is at #706406. ---------- nosy: +georg.brandl resolution: -> duplicate status: open -> closed superseder: -> fix bug #685846: raw_input defers signals __________________________________ Tracker __________________________________ From report at bugs.python.org Thu Sep 6 17:17:55 2007 From: report at bugs.python.org (Georg Brandl) Date: Thu, 06 Sep 2007 15:17:55 -0000 Subject: [issue1095] make install failed In-Reply-To: <1188839355.89.0.39344138919.issue1095@psf.upfronthosting.co.za> Message-ID: <46E01A27.2040707@gmx.net> Georg Brandl added the comment: Aki schrieb: > (cd /usr/local/bin; ln python2.5 python) > (cd /usr/local/bin; ln -sf python2.5-config python-config) > ln: cannot create python-config: File exists > make: *** [bininstall] Error 2 Shouldn't ln -f ignore existing destination files? What system is that? ---------- nosy: +georg.brandl __________________________________ Tracker __________________________________ From report at bugs.python.org Thu Sep 6 17:38:19 2007 From: report at bugs.python.org (Aki) Date: Thu, 06 Sep 2007 15:38:19 -0000 Subject: [issue1095] make install failed Message-ID: <1189093099.22.0.624610199322.issue1095@psf.upfronthosting.co.za> Aki added the comment: > Shouldn't ln -f ignore existing destination files? > What system is that? Well, it was on Solaris 9. Under Solaris, ln -sf won't clobber an existing soft link. I don't know if there is a work around of this rather than removing the link explicitly. Other Unix experts, any help? Aki- __________________________________ Tracker __________________________________ From report at bugs.python.org Thu Sep 6 17:44:58 2007 From: report at bugs.python.org (Skip Montanaro) Date: Thu, 06 Sep 2007 15:44:58 -0000 Subject: [issue1117] Spurious warning about missing _sha256 and _sha512 when not needed Message-ID: <1189093498.13.0.653651248808.issue1117@psf.upfronthosting.co.za> Skip Montanaro added the comment: Assigning to me because? I've had no involvement at all with SSL or sha code in Python. __________________________________ Tracker __________________________________ From report at bugs.python.org Thu Sep 6 18:05:51 2007 From: report at bugs.python.org (Georg Brandl) Date: Thu, 06 Sep 2007 16:05:51 -0000 Subject: [issue1117] Spurious warning about missing _sha256 and _sha512 when not needed In-Reply-To: <1189093498.13.0.653651248808.issue1117@psf.upfronthosting.co.za> Message-ID: <46E02560.8090907@python.org> Georg Brandl added the comment: Skip Montanaro schrieb: > Skip Montanaro added the comment: > > Assigning to me because? I've had no involvement at all > with SSL or sha code in Python. IIRC you added the code that collects and displays these messages. __________________________________ Tracker __________________________________ From report at bugs.python.org Thu Sep 6 18:06:21 2007 From: report at bugs.python.org (Georg Brandl) Date: Thu, 06 Sep 2007 16:06:21 -0000 Subject: [issue1095] make install failed In-Reply-To: <1189093099.22.0.624610199322.issue1095@psf.upfronthosting.co.za> Message-ID: <46E0257F.7080706@python.org> Georg Brandl added the comment: Perhaps Martin knows something? ---------- assignee: -> loewis nosy: +loewis __________________________________ Tracker __________________________________ From report at bugs.python.org Thu Sep 6 18:27:04 2007 From: report at bugs.python.org (Skip Montanaro) Date: Thu, 06 Sep 2007 16:27:04 -0000 Subject: [issue1117] Spurious warning about missing _sha256 and _sha512 when not needed In-Reply-To: <46E02560.8090907@python.org> Message-ID: <18144.10834.982214.894326@montanaro.dyndns.org> Skip Montanaro added the comment: >> Assigning to me because? I've had no involvement at all >> with SSL or sha code in Python. Georg> IIRC you added the code that collects and displays these Georg> messages. Ah, okay. I will take a look at that. Skip ---------- title: Spurious warning about missing _sha256 and _sha512 when not needed -> Spurious warning about missing _sha256 and _sha512 when not needed __________________________________ Tracker __________________________________ From report at bugs.python.org Thu Sep 6 18:31:20 2007 From: report at bugs.python.org (Skip Montanaro) Date: Thu, 06 Sep 2007 16:31:20 -0000 Subject: [issue1117] Spurious warning about missing _sha256 and _sha512 when not needed Message-ID: <1189096280.88.0.470524712091.issue1117@psf.upfronthosting.co.za> Skip Montanaro added the comment: I just checked in r58016. See if that solves the problem. ---------- resolution: -> fixed status: open -> pending __________________________________ Tracker __________________________________ From report at bugs.python.org Thu Sep 6 18:59:43 2007 From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=) Date: Thu, 06 Sep 2007 16:59:43 -0000 Subject: [issue1095] make install failed Message-ID: <1189097983.67.0.980419139201.issue1095@psf.upfronthosting.co.za> Martin v. L?wis added the comment: The -f option to ln was not portable, traditionally. So the portable way to create a symlink if the target might exist is to remove the old symlink first. I've verified that 'ln -sf' indeed works as reported on Solaris 9. On Solaris 10, it seems Sun has finally "given in" and changed the implementation (but not the documentation). I'm not sure why we bother checking whether the old file exists before removing it, instead of just doing 'rm -f'; that has been there since r6352 with no explanation given. ---------- assignee: loewis -> __________________________________ Tracker __________________________________ From report at bugs.python.org Thu Sep 6 19:30:22 2007 From: report at bugs.python.org (Georg Brandl) Date: Thu, 06 Sep 2007 17:30:22 -0000 Subject: [issue1095] make install failed In-Reply-To: <1189097983.67.0.980419139201.issue1095@psf.upfronthosting.co.za> Message-ID: <46E0392F.8050303@python.org> Georg Brandl added the comment: [Martin] > I'm not sure why we bother checking whether the old file exists before > removing it, instead of just doing 'rm -f'; that has been there since > r6352 with no explanation given. So would this patch be acceptable? Index: Makefile.pre.in =================================================================== --- Makefile.pre.in (Revision 57865) +++ Makefile.pre.in (Arbeitskopie) @@ -655,7 +655,8 @@ else true; \ fi (cd $(DESTDIR)$(BINDIR); $(LN) python$(VERSION)$(EXE) $(PYTHON)) - (cd $(DESTDIR)$(BINDIR); $(LN) -sf python$(VERSION)-config python-config) + -rm -f $(DESTDIR)$(BINDIR)/python-config + (cd $(DESTDIR)$(BINDIR); $(LN) -s python$(VERSION)-config python-config) # Install the interpreter with $(VERSION) affixed # This goes into $(exec_prefix) __________________________________ Tracker __________________________________ From report at bugs.python.org Thu Sep 6 19:58:09 2007 From: report at bugs.python.org (Collin Winter) Date: Thu, 06 Sep 2007 17:58:09 -0000 Subject: [issue1107] 2to3, lambda with non-tuple argument inside parenthesis Message-ID: <1189101489.63.0.518705637899.issue1107@psf.upfronthosting.co.za> Changes by Collin Winter: ---------- components: +2to3 (2.x to 3.x conversion tool) -Demos and Tools __________________________________ Tracker __________________________________ From report at bugs.python.org Thu Sep 6 19:58:46 2007 From: report at bugs.python.org (Collin Winter) Date: Thu, 06 Sep 2007 17:58:46 -0000 Subject: [issue1001] 2to3 crashes on input files with no trailing newlines Message-ID: <1189101526.68.0.306611647665.issue1001@psf.upfronthosting.co.za> Changes by Collin Winter: ---------- assignee: -> collinwinter components: +2to3 (2.x to 3.x conversion tool) -Demos and Tools nosy: +collinwinter __________________________________ Tracker __________________________________ From report at bugs.python.org Thu Sep 6 19:58:56 2007 From: report at bugs.python.org (Collin Winter) Date: Thu, 06 Sep 2007 17:58:56 -0000 Subject: [issue1034] [patch] Add 2to3 support for displaying warnings as Python comments Message-ID: <1189101536.68.0.996982063285.issue1034@psf.upfronthosting.co.za> Changes by Collin Winter: ---------- assignee: -> collinwinter components: +2to3 (2.x to 3.x conversion tool) -Demos and Tools nosy: +collinwinter __________________________________ Tracker __________________________________ From report at bugs.python.org Thu Sep 6 19:59:30 2007 From: report at bugs.python.org (Maciej Piechorka) Date: Thu, 06 Sep 2007 17:59:30 -0000 Subject: [issue1111] Users' directories information Message-ID: <1189101570.56.0.882682292587.issue1111@psf.upfronthosting.co.za> Maciej Piechorka added the comment: As a 'special library' I meant for example QT(metioned at least on #python channel but I can't find it in pyQT documentation) which is a nonsense in pygtk app. __________________________________ Tracker __________________________________ From report at bugs.python.org Thu Sep 6 20:01:03 2007 From: report at bugs.python.org (Collin Winter) Date: Thu, 06 Sep 2007 18:01:03 -0000 Subject: [issue1001] 2to3 crashes on input files with no trailing newlines Message-ID: <1189101663.48.0.107796712787.issue1001@psf.upfronthosting.co.za> Collin Winter added the comment: I believe this was fixed in r57942; can you test to see if you still have this problem? __________________________________ Tracker __________________________________ From report at bugs.python.org Thu Sep 6 20:01:34 2007 From: report at bugs.python.org (Collin Winter) Date: Thu, 06 Sep 2007 18:01:34 -0000 Subject: [issue1005] Patches to rename Queue module to queue Message-ID: <1189101694.24.0.598902060242.issue1005@psf.upfronthosting.co.za> Changes by Collin Winter: ---------- components: +2to3 (2.x to 3.x conversion tool) __________________________________ Tracker __________________________________ From report at bugs.python.org Thu Sep 6 20:01:39 2007 From: report at bugs.python.org (Collin Winter) Date: Thu, 06 Sep 2007 18:01:39 -0000 Subject: [issue1002] Patch to rename HTMLParser module to lower_case Message-ID: <1189101699.44.0.742643143776.issue1002@psf.upfronthosting.co.za> Changes by Collin Winter: ---------- components: +2to3 (2.x to 3.x conversion tool) __________________________________ Tracker __________________________________ From report at bugs.python.org Thu Sep 6 20:02:17 2007 From: report at bugs.python.org (Collin Winter) Date: Thu, 06 Sep 2007 18:02:17 -0000 Subject: [issue1000] Patch to rename *Server modules to lower-case Message-ID: <1189101737.09.0.613102775224.issue1000@psf.upfronthosting.co.za> Changes by Collin Winter: ---------- components: +2to3 (2.x to 3.x conversion tool) __________________________________ Tracker __________________________________ From report at bugs.python.org Thu Sep 6 20:02:38 2007 From: report at bugs.python.org (Collin Winter) Date: Thu, 06 Sep 2007 18:02:38 -0000 Subject: [issue1000] Patch to rename *Server modules to lower-case Message-ID: <1189101758.36.0.904031505617.issue1000@psf.upfronthosting.co.za> Changes by Collin Winter: ---------- nosy: +collinwinter __________________________________ Tracker __________________________________ From report at bugs.python.org Thu Sep 6 20:03:48 2007 From: report at bugs.python.org (Collin Winter) Date: Thu, 06 Sep 2007 18:03:48 -0000 Subject: [issue1619049] sys.intern() 2to3 fixer Message-ID: <1189101828.67.0.0998964717065.issue1619049@psf.upfronthosting.co.za> Changes by Collin Winter: ---------- components: +2to3 (2.x to 3.x conversion tool) -None _____________________________________ Tracker _____________________________________ From report at bugs.python.org Thu Sep 6 20:23:02 2007 From: report at bugs.python.org (Adrian Holovaty) Date: Thu, 06 Sep 2007 18:23:02 -0000 Subject: [issue1001] 2to3 crashes on input files with no trailing newlines Message-ID: <1189102982.07.0.266471962408.issue1001@psf.upfronthosting.co.za> Adrian Holovaty added the comment: I just checked, and, yes, it's been fixed. __________________________________ Tracker __________________________________ From report at bugs.python.org Thu Sep 6 20:26:37 2007 From: report at bugs.python.org (Collin Winter) Date: Thu, 06 Sep 2007 18:26:37 -0000 Subject: [issue1001] 2to3 crashes on input files with no trailing newlines Message-ID: <1189103197.48.0.161651329617.issue1001@psf.upfronthosting.co.za> Changes by Collin Winter: ---------- resolution: -> fixed status: open -> closed __________________________________ Tracker __________________________________ From report at bugs.python.org Thu Sep 6 23:43:25 2007 From: report at bugs.python.org (Daniel Larsson) Date: Thu, 06 Sep 2007 21:43:25 -0000 Subject: [issue1108] Problem with doctest and decorated functions Message-ID: <1189115005.87.0.556543767961.issue1108@psf.upfronthosting.co.za> Daniel Larsson added the comment: Here's a patch that alters the order of checks in DocTestFinder._from_module __________________________________ Tracker __________________________________ -------------- next part -------------- A non-text attachment was scrubbed... Name: doctest.py.patch Type: text/x-patch Size: 756 bytes Desc: not available Url : http://mail.python.org/pipermail/python-bugs-list/attachments/20070906/3f3f3900/attachment.bin From report at bugs.python.org Thu Sep 6 23:51:04 2007 From: report at bugs.python.org (David Ripton) Date: Thu, 06 Sep 2007 21:51:04 -0000 Subject: [issue1117] Spurious warning about missing _sha256 and _sha512 when not needed Message-ID: <1189115464.32.0.15323012992.issue1117@psf.upfronthosting.co.za> David Ripton added the comment: Yes, the fix works for me. Thanks. __________________________________ Tracker __________________________________ From report at bugs.python.org Fri Sep 7 00:06:50 2007 From: report at bugs.python.org (David Ripton) Date: Thu, 06 Sep 2007 22:06:50 -0000 Subject: [issue1120] "make altinstall" installs pydoc, idle, smtpd.py with broken shebang lines Message-ID: <1189116410.02.0.82025271699.issue1120@psf.upfronthosting.co.za> New submission from David Ripton: Gentoo Linux, x86, Python 3.0a I did a vanilla "./configure; make; make test; make altinstall" build. The following files were created in /usr/local/bin: -rwxr-xr-x 1 root root 18036 Sep 6 17:49 smtpd.py -rwxr-xr-x 1 root root 81 Sep 6 17:49 pydoc -rwxr-xr-x 1 root root 96 Sep 6 17:49 idle -rwxr-xr-x 1 root root 3644316 Sep 6 17:58 python3.0 -rwxr-xr-x 1 root root 1401 Sep 6 17:59 python3.0-config As intended, altinstall does not create /usr/local/bin/python, so "python" is still the pre-existing python2.5. However, other binaries are installed as though /usr/local/bin/python were created, so they don't work. dripton at al ~ $ pydoc bash: /usr/local/bin/pydoc: /usr/local/bin/python: bad interpreter: No such file or directory dripton at al ~ $ idle bash: /usr/local/bin/idle: /usr/local/bin/python: bad interpreter: No such file or directory dripton at al ~ $ smtpd.py bash: /usr/local/bin/smtpd.py: /usr/local/bin/python: bad interpreter: No such file or directory Suggest that "make altinstall" should not put anything in the bin directory except pythonX.Y and pythonX.Y-config, which are "safe" because of the embedded version numbers. Another option would be installing those other binaries but with fixed shebang lines. ---------- components: Build messages: 55714 nosy: dripton severity: minor status: open title: "make altinstall" installs pydoc, idle, smtpd.py with broken shebang lines type: crash versions: Python 3.0 __________________________________ Tracker __________________________________ From report at bugs.python.org Fri Sep 7 00:06:50 2007 From: report at bugs.python.org (David Ripton) Date: Thu, 06 Sep 2007 22:06:50 -0000 Subject: [issue1120] "make altinstall" installs pydoc, idle, smtpd.py with broken shebang lines Message-ID: <1189116410.02.0.82025271699.issue1120@psf.upfronthosting.co.za> New submission from David Ripton: Gentoo Linux, x86, Python 3.0a I did a vanilla "./configure; make; make test; make altinstall" build. The following files were created in /usr/local/bin: -rwxr-xr-x 1 root root 18036 Sep 6 17:49 smtpd.py -rwxr-xr-x 1 root root 81 Sep 6 17:49 pydoc -rwxr-xr-x 1 root root 96 Sep 6 17:49 idle -rwxr-xr-x 1 root root 3644316 Sep 6 17:58 python3.0 -rwxr-xr-x 1 root root 1401 Sep 6 17:59 python3.0-config As intended, altinstall does not create /usr/local/bin/python, so "python" is still the pre-existing python2.5. However, other binaries are installed as though /usr/local/bin/python were created, so they don't work. dripton at al ~ $ pydoc bash: /usr/local/bin/pydoc: /usr/local/bin/python: bad interpreter: No such file or directory dripton at al ~ $ idle bash: /usr/local/bin/idle: /usr/local/bin/python: bad interpreter: No such file or directory dripton at al ~ $ smtpd.py bash: /usr/local/bin/smtpd.py: /usr/local/bin/python: bad interpreter: No such file or directory Suggest that "make altinstall" should not put anything in the bin directory except pythonX.Y and pythonX.Y-config, which are "safe" because of the embedded version numbers. Another option would be installing those other binaries but with fixed shebang lines. ---------- components: Build messages: 55714 nosy: dripton severity: minor status: open title: "make altinstall" installs pydoc, idle, smtpd.py with broken shebang lines type: crash versions: Python 3.0 __________________________________ Tracker __________________________________ From report at bugs.python.org Fri Sep 7 00:30:39 2007 From: report at bugs.python.org (Skip Montanaro) Date: Thu, 06 Sep 2007 22:30:39 -0000 Subject: [issue1117] Spurious warning about missing _sha256 and _sha512 when not needed Message-ID: <1189117839.03.0.915001694237.issue1117@psf.upfronthosting.co.za> Skip Montanaro added the comment: Thanks. I'm not sure how this slipped in there (I could check, I suppose). It seems to already be on the 2.5 branch, so I added it to the trunk (r58022) as well. ---------- status: pending -> closed __________________________________ Tracker __________________________________ From report at bugs.python.org Fri Sep 7 01:07:17 2007 From: report at bugs.python.org (Gregory P. Smith) Date: Thu, 06 Sep 2007 23:07:17 -0000 Subject: [issue1112] Test debug assertion in bsddb test_1413192.py Message-ID: <1189120037.81.0.382891943693.issue1112@psf.upfronthosting.co.za> Gregory P. Smith added the comment: that looks good to me. fixed in: 2.6 trunk r58023 release25-maint r58024 py3k r58025 ---------- resolution: -> fixed status: open -> closed __________________________________ Tracker __________________________________ From report at bugs.python.org Fri Sep 7 01:30:44 2007 From: report at bugs.python.org (Brett Cannon) Date: Thu, 06 Sep 2007 23:30:44 -0000 Subject: [issue1121] Document inspect.getfullargspec() Message-ID: <1189121444.48.0.486854487775.issue1121@psf.upfronthosting.co.za> New submission from Brett Cannon: inspect.getfullargspec() needs to be documented before it is backported to 2.6. ---------- components: Documentation keywords: py3k messages: 55717 nosy: brett.cannon priority: normal severity: normal status: open title: Document inspect.getfullargspec() versions: Python 3.0 __________________________________ Tracker __________________________________ From report at bugs.python.org Fri Sep 7 01:30:44 2007 From: report at bugs.python.org (Brett Cannon) Date: Thu, 06 Sep 2007 23:30:44 -0000 Subject: [issue1121] Document inspect.getfullargspec() Message-ID: <1189121444.48.0.486854487775.issue1121@psf.upfronthosting.co.za> New submission from Brett Cannon: inspect.getfullargspec() needs to be documented before it is backported to 2.6. ---------- components: Documentation keywords: py3k messages: 55717 nosy: brett.cannon priority: normal severity: normal status: open title: Document inspect.getfullargspec() versions: Python 3.0 __________________________________ Tracker __________________________________ From report at bugs.python.org Fri Sep 7 01:31:10 2007 From: report at bugs.python.org (Brett Cannon) Date: Thu, 06 Sep 2007 23:31:10 -0000 Subject: [issue1121] Document inspect.getfullargspec() Message-ID: <1189121470.16.0.919471709542.issue1121@psf.upfronthosting.co.za> Changes by Brett Cannon: ---------- severity: normal -> minor __________________________________ Tracker __________________________________ From report at bugs.python.org Fri Sep 7 02:43:14 2007 From: report at bugs.python.org (=?utf-8?q?=0A=09=09=09=09=09Andrew_Gaul=0A=09=09=09=09?=) Date: Fri, 07 Sep 2007 00:43:14 -0000 Subject: [issue1122] PyTuple_Size and PyTuple_GET_SIZE return type documentation incorrect Message-ID: <1189125794.07.0.790446459894.issue1122@psf.upfronthosting.co.za> New submission from Andrew Gaul : Documentation claims int, API uses Py_ssize_t. ---------- components: Documentation files: pytuple_size.patch messages: 55718 nosy: gaul severity: minor status: open title: PyTuple_Size and PyTuple_GET_SIZE return type documentation incorrect versions: Python 2.5 __________________________________ Tracker __________________________________ -------------- next part -------------- A non-text attachment was scrubbed... Name: pytuple_size.patch Type: text/x-patch Size: 646 bytes Desc: not available Url : http://mail.python.org/pipermail/python-bugs-list/attachments/20070907/034f733c/attachment.bin From report at bugs.python.org Fri Sep 7 02:43:14 2007 From: report at bugs.python.org (=?utf-8?q?=0A=09=09=09=09=09Andrew_Gaul=0A=09=09=09=09?=) Date: Fri, 07 Sep 2007 00:43:14 -0000 Subject: [issue1122] PyTuple_Size and PyTuple_GET_SIZE return type documentation incorrect Message-ID: <1189125794.07.0.790446459894.issue1122@psf.upfronthosting.co.za> New submission from Andrew Gaul : Documentation claims int, API uses Py_ssize_t. ---------- components: Documentation files: pytuple_size.patch messages: 55718 nosy: gaul severity: minor status: open title: PyTuple_Size and PyTuple_GET_SIZE return type documentation incorrect versions: Python 2.5 __________________________________ Tracker __________________________________ -------------- next part -------------- A non-text attachment was scrubbed... Name: pytuple_size.patch Type: text/x-patch Size: 646 bytes Desc: not available Url : http://mail.python.org/pipermail/python-bugs-list/attachments/20070907/034f733c/attachment-0001.bin From report at bugs.python.org Fri Sep 7 03:05:25 2007 From: report at bugs.python.org (Anand Patil) Date: Fri, 07 Sep 2007 01:05:25 -0000 Subject: [issue1113] interrupt_main() fails to interrupt raw_input() In-Reply-To: <1189091656.97.0.352009723786.issue1113@psf.upfronthosting.co.za> Message-ID: <2bc7a5a50709061805u2b5cc7f0qa5ae0ac1e571196f@mail.gmail.com> Anand Patil added the comment: Sorry- Where can I get this patch? The SourceForge patch manager says it's closed. Thanks, Anand On 9/6/07, Georg Brandl wrote: > > > Georg Brandl added the comment: > > This is ultimately the same as #685846, for which a patch is at #706406. > > ---------- > nosy: +georg.brandl > resolution: -> duplicate > status: open -> closed > superseder: -> fix bug #685846: raw_input defers signals > > __________________________________ > Tracker > > __________________________________ > __________________________________ Tracker __________________________________ -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: unnamed Url: http://mail.python.org/pipermail/python-bugs-list/attachments/20070907/f84fcadd/attachment.txt From report at bugs.python.org Fri Sep 7 03:18:41 2007 From: report at bugs.python.org (Nir Soffer) Date: Fri, 07 Sep 2007 01:18:41 -0000 Subject: [issue1123] split(None, maxplit) does not strip whitespace correctly Message-ID: <1189127921.0.0.701786903755.issue1123@psf.upfronthosting.co.za> New submission from Nir Soffer: string object .split doc say (http://docs.python.org/lib/string- methods.html): "If sep is not specified or is None, a different splitting algorithm is applied. First, whitespace characters (spaces, tabs, newlines, returns, and formfeeds) are stripped from both ends." If the maxsplit argument is set and is smaller then the number of possible parts, whitespace is not removed. Examples: >>> 'k: v\n'.split(None, 1) ['k:', 'v\n'] Expected: ['k:', 'v'] >>> u'k: v\n'.split(None, 1) [u'k:', u'v\n'] Expected: [u'k:', u'v'] With larger values of maxsplits, it works correctly: >>> 'k: v\n'.split(None, 2) ['k:', 'v'] >>> u'k: v\n'.split(None, 2) [u'k:', u'v'] This looks like implementation bug, because there it does not make sense that the striping depends on the maxsplit argument, and it will be hard to explain such behavior. Maybe the striping should be removed in Python 3? It does not make sense to strip a string behind your back when you want to split it, and the caller can easily strip the string if needed. ---------- components: Library (Lib) messages: 55720 nosy: nirs severity: normal status: open title: split(None, maxplit) does not strip whitespace correctly versions: Python 2.4, Python 2.5, Python 3.0 __________________________________ Tracker __________________________________ From report at bugs.python.org Fri Sep 7 03:18:41 2007 From: report at bugs.python.org (Nir Soffer) Date: Fri, 07 Sep 2007 01:18:41 -0000 Subject: [issue1123] split(None, maxplit) does not strip whitespace correctly Message-ID: <1189127921.0.0.701786903755.issue1123@psf.upfronthosting.co.za> New submission from Nir Soffer: string object .split doc say (http://docs.python.org/lib/string- methods.html): "If sep is not specified or is None, a different splitting algorithm is applied. First, whitespace characters (spaces, tabs, newlines, returns, and formfeeds) are stripped from both ends." If the maxsplit argument is set and is smaller then the number of possible parts, whitespace is not removed. Examples: >>> 'k: v\n'.split(None, 1) ['k:', 'v\n'] Expected: ['k:', 'v'] >>> u'k: v\n'.split(None, 1) [u'k:', u'v\n'] Expected: [u'k:', u'v'] With larger values of maxsplits, it works correctly: >>> 'k: v\n'.split(None, 2) ['k:', 'v'] >>> u'k: v\n'.split(None, 2) [u'k:', u'v'] This looks like implementation bug, because there it does not make sense that the striping depends on the maxsplit argument, and it will be hard to explain such behavior. Maybe the striping should be removed in Python 3? It does not make sense to strip a string behind your back when you want to split it, and the caller can easily strip the string if needed. ---------- components: Library (Lib) messages: 55720 nosy: nirs severity: normal status: open title: split(None, maxplit) does not strip whitespace correctly versions: Python 2.4, Python 2.5, Python 3.0 __________________________________ Tracker __________________________________ From report at bugs.python.org Fri Sep 7 03:19:23 2007 From: report at bugs.python.org (Nir Soffer) Date: Fri, 07 Sep 2007 01:19:23 -0000 Subject: [issue1123] split(None, maxsplit) does not strip whitespace correctly Message-ID: <1189127963.14.0.607273757591.issue1123@psf.upfronthosting.co.za> Nir Soffer added the comment: typo in the title ---------- title: split(None, maxplit) does not strip whitespace correctly -> split(None, maxsplit) does not strip whitespace correctly __________________________________ Tracker __________________________________ From report at bugs.python.org Fri Sep 7 03:29:03 2007 From: report at bugs.python.org (Edward Abraham) Date: Fri, 07 Sep 2007 01:29:03 -0000 Subject: [issue1124] Webchecker not parsing css "@import url" Message-ID: <1189128543.92.0.989336234213.issue1124@psf.upfronthosting.co.za> New submission from Edward Abraham: webchecker and its dependent, websucker, which are distributed with the python tools, are not following references to stylesheets given with the declaration ... This means that the websucker isn't copying across stylesheets ... ---------- components: Demos and Tools messages: 55722 nosy: ready.eddy severity: normal status: open title: Webchecker not parsing css "@import url" versions: Python 2.5 __________________________________ Tracker __________________________________ From report at bugs.python.org Fri Sep 7 03:29:04 2007 From: report at bugs.python.org (Edward Abraham) Date: Fri, 07 Sep 2007 01:29:04 -0000 Subject: [issue1124] Webchecker not parsing css "@import url" Message-ID: <1189128543.92.0.989336234213.issue1124@psf.upfronthosting.co.za> New submission from Edward Abraham: webchecker and its dependent, websucker, which are distributed with the python tools, are not following references to stylesheets given with the declaration ... This means that the websucker isn't copying across stylesheets ... ---------- components: Demos and Tools messages: 55722 nosy: ready.eddy severity: normal status: open title: Webchecker not parsing css "@import url" versions: Python 2.5 __________________________________ Tracker __________________________________ From report at bugs.python.org Fri Sep 7 03:30:28 2007 From: report at bugs.python.org (Nir Soffer) Date: Fri, 07 Sep 2007 01:30:28 -0000 Subject: [issue1125] bytes.split shold have same interface as str.split, or different name Message-ID: <1189128628.62.0.444123560856.issue1125@psf.upfronthosting.co.za> New submission from Nir Soffer: >>> b'foo bar'.split() Traceback (most recent call last): File "", line 1, in TypeError: split() takes at least 1 argument (0 given) >>> b'foo bar'.split(None) Traceback (most recent call last): File "", line 1, in TypeError: expected an object with the buffer interface str.split and bytes.split should have the same interface, or different names. ---------- components: Library (Lib) messages: 55723 nosy: nirs severity: normal status: open title: bytes.split shold have same interface as str.split, or different name versions: Python 3.0 __________________________________ Tracker __________________________________ From report at bugs.python.org Fri Sep 7 03:30:28 2007 From: report at bugs.python.org (Nir Soffer) Date: Fri, 07 Sep 2007 01:30:28 -0000 Subject: [issue1125] bytes.split shold have same interface as str.split, or different name Message-ID: <1189128628.62.0.444123560856.issue1125@psf.upfronthosting.co.za> New submission from Nir Soffer: >>> b'foo bar'.split() Traceback (most recent call last): File "", line 1, in TypeError: split() takes at least 1 argument (0 given) >>> b'foo bar'.split(None) Traceback (most recent call last): File "", line 1, in TypeError: expected an object with the buffer interface str.split and bytes.split should have the same interface, or different names. ---------- components: Library (Lib) messages: 55723 nosy: nirs severity: normal status: open title: bytes.split shold have same interface as str.split, or different name versions: Python 3.0 __________________________________ Tracker __________________________________ From report at bugs.python.org Fri Sep 7 04:00:04 2007 From: report at bugs.python.org (Nir Soffer) Date: Fri, 07 Sep 2007 02:00:04 -0000 Subject: [issue1126] file.fileno and file.isatty() should be implementable by any file like object Message-ID: <1189130404.46.0.902963366118.issue1126@psf.upfronthosting.co.za> New submission from Nir Soffer: The docs (http://docs.python.org/dev/3.0/library/stdtypes.html#sequence- types-str-bytes-list-tuple-buffer-range) warn that .fileno and .istty should not be implemented by a file like object. This require client to check if the file object has the attribute before they call the method, instead of treating all files the same. if hasattr(foo, 'istty'): if foo.istty(): # ... Instead of: if foo.istty(): # ... istty can easily return False. fileno can return invalid file descriptor number (-1?). ---------- components: Library (Lib) messages: 55724 nosy: nirs severity: normal status: open title: file.fileno and file.isatty() should be implementable by any file like object type: rfe versions: Python 3.0 __________________________________ Tracker __________________________________ From report at bugs.python.org Fri Sep 7 04:00:06 2007 From: report at bugs.python.org (Nir Soffer) Date: Fri, 07 Sep 2007 02:00:06 -0000 Subject: [issue1126] file.fileno and file.isatty() should be implementable by any file like object Message-ID: <1189130404.46.0.902963366118.issue1126@psf.upfronthosting.co.za> New submission from Nir Soffer: The docs (http://docs.python.org/dev/3.0/library/stdtypes.html#sequence- types-str-bytes-list-tuple-buffer-range) warn that .fileno and .istty should not be implemented by a file like object. This require client to check if the file object has the attribute before they call the method, instead of treating all files the same. if hasattr(foo, 'istty'): if foo.istty(): # ... Instead of: if foo.istty(): # ... istty can easily return False. fileno can return invalid file descriptor number (-1?). ---------- components: Library (Lib) messages: 55724 nosy: nirs severity: normal status: open title: file.fileno and file.isatty() should be implementable by any file like object type: rfe versions: Python 3.0 __________________________________ Tracker __________________________________ From report at bugs.python.org Fri Sep 7 04:03:43 2007 From: report at bugs.python.org (Nir Soffer) Date: Fri, 07 Sep 2007 02:03:43 -0000 Subject: [issue1125] bytes.split shold have same interface as str.split, or different name Message-ID: <1189130623.94.0.16463284233.issue1125@psf.upfronthosting.co.za> Nir Soffer added the comment: set type ---------- type: -> rfe __________________________________ Tracker __________________________________ From report at bugs.python.org Fri Sep 7 04:04:13 2007 From: report at bugs.python.org (Nir Soffer) Date: Fri, 07 Sep 2007 02:04:13 -0000 Subject: [issue1123] split(None, maxsplit) does not strip whitespace correctly Message-ID: <1189130653.87.0.0697592518179.issue1123@psf.upfronthosting.co.za> Nir Soffer added the comment: set type ---------- type: -> behavior __________________________________ Tracker __________________________________ From report at bugs.python.org Fri Sep 7 04:06:34 2007 From: report at bugs.python.org (Brett Cannon) Date: Fri, 07 Sep 2007 02:06:34 -0000 Subject: [issue1127] No tests for inspect.getfullargspec() Message-ID: <1189130794.67.0.458163021879.issue1127@psf.upfronthosting.co.za> Changes by Brett Cannon: ---------- components: Library (Lib) keywords: py3k priority: high severity: normal status: open title: No tests for inspect.getfullargspec() versions: Python 3.0 __________________________________ Tracker __________________________________ From report at bugs.python.org Fri Sep 7 04:14:24 2007 From: report at bugs.python.org (Nir Soffer) Date: Fri, 07 Sep 2007 02:14:24 -0000 Subject: [issue1014] cgi: parse_qs and parse_qsl misbehave on empty strings Message-ID: <1189131264.54.0.879607299118.issue1014@psf.upfronthosting.co.za> Nir Soffer added the comment: Addionally, if the default value is empty string, you expect it work with empty string. If a non empty value is needed, it would use None as the default. __________________________________ Tracker __________________________________ From report at bugs.python.org Fri Sep 7 05:38:05 2007 From: report at bugs.python.org (Brett Cannon) Date: Fri, 07 Sep 2007 03:38:05 -0000 Subject: [issue1267884] crash recursive __getattr__ Message-ID: <1189136285.13.0.121818884583.issue1267884@psf.upfronthosting.co.za> Changes by Brett Cannon: ---------- superseder: -> a bunch of infinite C recursions _____________________________________ Tracker _____________________________________ From report at bugs.python.org Fri Sep 7 06:18:59 2007 From: report at bugs.python.org (Brett Cannon) Date: Fri, 07 Sep 2007 04:18:59 -0000 Subject: [issue1202533] a bunch of infinite C recursions Message-ID: <1189138739.49.0.255290199226.issue1202533@psf.upfronthosting.co.za> Brett Cannon added the comment: Rev. 58032 applied the patch and added a test to test_descr. ---------- resolution: -> fixed status: open -> closed _____________________________________ Tracker _____________________________________ From report at bugs.python.org Fri Sep 7 08:48:06 2007 From: report at bugs.python.org (Georg Brandl) Date: Fri, 07 Sep 2007 06:48:06 -0000 Subject: [issue1113] interrupt_main() fails to interrupt raw_input() In-Reply-To: <2bc7a5a50709061805u2b5cc7f0qa5ae0ac1e571196f@mail.gmail.com> Message-ID: <46E0F425.60104@python.org> Georg Brandl added the comment: Anand Patil schrieb: > Anand Patil added the comment: > > Sorry- Where can I get this patch? The SourceForge patch manager says it's > closed. It is - like all other issues - in this tracker at http://bugs.python.org/706406. __________________________________ Tracker __________________________________ From report at bugs.python.org Fri Sep 7 08:55:26 2007 From: report at bugs.python.org (Georg Brandl) Date: Fri, 07 Sep 2007 06:55:26 -0000 Subject: [issue1125] bytes.split shold have same interface as str.split, or different name In-Reply-To: <1189130623.94.0.16463284233.issue1125@psf.upfronthosting.co.za> Message-ID: <46E0F5E2.2080602@gmx.net> Georg Brandl added the comment: I don't think so. They can't have the same behavior, and "split" is the most reasonable name for what the bytes method does. There have always been subtle differences between the behavior of string and unicode methods; this was even more objectable because they were supposed to be interchangeable to some degree; 3k strings and bytes are not. ---------- nosy: +georg.brandl __________________________________ Tracker __________________________________ From report at bugs.python.org Fri Sep 7 09:34:15 2007 From: report at bugs.python.org (=?utf-8?q?=0A=09=09=09=09=09robs_pythonid=0A=09=09=09=09?=) Date: Fri, 07 Sep 2007 07:34:15 -0000 Subject: [issue1764044] copy 2 Message-ID: <1189150455.37.0.599498418699.issue1764044@psf.upfronthosting.co.za> robs pythonid added the comment: Thanks for your reaction, I do not really now the answer to your question but I added the code to copy files in a directory (to keep it simple I removed the recursiveness): import os import shutil sourcedir="d:\\testsourcedir" targetdir="d:\\testtargetdir" filelist=os.listdir(sourcedir) for afile in filelist: source=sourcedir + "\\" + afile if os.path.isfile(source): time1=os.path.getmtime(source) print source,time1, docopy=0 target=targetdir+"\\"+afile if os.path.isfile(target): time2=os.path.getmtime(target) if time1>time2: docopy=1 else: docopy=1 if docopy==1: print " ....copying" shutil.copy2(source,target) else: print " not copied" If I run this program twice without changing any file in the source directory it should not copy any files anymore (but is does 20% of the files it there are 100000 files). Now that I have been thinking about this a little the problems I see, happen on a Windows Vista Business machine, on my XP machine i don't seem to be able to reproduce the issues, maybe it is somethin in Vista..... quite frustrating.... _____________________________________ Tracker _____________________________________ From report at bugs.python.org Fri Sep 7 09:38:56 2007 From: report at bugs.python.org (Georg Brandl) Date: Fri, 07 Sep 2007 07:38:56 -0000 Subject: [issue1749583] expanduser("~") on Windows looks for HOME first Message-ID: <1189150736.59.0.478479551793.issue1749583@psf.upfronthosting.co.za> Changes by Georg Brandl: ---------- status: pending -> closed _____________________________________ Tracker _____________________________________ From report at bugs.python.org Fri Sep 7 09:40:29 2007 From: report at bugs.python.org (Georg Brandl) Date: Fri, 07 Sep 2007 07:40:29 -0000 Subject: [issue1209562] add single html files Message-ID: <1189150829.9.0.303895296004.issue1209562@psf.upfronthosting.co.za> Changes by Georg Brandl: ---------- status: pending -> closed _____________________________________ Tracker _____________________________________ From report at bugs.python.org Fri Sep 7 09:40:37 2007 From: report at bugs.python.org (Georg Brandl) Date: Fri, 07 Sep 2007 07:40:37 -0000 Subject: [issue1767242] os.chmod failure Message-ID: <1189150837.28.0.392180070132.issue1767242@psf.upfronthosting.co.za> Changes by Georg Brandl: ---------- status: pending -> closed _____________________________________ Tracker _____________________________________ From report at bugs.python.org Fri Sep 7 09:40:49 2007 From: report at bugs.python.org (Georg Brandl) Date: Fri, 07 Sep 2007 07:40:49 -0000 Subject: [issue1708326] imp.find_module doc ambiguity Message-ID: <1189150849.77.0.424260710861.issue1708326@psf.upfronthosting.co.za> Changes by Georg Brandl: ---------- status: pending -> closed _____________________________________ Tracker _____________________________________ From report at bugs.python.org Fri Sep 7 16:38:54 2007 From: report at bugs.python.org (Nir Soffer) Date: Fri, 07 Sep 2007 14:38:54 -0000 Subject: [issue1125] bytes.split shold have same interface as str.split, or different name Message-ID: <1189175934.9.0.528203057588.issue1125@psf.upfronthosting.co.za> Nir Soffer added the comment: Why bytes should not use a default whitespace split behavior as str? __________________________________ Tracker __________________________________ From report at bugs.python.org Fri Sep 7 17:16:31 2007 From: report at bugs.python.org (=?utf-8?q?Walter_D=C3=B6rwald?=) Date: Fri, 07 Sep 2007 15:16:31 -0000 Subject: [issue1125] bytes.split shold have same interface as str.split, or different name Message-ID: <1189178191.77.0.425876239508.issue1125@psf.upfronthosting.co.za> Walter D?rwald added the comment: Because it's not clear whether b'\xa0' *is* whitespace or not. Bytes have no meaning, characters do. ---------- nosy: +doerwalter __________________________________ Tracker __________________________________ From report at bugs.python.org Fri Sep 7 17:29:35 2007 From: report at bugs.python.org (Anand Patil) Date: Fri, 07 Sep 2007 15:29:35 -0000 Subject: [issue1113] interrupt_main() fails to interrupt raw_input() In-Reply-To: <46E0F425.60104@python.org> Message-ID: <2bc7a5a50709070829v1e8ee833y6f613b966a922486@mail.gmail.com> Anand Patil added the comment: OK, thanks for your help. On 9/6/07, Georg Brandl wrote: > > > Georg Brandl added the comment: > > Anand Patil schrieb: > > Anand Patil added the comment: > > > > Sorry- Where can I get this patch? The SourceForge patch manager says > it's > > closed. > > It is - like all other issues - in this tracker at > http://bugs.python.org/706406. > > __________________________________ > Tracker > > __________________________________ > __________________________________ Tracker __________________________________ -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: unnamed Url: http://mail.python.org/pipermail/python-bugs-list/attachments/20070907/3be659f5/attachment.txt From report at bugs.python.org Fri Sep 7 17:38:40 2007 From: report at bugs.python.org (=?utf-8?q?=0A=09=09=09=09=09Anthony_Tuininga=0A=09=09=09=09?=) Date: Fri, 07 Sep 2007 15:38:40 -0000 Subject: [issue1128] msilib.Directory.make_short only handles file names with a single dot in them Message-ID: <1189179520.92.0.794860414513.issue1128@psf.upfronthosting.co.za> New submission from Anthony Tuininga : Attached is a patch that fixes the handling of file names with 0 or 2 or more dots in them. ---------- components: Library (Lib) files: msilib.__init__.patch messages: 55736 nosy: atuining severity: normal status: open title: msilib.Directory.make_short only handles file names with a single dot in them versions: Python 2.5 __________________________________ Tracker __________________________________ -------------- next part -------------- A non-text attachment was scrubbed... Name: msilib.__init__.patch Type: application/octet-stream Size: 556 bytes Desc: not available Url : http://mail.python.org/pipermail/python-bugs-list/attachments/20070907/2dce6a39/attachment.obj From report at bugs.python.org Fri Sep 7 17:38:41 2007 From: report at bugs.python.org (=?utf-8?q?=0A=09=09=09=09=09Anthony_Tuininga=0A=09=09=09=09?=) Date: Fri, 07 Sep 2007 15:38:41 -0000 Subject: [issue1128] msilib.Directory.make_short only handles file names with a single dot in them Message-ID: <1189179520.92.0.794860414513.issue1128@psf.upfronthosting.co.za> New submission from Anthony Tuininga : Attached is a patch that fixes the handling of file names with 0 or 2 or more dots in them. ---------- components: Library (Lib) files: msilib.__init__.patch messages: 55736 nosy: atuining severity: normal status: open title: msilib.Directory.make_short only handles file names with a single dot in them versions: Python 2.5 __________________________________ Tracker __________________________________ -------------- next part -------------- A non-text attachment was scrubbed... Name: msilib.__init__.patch Type: application/octet-stream Size: 556 bytes Desc: not available Url : http://mail.python.org/pipermail/python-bugs-list/attachments/20070907/2dce6a39/attachment-0001.obj From report at bugs.python.org Fri Sep 7 19:06:08 2007 From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=) Date: Fri, 07 Sep 2007 17:06:08 -0000 Subject: [issue1128] msilib.Directory.make_short only handles file names with a single dot in them Message-ID: <1189184768.1.0.181686916391.issue1128@psf.upfronthosting.co.za> Changes by Martin v. L?wis: ---------- assignee: -> loewis keywords: +patch nosy: +loewis __________________________________ Tracker __________________________________ From report at bugs.python.org Fri Sep 7 19:27:24 2007 From: report at bugs.python.org (Guido van Rossum) Date: Fri, 07 Sep 2007 17:27:24 -0000 Subject: [issue1125] bytes.split shold have same interface as str.split, or different name Message-ID: <1189186044.45.0.719239795024.issue1125@psf.upfronthosting.co.za> Guido van Rossum added the comment: I tend to agree with the author; I've run into this myself. For whitespace, I propose to use only the following: tab LF FF VT CR space. These are the whitespace ASCII characters according to isspace() in libc. (Unicode also treats hex 1C, 1D, 1E and 1F as whitespace; I have no idea what these mean. In practice I don't think it matters either way.) ---------- assignee: -> gvanrossum nosy: +gvanrossum __________________________________ Tracker __________________________________ From report at bugs.python.org Fri Sep 7 19:28:16 2007 From: report at bugs.python.org (Guido van Rossum) Date: Fri, 07 Sep 2007 17:28:16 -0000 Subject: [issue1125] bytes.split shold have same interface as str.split, or different name Message-ID: <1189186096.54.0.517934839083.issue1125@psf.upfronthosting.co.za> Changes by Guido van Rossum: __________________________________ Tracker __________________________________ From report at bugs.python.org Fri Sep 7 19:31:49 2007 From: report at bugs.python.org (Guido van Rossum) Date: Fri, 07 Sep 2007 17:31:49 -0000 Subject: [issue1123] split(None, maxsplit) does not strip whitespace correctly Message-ID: <1189186309.9.0.784906939837.issue1123@psf.upfronthosting.co.za> Changes by Guido van Rossum: __________________________________ Tracker __________________________________ From report at bugs.python.org Fri Sep 7 19:31:54 2007 From: report at bugs.python.org (Guido van Rossum) Date: Fri, 07 Sep 2007 17:31:54 -0000 Subject: [issue1123] split(None, maxsplit) does not strip whitespace correctly Message-ID: <1189186314.6.0.499929353863.issue1123@psf.upfronthosting.co.za> Changes by Guido van Rossum: __________________________________ Tracker __________________________________ From report at bugs.python.org Fri Sep 7 19:56:24 2007 From: report at bugs.python.org (Guido van Rossum) Date: Fri, 07 Sep 2007 17:56:24 -0000 Subject: [issue1124] Webchecker not parsing css "@import url" Message-ID: <1189187784.08.0.571387695925.issue1124@psf.upfronthosting.co.za> Guido van Rossum added the comment: This is essentially unsupported and unmaintaned example code. Feel free to submit a patch though! ---------- nosy: +gvanrossum __________________________________ Tracker __________________________________ From report at bugs.python.org Fri Sep 7 20:41:13 2007 From: report at bugs.python.org (Stefan Sonnenberg-Carstens) Date: Fri, 07 Sep 2007 18:41:13 -0000 Subject: [issue1129] OpenSSL detection broken for Python 3.0a1 Message-ID: <1189190473.33.0.541270501112.issue1129@psf.upfronthosting.co.za> New submission from Stefan Sonnenberg-Carstens: In line 618 the comparison must be this: if (openssl_ver >= 0x00908000): otherwise there are complaints about not being able to build the _sha256 and _sha512 modules, even if OpenSSL >= 0.9.8 is installed, as in my case. ---------- components: Build messages: 55739 nosy: pythonmeister severity: major status: open title: OpenSSL detection broken for Python 3.0a1 type: compile error versions: Python 3.0 __________________________________ Tracker __________________________________ From report at bugs.python.org Fri Sep 7 20:41:13 2007 From: report at bugs.python.org (Stefan Sonnenberg-Carstens) Date: Fri, 07 Sep 2007 18:41:13 -0000 Subject: [issue1129] OpenSSL detection broken for Python 3.0a1 Message-ID: <1189190473.33.0.541270501112.issue1129@psf.upfronthosting.co.za> New submission from Stefan Sonnenberg-Carstens: In line 618 the comparison must be this: if (openssl_ver >= 0x00908000): otherwise there are complaints about not being able to build the _sha256 and _sha512 modules, even if OpenSSL >= 0.9.8 is installed, as in my case. ---------- components: Build messages: 55739 nosy: pythonmeister severity: major status: open title: OpenSSL detection broken for Python 3.0a1 type: compile error versions: Python 3.0 __________________________________ Tracker __________________________________ From report at bugs.python.org Fri Sep 7 20:50:53 2007 From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=) Date: Fri, 07 Sep 2007 18:50:53 -0000 Subject: [issue1095] make install failed Message-ID: <1189191053.01.0.872133630334.issue1095@psf.upfronthosting.co.za> Martin v. L?wis added the comment: I haven't tested it, but it looks fine to me. ---------- assignee: -> georg.brandl resolution: -> accepted __________________________________ Tracker __________________________________ From report at bugs.python.org Fri Sep 7 22:08:46 2007 From: report at bugs.python.org (Stefan Sonnenberg-Carstens) Date: Fri, 07 Sep 2007 20:08:46 -0000 Subject: [issue1129] OpenSSL detection broken for Python 3.0a1 Message-ID: <1189195726.63.0.942374685973.issue1129@psf.upfronthosting.co.za> Stefan Sonnenberg-Carstens added the comment: Patch attached: --- setup.py 2007-09-07 16:08:05.000000000 -0400 +++ ../Python-3.0a1_SSC/setup.py 2007-09-07 16:07:31.000000000 -0400 @@ -613,7 +613,7 @@ else: missing.append('_hashlib') - if (openssl_ver < 0x00908000): + if (openssl_ver >= 0x00908000): # OpenSSL doesn't do these until 0.9.8 so we'll bring our own hash exts.append( Extension('_sha256', ['sha256module.c']) ) exts.append( Extension('_sha512', ['sha512module.c']) ) __________________________________ Tracker __________________________________ From report at bugs.python.org Fri Sep 7 22:13:15 2007 From: report at bugs.python.org (Georg Brandl) Date: Fri, 07 Sep 2007 20:13:15 -0000 Subject: [issue1095] make install failed In-Reply-To: <1189191053.01.0.872133630334.issue1095@psf.upfronthosting.co.za> Message-ID: <46E1B0D9.6010902@python.org> Georg Brandl added the comment: Committed as rev. 58043, 58044. ---------- resolution: accepted -> fixed status: open -> closed __________________________________ Tracker __________________________________ From report at bugs.python.org Fri Sep 7 22:19:43 2007 From: report at bugs.python.org (Stefan Sonnenberg-Carstens) Date: Fri, 07 Sep 2007 20:19:43 -0000 Subject: [issue1126] file.fileno and file.isatty() should be implementable by any file like object Message-ID: <1189196383.51.0.959659164755.issue1126@psf.upfronthosting.co.za> Stefan Sonnenberg-Carstens added the comment: You are free to do what you want. Reasons for not implementing fileno and isatty are: - fileno should be an integer pointing to a real file, so that low-level functions in libc can handle that. Can you provide such ? (see http://netbsd.gw.com/cgi-bin/man-cgi?open++NetBSD-current) - duck-typing / there must be a difference to "real" files in the first sense ---------- nosy: +pythonmeister __________________________________ Tracker __________________________________ From report at bugs.python.org Fri Sep 7 23:07:29 2007 From: report at bugs.python.org (Georg Brandl) Date: Fri, 07 Sep 2007 21:07:29 -0000 Subject: [issue1129] OpenSSL detection broken for Python 3.0a1 In-Reply-To: <1189195726.63.0.942374685973.issue1129@psf.upfronthosting.co.za> Message-ID: <46E1BD96.2010707@gmx.net> Georg Brandl added the comment: I think you misunderstood the setup.py message; from OpenSSL 0.9.8, building the _sha modules is not needed. That they are reported as not built is a bug which has been fixed now in SVN. ---------- nosy: +georg.brandl resolution: -> invalid status: open -> closed __________________________________ Tracker __________________________________ From report at bugs.python.org Sat Sep 8 02:35:22 2007 From: report at bugs.python.org (Guido van Rossum) Date: Sat, 08 Sep 2007 00:35:22 -0000 Subject: [issue1125] bytes.split shold have same interface as str.split, or different name Message-ID: <1189211722.24.0.0597929647182.issue1125@psf.upfronthosting.co.za> Guido van Rossum added the comment: Here's a patch that fixes bytes.split and .rsplit. I'll hold off for a while in case there's strong disagreement. I might add a patch for bytes.strip later (it's simpler). ---------- keywords: +patch __________________________________ Tracker __________________________________ -------------- next part -------------- A non-text attachment was scrubbed... Name: bytes-split.diff Type: text/x-patch Size: 7604 bytes Desc: not available Url : http://mail.python.org/pipermail/python-bugs-list/attachments/20070908/f414a118/attachment.bin From report at bugs.python.org Sat Sep 8 02:35:55 2007 From: report at bugs.python.org (Guido van Rossum) Date: Sat, 08 Sep 2007 00:35:55 -0000 Subject: [issue1125] bytes.split shold have same interface as str.split, or different name Message-ID: <1189211755.19.0.290596870466.issue1125@psf.upfronthosting.co.za> Changes by Guido van Rossum: ---------- components: +Interpreter Core -Library (Lib) type: rfe -> behavior __________________________________ Tracker __________________________________ From report at bugs.python.org Sat Sep 8 04:27:20 2007 From: report at bugs.python.org (Carl Trachte) Date: Sat, 08 Sep 2007 02:27:20 -0000 Subject: [issue1130] Idle - Save (buffer) Message-ID: <1189218440.32.0.289550015248.issue1130@psf.upfronthosting.co.za> Changes by Carl Trachte: ---------- components: IDLE severity: normal status: open title: Idle - Save (buffer) type: behavior versions: Python 3.0 __________________________________ Tracker __________________________________ From report at bugs.python.org Sat Sep 8 04:29:45 2007 From: report at bugs.python.org (Carl Trachte) Date: Sat, 08 Sep 2007 02:29:45 -0000 Subject: [issue1130] Idle - Save (buffer) - closes IDLE and does not save file (Windows XP) Message-ID: <1189218585.29.0.544244221326.issue1130@psf.upfronthosting.co.za> Changes by Carl Trachte: ---------- title: Idle - Save (buffer) -> Idle - Save (buffer) - closes IDLE and does not save file (Windows XP) __________________________________ Tracker __________________________________ From report at bugs.python.org Sat Sep 8 12:25:22 2007 From: report at bugs.python.org (Stefan Sonnenberg-Carstens) Date: Sat, 08 Sep 2007 10:25:22 -0000 Subject: [issue1125] bytes.split shold have same interface as str.split, or different name Message-ID: <1189247122.35.0.814603713391.issue1125@psf.upfronthosting.co.za> Stefan Sonnenberg-Carstens added the comment: IMHO I also aggree that strings and bytes (list of bytes) should have the same interface. It is common sense that talking about strings most programmers think of a list of bytes composing it (char *). So the abbreviation should also hold true with python. ---------- nosy: +pythonmeister __________________________________ Tracker __________________________________ From report at bugs.python.org Sat Sep 8 14:01:46 2007 From: report at bugs.python.org (Vinay Sajip) Date: Sat, 08 Sep 2007 12:01:46 -0000 Subject: [issue1765140] logging: delay_fh option and configuration kwargs Message-ID: <1189252906.23.0.838279208498.issue1765140@psf.upfronthosting.co.za> Vinay Sajip added the comment: Thanks for the patch. I think it would be simpler to just implement an optional delay parameter in FileHandler and its subclasses: then the configuration stuff need not be touched at all, since the delay parameter can be specified in the configuration file. There would then be no need for a callback or a file-opening closure: If delay is False (the default), FileHandler would behave as it does now. If True, then the open code in FileHandler's constructor would be deferred until the time emit() was called on the instance. Would this meet your needs? _____________________________________ Tracker _____________________________________ From report at bugs.python.org Sat Sep 8 15:49:52 2007 From: report at bugs.python.org (Elias Pipping) Date: Sat, 08 Sep 2007 13:49:52 -0000 Subject: [issue1099] Mac compile fails with pydebug and framework enabled Message-ID: <1189259392.34.0.00118088440605.issue1099@psf.upfronthosting.co.za> Elias Pipping added the comment: I can reproduce this problem on both an intel and a powerpc mac. With '--with-pydebug --enable-framework --enable-universalsdk', the behavior is very much different: On a powerpc mac, configure fails with 'checking size of wchar_t...configure: error: cannot compute sizeof (wchar_t)' On an intel mac, configure and make succeed; a test fails, though (which normally passes, e.g. when no arguments at all were passed to configure). The failing test is: test_xmlrpc. ---------- nosy: +pipping __________________________________ Tracker __________________________________ From report at bugs.python.org Sat Sep 8 16:26:46 2007 From: report at bugs.python.org (Martoon) Date: Sat, 08 Sep 2007 14:26:46 -0000 Subject: [issue1131] Reference Manual: "for statement" links to "break statement" Message-ID: <1189261606.63.0.731863815779.issue1131@psf.upfronthosting.co.za> New submission from Martoon: Error in the Windows distro documentation. If you go to "for" or "for statement" in the index, it brings you to the doc page for "The break statement." ---------- components: Documentation, Windows messages: 55749 nosy: Martoon severity: minor status: open title: Reference Manual: "for statement" links to "break statement" versions: Python 2.5 __________________________________ Tracker __________________________________ From report at bugs.python.org Sat Sep 8 16:26:46 2007 From: report at bugs.python.org (Martoon) Date: Sat, 08 Sep 2007 14:26:46 -0000 Subject: [issue1131] Reference Manual: "for statement" links to "break statement" Message-ID: <1189261606.63.0.731863815779.issue1131@psf.upfronthosting.co.za> New submission from Martoon: Error in the Windows distro documentation. If you go to "for" or "for statement" in the index, it brings you to the doc page for "The break statement." ---------- components: Documentation, Windows messages: 55749 nosy: Martoon severity: minor status: open title: Reference Manual: "for statement" links to "break statement" versions: Python 2.5 __________________________________ Tracker __________________________________ From report at bugs.python.org Sat Sep 8 18:44:22 2007 From: report at bugs.python.org (Guido van Rossum) Date: Sat, 08 Sep 2007 16:44:22 -0000 Subject: [issue1125] bytes.split shold have same interface as str.split, or different name Message-ID: <1189269862.13.0.744550758448.issue1125@psf.upfronthosting.co.za> Guido van Rossum added the comment: Updated patch that also modifies bytes.*strip(). __________________________________ Tracker __________________________________ -------------- next part -------------- A non-text attachment was scrubbed... Name: bytes-split.diff Type: text/x-patch Size: 12796 bytes Desc: not available Url : http://mail.python.org/pipermail/python-bugs-list/attachments/20070908/17c07b27/attachment-0001.bin From report at bugs.python.org Sat Sep 8 19:05:10 2007 From: report at bugs.python.org (Guido van Rossum) Date: Sat, 08 Sep 2007 17:05:10 -0000 Subject: [issue1125] bytes.split shold have same interface as str.split, or different name Message-ID: <1189271110.25.0.603555059251.issue1125@psf.upfronthosting.co.za> Guido van Rossum added the comment: New version with corrected docstrings and buffer support for *split() as well. Added unittests. __________________________________ Tracker __________________________________ -------------- next part -------------- A non-text attachment was scrubbed... Name: bytes-split.diff Type: text/x-patch Size: 16087 bytes Desc: not available Url : http://mail.python.org/pipermail/python-bugs-list/attachments/20070908/ad4a2796/attachment.bin From report at bugs.python.org Sat Sep 8 19:05:22 2007 From: report at bugs.python.org (Guido van Rossum) Date: Sat, 08 Sep 2007 17:05:22 -0000 Subject: [issue1125] bytes.split shold have same interface as str.split, or different name Message-ID: <1189271122.56.0.609980943249.issue1125@psf.upfronthosting.co.za> Changes by Guido van Rossum: __________________________________ Tracker __________________________________ From report at bugs.python.org Sat Sep 8 19:05:38 2007 From: report at bugs.python.org (Guido van Rossum) Date: Sat, 08 Sep 2007 17:05:38 -0000 Subject: [issue1125] bytes.split shold have same interface as str.split, or different name Message-ID: <1189271138.04.0.721733131824.issue1125@psf.upfronthosting.co.za> Changes by Guido van Rossum: __________________________________ Tracker __________________________________ From report at bugs.python.org Sat Sep 8 21:08:01 2007 From: report at bugs.python.org (Bill Janssen) Date: Sat, 08 Sep 2007 19:08:01 -0000 Subject: [issue1099] Mac compile fails with pydebug and framework enabled Message-ID: <1189278481.86.0.755169926235.issue1099@psf.upfronthosting.co.za> Bill Janssen added the comment: Which versions of OS X, please? And which Xcode versions? ---------- nosy: +janssen __________________________________ Tracker __________________________________ From report at bugs.python.org Sat Sep 8 22:15:36 2007 From: report at bugs.python.org (=?utf-8?q?Andr=C3=A9?=) Date: Sat, 08 Sep 2007 20:15:36 -0000 Subject: [issue1132] compile error in poplib.py Message-ID: <1189282536.64.0.420049245875.issue1132@psf.upfronthosting.co.za> New submission from Andr?: File "c:\Python30\lib\poplib.py", line 137, in _getlongresp while line != '.': TypeError: can't compare bytes and str ---------- components: Library (Lib) messages: 55753 nosy: andre severity: normal status: open title: compile error in poplib.py type: compile error versions: Python 3.0 __________________________________ Tracker __________________________________ From report at bugs.python.org Sat Sep 8 22:15:36 2007 From: report at bugs.python.org (=?utf-8?q?Andr=C3=A9?=) Date: Sat, 08 Sep 2007 20:15:36 -0000 Subject: [issue1132] compile error in poplib.py Message-ID: <1189282536.64.0.420049245875.issue1132@psf.upfronthosting.co.za> New submission from Andr?: File "c:\Python30\lib\poplib.py", line 137, in _getlongresp while line != '.': TypeError: can't compare bytes and str ---------- components: Library (Lib) messages: 55753 nosy: andre severity: normal status: open title: compile error in poplib.py type: compile error versions: Python 3.0 __________________________________ Tracker __________________________________ From report at bugs.python.org Sat Sep 8 22:42:12 2007 From: report at bugs.python.org (Elias Pipping) Date: Sat, 08 Sep 2007 20:42:12 -0000 Subject: [issue1099] Mac compile fails with pydebug and framework enabled Message-ID: <1189284132.03.0.853544282355.issue1099@psf.upfronthosting.co.za> Elias Pipping added the comment: powerpc : macosx 10.4.10, xcode 2.4.1 (gcc 4.0.1 build 5367) intel : macosx 10.4.10, xcode 2.5pre (gcc 4.0.1 build 5370) __________________________________ Tracker __________________________________ From report at bugs.python.org Sat Sep 8 23:16:31 2007 From: report at bugs.python.org (Collin Winter) Date: Sat, 08 Sep 2007 21:16:31 -0000 Subject: [issue1107] 2to3, lambda with non-tuple argument inside parenthesis Message-ID: <1189286191.51.0.701677416199.issue1107@psf.upfronthosting.co.za> Collin Winter added the comment: Fixed in r58055, r58056. ---------- resolution: -> fixed status: open -> closed __________________________________ Tracker __________________________________ From report at bugs.python.org Sun Sep 9 01:51:46 2007 From: report at bugs.python.org (Bill Janssen) Date: Sat, 08 Sep 2007 23:51:46 -0000 Subject: [issue1132] compile error in poplib.py Message-ID: <1189295506.66.0.68100610886.issue1132@psf.upfronthosting.co.za> Bill Janssen added the comment: Isn't this 1094? ---------- nosy: +janssen __________________________________ Tracker __________________________________ From report at bugs.python.org Sun Sep 9 02:18:18 2007 From: report at bugs.python.org (Viktor Ferenczi) Date: Sun, 09 Sep 2007 00:18:18 -0000 Subject: [issue1133] python3.0-config raises SyntaxError Message-ID: <1189297098.34.0.426039385433.issue1133@psf.upfronthosting.co.za> New submission from Viktor Ferenczi: Running python3.0-config raises SyntaxError: $ python3.0-config File "/usr/local/bin/python3.0-config", line 33 print sysconfig.PREFIX ^ SyntaxError: invalid syntax OS: Ununtu Feisty, up-to-date Python: Python 3.0a1, compiled from source, configured with: --prefix=/usr/local ---------- components: Demos and Tools, Installation messages: 55757 nosy: complex severity: normal status: open title: python3.0-config raises SyntaxError versions: Python 3.0 __________________________________ Tracker __________________________________ From report at bugs.python.org Sun Sep 9 02:18:18 2007 From: report at bugs.python.org (Viktor Ferenczi) Date: Sun, 09 Sep 2007 00:18:18 -0000 Subject: [issue1133] python3.0-config raises SyntaxError Message-ID: <1189297098.34.0.426039385433.issue1133@psf.upfronthosting.co.za> New submission from Viktor Ferenczi: Running python3.0-config raises SyntaxError: $ python3.0-config File "/usr/local/bin/python3.0-config", line 33 print sysconfig.PREFIX ^ SyntaxError: invalid syntax OS: Ununtu Feisty, up-to-date Python: Python 3.0a1, compiled from source, configured with: --prefix=/usr/local ---------- components: Demos and Tools, Installation messages: 55757 nosy: complex severity: normal status: open title: python3.0-config raises SyntaxError versions: Python 3.0 __________________________________ Tracker __________________________________ From report at bugs.python.org Sun Sep 9 02:35:45 2007 From: report at bugs.python.org (Viktor Ferenczi) Date: Sun, 09 Sep 2007 00:35:45 -0000 Subject: [issue1134] Parsing a simple script eats all of your memory Message-ID: <1189298145.63.0.146267500715.issue1134@psf.upfronthosting.co.za> New submission from Viktor Ferenczi: Read the WARNING below, then run the attached script with Python3.0a2. It will eat all of your memory. WARNING: Keep a process killing tool or an extra command line at your fingertips, since this script could render your machine unusable in about 10-20 seconds depending on your memory and CPU speed!!! YOU ARE WARNED! OS: Ubuntu Feisty, up-to-date Python: Python3.0a1, built from sources, configured with: --prefix=/usr/local ---------- components: Interpreter Core files: hungry_script.py messages: 55758 nosy: complex severity: critical status: open title: Parsing a simple script eats all of your memory type: crash versions: Python 3.0 __________________________________ Tracker __________________________________ -------------- next part -------------- A non-text attachment was scrubbed... Name: hungry_script.py Type: text/x-python Size: 179 bytes Desc: not available Url : http://mail.python.org/pipermail/python-bugs-list/attachments/20070909/5fdd290a/attachment.py From report at bugs.python.org Sun Sep 9 02:35:45 2007 From: report at bugs.python.org (Viktor Ferenczi) Date: Sun, 09 Sep 2007 00:35:45 -0000 Subject: [issue1134] Parsing a simple script eats all of your memory Message-ID: <1189298145.63.0.146267500715.issue1134@psf.upfronthosting.co.za> New submission from Viktor Ferenczi: Read the WARNING below, then run the attached script with Python3.0a2. It will eat all of your memory. WARNING: Keep a process killing tool or an extra command line at your fingertips, since this script could render your machine unusable in about 10-20 seconds depending on your memory and CPU speed!!! YOU ARE WARNED! OS: Ubuntu Feisty, up-to-date Python: Python3.0a1, built from sources, configured with: --prefix=/usr/local ---------- components: Interpreter Core files: hungry_script.py messages: 55758 nosy: complex severity: critical status: open title: Parsing a simple script eats all of your memory type: crash versions: Python 3.0 __________________________________ Tracker __________________________________ -------------- next part -------------- A non-text attachment was scrubbed... Name: hungry_script.py Type: text/x-python Size: 179 bytes Desc: not available Url : http://mail.python.org/pipermail/python-bugs-list/attachments/20070909/5fdd290a/attachment-0001.py From report at bugs.python.org Sun Sep 9 02:45:40 2007 From: report at bugs.python.org (Viktor Ferenczi) Date: Sun, 09 Sep 2007 00:45:40 -0000 Subject: [issue1134] Parsing a simple script eats all of your memory Message-ID: <1189298740.0.0.957828280938.issue1134@psf.upfronthosting.co.za> Viktor Ferenczi added the comment: Confirmed on Windows: OS: Windows XP SP2 ENG Python: Python3.0a1 MSI installer, default installation __________________________________ Tracker __________________________________ From report at bugs.python.org Sun Sep 9 02:50:01 2007 From: report at bugs.python.org (Viktor Ferenczi) Date: Sun, 09 Sep 2007 00:50:01 -0000 Subject: [issue1134] Parsing a simple script eats all of your memory Message-ID: <1189299001.42.0.803496677722.issue1134@psf.upfronthosting.co.za> Viktor Ferenczi added the comment: Works fine (does nothing) with Python 2.4.4 and Python 2.5.1 under Windows, so this bug must be caused by some new code in Python3.0a1. The bug depends on the contents of the doc string. There's another strange behavior if you write the word "this" in the docstring somewhere. The docstring could be parsed as source code somehow and causes strange things to the new parser. __________________________________ Tracker __________________________________ From report at bugs.python.org Sun Sep 9 02:57:59 2007 From: report at bugs.python.org (Viktor Ferenczi) Date: Sun, 09 Sep 2007 00:57:59 -0000 Subject: [issue1134] Parsing a simple script eats all of your memory Message-ID: <1189299479.98.0.75051906135.issue1134@psf.upfronthosting.co.za> Viktor Ferenczi added the comment: Errata: In the first line of my original post I mean Python3.0a1 and not 3.0a2, certainly. __________________________________ Tracker __________________________________ From report at bugs.python.org Sun Sep 9 07:07:26 2007 From: report at bugs.python.org (=?utf-8?q?=0A=09=09=09=09=09Hirokazu_Yamamoto=0A=09=09=09=09?=) Date: Sun, 09 Sep 2007 05:07:26 -0000 Subject: [issue1135] xview/yview of Tix.Grid is broken Message-ID: <1189314445.29.0.484479560219.issue1135@psf.upfronthosting.co.za> New submission from Hirokazu Yamamoto : Attached code "test_tixGrid.py" fails with following error message. TypeError: yview() takes exactly 1 argument (4 given) ---------- components: Tkinter files: test_tixGrid.py messages: 55762 nosy: ocean-city severity: normal status: open title: xview/yview of Tix.Grid is broken type: behavior versions: Python 2.5 __________________________________ Tracker __________________________________ -------------- next part -------------- A non-text attachment was scrubbed... Name: test_tixGrid.py Type: text/x-python Size: 907 bytes Desc: not available Url : http://mail.python.org/pipermail/python-bugs-list/attachments/20070909/f8ce3c60/attachment.py From report at bugs.python.org Sun Sep 9 07:07:25 2007 From: report at bugs.python.org (=?utf-8?q?=0A=09=09=09=09=09Hirokazu_Yamamoto=0A=09=09=09=09?=) Date: Sun, 09 Sep 2007 05:07:25 -0000 Subject: [issue1135] xview/yview of Tix.Grid is broken Message-ID: <1189314445.29.0.484479560219.issue1135@psf.upfronthosting.co.za> New submission from Hirokazu Yamamoto : Attached code "test_tixGrid.py" fails with following error message. TypeError: yview() takes exactly 1 argument (4 given) ---------- components: Tkinter files: test_tixGrid.py messages: 55762 nosy: ocean-city severity: normal status: open title: xview/yview of Tix.Grid is broken type: behavior versions: Python 2.5 __________________________________ Tracker __________________________________ -------------- next part -------------- A non-text attachment was scrubbed... Name: test_tixGrid.py Type: text/x-python Size: 907 bytes Desc: not available Url : http://mail.python.org/pipermail/python-bugs-list/attachments/20070909/f8ce3c60/attachment-0001.py From report at bugs.python.org Sun Sep 9 07:08:18 2007 From: report at bugs.python.org (=?utf-8?q?=0A=09=09=09=09=09Hirokazu_Yamamoto=0A=09=09=09=09?=) Date: Sun, 09 Sep 2007 05:08:18 -0000 Subject: [issue1135] xview/yview of Tix.Grid is broken Message-ID: <1189314498.36.0.466775616056.issue1135@psf.upfronthosting.co.za> Hirokazu Yamamoto added the comment: Probably right fix is attached file "fix_tixGrid.patch" __________________________________ Tracker __________________________________ -------------- next part -------------- A non-text attachment was scrubbed... Name: fix_tixGrid.patch Type: text/x-patch Size: 1048 bytes Desc: not available Url : http://mail.python.org/pipermail/python-bugs-list/attachments/20070909/1d212027/attachment.bin From report at bugs.python.org Sun Sep 9 09:29:30 2007 From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=) Date: Sun, 09 Sep 2007 07:29:30 -0000 Subject: [issue1133] python3.0-config raises SyntaxError Message-ID: <1189322970.96.0.653103270661.issue1133@psf.upfronthosting.co.za> Martin v. L?wis added the comment: Duplicate of #1074 ---------- nosy: +loewis superseder: -> python3.0-config script does not run on py3k __________________________________ Tracker __________________________________ From report at bugs.python.org Sun Sep 9 09:29:40 2007 From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=) Date: Sun, 09 Sep 2007 07:29:40 -0000 Subject: [issue1133] python3.0-config raises SyntaxError Message-ID: <1189322980.37.0.680338200374.issue1133@psf.upfronthosting.co.za> Changes by Martin v. L?wis: ---------- resolution: -> duplicate status: open -> closed __________________________________ Tracker __________________________________ From report at bugs.python.org Sun Sep 9 12:04:33 2007 From: report at bugs.python.org (Georg Brandl) Date: Sun, 09 Sep 2007 10:04:33 -0000 Subject: [issue1132] compile error in poplib.py In-Reply-To: <1189295506.66.0.68100610886.issue1132@psf.upfronthosting.co.za> Message-ID: <46E3C536.1090805@gmx.net> Georg Brandl added the comment: Bill Janssen schrieb: > Isn't this 1094? It is. ---------- nosy: +georg.brandl resolution: -> duplicate status: open -> closed superseder: -> TypeError in poplib.py __________________________________ Tracker __________________________________ From report at bugs.python.org Sun Sep 9 17:09:58 2007 From: report at bugs.python.org (=?utf-8?q?Cristina_Yenyxe_Gonz=C3=A1lez_Garc=C3=ADa?=) Date: Sun, 09 Sep 2007 15:09:58 -0000 Subject: [issue1136] Bdb documentation Message-ID: <1189350598.74.0.444116788582.issue1136@psf.upfronthosting.co.za> New submission from Cristina Yenyxe Gonz?lez Garc?a: Hello, I thought it could be interesting to write some documentation for the bdb module, since it keeps undocumented on Python 2.6 and 3.0. The document I attach is written in reStructuredText, and for using it with 2.5 it only needs to change the header for the 'Bdb.user_exception' method (and convert to LaTeX format, of course). It will thank a revision because there can be some grammatical errors (I'm from Spain). Anyway, I hope it helps, and any comment will be welcomed :D ---------- components: Documentation files: bdb.rst messages: 55766 nosy: arklad severity: normal status: open title: Bdb documentation versions: Python 2.6, Python 3.0 __________________________________ Tracker __________________________________ -------------- next part -------------- A non-text attachment was scrubbed... Name: bdb.rst Type: application/octet-stream Size: 10839 bytes Desc: not available Url : http://mail.python.org/pipermail/python-bugs-list/attachments/20070909/9f4b19b2/attachment-0002.obj From report at bugs.python.org Sun Sep 9 17:09:59 2007 From: report at bugs.python.org (=?utf-8?q?Cristina_Yenyxe_Gonz=C3=A1lez_Garc=C3=ADa?=) Date: Sun, 09 Sep 2007 15:09:59 -0000 Subject: [issue1136] Bdb documentation Message-ID: <1189350598.74.0.444116788582.issue1136@psf.upfronthosting.co.za> New submission from Cristina Yenyxe Gonz?lez Garc?a: Hello, I thought it could be interesting to write some documentation for the bdb module, since it keeps undocumented on Python 2.6 and 3.0. The document I attach is written in reStructuredText, and for using it with 2.5 it only needs to change the header for the 'Bdb.user_exception' method (and convert to LaTeX format, of course). It will thank a revision because there can be some grammatical errors (I'm from Spain). Anyway, I hope it helps, and any comment will be welcomed :D ---------- components: Documentation files: bdb.rst messages: 55766 nosy: arklad severity: normal status: open title: Bdb documentation versions: Python 2.6, Python 3.0 __________________________________ Tracker __________________________________ -------------- next part -------------- A non-text attachment was scrubbed... Name: bdb.rst Type: application/octet-stream Size: 10839 bytes Desc: not available Url : http://mail.python.org/pipermail/python-bugs-list/attachments/20070909/9f4b19b2/attachment-0003.obj From report at bugs.python.org Sun Sep 9 18:40:11 2007 From: report at bugs.python.org (Achim Gaedke) Date: Sun, 09 Sep 2007 16:40:11 -0000 Subject: [issue1137] pyexpat patch for changing buffer_size Message-ID: <1189356011.84.0.968400197849.issue1137@psf.upfronthosting.co.za> New submission from Achim Gaedke: Hello! Sometimes people have big amounts of text/data in xml files. To make processing more effective, they should be able to change the buffer size for collecting character data in one string. Here comes a patch that applies necessary changes in setattr method. It handles reallocation sufficiently efficient without introducing extra variables to the parser class. Also a documentation patch and some test cases are available. These patches and tests were done with debian etch python2.5, which is python-2.5.1 . This patch also works on python2.4 . ---------- components: XML files: pyexpat_c_patch messages: 55767 nosy: AchimGaedke severity: normal status: open title: pyexpat patch for changing buffer_size versions: Python 2.5 __________________________________ Tracker __________________________________ -------------- next part -------------- A non-text attachment was scrubbed... Name: pyexpat_c_patch Type: application/octet-stream Size: 2544 bytes Desc: not available Url : http://mail.python.org/pipermail/python-bugs-list/attachments/20070909/b99c513a/attachment.obj From report at bugs.python.org Sun Sep 9 18:40:12 2007 From: report at bugs.python.org (Achim Gaedke) Date: Sun, 09 Sep 2007 16:40:12 -0000 Subject: [issue1137] pyexpat patch for changing buffer_size Message-ID: <1189356011.84.0.968400197849.issue1137@psf.upfronthosting.co.za> New submission from Achim Gaedke: Hello! Sometimes people have big amounts of text/data in xml files. To make processing more effective, they should be able to change the buffer size for collecting character data in one string. Here comes a patch that applies necessary changes in setattr method. It handles reallocation sufficiently efficient without introducing extra variables to the parser class. Also a documentation patch and some test cases are available. These patches and tests were done with debian etch python2.5, which is python-2.5.1 . This patch also works on python2.4 . ---------- components: XML files: pyexpat_c_patch messages: 55767 nosy: AchimGaedke severity: normal status: open title: pyexpat patch for changing buffer_size versions: Python 2.5 __________________________________ Tracker __________________________________ -------------- next part -------------- A non-text attachment was scrubbed... Name: pyexpat_c_patch Type: application/octet-stream Size: 2544 bytes Desc: not available Url : http://mail.python.org/pipermail/python-bugs-list/attachments/20070909/b99c513a/attachment-0001.obj From report at bugs.python.org Sun Sep 9 18:41:57 2007 From: report at bugs.python.org (Achim Gaedke) Date: Sun, 09 Sep 2007 16:41:57 -0000 Subject: [issue1137] pyexpat patch for changing buffer_size Message-ID: <1189356117.31.0.577679804965.issue1137@psf.upfronthosting.co.za> Changes by Achim Gaedke: __________________________________ Tracker __________________________________ From report at bugs.python.org Sun Sep 9 18:42:18 2007 From: report at bugs.python.org (Achim Gaedke) Date: Sun, 09 Sep 2007 16:42:18 -0000 Subject: [issue1137] pyexpat patch for changing buffer_size Message-ID: <1189356138.44.0.485681393023.issue1137@psf.upfronthosting.co.za> Changes by Achim Gaedke: __________________________________ Tracker __________________________________ From report at bugs.python.org Sun Sep 9 18:49:29 2007 From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=) Date: Sun, 09 Sep 2007 16:49:29 -0000 Subject: [issue1137] pyexpat patch for changing buffer_size Message-ID: <1189356569.29.0.661033914579.issue1137@psf.upfronthosting.co.za> Changes by Martin v. L?wis: ---------- keywords: +patch __________________________________ Tracker __________________________________ From report at bugs.python.org Sun Sep 9 18:49:40 2007 From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=) Date: Sun, 09 Sep 2007 16:49:40 -0000 Subject: [issue1136] Bdb documentation Message-ID: <1189356580.69.0.101626477157.issue1136@psf.upfronthosting.co.za> Changes by Martin v. L?wis: ---------- keywords: +patch __________________________________ Tracker __________________________________ From report at bugs.python.org Sun Sep 9 18:53:45 2007 From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=) Date: Sun, 09 Sep 2007 16:53:45 -0000 Subject: [issue1122] PyTuple_Size and PyTuple_GET_SIZE return type documentation incorrect Message-ID: <1189356825.02.0.329976980995.issue1122@psf.upfronthosting.co.za> Changes by Martin v. L?wis: ---------- keywords: +patch __________________________________ Tracker __________________________________ From report at bugs.python.org Sun Sep 9 18:54:20 2007 From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=) Date: Sun, 09 Sep 2007 16:54:20 -0000 Subject: [issue1114] _curses issues on 64-bit big-endian (e.g, AIX) Message-ID: <1189356860.46.0.914365027808.issue1114@psf.upfronthosting.co.za> Changes by Martin v. L?wis: ---------- keywords: +patch __________________________________ Tracker __________________________________ From report at bugs.python.org Sun Sep 9 23:56:26 2007 From: report at bugs.python.org (Alan McIntyre) Date: Sun, 09 Sep 2007 21:56:26 -0000 Subject: [issue1134] Parsing a simple script eats all of your memory Message-ID: <1189374986.46.0.375957579419.issue1134@psf.upfronthosting.co.za> Alan McIntyre added the comment: Confirmed that this happens on Mac OS X with a fresh build of py3k from svn. ---------- nosy: +alanmcintyre __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Sep 10 01:20:00 2007 From: report at bugs.python.org (Collin Winter) Date: Sun, 09 Sep 2007 23:20:00 -0000 Subject: [issue1138] Fixer needed for __future__ imports Message-ID: <1189379999.94.0.155888611794.issue1138@psf.upfronthosting.co.za> New submission from Collin Winter: Per http://mail.python.org/pipermail/python-3000/2007-September/010337.html, 2to3 should strip out __future__ imports. This should probably be added to the existing import fixer. ---------- assignee: collinwinter components: 2to3 (2.x to 3.0 conversion tool) messages: 55769 nosy: collinwinter priority: normal severity: normal status: open title: Fixer needed for __future__ imports type: behavior __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Sep 10 01:19:59 2007 From: report at bugs.python.org (Collin Winter) Date: Sun, 09 Sep 2007 23:19:59 -0000 Subject: [issue1138] Fixer needed for __future__ imports Message-ID: <1189379999.94.0.155888611794.issue1138@psf.upfronthosting.co.za> New submission from Collin Winter: Per http://mail.python.org/pipermail/python-3000/2007-September/010337.html, 2to3 should strip out __future__ imports. This should probably be added to the existing import fixer. ---------- assignee: collinwinter components: 2to3 (2.x to 3.0 conversion tool) messages: 55769 nosy: collinwinter priority: normal severity: normal status: open title: Fixer needed for __future__ imports type: behavior __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Sep 10 01:38:26 2007 From: report at bugs.python.org (Gregory P. Smith) Date: Sun, 09 Sep 2007 23:38:26 -0000 Subject: [issue1706815] socket.error exceptions not subclass of StandardError Message-ID: <1189381106.06.0.886081422376.issue1706815@psf.upfronthosting.co.za> Gregory P. Smith added the comment: socket.error now inherits from IOError as of trunk r58067: Change socket.error to inherit from IOError rather than being a stand alone class. This addresses the primary concern in http://bugs.python.org/issue1706815 python-dev discussion here: http://mail.python.org/pipermail/python-dev/2007-July/073749.html I chose IOError rather than EnvironmentError as the base class since socket objects are often used as transparent duck typed file objects in code already prepared to deal with IOError exceptions. also a minor fix: urllib2 - fix a couple places where IOError was raised rather than URLError. for better or worse, URLError already inherits from IOError so this won't break any existing code. test_urllib2net - replace bad ftp urls. ---------- nosy: -gps resolution: -> fixed status: open -> closed _____________________________________ Tracker _____________________________________ From report at bugs.python.org Mon Sep 10 02:23:28 2007 From: report at bugs.python.org (Guido van Rossum) Date: Mon, 10 Sep 2007 00:23:28 -0000 Subject: [issue1094] TypeError in poplib.py Message-ID: <1189383808.88.0.344730756411.issue1094@psf.upfronthosting.co.za> Changes by Guido van Rossum: __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Sep 10 02:27:51 2007 From: report at bugs.python.org (Guido van Rossum) Date: Mon, 10 Sep 2007 00:27:51 -0000 Subject: [issue1094] TypeError in poplib.py Message-ID: <1189384071.0.0.938531629732.issue1094@psf.upfronthosting.co.za> Guido van Rossum added the comment: Oops, I accidentally deleted the patch. Here is is again. Thanks for the patch! I've applied it. Committed revision 58072. ---------- assignee: -> gvanrossum nosy: +gvanrossum resolution: -> fixed status: open -> closed __________________________________ Tracker __________________________________ -------------- next part -------------- A non-text attachment was scrubbed... Name: poplib.diff Type: text/x-patch Size: 459 bytes Desc: not available Url : http://mail.python.org/pipermail/python-bugs-list/attachments/20070910/a43a0eb5/attachment.bin From report at bugs.python.org Mon Sep 10 03:28:25 2007 From: report at bugs.python.org (Chris Leary) Date: Mon, 10 Sep 2007 01:28:25 -0000 Subject: [issue1765140] logging: delay_fh option and configuration kwargs Message-ID: <1189387705.45.0.370726000816.issue1765140@psf.upfronthosting.co.za> Chris Leary added the comment: Hi Vinay, I was actually trying to address a use case where the delay_fh option in the fileConfig() would be necessary. Let's say I'm running a simulator that I run many instances of at once. The logging configuration is extensive, so I want to use a configuration file; however, I don't want any existing log files to be clobbered as soon as I run fileConfig() -- I want to run fileConfig() to load the configuration, then remove/modify the handlers /before/ they touch the file handles. If fileConfig has no delay_fh option, fileConfig() would create the FileHandlers with delay_fh as False; therefore, adding the option to the FileHandler alone isn't enough to fix this use case. Let me know if this is unclear, or if I should provide a more concrete example. _____________________________________ Tracker _____________________________________ From report at bugs.python.org Mon Sep 10 05:05:11 2007 From: report at bugs.python.org (Stefan Sonnenberg-Carstens) Date: Mon, 10 Sep 2007 03:05:11 -0000 Subject: [issue1134] Parsing a simple script eats all of your memory Message-ID: <1189393511.0.0.115097282852.issue1134@psf.upfronthosting.co.za> Stefan Sonnenberg-Carstens added the comment: Same under Linux with Python 3.0a1. Eats all cpu + memory ---------- nosy: +pythonmeister __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Sep 10 05:27:16 2007 From: report at bugs.python.org (Gabriel Genellina) Date: Mon, 10 Sep 2007 03:27:16 -0000 Subject: [issue1139] PyFile_Encoding should be PyFile_SetEncoding Message-ID: <1189394836.73.0.483102180723.issue1139@psf.upfronthosting.co.za> New submission from Gabriel Genellina: Describing the PyFile C API, there is a typo: PyFile_Encoding function does not exist, should say PyFile_SetEncoding instead. (This goes down to version 2.3 when the function was initially added). http://docs.python.org/dev/c-api/ concrete.html#PyFile_Encoding ---------- components: Documentation messages: 55774 nosy: gagenellina severity: normal status: open title: PyFile_Encoding should be PyFile_SetEncoding type: behavior versions: Python 2.5, Python 2.6, Python 3.0 __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Sep 10 05:27:17 2007 From: report at bugs.python.org (Gabriel Genellina) Date: Mon, 10 Sep 2007 03:27:17 -0000 Subject: [issue1139] PyFile_Encoding should be PyFile_SetEncoding Message-ID: <1189394836.73.0.483102180723.issue1139@psf.upfronthosting.co.za> New submission from Gabriel Genellina: Describing the PyFile C API, there is a typo: PyFile_Encoding function does not exist, should say PyFile_SetEncoding instead. (This goes down to version 2.3 when the function was initially added). http://docs.python.org/dev/c-api/ concrete.html#PyFile_Encoding ---------- components: Documentation messages: 55774 nosy: gagenellina severity: normal status: open title: PyFile_Encoding should be PyFile_SetEncoding type: behavior versions: Python 2.5, Python 2.6, Python 3.0 __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Sep 10 08:37:19 2007 From: report at bugs.python.org (Beda Kosata) Date: Mon, 10 Sep 2007 06:37:19 -0000 Subject: [issue1140] re.sub returns str when processing empty unicode string Message-ID: <1189406238.99.0.778554736734.issue1140@psf.upfronthosting.co.za> New submission from Beda Kosata: While re.sub normally returns unicode strings when processing unicode, it returns a normal string when dealing with an empty unicode string. Example: >>> print type( re.sub( "XX", "", u"")) >>> print type( re.sub( "XX", "", u"A")) This inconsistency could lead to annoying bugs (at least it did for me :) ---------- components: Regular Expressions messages: 55775 nosy: beda severity: minor status: open title: re.sub returns str when processing empty unicode string type: behavior versions: Python 2.4, Python 2.5 __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Sep 10 08:37:19 2007 From: report at bugs.python.org (Beda Kosata) Date: Mon, 10 Sep 2007 06:37:19 -0000 Subject: [issue1140] re.sub returns str when processing empty unicode string Message-ID: <1189406238.99.0.778554736734.issue1140@psf.upfronthosting.co.za> New submission from Beda Kosata: While re.sub normally returns unicode strings when processing unicode, it returns a normal string when dealing with an empty unicode string. Example: >>> print type( re.sub( "XX", "", u"")) >>> print type( re.sub( "XX", "", u"A")) This inconsistency could lead to annoying bugs (at least it did for me :) ---------- components: Regular Expressions messages: 55775 nosy: beda severity: minor status: open title: re.sub returns str when processing empty unicode string type: behavior versions: Python 2.4, Python 2.5 __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Sep 10 10:54:44 2007 From: report at bugs.python.org (Vinay Sajip) Date: Mon, 10 Sep 2007 08:54:44 -0000 Subject: [issue1765140] logging: delay_fh option and configuration kwargs Message-ID: <1189414484.73.0.151582796914.issue1765140@psf.upfronthosting.co.za> Vinay Sajip added the comment: I'm not sure I agree with "If fileConfig has no delay_fh option, fileConfig() would create the FileHandlers with delay_fh as False". fileConfig will create the FileHandlers using the args= section entry to pass to the constructor. Hence, by specifying True for this parameter, you get the FileHandlers to delay opening the files. In fact you get more control - you can specify True for some FileHandlers and False for others. The relevant code is in config.py in _install_handlers: ... klass = eval(klass, vars(logging)) args = cp.get(sectname, "args") args = eval(args, vars(logging)) h = apply(klass, args) ... _____________________________________ Tracker _____________________________________ From report at bugs.python.org Mon Sep 10 14:45:04 2007 From: report at bugs.python.org (christen) Date: Mon, 10 Sep 2007 12:45:04 -0000 Subject: [issue1141] reading large files Message-ID: <1189428303.96.0.66125933613.issue1141@psf.upfronthosting.co.za> New submission from christen: September 11, 2007 I downloaded py 3.k The good news : Under Windows, Python 3k properly reads files larger than 4 Go (in contrast to python 2.5 that skips some lines, see below) The bad news : py 3k is very slow compared to py 2.5; see the results below the code is it reads a 4.9 Go file of 81,017,719 lines (a genbank entry of bacterial sequences) ####################### import time print (time.localtime()) fichin=open(r'D:\pythons\16s\total_gb_161_16S.gb') t0= time.localtime() print (t0) i=0 for li in fichin: i+=1 if i%1000000==0: print (i,time.localtime()) fichin.close() print () print (i) print (time.localtime()) ######################### I got the following results (Windows XP 64) on the same machine, using either py 3k or py 2.5 As soon as my BSD and Linux machines are done with calculations, I will try that on them. Best Richard Christen python 3k (2007, 9, 10, 13, 53, 36, 0, 253, 1) (2007, 9, 10, 13, 53, 36, 0, 253, 1) 1000000 (2007, 9, 10, 13, 53, 49, 0, 253, 1) 2000000 (2007, 9, 10, 13, 54, 3, 0, 253, 1) 3000000 (2007, 9, 10, 13, 54, 18, 0, 253, 1) 4000000 (2007, 9, 10, 13, 54, 32, 0, 253, 1) 5000000 (2007, 9, 10, 13, 54, 47, 0, 253, 1) .... 77000000 (2007, 9, 10, 14, 14, 55, 0, 253, 1) 78000000 (2007, 9, 10, 14, 15, 9, 0, 253, 1) 79000000 (2007, 9, 10, 14, 15, 22, 0, 253, 1) 80000000 (2007, 9, 10, 14, 15, 36, 0, 253, 1) 81000000 (2007, 9, 10, 14, 15, 49, 0, 253, 1) 81017719 #this is the proper number of lines (2007, 9, 10, 14, 15, 50, 0, 253, 1) Python 2.5 (2007, 9, 10, 14, 18, 33, 0, 253, 1) (2007, 9, 10, 14, 18, 33, 0, 253, 1) (1000000, (2007, 9, 10, 14, 18, 34, 0, 253, 1)) (2000000, (2007, 9, 10, 14, 18, 34, 0, 253, 1)) (3000000, (2007, 9, 10, 14, 18, 35, 0, 253, 1)) (4000000, (2007, 9, 10, 14, 18, 35, 0, 253, 1)) (5000000, (2007, 9, 10, 14, 18, 36, 0, 253, 1)) ... (77000000, (2007, 9, 10, 14, 19, 10, 0, 253, 1)) (78000000, (2007, 9, 10, 14, 19, 11, 0, 253, 1)) (79000000, (2007, 9, 10, 14, 19, 11, 0, 253, 1)) (80000000, (2007, 9, 10, 14, 19, 12, 0, 253, 1)) (81000000, (2007, 9, 10, 14, 19, 12, 0, 253, 1)) () 81014962 #python 2.5 missed some lines !!!! (2007, 9, 10, 14, 19, 12, 0, 253, 1) ---------- components: Tests messages: 55777 nosy: Richard.Christen at unice.fr severity: normal status: open title: reading large files type: behavior versions: Python 3.0 __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Sep 10 14:45:04 2007 From: report at bugs.python.org (christen) Date: Mon, 10 Sep 2007 12:45:04 -0000 Subject: [issue1141] reading large files Message-ID: <1189428303.96.0.66125933613.issue1141@psf.upfronthosting.co.za> New submission from christen: September 11, 2007 I downloaded py 3.k The good news : Under Windows, Python 3k properly reads files larger than 4 Go (in contrast to python 2.5 that skips some lines, see below) The bad news : py 3k is very slow compared to py 2.5; see the results below the code is it reads a 4.9 Go file of 81,017,719 lines (a genbank entry of bacterial sequences) ####################### import time print (time.localtime()) fichin=open(r'D:\pythons\16s\total_gb_161_16S.gb') t0= time.localtime() print (t0) i=0 for li in fichin: i+=1 if i%1000000==0: print (i,time.localtime()) fichin.close() print () print (i) print (time.localtime()) ######################### I got the following results (Windows XP 64) on the same machine, using either py 3k or py 2.5 As soon as my BSD and Linux machines are done with calculations, I will try that on them. Best Richard Christen python 3k (2007, 9, 10, 13, 53, 36, 0, 253, 1) (2007, 9, 10, 13, 53, 36, 0, 253, 1) 1000000 (2007, 9, 10, 13, 53, 49, 0, 253, 1) 2000000 (2007, 9, 10, 13, 54, 3, 0, 253, 1) 3000000 (2007, 9, 10, 13, 54, 18, 0, 253, 1) 4000000 (2007, 9, 10, 13, 54, 32, 0, 253, 1) 5000000 (2007, 9, 10, 13, 54, 47, 0, 253, 1) .... 77000000 (2007, 9, 10, 14, 14, 55, 0, 253, 1) 78000000 (2007, 9, 10, 14, 15, 9, 0, 253, 1) 79000000 (2007, 9, 10, 14, 15, 22, 0, 253, 1) 80000000 (2007, 9, 10, 14, 15, 36, 0, 253, 1) 81000000 (2007, 9, 10, 14, 15, 49, 0, 253, 1) 81017719 #this is the proper number of lines (2007, 9, 10, 14, 15, 50, 0, 253, 1) Python 2.5 (2007, 9, 10, 14, 18, 33, 0, 253, 1) (2007, 9, 10, 14, 18, 33, 0, 253, 1) (1000000, (2007, 9, 10, 14, 18, 34, 0, 253, 1)) (2000000, (2007, 9, 10, 14, 18, 34, 0, 253, 1)) (3000000, (2007, 9, 10, 14, 18, 35, 0, 253, 1)) (4000000, (2007, 9, 10, 14, 18, 35, 0, 253, 1)) (5000000, (2007, 9, 10, 14, 18, 36, 0, 253, 1)) ... (77000000, (2007, 9, 10, 14, 19, 10, 0, 253, 1)) (78000000, (2007, 9, 10, 14, 19, 11, 0, 253, 1)) (79000000, (2007, 9, 10, 14, 19, 11, 0, 253, 1)) (80000000, (2007, 9, 10, 14, 19, 12, 0, 253, 1)) (81000000, (2007, 9, 10, 14, 19, 12, 0, 253, 1)) () 81014962 #python 2.5 missed some lines !!!! (2007, 9, 10, 14, 19, 12, 0, 253, 1) ---------- components: Tests messages: 55777 nosy: Richard.Christen at unice.fr severity: normal status: open title: reading large files type: behavior versions: Python 3.0 __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Sep 10 16:04:50 2007 From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=) Date: Mon, 10 Sep 2007 14:04:50 -0000 Subject: [issue1141] reading large files Message-ID: <1189433090.42.0.510644360099.issue1141@psf.upfronthosting.co.za> Martin v. L?wis added the comment: If you would like to help resolving the issue with the missing lines, please submit a separate report for that. It is very difficult to track unrelated bugs in a single tracker issue. It would help if you could determine which lines are missing, e.g. by writing out all lines and then comparing the two files. If you want to compute runtimes, it is better to not convert them to local time. Instead, use the pattern start = time.time() ... print time.time()-start # seconds since the program started ---------- nosy: +loewis __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Sep 10 16:20:50 2007 From: report at bugs.python.org (christen) Date: Mon, 10 Sep 2007 14:20:50 -0000 Subject: [issue1141] reading large files In-Reply-To: <1189433090.42.0.510644360099.issue1141@psf.upfronthosting.co.za> Message-ID: <46E55249.9050605@unice.fr> christen added the comment: Hi Martin I could certainly do that, but how you get my huge files ? 5 Go of data is quite big... > If you want to compute runtimes, it is better to not convert them to > local time. Instead, use the pattern > > start = time.time() > ... > print time.time()-start # seconds since the program started > OK I'll do that next time Richard __________________________________ Tracker __________________________________ -------------- next part -------------- A non-text attachment was scrubbed... Name: christen.vcf Type: text/x-vcard Size: 371 bytes Desc: not available Url : http://mail.python.org/pipermail/python-bugs-list/attachments/20070910/0d91ddb1/attachment.vcf From report at bugs.python.org Mon Sep 10 16:26:47 2007 From: report at bugs.python.org (Chris Leary) Date: Mon, 10 Sep 2007 14:26:47 -0000 Subject: [issue1765140] logging: delay_fh option and configuration kwargs Message-ID: <1189434407.21.0.0414417357768.issue1765140@psf.upfronthosting.co.za> Chris Leary added the comment: Ah, I see what the miscommunication is now. Yes, implementing the feature as you suggested would give the user the ability to specify the delayed handle-opening /within/ the configuration file. What I had intended was a way to load/inspect a file configuration without it having any handle-opening side affects, even if it were a totally unknown configuration file. If you want to assume a good trust relationship with the contents of a file configuration that you're loading (as in, you trust that it won't clobber any files that you still want), then that works well. I just assumed it would be useful to open a file configuration in an "untrusted" way (via delay_fh) in order to inspect/modify it. It seems to me to put more power in the hands of the loader of the configuration, rather than leaving the loader subject to the potentially "bad" contents of the configuration file. If you think I'm being too paranoid or feel that this is too obscure a use case, feel free to implement it how you see fit! :) _____________________________________ Tracker _____________________________________ From report at bugs.python.org Mon Sep 10 16:28:44 2007 From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=) Date: Mon, 10 Sep 2007 14:28:44 -0000 Subject: [issue1141] reading large files In-Reply-To: <46E55249.9050605@unice.fr> Message-ID: <46E5549A.20701@v.loewis.de> Martin v. L?wis added the comment: > I could certainly do that, but how you get my huge files ? 5 Go of data > is quite big... [not sure what "that" is] I did not mean to suggest that you attach such a large file. Instead, just report that as a separate bug report, and be prepared to answer follow-up questions. Regards, Martin __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Sep 10 16:29:24 2007 From: report at bugs.python.org (Stefan Sonnenberg-Carstens) Date: Mon, 10 Sep 2007 14:29:24 -0000 Subject: [issue1141] reading large files Message-ID: <1189434564.68.0.0256605156566.issue1141@psf.upfronthosting.co.za> Stefan Sonnenberg-Carstens added the comment: Perhaps this is an issue of line separation ? Could you provide the output of wc -l on a *NIX box ? And, could you try with this code: import sys print(sys.version_info) import time print (time.localtime()) fichin=open(r'D:\pythons\16s\total_gb_161_16S.gb') start = time.time() for i,li in enumerate(fichin): if i%1000000==0 and i>0: print (i,start-time.time()) fichin.close() print(i) print(start-time.time()) Thx ---------- nosy: +pythonmeister __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Sep 10 16:32:24 2007 From: report at bugs.python.org (Stefan Sonnenberg-Carstens) Date: Mon, 10 Sep 2007 14:32:24 -0000 Subject: [issue1141] reading large files Message-ID: <1189434744.03.0.4973264655.issue1141@psf.upfronthosting.co.za> Stefan Sonnenberg-Carstens added the comment: Sorry, this way: import sys print(sys.version_info) import time print (time.strftime('%Y-%m-%d %H:%M:%S')) fichin=open(r'D:\pythons\16s\total_gb_161_16S.gb') start = time.time() for i,li in enumerate(fichin): if i%1000000==0 and i>0: print (i,time.time()-start) fichin.close() print(i) print(time.time()-start) __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Sep 10 17:46:27 2007 From: report at bugs.python.org (christen) Date: Mon, 10 Sep 2007 15:46:27 -0000 Subject: [issue1141] reading large files In-Reply-To: <1189434744.03.0.4973264655.issue1141@psf.upfronthosting.co.za> Message-ID: <46E56661.8020607@unice.fr> christen added the comment: Hi Stefan Calculations are underway both read and write do not work well with p3k you can try the code below on your own machine : fichout.write(str(i)+' '*59+'\n') #generates a big file fichout.write(str(i)+'\n') #generate file <4Go the big file is not read properly with python 2.5 (the small one is) the big file is long to write and to read with python 3.k I send you the results as soon it is done under 3k (very very slow indeed) best r import sys print(sys.version_info) import time print (time.strftime('%Y-%m-%d %H:%M:%S')) liste=[] start = time.time() fichout=open('test.txt','w') for i in xrange(85014961): if i%5000000==0 and i>0: print (i,time.time()-start) fichout.write(str(i)+' '*59+'\n') fichout.close() print ('total lines written ',i) print (i,time.time()-start) print ('*'*50) fichin=open('test.txt') start3 = time.time() for i,li in enumerate(fichin): if i%5000000==0 and i>0: print (i,time.time()-start3) fichin.close() print ('total lines read ',i) print(time.time()-start) __________________________________ Tracker __________________________________ -------------- next part -------------- A non-text attachment was scrubbed... Name: christen.vcf Type: text/x-vcard Size: 371 bytes Desc: not available Url : http://mail.python.org/pipermail/python-bugs-list/attachments/20070910/f7f256d1/attachment.vcf From report at bugs.python.org Mon Sep 10 17:52:42 2007 From: report at bugs.python.org (christen) Date: Mon, 10 Sep 2007 15:52:42 -0000 Subject: [issue1142] code sample showing errors reading large files with py 2.5 Message-ID: <1189439562.54.0.204300359031.issue1142@psf.upfronthosting.co.za> New submission from christen: Error in reading >4Go files under windows try this: import sys print(sys.version_info) import time print (time.strftime('%Y-%m-%d %H:%M:%S')) liste=[] start = time.time() fichout=open('test.txt','w') for i in xrange(85014961): if i%5000000==0 and i>0: print (i,time.time()-start) fichout.write(str(i)+' '*59+'\n') fichout.close() print ('total lines written ',i) print (i,time.time()-start) print ('*'*50) fichin=open('test.txt') start3 = time.time() for i,li in enumerate(fichin): if i%5000000==0 and i>0: print (i,time.time()-start3) fichin.close() print ('total lines read ',i) print(time.time()-start) it generates a >4Go file,not all lines are read !! example: ('total lines written ', 85014960) ('total lines read ', 85014950) 10 lines are missing if you replace by fichout.write(str(i)+' '*59+'\n') file is now under 4Go, is properly read Used both a 32 and 64 Windows XP machines seems to work with Linux and BSD (did not tried this example but had no pb with my home made big files) Pb : many examples of >4Go files for the human genome and other biological applications. Almost sure that people are doing mistakes, because it took me a while before discovering that... Note : does not happen with py 3k :-) ---------- components: Windows messages: 55785 nosy: Richard.Christen at unice.fr severity: urgent status: open title: code sample showing errors reading large files with py 2.5 type: behavior versions: Python 2.5 __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Sep 10 17:52:42 2007 From: report at bugs.python.org (christen) Date: Mon, 10 Sep 2007 15:52:42 -0000 Subject: [issue1142] code sample showing errors reading large files with py 2.5 Message-ID: <1189439562.54.0.204300359031.issue1142@psf.upfronthosting.co.za> New submission from christen: Error in reading >4Go files under windows try this: import sys print(sys.version_info) import time print (time.strftime('%Y-%m-%d %H:%M:%S')) liste=[] start = time.time() fichout=open('test.txt','w') for i in xrange(85014961): if i%5000000==0 and i>0: print (i,time.time()-start) fichout.write(str(i)+' '*59+'\n') fichout.close() print ('total lines written ',i) print (i,time.time()-start) print ('*'*50) fichin=open('test.txt') start3 = time.time() for i,li in enumerate(fichin): if i%5000000==0 and i>0: print (i,time.time()-start3) fichin.close() print ('total lines read ',i) print(time.time()-start) it generates a >4Go file,not all lines are read !! example: ('total lines written ', 85014960) ('total lines read ', 85014950) 10 lines are missing if you replace by fichout.write(str(i)+' '*59+'\n') file is now under 4Go, is properly read Used both a 32 and 64 Windows XP machines seems to work with Linux and BSD (did not tried this example but had no pb with my home made big files) Pb : many examples of >4Go files for the human genome and other biological applications. Almost sure that people are doing mistakes, because it took me a while before discovering that... Note : does not happen with py 3k :-) ---------- components: Windows messages: 55785 nosy: Richard.Christen at unice.fr severity: urgent status: open title: code sample showing errors reading large files with py 2.5 type: behavior versions: Python 2.5 __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Sep 10 17:54:06 2007 From: report at bugs.python.org (christen) Date: Mon, 10 Sep 2007 15:54:06 -0000 Subject: [issue1142] code sample showing errors reading large files with py 2.5 Message-ID: <1189439646.7.0.203163909704.issue1142@psf.upfronthosting.co.za> christen added the comment: made an error in copy paste if you replace by fichout.write(str(i)+' '*59+'\n') should be if you replace by fichout.write(str(i)+'\n') of course :-( __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Sep 10 18:53:53 2007 From: report at bugs.python.org (Guido van Rossum) Date: Mon, 10 Sep 2007 16:53:53 -0000 Subject: [issue1125] bytes.split shold have same interface as str.split, or different name Message-ID: <1189443233.14.0.145886870935.issue1125@psf.upfronthosting.co.za> Guido van Rossum added the comment: Committed revision 58093. ---------- resolution: -> accepted status: open -> closed __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Sep 10 19:12:18 2007 From: report at bugs.python.org (Guido van Rossum) Date: Mon, 10 Sep 2007 17:12:18 -0000 Subject: [issue1139] PyFile_Encoding should be PyFile_SetEncoding Message-ID: <1189444338.91.0.0271434293036.issue1139@psf.upfronthosting.co.za> Changes by Guido van Rossum: ---------- assignee: -> georg.brandl nosy: +georg.brandl __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Sep 10 19:14:03 2007 From: report at bugs.python.org (Guido van Rossum) Date: Mon, 10 Sep 2007 17:14:03 -0000 Subject: [issue1140] re.sub returns str when processing empty unicode string Message-ID: <1189444443.68.0.275635181009.issue1140@psf.upfronthosting.co.za> Guido van Rossum added the comment: I agree. I wonder if it should return Unicode as soon as *any* of the arguments are unicode??? ---------- nosy: +gvanrossum __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Sep 10 20:25:30 2007 From: report at bugs.python.org (Beda Kosata) Date: Mon, 10 Sep 2007 18:25:30 -0000 Subject: [issue1140] re.sub returns str when processing empty unicode string Message-ID: <1189448730.85.0.69362885524.issue1140@psf.upfronthosting.co.za> Beda Kosata added the comment: I would certainly expect it to return unicode when either the "modified" string or the replacement are unicode. I don't think that the type of the replaced string should influence the type of the result. __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Sep 10 20:42:54 2007 From: report at bugs.python.org (Guido van Rossum) Date: Mon, 10 Sep 2007 18:42:54 -0000 Subject: [issue1140] re.sub returns str when processing empty unicode string Message-ID: <1189449774.84.0.183059986646.issue1140@psf.upfronthosting.co.za> Guido van Rossum added the comment: Actually, it already implements the best possible rules, *except* for the special case of an empty 3rd argument. (When there are no substitutions, it normally returns the input unchanged; but somehow an empty input is handled with a shortcut even before that point. It ought to be a simlpe fix. __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Sep 10 21:48:30 2007 From: report at bugs.python.org (Bill Janssen) Date: Mon, 10 Sep 2007 19:48:30 -0000 Subject: [issue783188] support for server side transactions in _ssl Message-ID: <1189453710.15.0.972972348828.issue783188@psf.upfronthosting.co.za> Bill Janssen added the comment: I think the example in Lib/test/test_ssl.py will have to suffice. It would be nice to have an asyncore example server, too. ____________________________________ Tracker ____________________________________ From report at bugs.python.org Mon Sep 10 22:00:39 2007 From: report at bugs.python.org (Ali Gholami Rudi) Date: Mon, 10 Sep 2007 20:00:39 -0000 Subject: [issue1774736] Binding fails Message-ID: <1189454439.69.0.139233939964.issue1774736@psf.upfronthosting.co.za> Ali Gholami Rudi added the comment: The same as issue1028. Fixed in r57450. _____________________________________ Tracker _____________________________________ From report at bugs.python.org Mon Sep 10 22:34:45 2007 From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=) Date: Mon, 10 Sep 2007 20:34:45 -0000 Subject: [issue1734346] patch for bug 1170311 "zipfile UnicodeDecodeError" Message-ID: <1189456485.27.0.118495602721.issue1734346@psf.upfronthosting.co.za> Changes by Martin v. L?wis: ---------- assignee: -> loewis severity: normal -> major _____________________________________ Tracker _____________________________________ From report at bugs.python.org Mon Sep 10 22:37:41 2007 From: report at bugs.python.org (Guido van Rossum) Date: Mon, 10 Sep 2007 20:37:41 -0000 Subject: [issue1140] re.sub returns str when processing empty unicode string Message-ID: <1189456661.14.0.00925153781904.issue1140@psf.upfronthosting.co.za> Guido van Rossum added the comment: Here's a patch. ---------- assignee: -> gvanrossum __________________________________ Tracker __________________________________ -------------- next part -------------- A non-text attachment was scrubbed... Name: sre.diff Type: text/x-patch Size: 2066 bytes Desc: not available Url : http://mail.python.org/pipermail/python-bugs-list/attachments/20070910/9c4bfb2f/attachment.bin From report at bugs.python.org Mon Sep 10 22:59:40 2007 From: report at bugs.python.org (Brett Cannon) Date: Mon, 10 Sep 2007 20:59:40 -0000 Subject: [issue1456280] Traceback error when compiling Regex Message-ID: <1189457980.4.0.282183847842.issue1456280@psf.upfronthosting.co.za> Changes by Brett Cannon: ---------- superseder: -> re incompatibility in sre title: Traceback error when compiling Regex -> Traceback error when compiling Regex _____________________________________ Tracker _____________________________________ From report at bugs.python.org Mon Sep 10 23:03:55 2007 From: report at bugs.python.org (Stefan Sonnenberg-Carstens) Date: Mon, 10 Sep 2007 21:03:55 -0000 Subject: [issue1142] code sample showing errors reading large files with py 2.5 Message-ID: <1189458235.43.0.11308479766.issue1142@psf.upfronthosting.co.za> Stefan Sonnenberg-Carstens added the comment: Error confirmed for this python: Python 3.0a1 (py3k, Sep 10 2007, 22:45:51) [GCC 4.1.2 20061115 (prerelease) (Debian 4.1.1-21)] on linux2 See this: stefan at nx6310:~$ python2.4 large_io.py (2, 4, 4, 'final', 0) 2007-09-10 21:41:52 (5000000, 14.321661949157715) (10000000, 30.311280965805054) (15000000, 45.24985408782959) (20000000, 59.537726879119873) (25000000, 74.075110912322998) (30000000, 87.76087498664856) (35000000, 104.54858303070068) (40000000, 121.84645009040833) (45000000, 137.88236308097839) (50000000, 155.42996501922607) (55000000, 171.81011009216309) (60000000, 188.44834208488464) (65000000, 204.46978211402893) (70000000, 218.81346702575684) (75000000, 232.86778998374939) (80000000, 246.6789391040802) (85000000, 260.89796900749207) ('total lines written ', 85014960) (85014960, 260.94281101226807) ************************************************** (5000000, 14.598887920379639) (10000000, 29.428265810012817) (15000000, 44.457981824874878) (20000000, 60.351485967636108) (25000000, 79.3228759765625) (30000000, 94.667810916900635) (35000000, 110.35149884223938) (40000000, 126.19746398925781) (45000000, 141.83787989616394) (50000000, 157.46236801147461) (55000000, 173.10227298736572) (60000000, 188.19510197639465) (65000000, 197.369295835495) (70000000, 206.41998481750488) (75000000, 215.53365993499756) (80000000, 224.55904102325439) (85000000, 233.75891900062561) ('total lines read ', 85014960) 494.727725029 stefan at nx6310:~$ python3.0 large_io.py (3, 0, 0, 'alpha', 1) 2007-09-10 21:50:53 5000000 194.725461006 Tasks: 144 total, 3 running, 141 sleeping, 0 stopped, 0 zombie Cpu(s): 50.2%us, 1.3%sy, 0.0%ni, 48.3%id, 0.0%wa, 0.2%hi, 0.0%si, 0.0%st Mem: 1026804k total, 846416k used, 180388k free, 7952k buffers Swap: 1028152k total, 66576k used, 961576k free, 679032k cached PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 28778 stefan 25 0 7800 3552 1596 R 100 0.3 6:01.48 python3.0 ---------- nosy: +pythonmeister __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Sep 10 23:04:28 2007 From: report at bugs.python.org (Brett Cannon) Date: Mon, 10 Sep 2007 21:04:28 -0000 Subject: [issue214033] re incompatibility in sre Message-ID: <1189458268.34.0.422954535805.issue214033@psf.upfronthosting.co.za> Changes by Brett Cannon: ---------- resolution: accepted -> type: -> behavior versions: +Python 2.6 ____________________________________ Tracker ____________________________________ From report at bugs.python.org Mon Sep 10 23:04:34 2007 From: report at bugs.python.org (Stefan Sonnenberg-Carstens) Date: Mon, 10 Sep 2007 21:04:34 -0000 Subject: [issue1142] code sample showing errors reading large files with py 2.5/3.0 Message-ID: <1189458274.07.0.716345490373.issue1142@psf.upfronthosting.co.za> Changes by Stefan Sonnenberg-Carstens: ---------- components: +Interpreter Core title: code sample showing errors reading large files with py 2.5 -> code sample showing errors reading large files with py 2.5/3.0 versions: +Python 3.0 __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Sep 10 23:21:09 2007 From: report at bugs.python.org (Brett Cannon) Date: Mon, 10 Sep 2007 21:21:09 -0000 Subject: [issue1096] Deeply recursive repr segfault Message-ID: <1189459269.47.0.905492970655.issue1096@psf.upfronthosting.co.za> Changes by Brett Cannon: ---------- priority: -> urgent __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Sep 10 23:28:35 2007 From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=) Date: Mon, 10 Sep 2007 21:28:35 -0000 Subject: [issue1774736] Binding fails Message-ID: <1189459715.98.0.646329184841.issue1774736@psf.upfronthosting.co.za> Changes by Martin v. L?wis: ---------- resolution: -> duplicate status: open -> closed superseder: -> Tkinter binding involving Control-spacebar raises unicode error _____________________________________ Tracker _____________________________________ From report at bugs.python.org Mon Sep 10 23:30:04 2007 From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=) Date: Mon, 10 Sep 2007 21:30:04 -0000 Subject: [issue783188] support for server side transactions in _ssl Message-ID: <1189459804.1.0.622394407401.issue783188@psf.upfronthosting.co.za> Martin v. L?wis added the comment: Marking as out-of-date ---------- resolution: -> out of date status: open -> closed superseder: -> server-side ssl support ____________________________________ Tracker ____________________________________ From report at bugs.python.org Mon Sep 10 23:38:51 2007 From: report at bugs.python.org (Brett Cannon) Date: Mon, 10 Sep 2007 21:38:51 -0000 Subject: [issue1096] Deeply recursive repr segfault Message-ID: <1189460331.07.0.721949637454.issue1096@psf.upfronthosting.co.za> Brett Cannon added the comment: Fixed in rev. 58096. ---------- assignee: -> brett.cannon nosy: +brett.cannon resolution: -> fixed status: open -> closed versions: +Python 2.6 __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Sep 10 23:40:05 2007 From: report at bugs.python.org (Guido van Rossum) Date: Mon, 10 Sep 2007 21:40:05 -0000 Subject: [issue1140] re.sub returns str when processing empty unicode string Message-ID: <1189460405.11.0.581277424091.issue1140@psf.upfronthosting.co.za> Guido van Rossum added the comment: Here's a better patch that also fixes a few related issues. __________________________________ Tracker __________________________________ -------------- next part -------------- A non-text attachment was scrubbed... Name: sre.diff Type: text/x-patch Size: 2811 bytes Desc: not available Url : http://mail.python.org/pipermail/python-bugs-list/attachments/20070910/ef35d5bd/attachment.bin From report at bugs.python.org Mon Sep 10 23:40:25 2007 From: report at bugs.python.org (Guido van Rossum) Date: Mon, 10 Sep 2007 21:40:25 -0000 Subject: [issue1140] re.sub returns str when processing empty unicode string Message-ID: <1189460425.33.0.334693263787.issue1140@psf.upfronthosting.co.za> Guido van Rossum added the comment: Fredrik, thoughts? ---------- assignee: gvanrossum -> effbot nosy: +effbot __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Sep 10 23:54:53 2007 From: report at bugs.python.org (Bill Janssen) Date: Mon, 10 Sep 2007 21:54:53 -0000 Subject: [issue1583946] SSL "issuer" and "server" names cannot be parsed Message-ID: <1189461293.47.0.716728650048.issue1583946@psf.upfronthosting.co.za> Bill Janssen added the comment: Fixed in rev 58097. _____________________________________ Tracker _____________________________________ From report at bugs.python.org Mon Sep 10 23:54:54 2007 From: report at bugs.python.org (Fredrik Lundh) Date: Mon, 10 Sep 2007 21:54:54 -0000 Subject: [issue1140] re.sub returns str when processing empty unicode string Message-ID: <1189461294.97.0.548859847374.issue1140@psf.upfronthosting.co.za> Fredrik Lundh added the comment: Looks good to me. I still subscribe to the idea that robust code should accept 8-bit *ASCII* strings any- where it accepts Unicode (especially when the 8-bit string is empty), but that's me. Feel free to check this in (or assign back to you if you don't have the time). ---------- assignee: effbot -> gvanrossum resolution: -> accepted __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Sep 10 23:55:03 2007 From: report at bugs.python.org (Bill Janssen) Date: Mon, 10 Sep 2007 21:55:03 -0000 Subject: [issue1583946] SSL "issuer" and "server" names cannot be parsed Message-ID: <1189461303.45.0.876093253311.issue1583946@psf.upfronthosting.co.za> Changes by Bill Janssen: ---------- resolution: -> fixed status: open -> closed _____________________________________ Tracker _____________________________________ From report at bugs.python.org Mon Sep 10 23:55:29 2007 From: report at bugs.python.org (Guido van Rossum) Date: Mon, 10 Sep 2007 21:55:29 -0000 Subject: [issue1142] code sample showing errors reading large files with py 2.5/3.0 Message-ID: <1189461329.47.0.127999464531.issue1142@psf.upfronthosting.co.za> Guido van Rossum added the comment: PythonMeister, what do you mean, "confirmed"? Your read loop ends printing ('total lines read ', 85014960) which is the expected output. (It's one less than the number of lines written due to a bug in the program -- it prints the 0-based ordinal of the last line written rather than the total number of lines written, which is one more. But the bug is the same in the input and output loop. Richard's output from the read loop was ('total lines read ', 85014950) i.e. 10 less than written. I wonder if the bug is simply a matter of a failure to flush on Windows? I can't reproduce it on Linux (Ubuntu dapper). Richard, can you somehow view the end of the file to see what its last lines actually are? It should end like this: 85014951 85014952 85014953 85014954 85014955 85014956 85014957 85014958 85014959 85014960 ---------- nosy: +gvanrossum __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Sep 10 23:56:18 2007 From: report at bugs.python.org (Bill Janssen) Date: Mon, 10 Sep 2007 21:56:18 -0000 Subject: [issue1065] ssl.py shouldn't change class names from 2.6 to 3.x Message-ID: <1189461378.09.0.022613639096.issue1065@psf.upfronthosting.co.za> Bill Janssen added the comment: Fixed in rev 58097. ---------- resolution: -> fixed status: open -> closed __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Sep 10 23:56:40 2007 From: report at bugs.python.org (Fredrik Lundh) Date: Mon, 10 Sep 2007 21:56:40 -0000 Subject: [issue1140] re.sub returns str when processing empty unicode string Message-ID: <1189461400.81.0.900817758821.issue1140@psf.upfronthosting.co.za> Fredrik Lundh added the comment: (is there a way to just add a comment in the new tracker, btw, or is everything a "change note", even if nothing has changed?) __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Sep 11 00:01:17 2007 From: report at bugs.python.org (Fredrik Lundh) Date: Mon, 10 Sep 2007 22:01:17 -0000 Subject: [issue1140] re.sub returns str when processing empty unicode string Message-ID: <1189461676.99.0.476014828867.issue1140@psf.upfronthosting.co.za> Fredrik Lundh added the comment: Well, I spent a minute hunting around for a "comment" field or an "add comment" button. Guess this is a "you only need to learn this once" thing... __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Sep 11 00:03:41 2007 From: report at bugs.python.org (Guido van Rossum) Date: Mon, 10 Sep 2007 22:03:41 -0000 Subject: [issue1140] re.sub returns str when processing empty unicode string Message-ID: <1189461821.71.0.126991059687.issue1140@psf.upfronthosting.co.za> Guido van Rossum added the comment: Thanks, Fredrik. Fixed in 2.6. Committed revision 58098. Someone else could backport to 2.5. Shouldn't be merged into 3.0. __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Sep 11 00:04:08 2007 From: report at bugs.python.org (Fredrik Lundh) Date: Mon, 10 Sep 2007 22:04:08 -0000 Subject: [issue1140] re.sub returns str when processing empty unicode string Message-ID: <1189461848.05.0.11613198543.issue1140@psf.upfronthosting.co.za> Changes by Fredrik Lundh: __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Sep 11 00:13:35 2007 From: report at bugs.python.org (Fredrik Lundh) Date: Mon, 10 Sep 2007 22:13:35 -0000 Subject: [issue1123] split(None, maxsplit) does not strip whitespace correctly Message-ID: <1189462415.01.0.0393352988246.issue1123@psf.upfronthosting.co.za> Fredrik Lundh added the comment: Looks like a *documentation* bug to me; at the implementation level, None just means "no empty parts, treat runs of whitespace as separators". ---------- nosy: +effbot __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Sep 11 00:32:48 2007 From: report at bugs.python.org (Nir Soffer) Date: Mon, 10 Sep 2007 22:32:48 -0000 Subject: [issue1123] split(None, maxsplit) does not strip whitespace correctly Message-ID: <1189463568.0.0.504496482363.issue1123@psf.upfronthosting.co.za> Nir Soffer added the comment: I did not look into the source, but obviously there is striping of leading and trailing whitespace. When you specify a separator you get: >>> ' '.split(' ') ['', '', ''] >>> ' a b '.split(' ') ['', 'a', 'b', ''] So one would expect to get this without striping: >>> ' a b '.split() ['', 'a', 'b', ''] But you get this: >>> ' a b '.split() ['a', 'b'] So the documentation is correct. __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Sep 11 00:37:17 2007 From: report at bugs.python.org (Guido van Rossum) Date: Mon, 10 Sep 2007 22:37:17 -0000 Subject: [issue1026] Backport ABC to 2.6 Message-ID: <1189463837.19.0.422264674513.issue1026@psf.upfronthosting.co.za> Guido van Rossum added the comment: Committed revision 58099. (I had to backport test_typechecks.py myself, and fix one issue in abc.py.) Are you going to backport _abcoll.py and its tests? ---------- assignee: -> gvanrossum nosy: +gvanrossum resolution: -> accepted status: open -> closed __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Sep 11 00:41:05 2007 From: report at bugs.python.org (Fredrik Lundh) Date: Mon, 10 Sep 2007 22:41:05 -0000 Subject: [issue1123] split(None, maxsplit) does not strip whitespace correctly Message-ID: <1189464065.86.0.841824603298.issue1123@psf.upfronthosting.co.za> Fredrik Lundh added the comment: But wasn't your complaint that the implementation didn't match the documentation? As I said, the *implementation* treats "runs of whitespace" as separators, except for whitespace at the beginning or end (or in other words, it never returns empty strings). That matches the documentation, except for the "first" in "first, whitespace characters are stripped from both ends". As far as I can tell, the documentation has never matched the implementation here. __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Sep 11 07:29:32 2007 From: report at bugs.python.org (Stefan Sonnenberg-Carstens) Date: Tue, 11 Sep 2007 05:29:32 -0000 Subject: [issue1142] code sample showing errors reading large files with py 2.5/3.0 Message-ID: <1189488572.32.0.600398771302.issue1142@psf.upfronthosting.co.za> Stefan Sonnenberg-Carstens added the comment: I can confirm that under Linux (Linux nx6310 2.6.22-1-mepis-smp #1 SMP PREEMPT Wed Sep 5 22:23:08 EDT 2007 i686 GNU/Linux, SimplyMepis 7.0b3) 1. using Python 3.0a1 is _very_ slow 2. it eats all your cpu (see my post) I did not take the time to wait for the program to finish with 3.0a1, as my patience is limited. I don't think it would silently drop lines, as the windows version. To see if flushing matters, I'll try this later: import sys print(sys.version_info) import time print (time.strftime('%Y-%m-%d %H:%M:%S')) liste=[] start = time.time() fichout=open('test.txt','w') for i in xrange(85014961): if i%5000000==0 and i>0: print (i,time.time()-start) fichout.write(str(i)+' '*59+'\n') fishout.flush() fichout.close() print ('total lines written ',i) print (i,time.time()-start) print ('*'*50) fichin=open('test.txt') start3 = time.time() for i,li in enumerate(fichin): if i%5000000==0 and i>0: print (i,time.time()-start3) fichin.close() print ('total lines read ',i) print(time.time()-start) I've seen a case lately on Windows XP SP2 with Python 2.3, where a college of mine wrote some files he read from a zip file to disk. Before the close() he also had to flush() the written files explicitly, otherwise he was not able to rename them afterwards. His first approach was time.sleep(30), which was not an option. I'll come back, if I ran the code under Windows. __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Sep 11 08:13:15 2007 From: report at bugs.python.org (Fredrik Lundh) Date: Tue, 11 Sep 2007 06:13:15 -0000 Subject: [issue1143] Updated to latest ElementTree in 2.6 Message-ID: <1189491195.66.0.621818063137.issue1143@psf.upfronthosting.co.za> New submission from Fredrik Lundh: The xml.etree package should be updated to ElementTree 1.3/cElementTree 1.0.6 (or later). ---------- assignee: effbot components: XML messages: 55811 nosy: effbot priority: normal severity: minor status: open title: Updated to latest ElementTree in 2.6 type: rfe versions: Python 2.6 __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Sep 11 08:13:15 2007 From: report at bugs.python.org (Fredrik Lundh) Date: Tue, 11 Sep 2007 06:13:15 -0000 Subject: [issue1143] Updated to latest ElementTree in 2.6 Message-ID: <1189491195.66.0.621818063137.issue1143@psf.upfronthosting.co.za> New submission from Fredrik Lundh: The xml.etree package should be updated to ElementTree 1.3/cElementTree 1.0.6 (or later). ---------- assignee: effbot components: XML messages: 55811 nosy: effbot priority: normal severity: minor status: open title: Updated to latest ElementTree in 2.6 type: rfe versions: Python 2.6 __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Sep 11 08:13:45 2007 From: report at bugs.python.org (Fredrik Lundh) Date: Tue, 11 Sep 2007 06:13:45 -0000 Subject: [issue1602189] Suggest a textlist() method for ElementTree Message-ID: <1189491225.52.0.319371861081.issue1602189@psf.upfronthosting.co.za> Fredrik Lundh added the comment: ElementTree 1.3 provides a variant of this (tentatively called "itertext"). ---------- resolution: -> accepted superseder: -> Updated to latest ElementTree in 2.6 _____________________________________ Tracker _____________________________________ From report at bugs.python.org Tue Sep 11 08:14:17 2007 From: report at bugs.python.org (Fredrik Lundh) Date: Tue, 11 Sep 2007 06:14:17 -0000 Subject: [issue1143] Update to latest ElementTree in Python 2.6 Message-ID: <1189491257.63.0.778008193795.issue1143@psf.upfronthosting.co.za> Changes by Fredrik Lundh: ---------- title: Updated to latest ElementTree in 2.6 -> Update to latest ElementTree in Python 2.6 __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Sep 11 08:15:21 2007 From: report at bugs.python.org (Fredrik Lundh) Date: Tue, 11 Sep 2007 06:15:21 -0000 Subject: [issue1602189] Suggest a textlist() method for ElementTree Message-ID: <1189491321.39.0.969745986072.issue1602189@psf.upfronthosting.co.za> Changes by Fredrik Lundh: ---------- status: open -> closed _____________________________________ Tracker _____________________________________ From report at bugs.python.org Tue Sep 11 08:18:19 2007 From: report at bugs.python.org (christen) Date: Tue, 11 Sep 2007 06:18:19 -0000 Subject: [issue1142] code sample showing errors reading large files with py 2.5/3.0 In-Reply-To: <1189461329.47.0.127999464531.issue1142@psf.upfronthosting.co.za> Message-ID: <46E632C1.80503@unice.fr> christen added the comment: Hi Guido It is not the end of the file that is not read (see also below) I found about that about one year ago when I was parsing very large files resulting from "blast" on the human genome My parser chock after 4 Go, well before the end of the file : one line was missing and my acc=li[x:y] end up with an error, because acc was never filled... This was kind of strange because this had not happened before with my Linux box. I opened the file (which I had created myself) with a editor that could show hexa code : the proper line was there and allright. If I remember well, I modified my code to see better what was going on : in fact the missing line had been concateneted to the previous line despite the proper existence of the end of line (hexa code was ok). see also below I forgot about that because nobody replied to my mails, and I thought it was possibly related with windows 32 . I moved to a windows 64 recently (windows has the best driver for SQL databases) and forgot about the bug until I again ran into it. I then decided to try python 3k, it reads >4Go file with no trouble but is so so slow, both in reading and writing files. The following code produces either <4Go or >4Go files depending upon which fichout.write is commented They both have the same line numbers, but the >4Go does not read completely under windows (32 or 64) I have no such pb on Linux or BSD (Mac). python 3k on windows read both files ok, but is very very slow (change xrange to range , I guess it is preposterous to advice you about that :-). best Richard import sys print(sys.version_info) import time print (time.strftime('%Y-%m-%d %H:%M:%S')) liste=[] start = time.time() fichout=open('test.txt','w') for i in xrange(85014961): if i%5000000==0 and i>0: print (i,time.time()-start) fichout.write(str(i)+' '*59+'\n') #big file #fichout.write(str(i)+'\n') #small file, same number of lines fishout.flush() fichout.close() print ('total lines written ',i) print (i,time.time()-start) print ('*'*50) fichin=open('test.txt') start3 = time.time() for i,li in enumerate(fichin): if i%5000000==0 and i>0: print (i,time.time()-start3) fichin.close() print ('total lines read ',i) print(time.time()-start) > Richard, can you somehow view the end of the file to see what its last > lines actually are? It should end like this: > > 85014951 > 85014952 > 85014953 > 85014954 > 85014955 > 85014956 > 85014957 > 85014958 > 85014959 > 85014960 > > using a text editor reads: 85014944 85014945 85014946 85014947 85014948 85014949 85014950 85014951 85014952 85014953 85014954 85014955 85014956 85014957 85014958 85014959 85014960 windows py 2.5, with if i>85014940: print i, li.strip() prints : (2, 5, 0, 'final', 0) 2007-09-11 07:58:47 (5000000, 2.6720001697540283) (10000000, 5.375) (15000000, 8.0320000648498535) (20000000, 10.703000068664551) (25000000, 13.375) (30000000, 16.047000169754028) (35000000, 18.703000068664551) (40000000, 21.360000133514404) (45000000, 24.032000064849854) (50000000, 26.687999963760376) (55000000, 29.360000133514404) (60000000, 32.032000064849854) (65000000, 34.703000068664551) (70000000, 37.407000064849854) (75000000, 40.094000101089478) (80000000, 42.797000169754028) (85000000, 45.485000133514404) 85014941 85014951 85014942 85014952 85014943 85014953 85014944 85014954 85014945 85014955 85014946 85014956 85014947 85014957 85014948 85014958 85014949 85014959 85014950 85014960 ==> missing lines are from within the file now introduce in the loop: if len(li)>80: print li.strip() (2, 5, 0, 'final', 0) 2007-09-11 08:08:16 (5000000, 3.1559998989105225) (10000000, 6.3280000686645508) (15000000, 9.4839999675750732) (20000000, 12.655999898910522) (25000000, 15.843999862670898) (30000000, 19.016000032424927) (35000000, 22.187999963760376) (40000000, 25.358999967575073) (45000000, 28.530999898910522) (50000000, 31.703000068664551) (55000000, 34.858999967575073) (60000000, 38.030999898910522) * 62410138 62410139 * * 62414887 62414888 * * 62415540 62415541 * * 62420289 62420290 * * 62420942 62420943 * * 62421595 62421596 * * 62422248 62422249 * * 62422901 62422902 * * 62427650 62427651 * * 62428303 62428304 * (65000000, 41.233999967575073) (70000000, 44.437999963760376) (75000000, 47.625) (80000000, 50.828000068664551) (85000000, 54.016000032424927) ('total lines read ', 85014950) 54.0309998989 ==> end of line not read for 10 lines in the middle of the file ! NTFS file system best Richard __________________________________ Tracker __________________________________ -------------- next part -------------- A non-text attachment was scrubbed... Name: christen.vcf Type: text/x-vcard Size: 371 bytes Desc: not available Url : http://mail.python.org/pipermail/python-bugs-list/attachments/20070911/b270fe77/attachment.vcf From report at bugs.python.org Tue Sep 11 08:20:18 2007 From: report at bugs.python.org (Fredrik Lundh) Date: Tue, 11 Sep 2007 06:20:18 -0000 Subject: [issue1745722] please add wsgi to SimpleXMLRPCServer Message-ID: <1189491618.46.0.821186114087.issue1745722@psf.upfronthosting.co.za> Fredrik Lundh added the comment: A proper patch, including tests (if possible) and documentation, would be nice. (also note that SimpleXMLRPCServer was written by Brian Quinlan.) ---------- assignee: effbot -> _____________________________________ Tracker _____________________________________ From report at bugs.python.org Tue Sep 11 08:23:11 2007 From: report at bugs.python.org (Fredrik Lundh) Date: Tue, 11 Sep 2007 06:23:11 -0000 Subject: [issue1690840] xmlrpclib methods submit call on __str__, __repr__ Message-ID: <1189491791.28.0.498085881428.issue1690840@psf.upfronthosting.co.za> Fredrik Lundh added the comment: I'm trying to think of a reason for actually providing __repr__ over RPC, but I cannot find any. Not quite as sure about __str__, though; I suggest adding a __repr__ method, but leaving the rest as is. ---------- assignee: effbot -> collinwinter _____________________________________ Tracker _____________________________________ From report at bugs.python.org Tue Sep 11 08:25:47 2007 From: report at bugs.python.org (Fredrik Lundh) Date: Tue, 11 Sep 2007 06:25:47 -0000 Subject: [issue814253] Grouprefs in lookbehind assertions Message-ID: <1189491947.0.0.31606118379.issue814253@psf.upfronthosting.co.za> Changes by Fredrik Lundh: ---------- type: -> behavior versions: +Python 2.4, Python 2.5 ____________________________________ Tracker ____________________________________ From report at bugs.python.org Tue Sep 11 08:26:10 2007 From: report at bugs.python.org (Benjamin Aranguren) Date: Tue, 11 Sep 2007 06:26:10 -0000 Subject: [issue1026] Backport ABC to 2.6 In-Reply-To: <1189463837.19.0.422264674513.issue1026@psf.upfronthosting.co.za> Message-ID: Benjamin Aranguren added the comment: Yes. I plan to work on it this weekend. I hope that's okay. On 9/10/07, Guido van Rossum wrote: > > Guido van Rossum added the comment: > > Committed revision 58099. > (I had to backport test_typechecks.py myself, and fix one issue in abc.py.) > > Are you going to backport _abcoll.py and its tests? > > ---------- > assignee: -> gvanrossum > nosy: +gvanrossum > resolution: -> accepted > status: open -> closed > > __________________________________ > Tracker > > __________________________________ > __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Sep 11 08:35:42 2007 From: report at bugs.python.org (Greg Hazel) Date: Tue, 11 Sep 2007 06:35:42 -0000 Subject: [issue1690840] xmlrpclib methods submit call on __str__, __repr__ Message-ID: <1189492542.76.0.603780531522.issue1690840@psf.upfronthosting.co.za> Greg Hazel added the comment: How about making ServerProxy a new-style class? _____________________________________ Tracker _____________________________________ From report at bugs.python.org Tue Sep 11 12:36:07 2007 From: report at bugs.python.org (Georg Brandl) Date: Tue, 11 Sep 2007 10:36:07 -0000 Subject: [issue1121] Document inspect.getfullargspec() Message-ID: <1189506967.97.0.357923729028.issue1121@psf.upfronthosting.co.za> Changes by Georg Brandl: ---------- assignee: -> georg.brandl nosy: +georg.brandl __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Sep 11 12:36:10 2007 From: report at bugs.python.org (Georg Brandl) Date: Tue, 11 Sep 2007 10:36:10 -0000 Subject: [issue1122] PyTuple_Size and PyTuple_GET_SIZE return type documentation incorrect Message-ID: <1189506970.57.0.752200160973.issue1122@psf.upfronthosting.co.za> Changes by Georg Brandl: ---------- assignee: -> georg.brandl nosy: +georg.brandl __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Sep 11 13:05:31 2007 From: report at bugs.python.org (David Binger) Date: Tue, 11 Sep 2007 11:05:31 -0000 Subject: [issue1144] parsermodule validation out of sync with Grammar Message-ID: <1189508731.28.0.0196002397645.issue1144@psf.upfronthosting.co.za> New submission from David Binger: >>> parser.sequence2st(parser.suite("class A(object): pass").tolist()) Traceback (most recent call last): File "", line 1, in parser.ParserError: Expected node type 326, got 329. --- The Grammar in python 3 uses "arglist" instead of "testlist" for class definitions. The parsermodule's validate_class() calls validate_testlist() where it should now be calling validate_arglist(). ---------- components: Library (Lib) messages: 55818 nosy: dbinger severity: normal status: open title: parsermodule validation out of sync with Grammar type: behavior versions: Python 3.0 __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Sep 11 13:05:31 2007 From: report at bugs.python.org (David Binger) Date: Tue, 11 Sep 2007 11:05:31 -0000 Subject: [issue1144] parsermodule validation out of sync with Grammar Message-ID: <1189508731.28.0.0196002397645.issue1144@psf.upfronthosting.co.za> New submission from David Binger: >>> parser.sequence2st(parser.suite("class A(object): pass").tolist()) Traceback (most recent call last): File "", line 1, in parser.ParserError: Expected node type 326, got 329. --- The Grammar in python 3 uses "arglist" instead of "testlist" for class definitions. The parsermodule's validate_class() calls validate_testlist() where it should now be calling validate_arglist(). ---------- components: Library (Lib) messages: 55818 nosy: dbinger severity: normal status: open title: parsermodule validation out of sync with Grammar type: behavior versions: Python 3.0 __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Sep 11 13:12:44 2007 From: report at bugs.python.org (Nir Soffer) Date: Tue, 11 Sep 2007 11:12:44 -0000 Subject: [issue1123] split(None, maxsplit) does not strip whitespace correctly Message-ID: <1189509164.21.0.712321683529.issue1123@psf.upfronthosting.co.za> Nir Soffer added the comment: There is a problem only when maxsplit is smaller than the available splits. In other cases, the docs and the behavior match. __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Sep 11 13:41:15 2007 From: report at bugs.python.org (Thomas Lee) Date: Tue, 11 Sep 2007 11:41:15 -0000 Subject: [issue1145] Allow str.join to join non-string types (as per PEP 3100) Message-ID: <1189510875.27.0.109757226088.issue1145@psf.upfronthosting.co.za> New submission from Thomas Lee: The current implementation of str.join requires that the parameters passed to it be string/unicode values. A suggestion to allow it to accept parameters of any type came up in PEP 3100. Implemented for Unicode using the attached patch. It would be trivial to add this functionality to the old string object too, but I haven't been following the string to unicode discussion too closely and I'm unsure if the old string object will remain for too much longer. ---------- components: Interpreter Core files: join-autostr.patch messages: 55820 nosy: thomas.lee severity: minor status: open title: Allow str.join to join non-string types (as per PEP 3100) type: behavior versions: Python 3.0 __________________________________ Tracker __________________________________ -------------- next part -------------- A non-text attachment was scrubbed... Name: join-autostr.patch Type: text/x-patch Size: 4684 bytes Desc: not available Url : http://mail.python.org/pipermail/python-bugs-list/attachments/20070911/ee4515ef/attachment.bin From report at bugs.python.org Tue Sep 11 13:41:15 2007 From: report at bugs.python.org (Thomas Lee) Date: Tue, 11 Sep 2007 11:41:15 -0000 Subject: [issue1145] Allow str.join to join non-string types (as per PEP 3100) Message-ID: <1189510875.27.0.109757226088.issue1145@psf.upfronthosting.co.za> New submission from Thomas Lee: The current implementation of str.join requires that the parameters passed to it be string/unicode values. A suggestion to allow it to accept parameters of any type came up in PEP 3100. Implemented for Unicode using the attached patch. It would be trivial to add this functionality to the old string object too, but I haven't been following the string to unicode discussion too closely and I'm unsure if the old string object will remain for too much longer. ---------- components: Interpreter Core files: join-autostr.patch messages: 55820 nosy: thomas.lee severity: minor status: open title: Allow str.join to join non-string types (as per PEP 3100) type: behavior versions: Python 3.0 __________________________________ Tracker __________________________________ -------------- next part -------------- A non-text attachment was scrubbed... Name: join-autostr.patch Type: text/x-patch Size: 4684 bytes Desc: not available Url : http://mail.python.org/pipermail/python-bugs-list/attachments/20070911/ee4515ef/attachment-0003.bin From report at bugs.python.org Tue Sep 11 13:42:58 2007 From: report at bugs.python.org (Thomas Lee) Date: Tue, 11 Sep 2007 11:42:58 -0000 Subject: [issue1145] Allow str.join to join non-string types (as per PEP 3100) Message-ID: <1189510978.79.0.4627140855.issue1145@psf.upfronthosting.co.za> Thomas Lee added the comment: Oh and an example of usage: # before the patch ', '.join([str(x) for x in [1, 2, 3]]) # after the patch ', '.join([1, 2, 3]) __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Sep 11 13:44:40 2007 From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=) Date: Tue, 11 Sep 2007 11:44:40 -0000 Subject: [issue1145] Allow str.join to join non-string types (as per PEP 3100) Message-ID: <1189511080.8.0.696710586581.issue1145@psf.upfronthosting.co.za> Changes by Martin v. L?wis: ---------- keywords: +patch __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Sep 11 15:37:37 2007 From: report at bugs.python.org (sam) Date: Tue, 11 Sep 2007 13:37:37 -0000 Subject: [issue1146] TextWrap vs words 1-character shorter than the width Message-ID: <1189517857.01.0.116632649875.issue1146@psf.upfronthosting.co.za> New submission from sam: >>> from textwrap import wrap >>> wrap("foobarbaz reallylongwordgoeshere", width = 10) ['foobarbaz r', 'eallylongw', 'ordgoesher', 'e'] >>> print [len(s) for s in _] [11, 10, 10, 1] This only seems to happen when the first word on the line is exactly one character shorter than the width, and the next word is too long to fit, so it is broken: >>> wrap("foo bar reallylongwordgoeshere", width = 7) ['foo bar', 'reallyl', 'ongword', 'goesher', 'e'] >>> wrap("foobarbaz really longwordgoeshere", width = 10) ['foobarbaz', 'really lon', 'gwordgoesh', 'ere'] >>> wrap("foobarbaz reallylongwordgoeshere", width = 10, break_long_words = False) ['foobarbaz', 'reallylongwordgoeshere'] This is on Python 2.5, on Windows XP SP2. ---------- messages: 55822 nosy: sam severity: normal status: open title: TextWrap vs words 1-character shorter than the width type: behavior versions: Python 2.5 __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Sep 11 15:37:37 2007 From: report at bugs.python.org (sam) Date: Tue, 11 Sep 2007 13:37:37 -0000 Subject: [issue1146] TextWrap vs words 1-character shorter than the width Message-ID: <1189517857.01.0.116632649875.issue1146@psf.upfronthosting.co.za> New submission from sam: >>> from textwrap import wrap >>> wrap("foobarbaz reallylongwordgoeshere", width = 10) ['foobarbaz r', 'eallylongw', 'ordgoesher', 'e'] >>> print [len(s) for s in _] [11, 10, 10, 1] This only seems to happen when the first word on the line is exactly one character shorter than the width, and the next word is too long to fit, so it is broken: >>> wrap("foo bar reallylongwordgoeshere", width = 7) ['foo bar', 'reallyl', 'ongword', 'goesher', 'e'] >>> wrap("foobarbaz really longwordgoeshere", width = 10) ['foobarbaz', 'really lon', 'gwordgoesh', 'ere'] >>> wrap("foobarbaz reallylongwordgoeshere", width = 10, break_long_words = False) ['foobarbaz', 'reallylongwordgoeshere'] This is on Python 2.5, on Windows XP SP2. ---------- messages: 55822 nosy: sam severity: normal status: open title: TextWrap vs words 1-character shorter than the width type: behavior versions: Python 2.5 __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Sep 11 16:03:59 2007 From: report at bugs.python.org (Nick Coghlan) Date: Tue, 11 Sep 2007 14:03:59 -0000 Subject: [issue1056] test_cmd_line starts python without -E Message-ID: <1189519439.77.0.401459254933.issue1056@psf.upfronthosting.co.za> Nick Coghlan added the comment: Fixed for 2.6 in rev 58103 (Is the head still being merged to the py3k branch? Or does this need to be forward-ported manually?) ---------- nosy: +ncoghlan resolution: -> fixed status: open -> closed __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Sep 11 16:19:48 2007 From: report at bugs.python.org (Nick Coghlan) Date: Tue, 11 Sep 2007 14:19:48 -0000 Subject: [issue1739468] Add a -z interpreter flag to execute a zip file Message-ID: <1189520388.18.0.717641811773.issue1739468@psf.upfronthosting.co.za> Nick Coghlan added the comment: I like PJE's approach, and the patch works for me. About the only thing I'd change is to switch the expression in PyImport_GetImporter to a simple chain of if-statements in order to: - silence the warning from GCC about an unused value - make it more obvious to a reader what the function is doing An optimising compiler is going to produce similar code either way, and it took me a moment to realise that the && operations are being used purely for their short-circuiting effect, even though there is no real advantage to using an expression instead of a statement at that point in the code. Adding a simple test of the functionality to test_cmd_line would also be good. _____________________________________ Tracker _____________________________________ From report at bugs.python.org Tue Sep 11 17:16:35 2007 From: report at bugs.python.org (Jean-Paul Calderone) Date: Tue, 11 Sep 2007 15:16:35 -0000 Subject: [issue1147] string exceptions inconsistently deprecated/disabled Message-ID: <1189523795.09.0.87571084132.issue1147@psf.upfronthosting.co.za> New submission from Jean-Paul Calderone: Python 2.5 deprecated raising string exceptions. It also added the throw method to generator objects which can be used to raise an exception, including a string exception. Raising an exception with this method doesn't issue a deprecation warning. It looks like Python 2.6 will remove string exceptions entirely. Current trunk still allows strings to be passed to the throw method of generators though, and raises the string exception, again without a deprecation warning. ---------- components: Interpreter Core messages: 55825 nosy: exarkun severity: normal status: open title: string exceptions inconsistently deprecated/disabled type: behavior versions: Python 2.5, Python 2.6 __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Sep 11 17:16:35 2007 From: report at bugs.python.org (Jean-Paul Calderone) Date: Tue, 11 Sep 2007 15:16:35 -0000 Subject: [issue1147] string exceptions inconsistently deprecated/disabled Message-ID: <1189523795.09.0.87571084132.issue1147@psf.upfronthosting.co.za> New submission from Jean-Paul Calderone: Python 2.5 deprecated raising string exceptions. It also added the throw method to generator objects which can be used to raise an exception, including a string exception. Raising an exception with this method doesn't issue a deprecation warning. It looks like Python 2.6 will remove string exceptions entirely. Current trunk still allows strings to be passed to the throw method of generators though, and raises the string exception, again without a deprecation warning. ---------- components: Interpreter Core messages: 55825 nosy: exarkun severity: normal status: open title: string exceptions inconsistently deprecated/disabled type: behavior versions: Python 2.5, Python 2.6 __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Sep 11 17:17:21 2007 From: report at bugs.python.org (Paul Moore) Date: Tue, 11 Sep 2007 15:17:21 -0000 Subject: [issue1739468] Add a -z interpreter flag to execute a zip file Message-ID: <1189523841.88.0.46738510552.issue1739468@psf.upfronthosting.co.za> Paul Moore added the comment: PJE's patch looks OK. I agree with Nick that the chain of &&s in PyImport_GetImporter should be expanded into a chain of ifs. As it stands, the code is needlessly obfuscated. _____________________________________ Tracker _____________________________________ From report at bugs.python.org Tue Sep 11 19:26:25 2007 From: report at bugs.python.org (Eduardo Padoan) Date: Tue, 11 Sep 2007 17:26:25 -0000 Subject: [issue1148] TypeError on join - httplib mixing str and bytes Message-ID: <1189531585.2.0.192204697498.issue1148@psf.upfronthosting.co.za> New submission from Eduardo Padoan: To reproduce: >>> import httplib >>> conn = httplib.HTTPConnection("www.python.org") >>> conn.request("GET", "/index.html") >>> r1 = conn.getresponse() >>> r1.read() Traceback (most recent call last): File "", line 1, in File "/home/eopadoan/pub/py3k/Lib/httplib.py", line 540, in read s = self._safe_read(self.length) File "/home/eopadoan/pub/py3k/Lib/httplib.py", line 627, in _safe_read return "".join(s) TypeError: sequence item 0: expected string or Unicode, bytes found Also, shouldn't the message be like "...expected str, bytes found"? ---------- components: Library (Lib) messages: 55827 nosy: eopadoan severity: normal status: open title: TypeError on join - httplib mixing str and bytes type: crash versions: Python 3.0 __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Sep 11 19:26:25 2007 From: report at bugs.python.org (Eduardo Padoan) Date: Tue, 11 Sep 2007 17:26:25 -0000 Subject: [issue1148] TypeError on join - httplib mixing str and bytes Message-ID: <1189531585.2.0.192204697498.issue1148@psf.upfronthosting.co.za> New submission from Eduardo Padoan: To reproduce: >>> import httplib >>> conn = httplib.HTTPConnection("www.python.org") >>> conn.request("GET", "/index.html") >>> r1 = conn.getresponse() >>> r1.read() Traceback (most recent call last): File "", line 1, in File "/home/eopadoan/pub/py3k/Lib/httplib.py", line 540, in read s = self._safe_read(self.length) File "/home/eopadoan/pub/py3k/Lib/httplib.py", line 627, in _safe_read return "".join(s) TypeError: sequence item 0: expected string or Unicode, bytes found Also, shouldn't the message be like "...expected str, bytes found"? ---------- components: Library (Lib) messages: 55827 nosy: eopadoan severity: normal status: open title: TypeError on join - httplib mixing str and bytes type: crash versions: Python 3.0 __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Sep 11 19:36:47 2007 From: report at bugs.python.org (Guido van Rossum) Date: Tue, 11 Sep 2007 17:36:47 -0000 Subject: [issue1142] code sample showing errors reading large files with py 2.5/3.0 Message-ID: <1189532207.4.0.423511671456.issue1142@psf.upfronthosting.co.za> Guido van Rossum added the comment: Folks, please focus on one issue at a time, and don't post such long transcripts. I know Py3k text I/O is very slow; it's written in Python and uses UTF-8 as the default encoding. We've got a summer of code student working on an accelerating this. (And if he doesn't finish we have another year to work on it before 3.0final is released.) So the real problem is that on Windows in 2.x reading files > 4 GB loses data. Please try to see if opening the file in binary mode still loses data. I suspect a problem in the Windows C stdio library related to line endings, but who knows. ---------- components: -Interpreter Core versions: -Python 3.0 __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Sep 11 20:03:46 2007 From: report at bugs.python.org (=?utf-8?q?Lu=C3=ADs_Pedro_Coelho?=) Date: Tue, 11 Sep 2007 18:03:46 -0000 Subject: [issue1149] fdopen does not work as expected Message-ID: <1189533826.38.0.958954232674.issue1149@psf.upfronthosting.co.za> New submission from Lu?s Pedro Coelho: from os import * def Fork(): b = fork() if b < 0: raise Exception('fork() failed') return b r,w=pipe() b = Fork() if b == 0: dup2(w,1) close(w) execlp('echo',\ 'echo',\ 'Hello world') else: for line in fdopen(r): print 'Read %s' % line I was expecting this code to print "Read Hello World". Instead, it hangs forever. Changing "for line in fdopen(r): print 'Read %s' % line" to "line=read(r,100); print 'Read %s' % line" makes the program work as expected. This is what I did on my actual production code, but it seems funny behaviour on the part of fdopen. I am running on Ubuntu on PowerPC. ---------- components: Library (Lib) messages: 55829 nosy: luis at luispedro.org severity: normal status: open title: fdopen does not work as expected type: behavior versions: Python 2.3, Python 2.4, Python 2.5 __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Sep 11 20:03:46 2007 From: report at bugs.python.org (=?utf-8?q?Lu=C3=ADs_Pedro_Coelho?=) Date: Tue, 11 Sep 2007 18:03:46 -0000 Subject: [issue1149] fdopen does not work as expected Message-ID: <1189533826.38.0.958954232674.issue1149@psf.upfronthosting.co.za> New submission from Lu?s Pedro Coelho: from os import * def Fork(): b = fork() if b < 0: raise Exception('fork() failed') return b r,w=pipe() b = Fork() if b == 0: dup2(w,1) close(w) execlp('echo',\ 'echo',\ 'Hello world') else: for line in fdopen(r): print 'Read %s' % line I was expecting this code to print "Read Hello World". Instead, it hangs forever. Changing "for line in fdopen(r): print 'Read %s' % line" to "line=read(r,100); print 'Read %s' % line" makes the program work as expected. This is what I did on my actual production code, but it seems funny behaviour on the part of fdopen. I am running on Ubuntu on PowerPC. ---------- components: Library (Lib) messages: 55829 nosy: luis at luispedro.org severity: normal status: open title: fdopen does not work as expected type: behavior versions: Python 2.3, Python 2.4, Python 2.5 __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Sep 11 20:23:03 2007 From: report at bugs.python.org (Guido van Rossum) Date: Tue, 11 Sep 2007 18:23:03 -0000 Subject: [issue1150] Rename PyBUF_WRITEABLE to PyBUF_WRITABLE Message-ID: <1189534983.38.0.207085295331.issue1150@psf.upfronthosting.co.za> New submission from Guido van Rossum: Because writeable is not an English word; writable is. Other names should be fixed as well. ---------- messages: 55830 nosy: gvanrossum severity: normal status: open title: Rename PyBUF_WRITEABLE to PyBUF_WRITABLE versions: Python 3.0 __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Sep 11 20:23:03 2007 From: report at bugs.python.org (Guido van Rossum) Date: Tue, 11 Sep 2007 18:23:03 -0000 Subject: [issue1150] Rename PyBUF_WRITEABLE to PyBUF_WRITABLE Message-ID: <1189534983.38.0.207085295331.issue1150@psf.upfronthosting.co.za> New submission from Guido van Rossum: Because writeable is not an English word; writable is. Other names should be fixed as well. ---------- messages: 55830 nosy: gvanrossum severity: normal status: open title: Rename PyBUF_WRITEABLE to PyBUF_WRITABLE versions: Python 3.0 __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Sep 11 20:33:46 2007 From: report at bugs.python.org (Ben Beasley) Date: Tue, 11 Sep 2007 18:33:46 -0000 Subject: [issue1141] reading large files Message-ID: <1189535626.85.0.762053999999.issue1141@psf.upfronthosting.co.za> Ben Beasley added the comment: I ran Richard Christen's script from msg55784 on Ubuntu Feisty Fawn (64-bit) with both Python 2.5.1 and Python 3.0a1 (for the latter, I had to change xrange to range). (2, 5, 1, 'final', 0) 2007-09-11 11:39:08 (5000000, 7.3925600051879883) (10000000, 15.068881034851074) (15000000, 22.870260953903198) (20000000, 30.588511943817139) (25000000, 37.977153062820435) (30000000, 45.393024921417236) (35000000, 57.039968013763428) (40000000, 71.122976064682007) (45000000, 85.065402984619141) (50000000, 97.03105092048645) (55000000, 108.22125887870789) (60000000, 122.95617389678955) (65000000, 130.45936799049377) (70000000, 141.0406129360199) (75000000, 150.52000093460083) (80000000, 158.0419979095459) (85000000, 168.46517896652222) ('total lines written ', 85014960) (85014960, 168.48725986480713) ************************************************** (5000000, 11.699964046478271) (10000000, 18.510161876678467) (15000000, 27.110308885574341) (20000000, 35.410284996032715) (25000000, 41.88045597076416) (30000000, 48.734965085983276) (35000000, 56.416620016098022) (40000000, 65.14509105682373) (45000000, 73.711935043334961) (50000000, 82.278150081634521) (55000000, 90.984658002853394) (60000000, 99.987648963928223) (65000000, 104.64127588272095) (70000000, 109.73277306556702) (75000000, 114.78491401672363) (80000000, 120.38562488555908) (85000000, 126.08317303657532) ('total lines read ', 85014960) 294.583214998 (3, 0, 0, 'alpha', 1) 2007-09-11 12:20:53 5000000 117.375117064 10000000 238.183109045 15000000 357.397506952 20000000 476.816791058 25000000 597.198447943 30000000 717.393661976 35000000 837.278333902 40000000 956.919227839 45000000 1077.25333095 50000000 1196.60731292 55000000 1316.08601999 60000000 1434.81360602 65000000 1554.1584239 70000000 1673.04580498 75000000 1792.35387397 80000000 1912.65659904 85000000 2032.99598598 total lines written 85014960 85014960 2033.35042787 ************************************************** 5000000 89.7920100689 10000000 180.910079002 15000000 272.628970146 20000000 364.904497147 25000000 457.229861021 30000000 549.14190793 35000000 641.054435968 40000000 733.30577898 45000000 826.058191061 50000000 917.997677088 55000000 1010.20616603 60000000 1102.142905 65000000 1194.16728902 70000000 1286.54789495 75000000 1378.50006604 80000000 1470.37746692 85000000 1562.25738001 total lines read 85014960 3595.88338494 ---------- nosy: +music __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Sep 11 20:39:49 2007 From: report at bugs.python.org (Ben Beasley) Date: Tue, 11 Sep 2007 18:39:49 -0000 Subject: [issue1141] reading large files Message-ID: <1189535989.9.0.571932098207.issue1141@psf.upfronthosting.co.za> Ben Beasley added the comment: See the BDFL's comment in msg55828. "I know Py3k text I/O is very slow; it's written in Python and uses UTF-8 as the default encoding. We've got a summer of code student working on an accelerating this. (And if he doesn't finish we have another year to work on it before 3.0final is released.)" __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Sep 11 21:15:21 2007 From: report at bugs.python.org (Kurt B. Kaiser) Date: Tue, 11 Sep 2007 19:15:21 -0000 Subject: [issue1130] Idle - Save (buffer) - closes IDLE and does not save file (Windows XP) Message-ID: <1189538121.33.0.605228196946.issue1130@psf.upfronthosting.co.za> Changes by Kurt B. Kaiser: ---------- assignee: -> kbk keywords: +py3k nosy: +kbk __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Sep 11 21:26:07 2007 From: report at bugs.python.org (Eduardo Padoan) Date: Tue, 11 Sep 2007 19:26:07 -0000 Subject: [issue1151] "TypeError: expected string, bytes found" instead of KeyboardInterrupt Message-ID: <1189538767.56.0.704624756031.issue1151@psf.upfronthosting.co.za> New submission from Eduardo Padoan: On revision 54803, interactive mode, on linux: if type ctrl+c you type ctrl+c, it should raise KeyboardInterrupt, but "TypeError: expected string, bytes found" printed. Also, I could *not* catch it doing: >>> try: ... while True: pass ... except KeyboardInterrupt: ... print('Ok') ... except TypeError: ... print('Ops') Ok To reproduce: >>> # press ctrl+c... TypeError: expected string, bytes found >>> It seems that it is simply printing the wrong error... ---------- components: Interpreter Core messages: 55833 nosy: eopadoan severity: normal status: open title: "TypeError: expected string, bytes found" instead of KeyboardInterrupt type: behavior versions: Python 3.0 __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Sep 11 21:26:07 2007 From: report at bugs.python.org (Eduardo Padoan) Date: Tue, 11 Sep 2007 19:26:07 -0000 Subject: [issue1151] "TypeError: expected string, bytes found" instead of KeyboardInterrupt Message-ID: <1189538767.56.0.704624756031.issue1151@psf.upfronthosting.co.za> New submission from Eduardo Padoan: On revision 54803, interactive mode, on linux: if type ctrl+c you type ctrl+c, it should raise KeyboardInterrupt, but "TypeError: expected string, bytes found" printed. Also, I could *not* catch it doing: >>> try: ... while True: pass ... except KeyboardInterrupt: ... print('Ok') ... except TypeError: ... print('Ops') Ok To reproduce: >>> # press ctrl+c... TypeError: expected string, bytes found >>> It seems that it is simply printing the wrong error... ---------- components: Interpreter Core messages: 55833 nosy: eopadoan severity: normal status: open title: "TypeError: expected string, bytes found" instead of KeyboardInterrupt type: behavior versions: Python 3.0 __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Sep 11 21:34:16 2007 From: report at bugs.python.org (Brett Cannon) Date: Tue, 11 Sep 2007 19:34:16 -0000 Subject: [issue1147] string exceptions inconsistently deprecated/disabled Message-ID: <1189539256.08.0.659418071582.issue1147@psf.upfronthosting.co.za> Changes by Brett Cannon: ---------- assignee: -> brett.cannon nosy: +brett.cannon __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Sep 11 23:03:13 2007 From: report at bugs.python.org (Brett Cannon) Date: Tue, 11 Sep 2007 21:03:13 -0000 Subject: [issue1147] string exceptions inconsistently deprecated/disabled Message-ID: <1189544593.95.0.931193436341.issue1147@psf.upfronthosting.co.za> Brett Cannon added the comment: Fixed on the trunk in rev. 58108. Need to change 2.5 to raise a warning. ---------- priority: -> normal versions: -Python 2.6 __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Sep 11 23:12:57 2007 From: report at bugs.python.org (Brett Cannon) Date: Tue, 11 Sep 2007 21:12:57 -0000 Subject: [issue1147] string exceptions inconsistently deprecated/disabled Message-ID: <1189545177.32.0.763617050224.issue1147@psf.upfronthosting.co.za> Brett Cannon added the comment: Rev. 58109 covers 2.5. ---------- resolution: -> fixed status: open -> closed __________________________________ Tracker __________________________________ From report at bugs.python.org Wed Sep 12 07:21:36 2007 From: report at bugs.python.org (Frank Millman) Date: Wed, 12 Sep 2007 05:21:36 -0000 Subject: [issue1152] Bug in documentation for SimpleXMLRPCServer Message-ID: <1189574496.01.0.0600340666373.issue1152@psf.upfronthosting.co.za> New submission from Frank Millman: I spotted a minor bug in the documentation to SimpleXMLRPCServer. Background: xmlrpclib.py has the following - # This class is available as ServerProxy and Server. New code should # use ServerProxy, to avoid confusion. # ... class ServerProxy: ... Server = ServerProxy The bug: Section 18.25.1 SimpleXMLRPCServer Objects ... Example: ... The following client code will call the methods made available by the preceding server: import xmlrpclib s = xmlrpclib.Server('http://localhost:8000') It should say: s = xmlrpclib.ServerProxy('http://localhost:8000') ---------- components: Documentation messages: 55836 nosy: FrankMillman severity: normal status: open title: Bug in documentation for SimpleXMLRPCServer versions: Python 2.5 __________________________________ Tracker __________________________________ From report at bugs.python.org Wed Sep 12 07:21:36 2007 From: report at bugs.python.org (Frank Millman) Date: Wed, 12 Sep 2007 05:21:36 -0000 Subject: [issue1152] Bug in documentation for SimpleXMLRPCServer Message-ID: <1189574496.01.0.0600340666373.issue1152@psf.upfronthosting.co.za> New submission from Frank Millman: I spotted a minor bug in the documentation to SimpleXMLRPCServer. Background: xmlrpclib.py has the following - # This class is available as ServerProxy and Server. New code should # use ServerProxy, to avoid confusion. # ... class ServerProxy: ... Server = ServerProxy The bug: Section 18.25.1 SimpleXMLRPCServer Objects ... Example: ... The following client code will call the methods made available by the preceding server: import xmlrpclib s = xmlrpclib.Server('http://localhost:8000') It should say: s = xmlrpclib.ServerProxy('http://localhost:8000') ---------- components: Documentation messages: 55836 nosy: FrankMillman severity: normal status: open title: Bug in documentation for SimpleXMLRPCServer versions: Python 2.5 __________________________________ Tracker __________________________________ From report at bugs.python.org Wed Sep 12 08:10:52 2007 From: report at bugs.python.org (christen) Date: Wed, 12 Sep 2007 06:10:52 -0000 Subject: [issue1142] code sample showing errors reading large files with py 2.5/3.0 In-Reply-To: <1189532207.4.0.423511671456.issue1142@psf.upfronthosting.co.za> Message-ID: <46E78282.4060805@unice.fr> christen added the comment: Bug is still there but pb is solved, simply use oepn('file', 'U') see outputs : fichin=open('test.txt','U') ===> (2, 5, 0, 'final', 0) 2007-09-12 08:00:43 (5000000, 9.312000036239624) (10000000, 22.312000036239624) (15000000, 35.094000101089478) (20000000, 47.812000036239624) (25000000, 60.562000036239624) (30000000, 73.265000104904175) (35000000, 85.953000068664551) (40000000, 98.672000169754028) (45000000, 111.35900020599365) (50000000, 123.98400020599365) (55000000, 136.625) (60000000, 149.26500010490417) (65000000, 161.9060001373291) (70000000, 174.625) (75000000, 187.29700016975403) (80000000, 199.89000010490417) (85000000, 212.5310001373291) ('total lines read ', 85014960) 212.562000036 now with fichin=open('test.txt') or fichin=open('test.txt','r') ===> (2, 5, 0, 'final', 0) 2007-09-12 08:04:48 (5000000, 3.187999963760376) (10000000, 6.3440001010894775) (15000000, 9.4690001010894775) (20000000, 12.594000101089478) (25000000, 15.719000101089478) (30000000, 18.844000101089478) (35000000, 21.969000101089478) (40000000, 25.094000101089478) (45000000, 28.219000101089478) (50000000, 31.344000101089478) (55000000, 34.469000101089478) (60000000, 37.594000101089478) * 62410138 62410139 * * 62414887 62414888 * * 62415540 62415541 * * 62420289 62420290 * * 62420942 62420943 * * 62421595 62421596 * * 62422248 62422249 * * 62422901 62422902 * * 62427650 62427651 * * 62428303 62428304 * (65000000, 40.75) (70000000, 43.953000068664551) (75000000, 47.125) (80000000, 50.328000068664551) (85000000, 53.516000032424927) ('total lines read ', 85014950) 53.5160000324 best Richard __________________________________ Tracker __________________________________ -------------- next part -------------- A non-text attachment was scrubbed... Name: christen.vcf Type: text/x-vcard Size: 371 bytes Desc: not available Url : http://mail.python.org/pipermail/python-bugs-list/attachments/20070912/3b31cbd7/attachment.vcf From report at bugs.python.org Wed Sep 12 08:32:56 2007 From: report at bugs.python.org (Georg Brandl) Date: Wed, 12 Sep 2007 06:32:56 -0000 Subject: [issue1152] Bug in documentation for SimpleXMLRPCServer Message-ID: <1189578776.56.0.58756578104.issue1152@psf.upfronthosting.co.za> Changes by Georg Brandl: ---------- assignee: -> georg.brandl nosy: +georg.brandl __________________________________ Tracker __________________________________ From report at bugs.python.org Wed Sep 12 08:57:35 2007 From: report at bugs.python.org (Gregory P. Smith) Date: Wed, 12 Sep 2007 06:57:35 -0000 Subject: [issue1035] bytes buffer API needs to support read locking and/or PyBUF_LOCKDATA Message-ID: <1189580255.42.0.204716542053.issue1035@psf.upfronthosting.co.za> Gregory P. Smith added the comment: Attaching the most recent patch (minor update from the second one i sent to the python-3000 mailing list to initialize ob_readonly_exports = 0 in the appropriate places). Current mailing list discussion is pointing out that the name LOCKDATA means something other than what the existing pep3118 description implies and that we may want to modify the pep to support more obviously named things such as READ_LOCK, and EXCLUSIVE or similar... here's a link to the current thread: http://mail.python.org/pipermail/python-3000/2007-September/010325.html ---------- keywords: +patch title: bytes buffer API needs to support PyBUF_LOCKDATA -> bytes buffer API needs to support read locking and/or PyBUF_LOCKDATA __________________________________ Tracker __________________________________ -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: bytes-readlock-via-lockdata-gps02.patch.txt Url: http://mail.python.org/pipermail/python-bugs-list/attachments/20070912/e3cf3a3b/attachment-0001.txt From report at bugs.python.org Wed Sep 12 12:46:54 2007 From: report at bugs.python.org (Marcin 'Qrczak' Kowalczyk) Date: Wed, 12 Sep 2007 10:46:54 -0000 Subject: [issue1153] help(pickle) fails: unorderable types: type() < type() Message-ID: <1189594014.38.0.661760959724.issue1153@psf.upfronthosting.co.za> New submission from Marcin 'Qrczak' Kowalczyk: Python 3.0a1 (py3k, Sep 8 2007, 15:57:56) [GCC 4.2.1 20070719 (release) (PLD-Linux)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> import pickle >>> help(pickle) Traceback (most recent call last): File "", line 1, in File "/usr/local/lib/python3.0/site.py", line 350, in __call__ return pydoc.help(*args, **kwds) File "/usr/local/lib/python3.0/pydoc.py", line 1685, in __call__ self.help(request) File "/usr/local/lib/python3.0/pydoc.py", line 1729, in help else: doc(request, 'Help on %s:') File "/usr/local/lib/python3.0/pydoc.py", line 1512, in doc pager(render_doc(thing, title, forceload)) File "/usr/local/lib/python3.0/pydoc.py", line 1490, in render_doc return title % desc + '\n\n' + text.document(object, name) File "/usr/local/lib/python3.0/pydoc.py", line 319, in document if inspect.ismodule(object): return self.docmodule(*args) File "/usr/local/lib/python3.0/pydoc.py", line 1076, in docmodule contents.append(self.document(value, key, name)) File "/usr/local/lib/python3.0/pydoc.py", line 320, in document if inspect.isclass(object): return self.docclass(*args) File "/usr/local/lib/python3.0/pydoc.py", line 1210, in docclass lambda t: t[1] == 'data') File "/usr/local/lib/python3.0/pydoc.py", line 1173, in spilldata name, mod, maxlen=70, doc=doc) + '\n') File "/usr/local/lib/python3.0/pydoc.py", line 1295, in docother repr = self.repr(object) File "/usr/local/lib/python3.0/repr.py", line 24, in repr return self.repr1(x, self.maxlevel) File "/usr/local/lib/python3.0/pydoc.py", line 954, in repr1 return getattr(self, methodname)(x, level) File "/usr/local/lib/python3.0/repr.py", line 78, in repr_dict for key in islice(sorted(x), self.maxdict): TypeError: unorderable types: type() < type() >>> ---------- components: Library (Lib) messages: 55839 nosy: Qrczak severity: normal status: open title: help(pickle) fails: unorderable types: type() < type() type: behavior versions: Python 3.0 __________________________________ Tracker __________________________________ From report at bugs.python.org Wed Sep 12 12:46:54 2007 From: report at bugs.python.org (Marcin 'Qrczak' Kowalczyk) Date: Wed, 12 Sep 2007 10:46:54 -0000 Subject: [issue1153] help(pickle) fails: unorderable types: type() < type() Message-ID: <1189594014.38.0.661760959724.issue1153@psf.upfronthosting.co.za> New submission from Marcin 'Qrczak' Kowalczyk: Python 3.0a1 (py3k, Sep 8 2007, 15:57:56) [GCC 4.2.1 20070719 (release) (PLD-Linux)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> import pickle >>> help(pickle) Traceback (most recent call last): File "", line 1, in File "/usr/local/lib/python3.0/site.py", line 350, in __call__ return pydoc.help(*args, **kwds) File "/usr/local/lib/python3.0/pydoc.py", line 1685, in __call__ self.help(request) File "/usr/local/lib/python3.0/pydoc.py", line 1729, in help else: doc(request, 'Help on %s:') File "/usr/local/lib/python3.0/pydoc.py", line 1512, in doc pager(render_doc(thing, title, forceload)) File "/usr/local/lib/python3.0/pydoc.py", line 1490, in render_doc return title % desc + '\n\n' + text.document(object, name) File "/usr/local/lib/python3.0/pydoc.py", line 319, in document if inspect.ismodule(object): return self.docmodule(*args) File "/usr/local/lib/python3.0/pydoc.py", line 1076, in docmodule contents.append(self.document(value, key, name)) File "/usr/local/lib/python3.0/pydoc.py", line 320, in document if inspect.isclass(object): return self.docclass(*args) File "/usr/local/lib/python3.0/pydoc.py", line 1210, in docclass lambda t: t[1] == 'data') File "/usr/local/lib/python3.0/pydoc.py", line 1173, in spilldata name, mod, maxlen=70, doc=doc) + '\n') File "/usr/local/lib/python3.0/pydoc.py", line 1295, in docother repr = self.repr(object) File "/usr/local/lib/python3.0/repr.py", line 24, in repr return self.repr1(x, self.maxlevel) File "/usr/local/lib/python3.0/pydoc.py", line 954, in repr1 return getattr(self, methodname)(x, level) File "/usr/local/lib/python3.0/repr.py", line 78, in repr_dict for key in islice(sorted(x), self.maxdict): TypeError: unorderable types: type() < type() >>> ---------- components: Library (Lib) messages: 55839 nosy: Qrczak severity: normal status: open title: help(pickle) fails: unorderable types: type() < type() type: behavior versions: Python 3.0 __________________________________ Tracker __________________________________ From report at bugs.python.org Wed Sep 12 15:19:14 2007 From: report at bugs.python.org (Tim Golden) Date: Wed, 12 Sep 2007 13:19:14 -0000 Subject: [issue1136] Bdb documentation Message-ID: <1189603154.63.0.209124386091.issue1136@psf.upfronthosting.co.za> Tim Golden added the comment: I've reviewed the docs for English and general readability. As mentioned, I've no idea of the tech involved. I did look through the bdb.py source and the existing docs for pdb to get some idea of the terminology used. Ultimately I've changed very little; in a couple of places the English was just wrong and in a couple of others I felt a small change improved things. One thing I couldn't work out is that arklad, the author, used "canonic" throughout which I've never seen used. I would simply have changed it to "canonical" except that the code itself uses "canonic" as a function name! In addition, there's no explanation of what canonic(al) means in the context. I've left ?TJG? marks around all the instances. ---------- nosy: +tim.golden __________________________________ Tracker __________________________________ -------------- next part -------------- A non-text attachment was scrubbed... Name: bdb.rst Type: application/octet-stream Size: 10946 bytes Desc: not available Url : http://mail.python.org/pipermail/python-bugs-list/attachments/20070912/355ab283/attachment.obj From report at bugs.python.org Wed Sep 12 16:40:25 2007 From: report at bugs.python.org (Guido van Rossum) Date: Wed, 12 Sep 2007 14:40:25 -0000 Subject: [issue1142] code sample showing errors reading large files with py 2.5/3.0 Message-ID: <1189608025.24.0.483822296639.issue1142@psf.upfronthosting.co.za> Guido van Rossum added the comment: Cool. This helps track down the bug a bit more; it's either in (our routine) getline_via_fgets or it's in Microsoft's text mode line end translation (which universal newlines bypasses). I'm assigning this to Tim Peters, who probably still has a Windows box and once optimized the snot out of this code. ---------- assignee: -> tim_one nosy: +tim_one __________________________________ Tracker __________________________________ From report at bugs.python.org Wed Sep 12 17:39:13 2007 From: report at bugs.python.org (Georg Brandl) Date: Wed, 12 Sep 2007 15:39:13 -0000 Subject: [issue1136] Bdb documentation Message-ID: <1189611553.84.0.587466494402.issue1136@psf.upfronthosting.co.za> Georg Brandl added the comment: Thanks for reviewing, I'll finish and commit that one shortly. ---------- assignee: -> georg.brandl nosy: +georg.brandl __________________________________ Tracker __________________________________ From report at bugs.python.org Wed Sep 12 18:28:40 2007 From: report at bugs.python.org (hhas) Date: Wed, 12 Sep 2007 16:28:40 -0000 Subject: [issue1154] Carbon.CF memory leak Message-ID: <1189614520.84.0.350968879835.issue1154@psf.upfronthosting.co.za> New submission from hhas: CFStringRefObj_Convert leaks memory when passed a str. See attached diff file for patch. ---------- components: Macintosh files: CFmodule.diff messages: 55843 nosy: hhas severity: normal status: open title: Carbon.CF memory leak type: resource usage versions: Python 2.5 __________________________________ Tracker __________________________________ -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: CFmodule.diff Url: http://mail.python.org/pipermail/python-bugs-list/attachments/20070912/4ebd686e/attachment.txt From report at bugs.python.org Wed Sep 12 18:28:40 2007 From: report at bugs.python.org (hhas) Date: Wed, 12 Sep 2007 16:28:40 -0000 Subject: [issue1154] Carbon.CF memory leak Message-ID: <1189614520.84.0.350968879835.issue1154@psf.upfronthosting.co.za> New submission from hhas: CFStringRefObj_Convert leaks memory when passed a str. See attached diff file for patch. ---------- components: Macintosh files: CFmodule.diff messages: 55843 nosy: hhas severity: normal status: open title: Carbon.CF memory leak type: resource usage versions: Python 2.5 __________________________________ Tracker __________________________________ -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: CFmodule.diff Url: http://mail.python.org/pipermail/python-bugs-list/attachments/20070912/4ebd686e/attachment-0001.txt From report at bugs.python.org Wed Sep 12 18:35:21 2007 From: report at bugs.python.org (=?utf-8?q?Cristina_Yenyxe_Gonz=C3=A1lez_Garc=C3=ADa?=) Date: Wed, 12 Sep 2007 16:35:21 -0000 Subject: [issue1136] Bdb documentation Message-ID: <1189614921.7.0.698575906928.issue1136@psf.upfronthosting.co.za> Cristina Yenyxe Gonz?lez Garc?a added the comment: Oops, of course a filename should be in canonical form (an absolute name which does not contain repeated path separators or symbolic links)! __________________________________ Tracker __________________________________ From report at bugs.python.org Wed Sep 12 19:09:03 2007 From: report at bugs.python.org (ajaksu) Date: Wed, 12 Sep 2007 17:09:03 -0000 Subject: [issue1772851] Decimal and long hash, compatibly and efficiently Message-ID: <1189616943.2.0.312335275339.issue1772851@psf.upfronthosting.co.za> ajaksu added the comment: IMHO this patch should be considered for (at least) py3k, in which long becomes the new int. As there is current interest in long/int performance[1] this seems like a good time to raise this kind of issue. Mark, could you please outline the semantic changes (specially at wraparound)? Would the hash value changes happen only in "wraparound (= subtraction + of 2**(bits_in_long)) by incrementing" cases? Would hash(-1) become -1? Sorry to ask all that, but my C (and maths) is (are) *very* limited. I guess an invalid hash value is the reason to have hash(-1) == hash(-2) == -2 currently, if so the period would have to skip that, right? I don't see the need for "y" and would chain some IFs (if x == -1 OR abs(x) == ULONG_MAX), but those are weak guesses. Maybe it's worth discussing this patch without linking its most important change (long hash becoming periodic) to Decimal: it would have many impacts beyond Decimal and is rather a core change (as opposed to Lib). Also, a recent discussion on hashing[2] shows that sometimes the current behavior was well planned :) 1 - http://mail.python.org/pipermail/python-3000/2007-September/010374.html 2 - http://mail.python.org/pipermail/python-3000/2007-September/010327.html ---------- nosy: +ajaksu2 _____________________________________ Tracker _____________________________________ From report at bugs.python.org Wed Sep 12 19:25:51 2007 From: report at bugs.python.org (hhas) Date: Wed, 12 Sep 2007 17:25:51 -0000 Subject: [issue1155] Carbon.CF memory management problem Message-ID: <1189617951.85.0.870438592148.issue1155@psf.upfronthosting.co.za> New submission from hhas: While other CF...RefObj_Convert functions return a borrowed object, CFStringRefObj_Convert will return either a new or borrowed CFStringRef depending on the type of value supplied (str, unicode or CFString). As a result, extensions that use CFStringRefObj_Convert function to (e.g.) parse arguments - for example, Carbon.Launch (Launch_LSGetApplicationForInfo, Launch_LSFindApplicationForInfo) - will leak memory when a str or unicode value is passed. Three possible solutions: 1. Make all CF...RefObj_Convert functions return a 'new' object (i.e. call CFRetain if returning an existing CF object) and make callers responsible for always calling CFRelease on these objects when done. 2. Make CFStringRefObj_Convert accept Carbon.CF.CFStringRef values only, and make users responsible for calling Carbon.CF.toCF on Python str/unicode values before passing them to extension functions. 3. Make no changes to existing code, but advise Python users to call Carbon.CF.toCF themselves before passing text values to extension functions whose docstrings specify CFStringRef parameters if they wish to avoid memory leaks. The third solution would be the obvious choice if future Python development plans call for the deprecation and eventual removal of Carbon.CF. If Carbon.CF is to retained in the long term, however, then some sort of fix would be preferable. While the other two solutions would inevitable cause some disruption, I would suggest #1 is the lesser evil as it would require only existing standard and 3rd-party C extensions to be modified, whereas #2 would require existing Python code to be modified which would affect end-users as well. Note that if solution #1 is used, callers would need to avoid invoking CFRelease when an older, unfixed version of Carbon.CF is in use as this would cause a memory error. This shouldn't cause a problem if the fix is made in a major Python release (whose extensions are incompatible with earlier versions, and vice-versa). pymactoolbox.h could supply a suitable macro, e.g.: #define CarbonCFRelease(v) if (v != NULL) CFRelease(v); which client code could invoke as: #ifdef CarbonCFRelease CarbonCFRelease(someRef); CarbonCFRelease(anotherRef); #endif Unpatched extensions would continue to leak (more) memory, of course, but there should be no other ill effects. ---------- components: Macintosh messages: 55846 nosy: hhas severity: normal status: open title: Carbon.CF memory management problem type: resource usage versions: Python 2.5 __________________________________ Tracker __________________________________ From report at bugs.python.org Wed Sep 12 19:25:51 2007 From: report at bugs.python.org (hhas) Date: Wed, 12 Sep 2007 17:25:51 -0000 Subject: [issue1155] Carbon.CF memory management problem Message-ID: <1189617951.85.0.870438592148.issue1155@psf.upfronthosting.co.za> New submission from hhas: While other CF...RefObj_Convert functions return a borrowed object, CFStringRefObj_Convert will return either a new or borrowed CFStringRef depending on the type of value supplied (str, unicode or CFString). As a result, extensions that use CFStringRefObj_Convert function to (e.g.) parse arguments - for example, Carbon.Launch (Launch_LSGetApplicationForInfo, Launch_LSFindApplicationForInfo) - will leak memory when a str or unicode value is passed. Three possible solutions: 1. Make all CF...RefObj_Convert functions return a 'new' object (i.e. call CFRetain if returning an existing CF object) and make callers responsible for always calling CFRelease on these objects when done. 2. Make CFStringRefObj_Convert accept Carbon.CF.CFStringRef values only, and make users responsible for calling Carbon.CF.toCF on Python str/unicode values before passing them to extension functions. 3. Make no changes to existing code, but advise Python users to call Carbon.CF.toCF themselves before passing text values to extension functions whose docstrings specify CFStringRef parameters if they wish to avoid memory leaks. The third solution would be the obvious choice if future Python development plans call for the deprecation and eventual removal of Carbon.CF. If Carbon.CF is to retained in the long term, however, then some sort of fix would be preferable. While the other two solutions would inevitable cause some disruption, I would suggest #1 is the lesser evil as it would require only existing standard and 3rd-party C extensions to be modified, whereas #2 would require existing Python code to be modified which would affect end-users as well. Note that if solution #1 is used, callers would need to avoid invoking CFRelease when an older, unfixed version of Carbon.CF is in use as this would cause a memory error. This shouldn't cause a problem if the fix is made in a major Python release (whose extensions are incompatible with earlier versions, and vice-versa). pymactoolbox.h could supply a suitable macro, e.g.: #define CarbonCFRelease(v) if (v != NULL) CFRelease(v); which client code could invoke as: #ifdef CarbonCFRelease CarbonCFRelease(someRef); CarbonCFRelease(anotherRef); #endif Unpatched extensions would continue to leak (more) memory, of course, but there should be no other ill effects. ---------- components: Macintosh messages: 55846 nosy: hhas severity: normal status: open title: Carbon.CF memory management problem type: resource usage versions: Python 2.5 __________________________________ Tracker __________________________________ From report at bugs.python.org Wed Sep 12 19:46:46 2007 From: report at bugs.python.org (Bill Janssen) Date: Wed, 12 Sep 2007 17:46:46 -0000 Subject: [issue1535659] NNTPS support in nntplib Message-ID: <1189619206.55.0.320694463685.issue1535659@psf.upfronthosting.co.za> Bill Janssen added the comment: Georg got it right -- this patch is bogus. I'm going to close it as "won't fix". Feel free to re-open it as an RFE with a good patch. ---------- resolution: -> wont fix status: open -> closed _____________________________________ Tracker _____________________________________ From report at bugs.python.org Wed Sep 12 20:05:02 2007 From: report at bugs.python.org (Georg Brandl) Date: Wed, 12 Sep 2007 18:05:02 -0000 Subject: [issue1136] Bdb documentation Message-ID: <1189620302.37.0.827876490729.issue1136@psf.upfronthosting.co.za> Georg Brandl added the comment: Okay, committed as rev. 58112, 58113. Thank you! ---------- resolution: -> accepted status: open -> closed __________________________________ Tracker __________________________________ From report at bugs.python.org Wed Sep 12 20:06:07 2007 From: report at bugs.python.org (Georg Brandl) Date: Wed, 12 Sep 2007 18:06:07 -0000 Subject: [issue1152] Bug in documentation for SimpleXMLRPCServer Message-ID: <1189620367.44.0.620867130554.issue1152@psf.upfronthosting.co.za> Georg Brandl added the comment: Fixed in rev. 58114. ---------- resolution: -> fixed status: open -> closed __________________________________ Tracker __________________________________ From report at bugs.python.org Wed Sep 12 20:09:13 2007 From: report at bugs.python.org (Georg Brandl) Date: Wed, 12 Sep 2007 18:09:13 -0000 Subject: [issue1122] PyTuple_Size and PyTuple_GET_SIZE return type documentation incorrect Message-ID: <1189620553.71.0.438345801871.issue1122@psf.upfronthosting.co.za> Georg Brandl added the comment: Fixed in rev. 58115, 58116 (2.5). Thanks! ---------- resolution: -> fixed status: open -> closed __________________________________ Tracker __________________________________ From report at bugs.python.org Wed Sep 12 20:11:18 2007 From: report at bugs.python.org (Georg Brandl) Date: Wed, 12 Sep 2007 18:11:18 -0000 Subject: [issue1139] PyFile_Encoding should be PyFile_SetEncoding Message-ID: <1189620678.01.0.829954568289.issue1139@psf.upfronthosting.co.za> Georg Brandl added the comment: Fixed in rev. 58117, 58118 (2.5). Thanks! ---------- resolution: -> fixed status: open -> closed __________________________________ Tracker __________________________________ From report at bugs.python.org Wed Sep 12 20:11:54 2007 From: report at bugs.python.org (Georg Brandl) Date: Wed, 12 Sep 2007 18:11:54 -0000 Subject: [issue1598083] Top-level exception handler writes to stdout unsafely Message-ID: <1189620714.09.0.906179445963.issue1598083@psf.upfronthosting.co.za> Georg Brandl added the comment: I'll look into it. ---------- nosy: +georg.brandl _____________________________________ Tracker _____________________________________ From report at bugs.python.org Wed Sep 12 20:23:15 2007 From: report at bugs.python.org (Johann Tonsing) Date: Wed, 12 Sep 2007 18:23:15 -0000 Subject: [issue1156] Suggested change to _exit function description in os module documentation Message-ID: <1189621394.95.0.799707623344.issue1156@psf.upfronthosting.co.za> New submission from Johann Tonsing: The document from which http://docs.python.org/lib/os-process.html was generated contains: "Note: The standard way to exit is sys.exit(n). _exit() should normally only be used in the child process after a fork()." Should "child" be replaced with "parent"? This also applies to: http://docs.python.org/dev/library/os.html Did not check the 3.0 docs (where can they be found?). ---------- components: Documentation messages: 55853 nosy: jtonsing severity: normal status: open title: Suggested change to _exit function description in os module documentation type: behavior versions: Python 2.5, Python 2.6 __________________________________ Tracker __________________________________ From report at bugs.python.org Wed Sep 12 20:23:14 2007 From: report at bugs.python.org (Johann Tonsing) Date: Wed, 12 Sep 2007 18:23:14 -0000 Subject: [issue1156] Suggested change to _exit function description in os module documentation Message-ID: <1189621394.95.0.799707623344.issue1156@psf.upfronthosting.co.za> New submission from Johann Tonsing: The document from which http://docs.python.org/lib/os-process.html was generated contains: "Note: The standard way to exit is sys.exit(n). _exit() should normally only be used in the child process after a fork()." Should "child" be replaced with "parent"? This also applies to: http://docs.python.org/dev/library/os.html Did not check the 3.0 docs (where can they be found?). ---------- components: Documentation messages: 55853 nosy: jtonsing severity: normal status: open title: Suggested change to _exit function description in os module documentation type: behavior versions: Python 2.5, Python 2.6 __________________________________ Tracker __________________________________ From report at bugs.python.org Wed Sep 12 20:29:42 2007 From: report at bugs.python.org (Georg Brandl) Date: Wed, 12 Sep 2007 18:29:42 -0000 Subject: [issue1154] Carbon.CF memory leak Message-ID: <1189621782.84.0.733197516397.issue1154@psf.upfronthosting.co.za> Georg Brandl added the comment: Fixed in rev. 58119, 58120 (2.5). ---------- nosy: +georg.brandl resolution: -> fixed status: open -> closed __________________________________ Tracker __________________________________ From report at bugs.python.org Wed Sep 12 20:39:18 2007 From: report at bugs.python.org (Guido van Rossum) Date: Wed, 12 Sep 2007 18:39:18 -0000 Subject: [issue1739468] Add a -z interpreter flag to execute a zip file Message-ID: <1189622358.8.0.998135009606.issue1739468@psf.upfronthosting.co.za> Guido van Rossum added the comment: PJE's patch looks good to me too. Stylistic nits: - The proper name of the now-public null importer type ought to be PyNullImporter_Type, to rhyme with e.g. PyString_Type - There's a multi-line if that has the closing parenthesis in an odd place at the start of the next line. The preferred style is to place the close paren after the last condition, and put the open curly on a line by itself. ---------- nosy: +gvanrossum _____________________________________ Tracker _____________________________________ From report at bugs.python.org Wed Sep 12 20:54:29 2007 From: report at bugs.python.org (Georg Brandl) Date: Wed, 12 Sep 2007 18:54:29 -0000 Subject: [issue1156] Suggested change to _exit function description in os module documentation Message-ID: <1189623269.35.0.123477960034.issue1156@psf.upfronthosting.co.za> Georg Brandl added the comment: Assigning to Martin. ---------- assignee: -> loewis nosy: +georg.brandl, loewis __________________________________ Tracker __________________________________ From report at bugs.python.org Wed Sep 12 21:01:35 2007 From: report at bugs.python.org (Georg Brandl) Date: Wed, 12 Sep 2007 19:01:35 -0000 Subject: [issue1153] help(pickle) fails: unorderable types: type() < type() Message-ID: <1189623695.55.0.131612204769.issue1153@psf.upfronthosting.co.za> Georg Brandl added the comment: Fixed in the repr module (it was calling sorted() on sets and dicts, which is wrong without fallback) in rev. 58122 (trunk), 58123 (2.5) -- will be merged to 3.0 shortly. ---------- assignee: -> georg.brandl nosy: +georg.brandl resolution: -> fixed status: open -> closed versions: +Python 2.5, Python 2.6 __________________________________ Tracker __________________________________ From report at bugs.python.org Wed Sep 12 21:04:32 2007 From: report at bugs.python.org (Georg Brandl) Date: Wed, 12 Sep 2007 19:04:32 -0000 Subject: [issue1121] Document inspect.getfullargspec() Message-ID: <1189623872.39.0.851147376587.issue1121@psf.upfronthosting.co.za> Georg Brandl added the comment: Documented in rev. 1121. ---------- resolution: -> fixed status: open -> closed __________________________________ Tracker __________________________________ From report at bugs.python.org Wed Sep 12 21:05:52 2007 From: report at bugs.python.org (Georg Brandl) Date: Wed, 12 Sep 2007 19:05:52 -0000 Subject: [issue1207379] class property fset not working Message-ID: <1189623952.2.0.316853037349.issue1207379@psf.upfronthosting.co.za> Georg Brandl added the comment: It says "... for new-style classes (classes that derive from object)." I think this is clear enough. ---------- resolution: -> wont fix status: open -> closed _____________________________________ Tracker _____________________________________ From report at bugs.python.org Wed Sep 12 21:13:30 2007 From: report at bugs.python.org (Guido van Rossum) Date: Wed, 12 Sep 2007 19:13:30 -0000 Subject: [issue1145] Allow str.join to join non-string types (as per PEP 3100) Message-ID: <1189624410.18.0.0768551141172.issue1145@psf.upfronthosting.co.za> Guido van Rossum added the comment: I like this, but the patch has problems: you don't error-check the return value from PyObject_Unicode() or PyUnicode_FromObject() (and why do you need the latter call anyway?) Also in the docstring I would reference str() instead of __str__(). There are also a few lines longer than 80 chars. ---------- assignee: -> gvanrossum nosy: +gvanrossum __________________________________ Tracker __________________________________ From report at bugs.python.org Wed Sep 12 21:20:00 2007 From: report at bugs.python.org (Thomas Heller) Date: Wed, 12 Sep 2007 19:20:00 -0000 Subject: [issue1777530] ctypes on Solaris Message-ID: <1189624800.74.0.302575817701.issue1777530@psf.upfronthosting.co.za> Thomas Heller added the comment: Can someone please test the patch and report back? -- Thanks _____________________________________ Tracker _____________________________________ From report at bugs.python.org Wed Sep 12 21:29:48 2007 From: report at bugs.python.org (Georg Brandl) Date: Wed, 12 Sep 2007 19:29:48 -0000 Subject: [issue1120] "make altinstall" installs pydoc, idle, smtpd.py with broken shebang lines Message-ID: <1189625388.55.0.573270902506.issue1120@psf.upfronthosting.co.za> Georg Brandl added the comment: Fixed in rev. 58125, should be merged to 3k shortly. Thanks! ---------- nosy: +georg.brandl resolution: -> fixed status: open -> closed __________________________________ Tracker __________________________________ From report at bugs.python.org Wed Sep 12 21:32:54 2007 From: report at bugs.python.org (Georg Brandl) Date: Wed, 12 Sep 2007 19:32:54 -0000 Subject: [issue1098] decode_unicode doesn't nul-terminate Message-ID: <1189625574.36.0.496840305677.issue1098@psf.upfronthosting.co.za> Georg Brandl added the comment: The function in question is in Python/ast.c. Martin, does the string need to be null-terminated or does DecodeUnicodeEscape need to be fixed (since it takes an explicit length argument)? ---------- assignee: -> loewis nosy: +georg.brandl, loewis type: -> crash __________________________________ Tracker __________________________________ From report at bugs.python.org Wed Sep 12 21:34:25 2007 From: report at bugs.python.org (Georg Brandl) Date: Wed, 12 Sep 2007 19:34:25 -0000 Subject: [issue1686386] Python SEGFAULT on invalid superclass access Message-ID: <1189625665.58.0.106574490166.issue1686386@psf.upfronthosting.co.za> Georg Brandl added the comment: Brett, you recently fixed an infinite recursion crasher, right? ---------- assignee: -> brett.cannon nosy: +brett.cannon _____________________________________ Tracker _____________________________________ From report at bugs.python.org Wed Sep 12 21:34:48 2007 From: report at bugs.python.org (Guido van Rossum) Date: Wed, 12 Sep 2007 19:34:48 -0000 Subject: [issue1148] TypeError on join - httplib mixing str and bytes Message-ID: <1189625688.97.0.893108626336.issue1148@psf.upfronthosting.co.za> Guido van Rossum added the comment: Confirmed. I'll fix it ASAP. ---------- assignee: -> gvanrossum nosy: +gvanrossum __________________________________ Tracker __________________________________ From report at bugs.python.org Wed Sep 12 21:36:08 2007 From: report at bugs.python.org (Georg Brandl) Date: Wed, 12 Sep 2007 19:36:08 -0000 Subject: [issue1019] Cleanup pass on _curses and _curses_panel Message-ID: <1189625768.84.0.589773810618.issue1019@psf.upfronthosting.co.za> Georg Brandl added the comment: Unfortunately, the patch is hard to review with all the whitespace cleanup distracting from semantic changes. Can you produce a patch with only those changes? ---------- nosy: +georg.brandl __________________________________ Tracker __________________________________ From report at bugs.python.org Wed Sep 12 21:37:17 2007 From: report at bugs.python.org (Guido van Rossum) Date: Wed, 12 Sep 2007 19:37:17 -0000 Subject: [issue1151] "TypeError: expected string, bytes found" instead of KeyboardInterrupt Message-ID: <1189625837.2.0.778023908609.issue1151@psf.upfronthosting.co.za> Guido van Rossum added the comment: Confirmed. Weird. ---------- nosy: +gvanrossum __________________________________ Tracker __________________________________ From report at bugs.python.org Wed Sep 12 21:43:46 2007 From: report at bugs.python.org (Guido van Rossum) Date: Wed, 12 Sep 2007 19:43:46 -0000 Subject: [issue1148] TypeError on join - httplib mixing str and bytes Message-ID: <1189626226.05.0.204733020732.issue1148@psf.upfronthosting.co.za> Guido van Rossum added the comment: Committed revision 58126. ---------- resolution: -> fixed status: open -> closed __________________________________ Tracker __________________________________ From report at bugs.python.org Wed Sep 12 21:44:33 2007 From: report at bugs.python.org (Georg Brandl) Date: Wed, 12 Sep 2007 19:44:33 -0000 Subject: [issue1038] [py3k] pdb does not work in python 3000 Message-ID: <1189626273.6.0.908084173239.issue1038@psf.upfronthosting.co.za> Georg Brandl added the comment: Fixed in rev. 58127. ---------- assignee: -> georg.brandl nosy: +georg.brandl resolution: -> fixed status: open -> closed __________________________________ Tracker __________________________________ From report at bugs.python.org Wed Sep 12 21:45:13 2007 From: report at bugs.python.org (Guido van Rossum) Date: Wed, 12 Sep 2007 19:45:13 -0000 Subject: [issue1145] Allow str.join to join non-string types (as per PEP 3100) Message-ID: <1189626313.43.0.672832148413.issue1145@psf.upfronthosting.co.za> Guido van Rossum added the comment: There's one additional issue. If any of the items is a bytes, the call should fail. __________________________________ Tracker __________________________________ From report at bugs.python.org Wed Sep 12 21:52:04 2007 From: report at bugs.python.org (Brett Cannon) Date: Wed, 12 Sep 2007 19:52:04 -0000 Subject: [issue1686386] Python SEGFAULT on invalid superclass access Message-ID: <1189626724.93.0.612583854351.issue1686386@psf.upfronthosting.co.za> Brett Cannon added the comment: So the first example (in msg31624) crashes because of infinite recursion with the repr of exceptions:: #7771 0x00065178 in BaseException_repr (self=0x5dc6b8) at Objects/exceptions.c:128 #7772 0x0001d90c in PyObject_Repr (v=0x5dc6b8) at Objects/object.c:362 #7773 0x0008c180 in tuplerepr (v=0x5dad58) at Objects/tupleobject.c:221 The second one in msg31626 dies because of the str of exceptions:: #3839 0x0001dd88 in PyObject_Str (v=0x5dc6b8) at Objects/object.c:427 #3840 0x00065120 in BaseException_str (self=0x5dc6b8) at Objects/exceptions.c:110 #3841 0x0001dc0c in _PyObject_Str (v=0x5dc6b8) at Objects/object.c:407 Both fail because BaseException uses the str/repr of its arguments to construct what string to return. When it's itself it just goes on forever trying to get the next object's representation. The repr issue might be fixed by looking at how lists catch loops in themselves (don't remember the exact C function). Either way it is not really str/repr that is causing the issue but exceptions for not worrying about possible recursion thanks to using the str/repr of contained objects. _____________________________________ Tracker _____________________________________ From report at bugs.python.org Wed Sep 12 21:52:10 2007 From: report at bugs.python.org (Brett Cannon) Date: Wed, 12 Sep 2007 19:52:10 -0000 Subject: [issue1686386] Python SEGFAULT on invalid superclass access Message-ID: <1189626730.11.0.812928824022.issue1686386@psf.upfronthosting.co.za> Changes by Brett Cannon: ---------- versions: +Python 2.6 _____________________________________ Tracker _____________________________________ From report at bugs.python.org Wed Sep 12 22:54:42 2007 From: report at bugs.python.org (=?utf-8?q?=0A=09=09=09=09=09Mark_Dickinson=0A=09=09=09=09?=) Date: Wed, 12 Sep 2007 20:54:42 -0000 Subject: [issue1772851] Decimal and long hash, compatibly and efficiently Message-ID: <1189630482.56.0.708229211175.issue1772851@psf.upfronthosting.co.za> Mark Dickinson added the comment: To help explain what's going on, here's some Python code. The Python function long_hash1 below has the properties that: (1) long_hash1(n) == hash(n) for almost all integers n, with a very small set of exceptions. (The first positive exception is 2**33-1, and the next after that is 3*2**33 - 1. The negative exceptions have the same absolute value as the positive ones, so the first negative exception is n = 1-2**33). (2) long_hash1(n) has a simple closed form, making it possible to compute an equivalent Decimal hash efficiently. (3) The current long_hash in Objects/longobject.c can be changed, by adding a single line of C code, so that hash(n) == long_hash1(n) always. That line is: if ((unsigned long)x < v->ob_digit[i]) x++; added directly after the addition. Explanation: the exceptions in (1) arise precisely when the addition x += v->ob_digit[i] in the long_hash code overflows (in the *unsigned* sense---equivalently, when the addition turns a negative x into a nonnegative one). Since ob_digit[i] only has 15 significant bits, and x has 32 (or 64), such overflow is going to be rare---it'll occur for roughly one addition in every 2**18 (or about 4 additions in every million), for `random' n. So for `most' n, hash(n) and long_hash1(n) are equal. So what about long_hash2(n)? This is what the patched long_hash is actually equivalent to; it's essentially the same as long_hash1(n), but fixed up to be genuinely periodic; that is, long_hash1(n+ULONG_MAX) == long_hash1(n) for any integer n. long_hash1 and long_hash2 are equal almost always for positive n (the exceptions being multiples of ULONG_MAX), equal about half the time for negative n, and off-by-one from each other about half the time. I don't really know whether the periodicity is that useful---the predictability is really what matters, so the 1-line change to produce a hash function equivalent to long_hash1 would do just fine as far as making Decimal work. For what it's worth, I regard this patch as an ugly hack. I don't like the idea of changing something as fundamental as long.__hash__, and I don't like having Decimal.__hash__ depend on knowing exactly how long.__hash__ gets its values. But there's a real problem here, namely that, for example, >>> set([Decimal("1E1000000")]) takes several minutes to complete. (Try it!) And I can't think of any other easy way to solve this. Alternative suggestions welcomed! LONG_BITS = 32 W = 2**LONG_BITS HW = W // 2 ULONG_MAX = W - 1 def long_hash1(n): if n == 0: h = 0 else: h = (1 + (abs(n)-1) % ULONG_MAX) * (1 if n > 0 else -1) # reduce mod W to lie in the usual range for a (signed) C long h = (h + HW) % W - HW if h == -1: h = -2 return int(h) def long_hash2(n): h = n % ULONG_MAX h = (h + HW) % W - HW if h == -1: h = -2 return int(h) _____________________________________ Tracker _____________________________________ From report at bugs.python.org Wed Sep 12 23:01:35 2007 From: report at bugs.python.org (Guido van Rossum) Date: Wed, 12 Sep 2007 21:01:35 -0000 Subject: [issue1157] test_urllib2net fails on test_ftp Message-ID: <1189630894.93.0.494420700317.issue1157@psf.upfronthosting.co.za> New submission from Guido van Rossum: ====================================================================== ERROR: test_ftp (__main__.OtherNetworkTests) ---------------------------------------------------------------------- Traceback (most recent call last): File "Lib/test/test_urllib2net.py", line 173, in test_ftp self._test_urls(urls, self._extra_handlers()) File "Lib/test/test_urllib2net.py", line 242, in _test_urls f = urllib2.urlopen(url, req) File "/usr/local/google/home/guido/python/py3k/Lib/urllib2.py", line 122, in urlopen return _opener.open(url, data, timeout) File "/usr/local/google/home/guido/python/py3k/Lib/urllib2.py", line 378, in open response = self._open(req, data) File "/usr/local/google/home/guido/python/py3k/Lib/urllib2.py", line 396, in _open '_open', req) File "/usr/local/google/home/guido/python/py3k/Lib/urllib2.py", line 356, in _call_chain result = func(*args) File "/usr/local/google/home/guido/python/py3k/Lib/urllib2.py", line 1271, in ftp_open fw = self.connect_ftp(user, passwd, host, port, dirs, req.timeout) File "/usr/local/google/home/guido/python/py3k/Lib/urllib2.py", line 1316, in connect_ftp self.cache[key] = ftpwrapper(user, passwd, host, port, dirs, timeout) File "/usr/local/google/home/guido/python/py3k/Lib/urllib.py", line 783, in __init__ self.init() File "/usr/local/google/home/guido/python/py3k/Lib/urllib.py", line 790, in init self.ftp.login(self.user, self.passwd) File "/usr/local/google/home/guido/python/py3k/Lib/ftplib.py", line 372, in login if resp[0] == '3': resp = self.sendcmd('PASS ' + passwd) File "/usr/local/google/home/guido/python/py3k/Lib/ftplib.py", line 242, in sendcmd return self.getresp() File "/usr/local/google/home/guido/python/py3k/Lib/ftplib.py", line 208, in getresp resp = self.getmultiline() File "/usr/local/google/home/guido/python/py3k/Lib/ftplib.py", line 198, in getmultiline nextline = self.getline() File "/usr/local/google/home/guido/python/py3k/Lib/ftplib.py", line 181, in getline line = self.file.readline() File "/usr/local/google/home/guido/python/py3k/Lib/io.py", line 1319, in readline readahead, pending = self._read_chunk() File "/usr/local/google/home/guido/python/py3k/Lib/io.py", line 1123, in _read_chunk pending = self._decoder.decode(readahead, not readahead) File "/usr/local/google/home/guido/python/py3k/Lib/encodings/ascii.py", line 26, in decode return codecs.ascii_decode(input, self.errors)[0] UnicodeDecodeError: 'ascii' codec can't decode byte 0xc3 in position 47: ordinal not in range(128) ---------- messages: 55873 nosy: gvanrossum severity: normal status: open title: test_urllib2net fails on test_ftp versions: Python 3.0 __________________________________ Tracker __________________________________ From report at bugs.python.org Wed Sep 12 23:01:34 2007 From: report at bugs.python.org (Guido van Rossum) Date: Wed, 12 Sep 2007 21:01:34 -0000 Subject: [issue1157] test_urllib2net fails on test_ftp Message-ID: <1189630894.93.0.494420700317.issue1157@psf.upfronthosting.co.za> New submission from Guido van Rossum: ====================================================================== ERROR: test_ftp (__main__.OtherNetworkTests) ---------------------------------------------------------------------- Traceback (most recent call last): File "Lib/test/test_urllib2net.py", line 173, in test_ftp self._test_urls(urls, self._extra_handlers()) File "Lib/test/test_urllib2net.py", line 242, in _test_urls f = urllib2.urlopen(url, req) File "/usr/local/google/home/guido/python/py3k/Lib/urllib2.py", line 122, in urlopen return _opener.open(url, data, timeout) File "/usr/local/google/home/guido/python/py3k/Lib/urllib2.py", line 378, in open response = self._open(req, data) File "/usr/local/google/home/guido/python/py3k/Lib/urllib2.py", line 396, in _open '_open', req) File "/usr/local/google/home/guido/python/py3k/Lib/urllib2.py", line 356, in _call_chain result = func(*args) File "/usr/local/google/home/guido/python/py3k/Lib/urllib2.py", line 1271, in ftp_open fw = self.connect_ftp(user, passwd, host, port, dirs, req.timeout) File "/usr/local/google/home/guido/python/py3k/Lib/urllib2.py", line 1316, in connect_ftp self.cache[key] = ftpwrapper(user, passwd, host, port, dirs, timeout) File "/usr/local/google/home/guido/python/py3k/Lib/urllib.py", line 783, in __init__ self.init() File "/usr/local/google/home/guido/python/py3k/Lib/urllib.py", line 790, in init self.ftp.login(self.user, self.passwd) File "/usr/local/google/home/guido/python/py3k/Lib/ftplib.py", line 372, in login if resp[0] == '3': resp = self.sendcmd('PASS ' + passwd) File "/usr/local/google/home/guido/python/py3k/Lib/ftplib.py", line 242, in sendcmd return self.getresp() File "/usr/local/google/home/guido/python/py3k/Lib/ftplib.py", line 208, in getresp resp = self.getmultiline() File "/usr/local/google/home/guido/python/py3k/Lib/ftplib.py", line 198, in getmultiline nextline = self.getline() File "/usr/local/google/home/guido/python/py3k/Lib/ftplib.py", line 181, in getline line = self.file.readline() File "/usr/local/google/home/guido/python/py3k/Lib/io.py", line 1319, in readline readahead, pending = self._read_chunk() File "/usr/local/google/home/guido/python/py3k/Lib/io.py", line 1123, in _read_chunk pending = self._decoder.decode(readahead, not readahead) File "/usr/local/google/home/guido/python/py3k/Lib/encodings/ascii.py", line 26, in decode return codecs.ascii_decode(input, self.errors)[0] UnicodeDecodeError: 'ascii' codec can't decode byte 0xc3 in position 47: ordinal not in range(128) ---------- messages: 55873 nosy: gvanrossum severity: normal status: open title: test_urllib2net fails on test_ftp versions: Python 3.0 __________________________________ Tracker __________________________________ From report at bugs.python.org Wed Sep 12 23:13:17 2007 From: report at bugs.python.org (Brett Cannon) Date: Wed, 12 Sep 2007 21:13:17 -0000 Subject: [issue1686386] Python SEGFAULT on invalid superclass access Message-ID: <1189631597.37.0.487531952371.issue1686386@psf.upfronthosting.co.za> Brett Cannon added the comment: OK, so I have attached a possible patch. I found out that tuple.__repr__ didn't do anything to prevent infinite recursion since you can't pull it off from Python code. But obviously C code is another matter. =) Same goes for object.__str__; it didn't think about a type's tp_str doing something that could lead to an infinite recursion. Assigning back to Georg to make sure I am not doing something stupid nor that the approach is to broad by changing _PyObject_Str() and tuple.__repr__ instead of BaseException itself. I have not written tests yet as they are rather difficult to do for what the C code is doing without relying specifically on how exceptions do their __repr__/__str__. ---------- assignee: brett.cannon -> georg.brandl keywords: +patch status: open -> pending _____________________________________ Tracker _____________________________________ -------------- next part -------------- A non-text attachment was scrubbed... Name: infinite_rec_fix.diff Type: application/octet-stream Size: 1650 bytes Desc: not available Url : http://mail.python.org/pipermail/python-bugs-list/attachments/20070912/c89768c1/attachment.obj From report at bugs.python.org Wed Sep 12 23:13:56 2007 From: report at bugs.python.org (Brett Cannon) Date: Wed, 12 Sep 2007 21:13:56 -0000 Subject: [issue1686386] Python SEGFAULT on tuple.__repr__ and str() Message-ID: <1189631636.8.0.694661880592.issue1686386@psf.upfronthosting.co.za> Changes by Brett Cannon: ---------- title: Python SEGFAULT on invalid superclass access -> Python SEGFAULT on tuple.__repr__ and str() _____________________________________ Tracker _____________________________________ From report at bugs.python.org Thu Sep 13 00:28:27 2007 From: report at bugs.python.org (ajaksu) Date: Wed, 12 Sep 2007 22:28:27 -0000 Subject: [issue1772851] Decimal and long hash, compatibly and efficiently Message-ID: <1189636107.49.0.575570026381.issue1772851@psf.upfronthosting.co.za> ajaksu added the comment: Thanks a lot for the explanation. I still think it could be valuable (C?)py3k change (but now for the predictability, as you say :) Regarding the performance of Decimal.__hash__: I believe (int) hash performance would be a moot issue if Decimal.__int__ was (much) faster. I've been, for the last three days, trying to convert decimal.py to use longs instead of tuples for Decimal._int. Here are some (hand picked) results (on a Celeron M 1.46GHz): In [906]: D = int_decimal.Decimal (...) In [914]: g = D("1E1000000") (...) In [916]: g Out[916]: Decimal("1E+1000000") (...) In [918]: %timeit k = int(g) 10 loops, best of 3: 3.22 s per loop (...) In [920]: %timeit k = hash(int(g)) 10 loops, best of 3: 3.28 s per loop (...) In [922]: log(int(g)) Out[922]: 2302585.0929940455 In [923]: log(10**1000000) Out[923]: 2302585.0929940455 I'm not very competent in many skills needed for the job AND I'm working between field trips (next starts tomorrow), so, unfortunately, the results are crude and awfully buggy so far. Most "(...)" above were exceptions for simple things like "hash(g)" and there are lots of these issues. The conversion is based on using divisions and multiplications to truncate/extend Decimal._int, from the notion that the bottleneck is the tuple->str->int conversion. I predict lots of currently fast things getting slower and a higher memory footprint, but it might still be worth it and I'm willing to test the idea. As I told Facundo in a private email (y otro llegar? hoy o ma?ana), the simple cases seem workable for me, but I'm not able to tell right now if this has any real chances of succeeding (because I'm bad at maths :/). I've not even looked at __pow__, __mul__ and __div__ yet! Anyway, I'll try to tidy things up as much as I can and email Facundo (and yourself, if you are interested) the results of this large ugly hack before now + 24h. _____________________________________ Tracker _____________________________________ From report at bugs.python.org Thu Sep 13 04:26:44 2007 From: report at bugs.python.org (Skip Montanaro) Date: Thu, 13 Sep 2007 02:26:44 -0000 Subject: [issue1158] %f format for datetime objects Message-ID: <1189650403.5.0.731044089134.issue1158@psf.upfronthosting.co.za> New submission from Skip Montanaro: Attached is a patch for py3k which adds a %f format code to its strftime method. When included in a format string it expands to the number of microseconds in the object. date, time and datetime objects all support the format (though I'm not sure what, if anything, it means for date objects). I don't know how practical this is for time.strftime() level because the inputs are all so excited about being ints. Still, if you wanted to allow the seconds field to be a float and were willing to cast it to an int where necessary and shadow struct tm with a pseudo-float-friendly version of the same, you could probably smash it in there as well. ---------- components: Extension Modules files: percent-f.diff keywords: patch, py3k messages: 55876 nosy: skip.montanaro priority: normal severity: normal status: open title: %f format for datetime objects type: rfe versions: Python 3.0 __________________________________ Tracker __________________________________ -------------- next part -------------- A non-text attachment was scrubbed... Name: percent-f.diff Type: text/x-diff Size: 2351 bytes Desc: not available Url : http://mail.python.org/pipermail/python-bugs-list/attachments/20070913/f31a009c/attachment.diff From report at bugs.python.org Thu Sep 13 04:26:43 2007 From: report at bugs.python.org (Skip Montanaro) Date: Thu, 13 Sep 2007 02:26:43 -0000 Subject: [issue1158] %f format for datetime objects Message-ID: <1189650403.5.0.731044089134.issue1158@psf.upfronthosting.co.za> New submission from Skip Montanaro: Attached is a patch for py3k which adds a %f format code to its strftime method. When included in a format string it expands to the number of microseconds in the object. date, time and datetime objects all support the format (though I'm not sure what, if anything, it means for date objects). I don't know how practical this is for time.strftime() level because the inputs are all so excited about being ints. Still, if you wanted to allow the seconds field to be a float and were willing to cast it to an int where necessary and shadow struct tm with a pseudo-float-friendly version of the same, you could probably smash it in there as well. ---------- components: Extension Modules files: percent-f.diff keywords: patch, py3k messages: 55876 nosy: skip.montanaro priority: normal severity: normal status: open title: %f format for datetime objects type: rfe versions: Python 3.0 __________________________________ Tracker __________________________________ -------------- next part -------------- A non-text attachment was scrubbed... Name: percent-f.diff Type: text/x-diff Size: 2351 bytes Desc: not available Url : http://mail.python.org/pipermail/python-bugs-list/attachments/20070913/f31a009c/attachment-0001.diff From report at bugs.python.org Thu Sep 13 08:23:08 2007 From: report at bugs.python.org (Aki) Date: Thu, 13 Sep 2007 06:23:08 -0000 Subject: [issue1777530] ctypes on Solaris Message-ID: <1189664588.92.0.102228538408.issue1777530@psf.upfronthosting.co.za> Aki added the comment: Sorry for not having done this earlier. I thought this was already closed ... I used your updated patch and installed the Python 2.5.1 from scratch. It worked without any problem except python-config issue, which I have reported in another case [issue1095]. _____________________________________ Tracker _____________________________________ From report at bugs.python.org Thu Sep 13 08:33:11 2007 From: report at bugs.python.org (Brett Cannon) Date: Thu, 13 Sep 2007 06:33:11 -0000 Subject: [issue1158] %f format for datetime objects Message-ID: <1189665191.78.0.440515634986.issue1158@psf.upfronthosting.co.za> Brett Cannon added the comment: Are you going to add support to strptime as well? As for the 'time' module, I don't think it would be useful as it serves no purpose since the time tuple can't resolve to that resolution. If you do add support, though, I guess you just default to 0. ---------- nosy: +brett.cannon __________________________________ Tracker __________________________________ From report at bugs.python.org Thu Sep 13 09:10:35 2007 From: report at bugs.python.org (Thomas Herve) Date: Thu, 13 Sep 2007 07:10:35 -0000 Subject: [issue1686386] Python SEGFAULT on tuple.__repr__ and str() Message-ID: <1189667435.85.0.610620433152.issue1686386@psf.upfronthosting.co.za> Thomas Herve added the comment: I think it could be solved both the same way: if tuple repr is wrong, there are probably some other repr code that is wrong too, so fixing PyObject_Repr is safer. _____________________________________ Tracker _____________________________________ From report at bugs.python.org Thu Sep 13 09:12:14 2007 From: report at bugs.python.org (Eric V. Smith) Date: Thu, 13 Sep 2007 07:12:14 -0000 Subject: [issue1158] %f format for datetime objects Message-ID: <1189667534.61.0.613129643254.issue1158@psf.upfronthosting.co.za> Eric V. Smith added the comment: It's a nit, but there are a few other comments that should be changed to mention %f in addition to %z/%Z. * giving special meanings to the %z and %Z format codes via a preprocessing /* Scan the input format, looking for %z and %Z escapes, building /* percent followed by neither z nor Z */ ---------- nosy: +eric.smith __________________________________ Tracker __________________________________ From report at bugs.python.org Thu Sep 13 09:22:07 2007 From: report at bugs.python.org (Robert Ancell) Date: Thu, 13 Sep 2007 07:22:07 -0000 Subject: [issue1159] os.getenv() not updated after external module uses C putenv() Message-ID: <1189668127.19.0.0258251668017.issue1159@psf.upfronthosting.co.za> New submission from Robert Ancell: The Python os.getenv() function accesses an Python dictionary which is mirroring the process environment. This dictionary is populated when the interpreter starts and updated when os.environ.__setitem__() or os.putenv() are called. However if the python program imports an extension module that uses the system putenv() then the changes cannot be accessed using the Python standard library. This has been a problem for us as we have created Python bindings to an existing C based library that modifies the environment dynamically (not the best design decision...). The workaround we are using is to create our own wrapper to the system (Solaris/Linux) getenv(). A potential solution could be to make environ a class where os.environ.__setitem__() calls putenv(), os.environ.__getitem__() calls getenv() and os.environ.keys()/items()/iter*() uses **environ (or other appropriate system call). This does however have undefined issues on how the environment behaves on various systems (memory leaks etc). ---------- components: Library (Lib) messages: 55881 nosy: robert.ancell severity: normal status: open title: os.getenv() not updated after external module uses C putenv() type: behavior versions: Python 2.6 __________________________________ Tracker __________________________________ From report at bugs.python.org Thu Sep 13 09:22:07 2007 From: report at bugs.python.org (Robert Ancell) Date: Thu, 13 Sep 2007 07:22:07 -0000 Subject: [issue1159] os.getenv() not updated after external module uses C putenv() Message-ID: <1189668127.19.0.0258251668017.issue1159@psf.upfronthosting.co.za> New submission from Robert Ancell: The Python os.getenv() function accesses an Python dictionary which is mirroring the process environment. This dictionary is populated when the interpreter starts and updated when os.environ.__setitem__() or os.putenv() are called. However if the python program imports an extension module that uses the system putenv() then the changes cannot be accessed using the Python standard library. This has been a problem for us as we have created Python bindings to an existing C based library that modifies the environment dynamically (not the best design decision...). The workaround we are using is to create our own wrapper to the system (Solaris/Linux) getenv(). A potential solution could be to make environ a class where os.environ.__setitem__() calls putenv(), os.environ.__getitem__() calls getenv() and os.environ.keys()/items()/iter*() uses **environ (or other appropriate system call). This does however have undefined issues on how the environment behaves on various systems (memory leaks etc). ---------- components: Library (Lib) messages: 55881 nosy: robert.ancell severity: normal status: open title: os.getenv() not updated after external module uses C putenv() type: behavior versions: Python 2.6 __________________________________ Tracker __________________________________ From report at bugs.python.org Thu Sep 13 09:29:43 2007 From: report at bugs.python.org (Thomas Lee) Date: Thu, 13 Sep 2007 07:29:43 -0000 Subject: [issue1145] Allow str.join to join non-string types (as per PEP 3100) Message-ID: <1189668583.76.0.118442154376.issue1145@psf.upfronthosting.co.za> Thomas Lee added the comment: Sure - I'll get onto that. Should have another patch up later tonight. __________________________________ Tracker __________________________________ From report at bugs.python.org Thu Sep 13 09:35:46 2007 From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=) Date: Thu, 13 Sep 2007 07:35:46 -0000 Subject: [issue1159] os.getenv() not updated after external module uses C putenv() Message-ID: <1189668946.69.0.0913344981789.issue1159@psf.upfronthosting.co.za> Martin v. L?wis added the comment: I can't see a bug here. If you want the current C library value of the environment variable, just use os.getenv, not os.environ. ---------- nosy: +loewis __________________________________ Tracker __________________________________ From report at bugs.python.org Thu Sep 13 09:49:42 2007 From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=) Date: Thu, 13 Sep 2007 07:49:42 -0000 Subject: [issue1159] os.getenv() not updated after external module uses C putenv() Message-ID: <1189669782.65.0.25537907464.issue1159@psf.upfronthosting.co.za> Martin v. L?wis added the comment: Ignore my comment - I see now that you are talking about os.getenv. __________________________________ Tracker __________________________________ From report at bugs.python.org Thu Sep 13 10:00:56 2007 From: report at bugs.python.org (=?utf-8?q?=0A=09=09=09=09=09Guido_Ostkamp=0A=09=09=09=09?=) Date: Thu, 13 Sep 2007 08:00:56 -0000 Subject: [issue1160] Medium size regexp crashes python Message-ID: <1189670456.94.0.669298411185.issue1160@psf.upfronthosting.co.za> New submission from Guido Ostkamp : Hello, a medium size regular expression crashes Python 2.5.1 as follows: Traceback (most recent call last): File "./regtest.py", line 14, in m = rematch(pats) File "./regtest.py", line 12, in rematch return re.compile(pat).match File "/export/home/ostkamp/local/lib/python2.5/re.py", line 180, in compile return _compile(pattern, flags) File "/export/home/ostkamp/local/lib/python2.5/re.py", line 231, in _compile p = sre_compile.compile(pattern, flags) File "/export/home/ostkamp/local/lib/python2.5/sre_compile.py", line 530, in compile groupindex, indexgroup OverflowError: regular expression code size limit exceeded This is apparently caused by some code in Modules/_sre.c and Modules/sre.h as follows: self->code[i] = (SRE_CODE) value; if ((unsigned long) self->code[i] != value) { PyErr_SetString(PyExc_OverflowError, "regular expression code size limit exceeded"); break; } An 'unsigned int' value is unnecessarily squeezed into an 'unsigned short' field defined in sre.h: #ifdef Py_UNICODE_WIDE #define SRE_CODE Py_UCS4 #else #define SRE_CODE unsigned short #endif On all systems I'm working on (SuSE Linux SLES 9, Solaris 8 etc.) the else case of the ifdef applies which chooses 'unsigned short'. I don't understand the relationship between 'unicode' and what is apparently the size of the regular expression stack here. Some experiments have shown that changing the 'unsigned short' to 'unsigned long' and rebuilding Python fixes the problem. Here is a test program to reproduce the error: #!/usr/bin/env python import re, random, sys def randhexstring(): return "".join(["%04x" % random.randint(0, 0xffff) for x in range(20)]) pats = [randhexstring() for x in range(1000)] def rematch(pats): pat = '(?:%s)' % '|'.join(pats) return re.compile(pat).match m = rematch(pats) count = 0 for s in pats * 100: if m(s): count += 1 print count Regards Guido ---------- components: Regular Expressions messages: 55885 nosy: ostkamp severity: normal status: open title: Medium size regexp crashes python type: crash versions: Python 2.5 __________________________________ Tracker __________________________________ From report at bugs.python.org Thu Sep 13 10:00:57 2007 From: report at bugs.python.org (=?utf-8?q?=0A=09=09=09=09=09Guido_Ostkamp=0A=09=09=09=09?=) Date: Thu, 13 Sep 2007 08:00:57 -0000 Subject: [issue1160] Medium size regexp crashes python Message-ID: <1189670456.94.0.669298411185.issue1160@psf.upfronthosting.co.za> New submission from Guido Ostkamp : Hello, a medium size regular expression crashes Python 2.5.1 as follows: Traceback (most recent call last): File "./regtest.py", line 14, in m = rematch(pats) File "./regtest.py", line 12, in rematch return re.compile(pat).match File "/export/home/ostkamp/local/lib/python2.5/re.py", line 180, in compile return _compile(pattern, flags) File "/export/home/ostkamp/local/lib/python2.5/re.py", line 231, in _compile p = sre_compile.compile(pattern, flags) File "/export/home/ostkamp/local/lib/python2.5/sre_compile.py", line 530, in compile groupindex, indexgroup OverflowError: regular expression code size limit exceeded This is apparently caused by some code in Modules/_sre.c and Modules/sre.h as follows: self->code[i] = (SRE_CODE) value; if ((unsigned long) self->code[i] != value) { PyErr_SetString(PyExc_OverflowError, "regular expression code size limit exceeded"); break; } An 'unsigned int' value is unnecessarily squeezed into an 'unsigned short' field defined in sre.h: #ifdef Py_UNICODE_WIDE #define SRE_CODE Py_UCS4 #else #define SRE_CODE unsigned short #endif On all systems I'm working on (SuSE Linux SLES 9, Solaris 8 etc.) the else case of the ifdef applies which chooses 'unsigned short'. I don't understand the relationship between 'unicode' and what is apparently the size of the regular expression stack here. Some experiments have shown that changing the 'unsigned short' to 'unsigned long' and rebuilding Python fixes the problem. Here is a test program to reproduce the error: #!/usr/bin/env python import re, random, sys def randhexstring(): return "".join(["%04x" % random.randint(0, 0xffff) for x in range(20)]) pats = [randhexstring() for x in range(1000)] def rematch(pats): pat = '(?:%s)' % '|'.join(pats) return re.compile(pat).match m = rematch(pats) count = 0 for s in pats * 100: if m(s): count += 1 print count Regards Guido ---------- components: Regular Expressions messages: 55885 nosy: ostkamp severity: normal status: open title: Medium size regexp crashes python type: crash versions: Python 2.5 __________________________________ Tracker __________________________________ From report at bugs.python.org Thu Sep 13 10:52:35 2007 From: report at bugs.python.org (Vladimir Konjkov) Date: Thu, 13 Sep 2007 08:52:35 -0000 Subject: [issue1722225] Build on QNX Message-ID: <1189673555.72.0.179464870674.issue1722225@psf.upfronthosting.co.za> Vladimir Konjkov added the comment: look this http://www.mail-archive.com/python-bugs-list%40python.org/msg07749.html it's for python-2.3.5 under qnx4.25. about pyport.h under qnx4.25: I include "unix.h" instead of definition of function openpty()+forkpty() in pyport.h, openpty()+forkpty() naturaly defined in "unix.h" but configure doesn't knows. ---------- nosy: +Konjkov _____________________________________ Tracker _____________________________________ From report at bugs.python.org Thu Sep 13 11:35:24 2007 From: report at bugs.python.org (Thomas Lee) Date: Thu, 13 Sep 2007 09:35:24 -0000 Subject: [issue1145] Allow str.join to join non-string types (as per PEP 3100) Message-ID: <1189676124.86.0.841795721324.issue1145@psf.upfronthosting.co.za> Thomas Lee added the comment: Updated patch: * unneeded PyUnicode_FromObject call removed (I thought this was necessary, but the original author appears to be using it for an INCREF) * documentation now fits into 80 chars * return values from PyObject_Unicode and PyObject_FromObject checked * bytes() objects found in the sequence will raise a TypeError * removed redundant assertion and added the bytes case to test_unicode __________________________________ Tracker __________________________________ -------------- next part -------------- A non-text attachment was scrubbed... Name: join-autostr-r2.patch Type: text/x-patch Size: 4956 bytes Desc: not available Url : http://mail.python.org/pipermail/python-bugs-list/attachments/20070913/7d0f9916/attachment.bin From report at bugs.python.org Thu Sep 13 14:23:09 2007 From: report at bugs.python.org (Eduardo Padoan) Date: Thu, 13 Sep 2007 12:23:09 -0000 Subject: [issue1161] Mangled chars in offending line of SyntaxError traceback Message-ID: <1189686189.66.0.054498459486.issue1161@psf.upfronthosting.co.za> New submission from Eduardo Padoan: Python 3.0a1 (py3k:58103, Sep 11 2007, 13:52:21) [GCC 4.1.2 (Ubuntu 4.1.2-0ubuntu4)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> asd asd File "", line 1 P?? ^ SyntaxError: invalid syntax ---------- components: Interpreter Core messages: 55888 nosy: eopadoan severity: normal status: open title: Mangled chars in offending line of SyntaxError traceback type: behavior versions: Python 3.0 __________________________________ Tracker __________________________________ From report at bugs.python.org Thu Sep 13 14:23:09 2007 From: report at bugs.python.org (Eduardo Padoan) Date: Thu, 13 Sep 2007 12:23:09 -0000 Subject: [issue1161] Mangled chars in offending line of SyntaxError traceback Message-ID: <1189686189.66.0.054498459486.issue1161@psf.upfronthosting.co.za> New submission from Eduardo Padoan: Python 3.0a1 (py3k:58103, Sep 11 2007, 13:52:21) [GCC 4.1.2 (Ubuntu 4.1.2-0ubuntu4)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> asd asd File "", line 1 P?? ^ SyntaxError: invalid syntax ---------- components: Interpreter Core messages: 55888 nosy: eopadoan severity: normal status: open title: Mangled chars in offending line of SyntaxError traceback type: behavior versions: Python 3.0 __________________________________ Tracker __________________________________ From report at bugs.python.org Thu Sep 13 14:24:05 2007 From: report at bugs.python.org (Eduardo Padoan) Date: Thu, 13 Sep 2007 12:24:05 -0000 Subject: [issue1161] Garbled chars in offending line of SyntaxError traceback Message-ID: <1189686245.52.0.34377815387.issue1161@psf.upfronthosting.co.za> Changes by Eduardo Padoan: ---------- title: Mangled chars in offending line of SyntaxError traceback -> Garbled chars in offending line of SyntaxError traceback __________________________________ Tracker __________________________________ From report at bugs.python.org Thu Sep 13 14:59:38 2007 From: report at bugs.python.org (Skip Montanaro) Date: Thu, 13 Sep 2007 12:59:38 -0000 Subject: [issue1158] %f format for datetime objects In-Reply-To: <1189665191.78.0.440515634986.issue1158@psf.upfronthosting.co.za> Message-ID: <18153.13363.304108.730575@montanaro.dyndns.org> Skip Montanaro added the comment: Brett> Are you going to add support to strptime as well? I looked at strptime for about two seconds then moved on. I presume you would know how to add it easily though. ;-) Brett> As for the 'time' module, I don't think it would be useful as it serves Brett> no purpose since the time tuple can't resolve to that Brett> resolution. Resolution isn't the issue. You just make sure you add enough zeroes to make it be microseconds. The bigger problem is that time.strftime() takes a tuple of ints which basically represents a struct tm. That struct has an int seconds field and no sub-second field. You'd either have to start allowing floating point tm_sec fields then either truncating or rounding (but which?) to get ints when you need to actually generate an actual struct tm. Skip __________________________________ Tracker __________________________________ From report at bugs.python.org Thu Sep 13 15:00:07 2007 From: report at bugs.python.org (Skip Montanaro) Date: Thu, 13 Sep 2007 13:00:07 -0000 Subject: [issue1158] %f format for datetime objects In-Reply-To: <1189667534.61.0.613129643254.issue1158@psf.upfronthosting.co.za> Message-ID: <18153.13387.401515.893247@montanaro.dyndns.org> Skip Montanaro added the comment: Eric> It's a nit, but there are a few other comments that should be Eric> changed to mention %f in addition to %z/%Z. Yes, thanks. Skip __________________________________ Tracker __________________________________ From report at bugs.python.org Thu Sep 13 16:35:44 2007 From: report at bugs.python.org (Swaroop) Date: Thu, 13 Sep 2007 14:35:44 -0000 Subject: [issue1162] Python doesn't compile on Microsoft Visual Studio 2008 "Orcas" Beta 2 Message-ID: <1189694143.62.0.229303741197.issue1162@psf.upfronthosting.co.za> New submission from Swaroop: I followed the README build instructions for VS2005. I opened pcbuild.sln in PCbuild8 directory and tried building, and I get the following errors: Warning 1 Command line warning D9035 : option 'Wp64' has been deprecated and will be removed in a future release cl make_buildinfo Warning 2 Command line warning D9035 : option 'Wp64' has been deprecated and will be removed in a future release cl make_versioninfo Warning 3 warning C4005: 'WRITE_RESTRICTED' : macro redefinition c:\program files\microsoft sdks\windows\v6.0a\include\winnt.h 7127 pythoncore Warning 4 warning C4005: 'WRITE_RESTRICTED' : macro redefinition c:\program files\microsoft sdks\windows\v6.0a\include\winnt.h 7127 pythoncore Warning 5 warning C4133: 'function' : incompatible types - from '_typeobject *' to 'PyObject *' c:\all\code\python-svn\modules\_collectionsmodule.c 1113 pythoncore Warning 6 warning C4005: 'WRITE_RESTRICTED' : macro redefinition c:\program files\microsoft sdks\windows\v6.0a\include\winnt.h 7127 pythoncore Warning 7 warning C4018: '>' : signed/unsigned mismatch c:\all\code\python-svn\modules\mmapmodule.c 693 pythoncore Warning 8 warning C4018: '>' : signed/unsigned mismatch c:\all\code\python-svn\modules\mmapmodule.c 834 pythoncore Error 9 fatal error C1083: Cannot open include file: 'db.h': No such file or directory c:\all\code\python-svn\modules\_bsddb.c 90 _bsddb Warning 10 warning LNK4075: ignoring '/EDITANDCONTINUE' due to '/INCREMENTAL:NO' specification _testcapimodule.obj _testcapi Warning 11 warning C4005: 'WRITE_RESTRICTED' : macro redefinition c:\program files\microsoft sdks\windows\v6.0a\include\winnt.h 7127 _socket Error 12 error C2373: 'inet_pton' : redefinition; different type modifiers c:\all\code\python-svn\modules\socketmodule.c 300 _socket Error 13 error C2373: 'inet_ntop' : redefinition; different type modifiers c:\all\code\python-svn\modules\socketmodule.c 301 _socket Error 14 error C2373: 'inet_pton' : redefinition; different type modifiers c:\all\code\python-svn\modules\socketmodule.c 5124 _socket Error 15 error C2373: 'inet_ntop' : redefinition; different type modifiers c:\all\code\python-svn\modules\socketmodule.c 5139 _socket Warning 16 warning LNK4075: ignoring '/EDITANDCONTINUE' due to '/INCREMENTAL:NO' specification winsound.obj winsound Warning 17 warning LNK4075: ignoring '/EDITANDCONTINUE' due to '/INCREMENTAL:NO' specification unicodedata.obj unicodedata Error 18 fatal error C1083: Cannot open include file: 'tcl.h': No such file or directory c:\all\code\python-svn\modules\_tkinter.c 66 _tkinter Error 19 fatal error C1083: Cannot open include file: 'tcl.h': No such file or directory c:\all\code\python-svn\modules\tkappinit.c 16 _tkinter Warning 20 warning LNK4075: ignoring '/EDITANDCONTINUE' due to '/INCREMENTAL:NO' specification selectmodule.obj select Error 21 fatal error C1083: Cannot open include file: 'sqlite3.h': No such file or directory c:\all\code\python-svn\modules\_sqlite\connection.h 33 _sqlite3 Error 22 fatal error C1083: Cannot open include file: 'sqlite3.h': No such file or directory c:\all\code\python-svn\modules\_sqlite\connection.h 33 _sqlite3 Error 23 fatal error C1083: Cannot open include file: 'sqlite3.h': No such file or directory c:\all\code\python-svn\modules\_sqlite\connection.h 33 _sqlite3 Error 24 fatal error C1083: Cannot open include file: 'sqlite3.h': No such file or directory c:\all\code\python-svn\modules\_sqlite\connection.h 33 _sqlite3 Error 25 fatal error C1083: Cannot open include file: 'sqlite3.h': No such file or directory c:\all\code\python-svn\modules\_sqlite\connection.h 33 _sqlite3 Error 26 fatal error C1083: Cannot open include file: 'sqlite3.h': No such file or directory c:\all\code\python-svn\modules\_sqlite\connection.h 33 _sqlite3 Error 27 fatal error C1083: Cannot open include file: 'sqlite3.h': No such file or directory c:\all\code\python-svn\modules\_sqlite\connection.h 33 _sqlite3 Warning 28 warning LNK4075: ignoring '/EDITANDCONTINUE' due to '/INCREMENTAL:NO' specification _msi.obj _msi Warning 29 warning LNK4075: ignoring '/EDITANDCONTINUE' due to '/INCREMENTAL:NO' specification _elementtree.obj _elementtree Warning 30 warning LNK4075: ignoring '/EDITANDCONTINUE' due to '/INCREMENTAL:NO' specification _ctypes_test.obj _ctypes_test Error 31 fatal error C1083: Cannot open include file: 'bzlib.h': No such file or directory c:\all\code\python-svn\modules\bz2module.c 12 bz2 Warning 32 warning C4005: 'WRITE_RESTRICTED' : macro redefinition c:\program files\microsoft sdks\windows\v6.0a\include\winnt.h 7127 _ctypes Warning 33 warning C4005: 'WRITE_RESTRICTED' : macro redefinition c:\program files\microsoft sdks\windows\v6.0a\include\winnt.h 7127 _ctypes Warning 34 warning LNK4075: ignoring '/EDITANDCONTINUE' due to '/INCREMENTAL:NO' specification pyexpat.obj pyexpat Warning 35 warning LNK4075: ignoring '/EDITANDCONTINUE' due to '/INCREMENTAL:NO' specification _ctypes.obj _ctypes Are these solvable problems? Is there something I can do to help? Thanks! Swaroop ---------- components: Build messages: 55891 nosy: swaroopch severity: normal status: open title: Python doesn't compile on Microsoft Visual Studio 2008 "Orcas" Beta 2 versions: Python 3.0 __________________________________ Tracker __________________________________ From report at bugs.python.org Thu Sep 13 16:35:43 2007 From: report at bugs.python.org (Swaroop) Date: Thu, 13 Sep 2007 14:35:43 -0000 Subject: [issue1162] Python doesn't compile on Microsoft Visual Studio 2008 "Orcas" Beta 2 Message-ID: <1189694143.62.0.229303741197.issue1162@psf.upfronthosting.co.za> New submission from Swaroop: I followed the README build instructions for VS2005. I opened pcbuild.sln in PCbuild8 directory and tried building, and I get the following errors: Warning 1 Command line warning D9035 : option 'Wp64' has been deprecated and will be removed in a future release cl make_buildinfo Warning 2 Command line warning D9035 : option 'Wp64' has been deprecated and will be removed in a future release cl make_versioninfo Warning 3 warning C4005: 'WRITE_RESTRICTED' : macro redefinition c:\program files\microsoft sdks\windows\v6.0a\include\winnt.h 7127 pythoncore Warning 4 warning C4005: 'WRITE_RESTRICTED' : macro redefinition c:\program files\microsoft sdks\windows\v6.0a\include\winnt.h 7127 pythoncore Warning 5 warning C4133: 'function' : incompatible types - from '_typeobject *' to 'PyObject *' c:\all\code\python-svn\modules\_collectionsmodule.c 1113 pythoncore Warning 6 warning C4005: 'WRITE_RESTRICTED' : macro redefinition c:\program files\microsoft sdks\windows\v6.0a\include\winnt.h 7127 pythoncore Warning 7 warning C4018: '>' : signed/unsigned mismatch c:\all\code\python-svn\modules\mmapmodule.c 693 pythoncore Warning 8 warning C4018: '>' : signed/unsigned mismatch c:\all\code\python-svn\modules\mmapmodule.c 834 pythoncore Error 9 fatal error C1083: Cannot open include file: 'db.h': No such file or directory c:\all\code\python-svn\modules\_bsddb.c 90 _bsddb Warning 10 warning LNK4075: ignoring '/EDITANDCONTINUE' due to '/INCREMENTAL:NO' specification _testcapimodule.obj _testcapi Warning 11 warning C4005: 'WRITE_RESTRICTED' : macro redefinition c:\program files\microsoft sdks\windows\v6.0a\include\winnt.h 7127 _socket Error 12 error C2373: 'inet_pton' : redefinition; different type modifiers c:\all\code\python-svn\modules\socketmodule.c 300 _socket Error 13 error C2373: 'inet_ntop' : redefinition; different type modifiers c:\all\code\python-svn\modules\socketmodule.c 301 _socket Error 14 error C2373: 'inet_pton' : redefinition; different type modifiers c:\all\code\python-svn\modules\socketmodule.c 5124 _socket Error 15 error C2373: 'inet_ntop' : redefinition; different type modifiers c:\all\code\python-svn\modules\socketmodule.c 5139 _socket Warning 16 warning LNK4075: ignoring '/EDITANDCONTINUE' due to '/INCREMENTAL:NO' specification winsound.obj winsound Warning 17 warning LNK4075: ignoring '/EDITANDCONTINUE' due to '/INCREMENTAL:NO' specification unicodedata.obj unicodedata Error 18 fatal error C1083: Cannot open include file: 'tcl.h': No such file or directory c:\all\code\python-svn\modules\_tkinter.c 66 _tkinter Error 19 fatal error C1083: Cannot open include file: 'tcl.h': No such file or directory c:\all\code\python-svn\modules\tkappinit.c 16 _tkinter Warning 20 warning LNK4075: ignoring '/EDITANDCONTINUE' due to '/INCREMENTAL:NO' specification selectmodule.obj select Error 21 fatal error C1083: Cannot open include file: 'sqlite3.h': No such file or directory c:\all\code\python-svn\modules\_sqlite\connection.h 33 _sqlite3 Error 22 fatal error C1083: Cannot open include file: 'sqlite3.h': No such file or directory c:\all\code\python-svn\modules\_sqlite\connection.h 33 _sqlite3 Error 23 fatal error C1083: Cannot open include file: 'sqlite3.h': No such file or directory c:\all\code\python-svn\modules\_sqlite\connection.h 33 _sqlite3 Error 24 fatal error C1083: Cannot open include file: 'sqlite3.h': No such file or directory c:\all\code\python-svn\modules\_sqlite\connection.h 33 _sqlite3 Error 25 fatal error C1083: Cannot open include file: 'sqlite3.h': No such file or directory c:\all\code\python-svn\modules\_sqlite\connection.h 33 _sqlite3 Error 26 fatal error C1083: Cannot open include file: 'sqlite3.h': No such file or directory c:\all\code\python-svn\modules\_sqlite\connection.h 33 _sqlite3 Error 27 fatal error C1083: Cannot open include file: 'sqlite3.h': No such file or directory c:\all\code\python-svn\modules\_sqlite\connection.h 33 _sqlite3 Warning 28 warning LNK4075: ignoring '/EDITANDCONTINUE' due to '/INCREMENTAL:NO' specification _msi.obj _msi Warning 29 warning LNK4075: ignoring '/EDITANDCONTINUE' due to '/INCREMENTAL:NO' specification _elementtree.obj _elementtree Warning 30 warning LNK4075: ignoring '/EDITANDCONTINUE' due to '/INCREMENTAL:NO' specification _ctypes_test.obj _ctypes_test Error 31 fatal error C1083: Cannot open include file: 'bzlib.h': No such file or directory c:\all\code\python-svn\modules\bz2module.c 12 bz2 Warning 32 warning C4005: 'WRITE_RESTRICTED' : macro redefinition c:\program files\microsoft sdks\windows\v6.0a\include\winnt.h 7127 _ctypes Warning 33 warning C4005: 'WRITE_RESTRICTED' : macro redefinition c:\program files\microsoft sdks\windows\v6.0a\include\winnt.h 7127 _ctypes Warning 34 warning LNK4075: ignoring '/EDITANDCONTINUE' due to '/INCREMENTAL:NO' specification pyexpat.obj pyexpat Warning 35 warning LNK4075: ignoring '/EDITANDCONTINUE' due to '/INCREMENTAL:NO' specification _ctypes.obj _ctypes Are these solvable problems? Is there something I can do to help? Thanks! Swaroop ---------- components: Build messages: 55891 nosy: swaroopch severity: normal status: open title: Python doesn't compile on Microsoft Visual Studio 2008 "Orcas" Beta 2 versions: Python 3.0 __________________________________ Tracker __________________________________ From report at bugs.python.org Thu Sep 13 16:46:04 2007 From: report at bugs.python.org (Swaroop) Date: Thu, 13 Sep 2007 14:46:04 -0000 Subject: [issue1162] Python doesn't compile on Microsoft Visual Studio 2008 "Orcas" Beta 2 Message-ID: <1189694764.95.0.985558358099.issue1162@psf.upfronthosting.co.za> Changes by Swaroop: ---------- versions: +Python 2.6 -Python 3.0 __________________________________ Tracker __________________________________ From report at bugs.python.org Thu Sep 13 17:39:38 2007 From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=) Date: Thu, 13 Sep 2007 15:39:38 -0000 Subject: [issue1162] Python doesn't compile on Microsoft Visual Studio 2008 "Orcas" Beta 2 In-Reply-To: <1189694143.62.0.229303741197.issue1162@psf.upfronthosting.co.za> Message-ID: <46E959B7.6070806@v.loewis.de> Martin v. L?wis added the comment: This problems are surely solvable. However, I don't think they need to be solved yet. Instead, before we make the next Python release, we decide what VS version to build it with; if it's Orcas, then the PCbuild directory will be updated to contain working project files. Meanwhile, if you want to do something now, feel free to submit a patch, either to PCbuild or PCbuild8. We will not apply that patch, but it would be available for anybody who wants to experiment with beta versions of Microsoft compilers. Regards, Martin ---------- nosy: +loewis __________________________________ Tracker __________________________________ From report at bugs.python.org Thu Sep 13 17:56:48 2007 From: report at bugs.python.org (Raghuram Devarakonda) Date: Thu, 13 Sep 2007 15:56:48 -0000 Subject: [issue1159] os.getenv() not updated after external module uses C putenv() Message-ID: <1189699008.7.0.583393055568.issue1159@psf.upfronthosting.co.za> Changes by Raghuram Devarakonda: ---------- nosy: +draghuram __________________________________ Tracker __________________________________ From report at bugs.python.org Thu Sep 13 18:20:30 2007 From: report at bugs.python.org (Raghuram Devarakonda) Date: Thu, 13 Sep 2007 16:20:30 -0000 Subject: [issue1159] os.getenv() not updated after external module uses C putenv() In-Reply-To: <1189668127.19.0.0258251668017.issue1159@psf.upfronthosting.co.za> Message-ID: <2c51ecee0709130920q314b3c0aia2bb0115d068ae39@mail.gmail.com> Raghuram Devarakonda added the comment: On 9/13/07, Robert Ancell wrote: > The Python os.getenv() function accesses an Python dictionary which is > mirroring the process environment. This dictionary is populated when the > interpreter starts and updated when os.environ.__setitem__() or > os.putenv() are called. However if the python program imports an As per the document and my simple test (on Linux), os.putenv() does not update os.environ. I think, it should update it. __________________________________ Tracker __________________________________ From report at bugs.python.org Thu Sep 13 19:43:52 2007 From: report at bugs.python.org (Stefan Sonnenberg-Carstens) Date: Thu, 13 Sep 2007 17:43:52 -0000 Subject: [issue1159] os.getenv() not updated after external module uses C putenv() Message-ID: <1189705432.8.0.301339620378.issue1159@psf.upfronthosting.co.za> Stefan Sonnenberg-Carstens added the comment: > As per the document and my simple test (on Linux), os.putenv() does > not update os.environ. I think, it should update it. What would be the benefit ? ---------- nosy: +pythonmeister __________________________________ Tracker __________________________________ From report at bugs.python.org Thu Sep 13 19:58:13 2007 From: report at bugs.python.org (Raghuram Devarakonda) Date: Thu, 13 Sep 2007 17:58:13 -0000 Subject: [issue1159] os.getenv() not updated after external module uses C putenv() In-Reply-To: <1189705432.8.0.301339620378.issue1159@psf.upfronthosting.co.za> Message-ID: <2c51ecee0709131058j1b8fc02jdb106f52d6efb1c7@mail.gmail.com> Raghuram Devarakonda added the comment: > Stefan Sonnenberg-Carstens added the comment: > > > As per the document and my simple test (on Linux), os.putenv() does > > not update os.environ. I think, it should update it. > What would be the benefit ? Symmetrical behaviour. When os.getenv() returns the value from os.environ, one would expect, os.putenv to store the value there (At least, I did). On the other hand, it is also ok for both os.getenv and os.putenv get/set the environment directly instead of going through os.environ. I am sure there was some reason for the current behaviour of os.putenv. Perhaps, because putenv is supposedly not available on all platforms? Any way, I think the OP was asking to always "get" the value dynamically when ever os.environ['VAR'] or os.getenv['VAR'] is done. I don't see any problem with that approach. How ever, if it is considered backwards incompatible, I guess an optional parameter can be added to os.getenv. __________________________________ Tracker __________________________________ From report at bugs.python.org Thu Sep 13 21:35:31 2007 From: report at bugs.python.org (Brett Cannon) Date: Thu, 13 Sep 2007 19:35:31 -0000 Subject: [issue1158] %f format for datetime objects In-Reply-To: <18153.13363.304108.730575@montanaro.dyndns.org> Message-ID: Brett Cannon added the comment: On 9/13/07, Skip Montanaro wrote: > > Skip Montanaro added the comment: > > Brett> Are you going to add support to strptime as well? > > I looked at strptime for about two seconds then moved on. I presume you > would know how to add it easily though. ;-) > Adding support is not issue. It's exposing the microseconds to datetime. It would probably require something along the lines of returning a tuple with microseconds included and have time use a function that creates another tuple with that info removed and datetime using the more informational tuple. But adding the %f support is very straightforward. > Brett> As for the 'time' module, I don't think it would be useful as it serves > Brett> no purpose since the time tuple can't resolve to that > Brett> resolution. > > Resolution isn't the issue. You just make sure you add enough zeroes to > make it be microseconds. The bigger problem is that time.strftime() takes a > tuple of ints which basically represents a struct tm. That struct has an > int seconds field and no sub-second field. You'd either have to start > allowing floating point tm_sec fields then either truncating or rounding > (but which?) to get ints when you need to actually generate an actual struct > tm. Right. I am in favour of this being just a datetime thing as we should get people moved off of time for stuff like this anyway. -Brett __________________________________ Tracker __________________________________ From report at bugs.python.org Thu Sep 13 21:45:01 2007 From: report at bugs.python.org (Stefan Sonnenberg-Carstens) Date: Thu, 13 Sep 2007 19:45:01 -0000 Subject: [issue1159] os.getenv() not updated after external module uses C putenv() Message-ID: <1189712701.56.0.190912722385.issue1159@psf.upfronthosting.co.za> Stefan Sonnenberg-Carstens added the comment: I'd like to see perl/ruby behaviour: an dict (os.environ), nothing more (perl %ENV,ruby $ENV). Get rid of setenv/putenv at all. 3.0a1 has even more: There is os.environ (a dict), os.[put|get]env() and os.environ.putenv() __________________________________ Tracker __________________________________ From report at bugs.python.org Thu Sep 13 21:58:00 2007 From: report at bugs.python.org (Georg Brandl) Date: Thu, 13 Sep 2007 19:58:00 -0000 Subject: [issue1145] Allow str.join to join non-string types (as per PEP 3100) In-Reply-To: <1189626313.43.0.672832148413.issue1145@psf.upfronthosting.co.za> Message-ID: <46E99655.9000108@gmx.net> Georg Brandl added the comment: Guido van Rossum schrieb: > Guido van Rossum added the comment: > > There's one additional issue. If any of the items is a bytes, the call > should fail. Should it really, even if the bytes is ascii-encodable? Georg ---------- nosy: +georg.brandl __________________________________ Tracker __________________________________ From report at bugs.python.org Thu Sep 13 22:44:44 2007 From: report at bugs.python.org (Jono DiCarlo) Date: Thu, 13 Sep 2007 20:44:44 -0000 Subject: [issue1163] Patch to make py3k/Lib/test/test_thread.py use unittest Message-ID: <1189716284.14.0.731587467816.issue1163@psf.upfronthosting.co.za> New submission from Jono DiCarlo: In the google spreadsheet for py3k tasks for the sprint last month, one of the listed tasks was to convert Lib/test/test_thread to use the unittest module, where it previously was using the old-style testing (i.e. comparing output of print statements to a text file). I'm attatching a patch that makes that change. This is my first time submitting a patch to Python, so please let me know if I'm doing anything wrong (or if this patch is redundant). ---------- components: Tests files: jdicarlo_stdlibtests_patch_sep7.diff messages: 55899 nosy: JonoDiCarlo severity: minor status: open title: Patch to make py3k/Lib/test/test_thread.py use unittest type: rfe versions: Python 3.0 __________________________________ Tracker __________________________________ -------------- next part -------------- A non-text attachment was scrubbed... Name: jdicarlo_stdlibtests_patch_sep7.diff Type: text/x-patch Size: 9757 bytes Desc: not available Url : http://mail.python.org/pipermail/python-bugs-list/attachments/20070913/febdae95/attachment-0001.bin From report at bugs.python.org Thu Sep 13 22:44:44 2007 From: report at bugs.python.org (Jono DiCarlo) Date: Thu, 13 Sep 2007 20:44:44 -0000 Subject: [issue1163] Patch to make py3k/Lib/test/test_thread.py use unittest Message-ID: <1189716284.14.0.731587467816.issue1163@psf.upfronthosting.co.za> New submission from Jono DiCarlo: In the google spreadsheet for py3k tasks for the sprint last month, one of the listed tasks was to convert Lib/test/test_thread to use the unittest module, where it previously was using the old-style testing (i.e. comparing output of print statements to a text file). I'm attatching a patch that makes that change. This is my first time submitting a patch to Python, so please let me know if I'm doing anything wrong (or if this patch is redundant). ---------- components: Tests files: jdicarlo_stdlibtests_patch_sep7.diff messages: 55899 nosy: JonoDiCarlo severity: minor status: open title: Patch to make py3k/Lib/test/test_thread.py use unittest type: rfe versions: Python 3.0 __________________________________ Tracker __________________________________ -------------- next part -------------- A non-text attachment was scrubbed... Name: jdicarlo_stdlibtests_patch_sep7.diff Type: text/x-patch Size: 9757 bytes Desc: not available Url : http://mail.python.org/pipermail/python-bugs-list/attachments/20070913/febdae95/attachment-0002.bin From report at bugs.python.org Thu Sep 13 23:41:13 2007 From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=) Date: Thu, 13 Sep 2007 21:41:13 -0000 Subject: [issue1163] Patch to make py3k/Lib/test/test_thread.py use unittest Message-ID: <1189719673.13.0.722243292863.issue1163@psf.upfronthosting.co.za> Changes by Martin v. L?wis: ---------- keywords: +patch __________________________________ Tracker __________________________________ From report at bugs.python.org Fri Sep 14 01:09:00 2007 From: report at bugs.python.org (Brett Cannon) Date: Thu, 13 Sep 2007 23:09:00 -0000 Subject: [issue416670] MatchObjects not deepcopy()able Message-ID: <1189724940.77.0.101073415123.issue416670@psf.upfronthosting.co.za> Changes by Brett Cannon: ---------- dependencies: +Fix #416670: register SRE types ____________________________________ Tracker ____________________________________ From report at bugs.python.org Fri Sep 14 01:11:35 2007 From: report at bugs.python.org (Brett Cannon) Date: Thu, 13 Sep 2007 23:11:35 -0000 Subject: [issue416670] MatchObjects not deepcopy()able Message-ID: <1189725095.54.0.885387789442.issue416670@psf.upfronthosting.co.za> Changes by Brett Cannon: ---------- dependencies: -Fix #416670: register SRE types ____________________________________ Tracker ____________________________________ From report at bugs.python.org Fri Sep 14 01:18:45 2007 From: report at bugs.python.org (Brett Cannon) Date: Thu, 13 Sep 2007 23:18:45 -0000 Subject: [issue487331] time mod's timezone doesn't honor TZ var Message-ID: <1189725525.45.0.122074160493.issue487331@psf.upfronthosting.co.za> Brett Cannon added the comment: time.tzset() was added in Python 2.3. Closing as fixed. ---------- nosy: +brett.cannon resolution: -> fixed status: open -> closed ____________________________________ Tracker ____________________________________ From report at bugs.python.org Fri Sep 14 01:23:09 2007 From: report at bugs.python.org (Brett Cannon) Date: Thu, 13 Sep 2007 23:23:09 -0000 Subject: [issue504152] rfc822 long header continuation broken Message-ID: <1189725789.99.0.63919408357.issue504152@psf.upfronthosting.co.za> Changes by Brett Cannon: ---------- keywords: +patch ____________________________________ Tracker ____________________________________ From report at bugs.python.org Fri Sep 14 01:41:39 2007 From: report at bugs.python.org (Brett Cannon) Date: Thu, 13 Sep 2007 23:41:39 -0000 Subject: [issue539444] asyncore file wrapper & os.error Message-ID: <1189726899.56.0.966997558217.issue539444@psf.upfronthosting.co.za> Brett Cannon added the comment: Following Josiah's advice and closing this as this has been sitting here long enough. ---------- nosy: +brett.cannon resolution: -> invalid status: open -> closed ____________________________________ Tracker ____________________________________ From report at bugs.python.org Fri Sep 14 01:44:05 2007 From: report at bugs.python.org (Brett Cannon) Date: Thu, 13 Sep 2007 23:44:05 -0000 Subject: [issue542314] long file name support broken in windows Message-ID: <1189727045.26.0.223964382202.issue542314@psf.upfronthosting.co.za> Brett Cannon added the comment: Can someone verify that the length issue has been fixed since Ptyhon 2.5? ---------- nosy: +brett.cannon ____________________________________ Tracker ____________________________________ From report at bugs.python.org Fri Sep 14 01:54:29 2007 From: report at bugs.python.org (Brett Cannon) Date: Thu, 13 Sep 2007 23:54:29 -0000 Subject: [issue614555] Rewrite _reduce and _reconstructor in C Message-ID: <1189727669.3.0.690822730903.issue614555@psf.upfronthosting.co.za> Brett Cannon added the comment: Classifying as an RFE since this is not critical (as shown by it not happening since early 2003). ---------- nosy: +brett.cannon type: -> rfe ____________________________________ Tracker ____________________________________ From report at bugs.python.org Fri Sep 14 01:59:28 2007 From: report at bugs.python.org (Brett Cannon) Date: Thu, 13 Sep 2007 23:59:28 -0000 Subject: [issue1083] Confusing error message when dividing timedelta using / Message-ID: <1189727968.75.0.586927886395.issue1083@psf.upfronthosting.co.za> Changes by Brett Cannon: ---------- keywords: +py3k versions: +Python 3.0 __________________________________ Tracker __________________________________ From report at bugs.python.org Fri Sep 14 02:10:16 2007 From: report at bugs.python.org (Brett Cannon) Date: Fri, 14 Sep 2007 00:10:16 -0000 Subject: [issue1083] Confusing error message when dividing timedelta using / Message-ID: <1189728616.19.0.0424066089391.issue1083@psf.upfronthosting.co.za> Brett Cannon added the comment: If you set nb_true_div on timedelta objects to delta_divide (just like nb_floor_div) you won't have this problem as the division will just work. Otherwise there is no other good way as if the divisor doesn't work you need to return NotImplemented, which then tries the right-hand object which fails, and 'object' returns the TypeError. Best you could do is a warning or something. But it might make sense to only set it on nb_true_div as the division does not round anything. ---------- nosy: +brett.cannon __________________________________ Tracker __________________________________ From report at bugs.python.org Fri Sep 14 02:20:26 2007 From: report at bugs.python.org (Robert Ancell) Date: Fri, 14 Sep 2007 00:20:26 -0000 Subject: [issue1159] os.getenv() not updated after external module uses C putenv() Message-ID: <1189729226.92.0.154996544042.issue1159@psf.upfronthosting.co.za> Robert Ancell added the comment: draghuram, unfortunately while os.putenv() can be fixed to be symmetrical any putenv call from a C module cannot, for example: If you make an extension: #include PyObject *putenvC(PyObject *module, PyObject *args) { int result; if (!PyArg_ParseTuple(args, "")) return 0; result = putenv("FOO=BAR"); return Py_BuildValue("i", result); } The following behaviour will occur: $ python >>> import putenv >>> putenv.putenvC() >>> assert(os.getenv('FOO') == None) >>> assert(os.environ.get('FOO') == None) This is because the os.environ dictionary will never be updated: >From Lib/os.py: def getenv(key, default=None): """Get an environment variable, return None if it doesn't exist. The optional second argument can specify an alternate default.""" return environ.get(key, default) __________________________________ Tracker __________________________________ From report at bugs.python.org Fri Sep 14 04:08:48 2007 From: report at bugs.python.org (Swaroop) Date: Fri, 14 Sep 2007 02:08:48 -0000 Subject: [issue1162] Python doesn't compile on Microsoft Visual Studio 2008 "Orcas" Beta 2 Message-ID: <1189735728.19.0.299772050261.issue1162@psf.upfronthosting.co.za> Swaroop added the comment: Hi Martin, I completely agree with you. I would like to get it working but would need some guidance on the build system... is there someone whose brains I can pick for this? :) Also, we can mark this issue as 'not a bug'? ---------- type: -> compile error __________________________________ Tracker __________________________________ From report at bugs.python.org Fri Sep 14 06:42:18 2007 From: report at bugs.python.org (Robert Ancell) Date: Fri, 14 Sep 2007 04:42:18 -0000 Subject: [issue1159] os.getenv() not updated after external module uses C putenv() Message-ID: <1189744938.07.0.311846256441.issue1159@psf.upfronthosting.co.za> Robert Ancell added the comment: I've attached proof-of-concept showing how os.environ would ideally work. It'll only work in Posix, etc etc. Reading into it more there are a lot of general issues with environments and memory allocation which is why I suspect Python doesn't use putenv... See putenv(3) for details. Compile with: gcc -shared -o environmodule.so -g -Wall -I /usr/include/python2.5 environmodule.c __________________________________ Tracker __________________________________ -------------- next part -------------- A non-text attachment was scrubbed... Name: environmodule.c Type: text/x-csrc Size: 4566 bytes Desc: not available Url : http://mail.python.org/pipermail/python-bugs-list/attachments/20070914/30335428/attachment.c From report at bugs.python.org Fri Sep 14 07:59:16 2007 From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=) Date: Fri, 14 Sep 2007 05:59:16 -0000 Subject: [issue1162] Python doesn't compile on Microsoft Visual Studio 2008 "Orcas" Beta 2 Message-ID: <1189749556.2.0.47977957386.issue1162@psf.upfronthosting.co.za> Martin v. L?wis added the comment: Ok, I'm closing this as "won't fix" now. If you want to look for help, ask on comp.lang.python. If you want some of the core developers to resolve this, be patient - in about a year, it should be resolved. If you ever come up with a patch, please submit this as a new report. ---------- resolution: -> wont fix type: compile error -> rfe __________________________________ Tracker __________________________________ From report at bugs.python.org Fri Sep 14 08:53:56 2007 From: report at bugs.python.org (Georg Brandl) Date: Fri, 14 Sep 2007 06:53:56 -0000 Subject: [issue1162] Python doesn't compile on Microsoft Visual Studio 2008 "Orcas" Beta 2 Message-ID: <1189752836.87.0.482906140532.issue1162@psf.upfronthosting.co.za> Changes by Georg Brandl: ---------- status: open -> closed __________________________________ Tracker __________________________________ From report at bugs.python.org Fri Sep 14 10:56:10 2007 From: report at bugs.python.org (Quentin Gallet-Gilles) Date: Fri, 14 Sep 2007 08:56:10 -0000 Subject: [issue1146] TextWrap vs words 1-character shorter than the width Message-ID: <1189760170.24.0.241704623447.issue1146@psf.upfronthosting.co.za> Quentin Gallet-Gilles added the comment: The bug is present in trunk and has been there since rev 33955. This revision contained a fix to an infinite loop when indentation was set longer than width with long word breaking enabled. In that case, it would strip off at least one character on every pass. The fix was however a bit too general, leading to the reported bug. The added patch makes sure this doesn't happen anymore when indentation isn't involved. ---------- nosy: +quentin.gallet-gilles __________________________________ Tracker __________________________________ -------------- next part -------------- A non-text attachment was scrubbed... Name: textwrap_r58153.diff Type: text/x-patch Size: 1772 bytes Desc: not available Url : http://mail.python.org/pipermail/python-bugs-list/attachments/20070914/9c39b95d/attachment-0001.bin From report at bugs.python.org Fri Sep 14 11:10:08 2007 From: report at bugs.python.org (Quentin Gallet-Gilles) Date: Fri, 14 Sep 2007 09:10:08 -0000 Subject: [issue1146] TextWrap vs words 1-character shorter than the width Message-ID: <1189761008.73.0.713298623526.issue1146@psf.upfronthosting.co.za> Quentin Gallet-Gilles added the comment: The previous patch is suboptimal and doesn't solve all cases. This one does. My apologies. __________________________________ Tracker __________________________________ From report at bugs.python.org Fri Sep 14 11:10:41 2007 From: report at bugs.python.org (Quentin Gallet-Gilles) Date: Fri, 14 Sep 2007 09:10:41 -0000 Subject: [issue1146] TextWrap vs words 1-character shorter than the width Message-ID: <1189761041.26.0.32164614604.issue1146@psf.upfronthosting.co.za> Changes by Quentin Gallet-Gilles: __________________________________ Tracker __________________________________ From report at bugs.python.org Fri Sep 14 13:01:22 2007 From: report at bugs.python.org (Georg Brandl) Date: Fri, 14 Sep 2007 11:01:22 -0000 Subject: [issue1146] TextWrap vs words 1-character shorter than the width Message-ID: <1189767682.25.0.424046268351.issue1146@psf.upfronthosting.co.za> Georg Brandl added the comment: I'll look at this shortly. ---------- assignee: -> georg.brandl nosy: +georg.brandl __________________________________ Tracker __________________________________ From report at bugs.python.org Fri Sep 14 17:37:33 2007 From: report at bugs.python.org (Raghuram Devarakonda) Date: Fri, 14 Sep 2007 15:37:33 -0000 Subject: [issue1159] os.getenv() not updated after external module uses C putenv() In-Reply-To: <1189729226.92.0.154996544042.issue1159@psf.upfronthosting.co.za> Message-ID: <2c51ecee0709140837j69cfe400yef66ef822b61f5bb@mail.gmail.com> Raghuram Devarakonda added the comment: > Robert Ancell added the comment: > > draghuram, unfortunately while os.putenv() can be fixed to be > symmetrical any putenv call from a C module cannot, for example: Hi Robert, I understood the problem from your very first report. I brought up putenv() not updating os.environ only because you mentioned in the original report that it does. All you need is a way to get the current value of an environment variable. The situation is a bit complicated since a cache is in the picture (os.environ). I would suggest that you bring up the topic for discussion on python-dev and once a consensus is reached, some one can come up with a patch (I can try). __________________________________ Tracker __________________________________ From report at bugs.python.org Fri Sep 14 21:21:37 2007 From: report at bugs.python.org (Armin Rigo) Date: Fri, 14 Sep 2007 19:21:37 -0000 Subject: [issue1164] tp_print slots don't release the GIL Message-ID: <1189797697.47.0.24596093087.issue1164@psf.upfronthosting.co.za> New submission from Armin Rigo: The tp_print slots, used by 'print' statements, don't release the GIL while writing into the C-level file. This is not only a missing opportunity, but can cause unexpected deadlocks, as shown in the attached file. ---------- components: Interpreter Core files: deadlock1.py messages: 55913 nosy: arigo severity: normal status: open title: tp_print slots don't release the GIL type: behavior __________________________________ Tracker __________________________________ -------------- next part -------------- A non-text attachment was scrubbed... Name: deadlock1.py Type: text/x-python Size: 288 bytes Desc: not available Url : http://mail.python.org/pipermail/python-bugs-list/attachments/20070914/487f9221/attachment.py From report at bugs.python.org Fri Sep 14 21:21:37 2007 From: report at bugs.python.org (Armin Rigo) Date: Fri, 14 Sep 2007 19:21:37 -0000 Subject: [issue1164] tp_print slots don't release the GIL Message-ID: <1189797697.47.0.24596093087.issue1164@psf.upfronthosting.co.za> New submission from Armin Rigo: The tp_print slots, used by 'print' statements, don't release the GIL while writing into the C-level file. This is not only a missing opportunity, but can cause unexpected deadlocks, as shown in the attached file. ---------- components: Interpreter Core files: deadlock1.py messages: 55913 nosy: arigo severity: normal status: open title: tp_print slots don't release the GIL type: behavior __________________________________ Tracker __________________________________ -------------- next part -------------- A non-text attachment was scrubbed... Name: deadlock1.py Type: text/x-python Size: 288 bytes Desc: not available Url : http://mail.python.org/pipermail/python-bugs-list/attachments/20070914/487f9221/attachment-0001.py From report at bugs.python.org Fri Sep 14 21:33:58 2007 From: report at bugs.python.org (Guido van Rossum) Date: Fri, 14 Sep 2007 19:33:58 -0000 Subject: [issue1145] Allow str.join to join non-string types (as per PEP 3100) Message-ID: <1189798438.05.0.7168204982.issue1145@psf.upfronthosting.co.za> Guido van Rossum added the comment: > Should it really, even if the bytes is ascii-encodable? Yes, really. We don't want to open up the same can of worms that made working with Unicode such a pain in 2.x. __________________________________ Tracker __________________________________ From report at bugs.python.org Fri Sep 14 21:40:49 2007 From: report at bugs.python.org (Guido van Rossum) Date: Fri, 14 Sep 2007 19:40:49 -0000 Subject: [issue1156] Suggested change to _exit function description in os module documentation Message-ID: <1189798849.45.0.259421590514.issue1156@psf.upfronthosting.co.za> Guido van Rossum added the comment: > Should "child" be replaced with "parent"? No. I'm pretty much I wrote that. The use case I was thinking of is the error handling in the child process after the exec fails. if you were to use sys.exit() there, which raises SystemExit, you're likely to hit various exception handlers that were set up in the parent, and you even run the risk of some main loop continuing *in the child*. I've had many a program produce the phenomenon of "double tracebacks" due to this mistake. OTOH, in the parent, if you want to exit after forking (e.g. to create a parent-less daemon process), a regular sys.exit() is usually just fine, as any exception handlers you might trigger were meant to be triggered. ---------- nosy: +gvanrossum resolution: -> rejected status: open -> closed __________________________________ Tracker __________________________________ From report at bugs.python.org Fri Sep 14 21:44:54 2007 From: report at bugs.python.org (Guido van Rossum) Date: Fri, 14 Sep 2007 19:44:54 -0000 Subject: [issue1160] Medium size regexp crashes python Message-ID: <1189799094.58.0.159160346465.issue1160@psf.upfronthosting.co.za> Guido van Rossum added the comment: /F? ---------- assignee: -> effbot nosy: +effbot, gvanrossum __________________________________ Tracker __________________________________ From report at bugs.python.org Fri Sep 14 21:48:12 2007 From: report at bugs.python.org (Guido van Rossum) Date: Fri, 14 Sep 2007 19:48:12 -0000 Subject: [issue1161] Garbled chars in offending line of SyntaxError traceback Message-ID: <1189799292.59.0.214652775516.issue1161@psf.upfronthosting.co.za> Guido van Rossum added the comment: I can't quite reproduce this, but I do see there's a problem with the syntax error reporting: Python 3.0a1 (py3k, Sep 12 2007, 12:23:06) [GCC 4.0.3 (Ubuntu 4.0.3-1ubuntu5)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> asd asd File "", line 1 >>> ---------- nosy: +gvanrossum __________________________________ Tracker __________________________________ From report at bugs.python.org Fri Sep 14 21:53:26 2007 From: report at bugs.python.org (Guido van Rossum) Date: Fri, 14 Sep 2007 19:53:26 -0000 Subject: [issue1163] Patch to make py3k/Lib/test/test_thread.py use unittest Message-ID: <1189799606.27.0.516672952439.issue1163@psf.upfronthosting.co.za> Guido van Rossum added the comment: This is a good start, but I think that instead of using global variables and functions, you should try to turn all those into instance variables (of the ThreadTest class). That way the tests are truly independent. Initialization should be taken care of in setUp(). ---------- nosy: +gvanrossum __________________________________ Tracker __________________________________ From report at bugs.python.org Fri Sep 14 22:07:16 2007 From: report at bugs.python.org (Thomas Heller) Date: Fri, 14 Sep 2007 20:07:16 -0000 Subject: [issue1777530] ctypes on Solaris Message-ID: <1189800436.91.0.828399750997.issue1777530@psf.upfronthosting.co.za> Thomas Heller added the comment: Fixed in SVN: trunk rev 58155, release25-maint rev 58158. Thanks. ---------- resolution: -> fixed status: open -> closed _____________________________________ Tracker _____________________________________ From report at bugs.python.org Fri Sep 14 23:37:55 2007 From: report at bugs.python.org (Brett Cannon) Date: Fri, 14 Sep 2007 21:37:55 -0000 Subject: [issue1164] tp_print slots don't release the GIL Message-ID: <1189805875.37.0.669475002381.issue1164@psf.upfronthosting.co.za> Brett Cannon added the comment: I quickly handled the GIL for lists and ints in their tp_print functions and your example still deadlocked. Don't have time to dig deeper right now, but what more are you suggesting be done? ---------- nosy: +brett.cannon __________________________________ Tracker __________________________________ From report at bugs.python.org Fri Sep 14 23:58:03 2007 From: report at bugs.python.org (Johann Tonsing) Date: Fri, 14 Sep 2007 21:58:03 -0000 Subject: [issue1156] Suggested change to _exit function description in os module documentation Message-ID: <1189807083.39.0.483988016143.issue1156@psf.upfronthosting.co.za> Johann Tonsing added the comment: Thanks for explaining. (FWIW I reported this because several examples / recipes I saw elsewhere on the net used os._exit() in the parent. Perhaps they did this because they don't want to disrupt resources like file descriptors which the child has inherited or something.) __________________________________ Tracker __________________________________ From report at bugs.python.org Sat Sep 15 00:24:15 2007 From: report at bugs.python.org (Humberto Diogenes) Date: Fri, 14 Sep 2007 22:24:15 -0000 Subject: [issue1099] Mac compile fails with pydebug and framework enabled Message-ID: <1189808655.92.0.38697191042.issue1099@psf.upfronthosting.co.za> Humberto Diogenes added the comment: I'm using these versions: intel: macosx 10.4.10, xcode 2.4.1 (gcc 4.0.1 build 5367) Tried again with current revision (58153) and with --enable-universalsdk it built just fine. Without it, I still get the same error. __________________________________ Tracker __________________________________ From report at bugs.python.org Sat Sep 15 04:00:29 2007 From: report at bugs.python.org (Mark Hammond) Date: Sat, 15 Sep 2007 02:00:29 -0000 Subject: [issue542314] long file name support broken in windows Message-ID: <1189821629.57.0.963966151955.issue542314@psf.upfronthosting.co.za> Mark Hammond added the comment: I can confirm the code in question was removed and that long filenames are possible in 2.5. Eg: import os p = "\\\\?\\" + os.getcwdu() for i in range(10): p = os.path.join(p, 'x' * 100) os.mkdir(p) os.stat(p) print len(p) I don't think Python should try and hide this madness, so I'm marking it as closed. ---------- resolution: -> fixed status: open -> closed ____________________________________ Tracker ____________________________________ From report at bugs.python.org Sat Sep 15 05:32:57 2007 From: report at bugs.python.org (=?utf-8?q?=0A=09=09=09=09=09Hirokazu_Yamamoto=0A=09=09=09=09?=) Date: Sat, 15 Sep 2007 03:32:57 -0000 Subject: [issue1135] xview/yview of Tix.Grid is broken Message-ID: <1189827177.01.0.29837502146.issue1135@psf.upfronthosting.co.za> Changes by Hirokazu Yamamoto : ---------- versions: +Python 2.6 __________________________________ Tracker __________________________________ From report at bugs.python.org Sat Sep 15 06:06:42 2007 From: report at bugs.python.org (=?utf-8?q?=0A=09=09=09=09=09Mark_Dickinson=0A=09=09=09=09?=) Date: Sat, 15 Sep 2007 04:06:42 -0000 Subject: [issue1772851] Decimal and long hash, compatibly and efficiently Message-ID: <1189829202.72.0.980292283083.issue1772851@psf.upfronthosting.co.za> Mark Dickinson added the comment: Here's a revised patch, that only touches longobject.c and does the minimum necessary to alter long.__hash__ from being *almost* completely predictable to being completely predictable. To summarize the effects of this patch: - the current long.__hash__ is predictable except for a very small number of (unpredictable) inputs; this patch makes it predictable for all inputs, thereby making it possible to define an efficient Decimal.__hash__. To be precise, the patched long.__hash__ has the property that it's periodic of period ULONG_MAX in the ranges [1, infinity) and (-infinity, -1]. - the value of hash(n) is unchanged for any n that's small enough to be representable as an int, and also unchanged for the vast majority of long integers n of reasonable size. (For integers up to 450 digits long, the new hash value differs from the old for around 1 in every 2500 integers on a 32-bit system; on a 64-bit system the figure is 1 in every 10000 billion.) - On my test system (Dual Xeon 2.8GHz/SuSE Linux 10.2/gcc 4.1), using timeit.timeit('hash(n)') there's no measurable slowdown for small integers. Unfortunately there *is* slowdown for larger integers: around 20% slowdown for 100 digit integers and around 70% extra time for 1000 digit integers, though in all cases the times are in fractions of a microsecond. It doesn't help that gcc doesn't optimize the inner loop perfectly: with the -O3 flag, the addition and subsequent correction are compiled to (with x in eax and v->ob_digit[i] in edx): addl %eax, %edx cmpl %eax, %edx adcl $0, %edx and the cmpl here is entirely redundant. Maybe there's some way of writing the C code that makes it easier for gcc to pick up on this optimization? _____________________________________ Tracker _____________________________________ -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: long_hash.patch Url: http://mail.python.org/pipermail/python-bugs-list/attachments/20070915/a65c8b9f/attachment.txt From report at bugs.python.org Sat Sep 15 06:07:43 2007 From: report at bugs.python.org (=?utf-8?q?=0A=09=09=09=09=09Mark_Dickinson=0A=09=09=09=09?=) Date: Sat, 15 Sep 2007 04:07:43 -0000 Subject: [issue1772851] Decimal and long hash, compatibly and efficiently Message-ID: <1189829263.02.0.569694598971.issue1772851@psf.upfronthosting.co.za> Mark Dickinson added the comment: And here's the updated decimal.__hash__ patch that goes with the long.__hash__ patch. _____________________________________ Tracker _____________________________________ -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: decimal_hash_v2.patch Url: http://mail.python.org/pipermail/python-bugs-list/attachments/20070915/2cb64d2a/attachment.txt From report at bugs.python.org Sat Sep 15 10:30:12 2007 From: report at bugs.python.org (Armin Rigo) Date: Sat, 15 Sep 2007 08:30:12 -0000 Subject: [issue1164] tp_print slots don't release the GIL Message-ID: <1189845012.18.0.975747896195.issue1164@psf.upfronthosting.co.za> Armin Rigo added the comment: We need to start from PyFile_WriteString() and PyFile_WriteObject() and PyObject_Print(), which are what the PRINT_* opcodes use, and make sure there is no single fprintf() or fputs() that occurs with the GIL held. It is not enough to fix a few places that could clearly write a lot of data, because even if there is just one place left where the GIL is not released it could be precisely where the OS decides to block, causing a deadlock. __________________________________ Tracker __________________________________ From report at bugs.python.org Sat Sep 15 17:19:47 2007 From: report at bugs.python.org (Eduardo Padoan) Date: Sat, 15 Sep 2007 15:19:47 -0000 Subject: [issue1165] Should itertools.count work for arbitrary integers? Message-ID: <1189869587.07.0.169329623403.issue1165@psf.upfronthosting.co.za> New submission from Eduardo Padoan: Currently, itertools.count.__next__ checks wether the current value is > PY_SSIZE_T_MAX and raises OverflowError if so. Shouldn't the value be stored as "long", at least in Py3k? Not that I have any use case for it, so it is minor. ---------- components: Library (Lib) messages: 55927 nosy: eopadoan severity: minor status: open title: Should itertools.count work for arbitrary integers? type: behavior versions: Python 3.0 __________________________________ Tracker __________________________________ From report at bugs.python.org Sat Sep 15 17:19:47 2007 From: report at bugs.python.org (Eduardo Padoan) Date: Sat, 15 Sep 2007 15:19:47 -0000 Subject: [issue1165] Should itertools.count work for arbitrary integers? Message-ID: <1189869587.07.0.169329623403.issue1165@psf.upfronthosting.co.za> New submission from Eduardo Padoan: Currently, itertools.count.__next__ checks wether the current value is > PY_SSIZE_T_MAX and raises OverflowError if so. Shouldn't the value be stored as "long", at least in Py3k? Not that I have any use case for it, so it is minor. ---------- components: Library (Lib) messages: 55927 nosy: eopadoan severity: minor status: open title: Should itertools.count work for arbitrary integers? type: behavior versions: Python 3.0 __________________________________ Tracker __________________________________ From report at bugs.python.org Sat Sep 15 17:27:31 2007 From: report at bugs.python.org (Eric S. R-eyyyy-mond) Date: Sat, 15 Sep 2007 15:27:31 -0000 Subject: [issue1165] Should itertools.count work for arbitrary integers? Message-ID: <1189870051.76.0.423210869887.issue1165@psf.upfronthosting.co.za> Eric S. R-eyyyy-mond added the comment: Hi guys. ---------- assignee: -> esr nosy: +esr __________________________________ Tracker __________________________________ From report at bugs.python.org Sat Sep 15 17:29:02 2007 From: report at bugs.python.org (Eric S. R-eyyyy-mond) Date: Sat, 15 Sep 2007 15:29:02 -0000 Subject: [issue1165] Should itertools.count work for arbitrary integers? Message-ID: <1189870142.63.0.677458500733.issue1165@psf.upfronthosting.co.za> Changes by Eric S. R-eyyyy-mond: ---------- severity: minor -> critical __________________________________ Tracker __________________________________ From report at bugs.python.org Sat Sep 15 17:29:37 2007 From: report at bugs.python.org (Eric S. R-eyyyy-mond) Date: Sat, 15 Sep 2007 15:29:37 -0000 Subject: [issue1165] Should itertools.count work for arbitrary integers? Message-ID: <1189870177.29.0.323455726846.issue1165@psf.upfronthosting.co.za> Changes by Eric S. R-eyyyy-mond: ---------- keywords: +r-eyyy-mond __________________________________ Tracker __________________________________ From report at bugs.python.org Sat Sep 15 17:30:04 2007 From: report at bugs.python.org (Eric S. R-eyyyy-mond) Date: Sat, 15 Sep 2007 15:30:04 -0000 Subject: [issue1165] Should itertools.count work for arbitrary integers? Message-ID: <1189870204.46.0.153892023944.issue1165@psf.upfronthosting.co.za> Changes by Eric S. R-eyyyy-mond: ---------- versions: +3rd party, Python 2.1.1, Python 2.1.2, Python 2.2, Python 2.2.1, Python 2.2.2, Python 2.2.3, Python 2.3, Python 2.4, Python 2.5, Python 2.6 __________________________________ Tracker __________________________________ From report at bugs.python.org Sat Sep 15 17:30:10 2007 From: report at bugs.python.org (Eric S. R-eyyyy-mond) Date: Sat, 15 Sep 2007 15:30:10 -0000 Subject: [issue1165] Should itertools.count work for arbitrary integers? Message-ID: <1189870210.97.0.895021061771.issue1165@psf.upfronthosting.co.za> Changes by Eric S. R-eyyyy-mond: ---------- type: behavior -> compile error __________________________________ Tracker __________________________________ From report at bugs.python.org Sat Sep 15 17:30:55 2007 From: report at bugs.python.org (Eric S. R-eyyyy-mond) Date: Sat, 15 Sep 2007 15:30:55 -0000 Subject: [issue1165] Should itertools.count work for arbitrary integers? Message-ID: <1189870255.69.0.0541639902887.issue1165@psf.upfronthosting.co.za> Changes by Eric S. R-eyyyy-mond: ---------- dependencies: +--install-base not honored on win32 type: compile error -> behavior versions: -3rd party, Python 2.1.1, Python 2.1.2, Python 2.2, Python 2.2.1, Python 2.2.2, Python 2.2.3, Python 2.3, Python 2.4, Python 2.5, Python 2.6 __________________________________ Tracker __________________________________ From report at bugs.python.org Sat Sep 15 17:31:10 2007 From: report at bugs.python.org (Eric S. R-eyyyy-mond) Date: Sat, 15 Sep 2007 15:31:10 -0000 Subject: [issue1165] Should itertools.count work for arbitrary integers? Message-ID: <1189870270.97.0.859896387271.issue1165@psf.upfronthosting.co.za> Changes by Eric S. R-eyyyy-mond: ---------- dependencies: + Elemental Security contribution - pgen2 package __________________________________ Tracker __________________________________ From report at bugs.python.org Sat Sep 15 17:32:00 2007 From: report at bugs.python.org (Eric S. R-eyyyy-mond) Date: Sat, 15 Sep 2007 15:32:00 -0000 Subject: [issue1166] NameError when calling malloc Message-ID: <1189870320.85.0.870817039772.issue1166@psf.upfronthosting.co.za> New submission from Eric S. R-eyyyy-mond: I tried this code, and it blew up in my face. >>> foo = malloc(4096) NameError: name 'malloc' is not defined Why? ---------- components: Library (Lib) keywords: r-eyyy-mond messages: 55929 nosy: esr priority: high severity: normal status: open title: NameError when calling malloc type: behavior versions: Python 2.4 __________________________________ Tracker __________________________________ From report at bugs.python.org Sat Sep 15 17:32:00 2007 From: report at bugs.python.org (Eric S. R-eyyyy-mond) Date: Sat, 15 Sep 2007 15:32:00 -0000 Subject: [issue1166] NameError when calling malloc Message-ID: <1189870320.85.0.870817039772.issue1166@psf.upfronthosting.co.za> New submission from Eric S. R-eyyyy-mond: I tried this code, and it blew up in my face. >>> foo = malloc(4096) NameError: name 'malloc' is not defined Why? ---------- components: Library (Lib) keywords: r-eyyy-mond messages: 55929 nosy: esr priority: high severity: normal status: open title: NameError when calling malloc type: behavior versions: Python 2.4 __________________________________ Tracker __________________________________ From report at bugs.python.org Sat Sep 15 20:59:13 2007 From: report at bugs.python.org (Guido van Rossum) Date: Sat, 15 Sep 2007 18:59:13 -0000 Subject: [issue1164] tp_print slots don't release the GIL Message-ID: <1189882753.2.0.836214173626.issue1164@psf.upfronthosting.co.za> Guido van Rossum added the comment: Plese do submit a patch. FWIW I think it's solved in Py3k, the tp_print slot is dead (as is any use of the C stdio library). ---------- nosy: +gvanrossum __________________________________ Tracker __________________________________ From report at bugs.python.org Sat Sep 15 23:34:56 2007 From: report at bugs.python.org (Brett Cannon) Date: Sat, 15 Sep 2007 21:34:56 -0000 Subject: [issue1164] tp_print slots don't release the GIL Message-ID: <1189892096.91.0.988205053914.issue1164@psf.upfronthosting.co.za> Changes by Brett Cannon: ---------- versions: +Python 2.6 __________________________________ Tracker __________________________________ From report at bugs.python.org Sat Sep 15 23:34:47 2007 From: report at bugs.python.org (Brett Cannon) Date: Sat, 15 Sep 2007 21:34:47 -0000 Subject: [issue1164] tp_print slots don't release the GIL Message-ID: <1189892087.33.0.583350854064.issue1164@psf.upfronthosting.co.za> Brett Cannon added the comment: Since I already did this once I just did a more thorough job; patch is attached. PyObject_WriteString() just calls PyFile_WriteObject() which ends up using PyObject_Print(), so it is was simple to handle those cases. I then released the GIL for strings, lists, and ints. That is enough to pass Armin's deadlock test. If the approach I am taking is OK with people and I can go through Object/*.c and do the proper thing for all the various object types for fprintf(), fputs(), fputc() and fwrite() (while skipping all of the debug output stuff) before committing the changes. __________________________________ Tracker __________________________________ -------------- next part -------------- A non-text attachment was scrubbed... Name: release_GIL_around_stdout.diff Type: application/octet-stream Size: 3409 bytes Desc: not available Url : http://mail.python.org/pipermail/python-bugs-list/attachments/20070915/88141e5c/attachment.obj From report at bugs.python.org Sat Sep 15 23:35:10 2007 From: report at bugs.python.org (Brett Cannon) Date: Sat, 15 Sep 2007 21:35:10 -0000 Subject: [issue1164] tp_print slots don't release the GIL Message-ID: <1189892110.45.0.248258359141.issue1164@psf.upfronthosting.co.za> Changes by Brett Cannon: ---------- keywords: +patch __________________________________ Tracker __________________________________ From report at bugs.python.org Sun Sep 16 00:22:09 2007 From: report at bugs.python.org (Alexey Suda-Chen) Date: Sat, 15 Sep 2007 22:22:09 -0000 Subject: [issue1134] Parsing a simple script eats all of your memory Message-ID: <1189894929.23.0.107175436672.issue1134@psf.upfronthosting.co.za> Alexey Suda-Chen added the comment: --- tokenizer.c (revision 58161) +++ tokenizer.c (working copy) @@ -402,6 +402,8 @@ if (allocated) { Py_DECREF(bufobj); } + Py_XDECREF(tok->decoding_buffer); + tok->decoding_buffer = 0; return s; ---------- nosy: +alexeychen __________________________________ Tracker __________________________________ From report at bugs.python.org Sun Sep 16 00:30:16 2007 From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=) Date: Sat, 15 Sep 2007 22:30:16 -0000 Subject: [issue1165] Should itertools.count work for arbitrary integers? Message-ID: <1189895416.05.0.489316669779.issue1165@psf.upfronthosting.co.za> Changes by Martin v. L?wis: ---------- assignee: esr -> __________________________________ Tracker __________________________________ From report at bugs.python.org Sun Sep 16 00:30:25 2007 From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=) Date: Sat, 15 Sep 2007 22:30:25 -0000 Subject: [issue1165] Should itertools.count work for arbitrary integers? Message-ID: <1189895425.68.0.168808774351.issue1165@psf.upfronthosting.co.za> Changes by Martin v. L?wis: ---------- keywords: +patch -r-eyyy-mond __________________________________ Tracker __________________________________ From report at bugs.python.org Sun Sep 16 00:31:03 2007 From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=) Date: Sat, 15 Sep 2007 22:31:03 -0000 Subject: [issue1165] Should itertools.count work for arbitrary integers? Message-ID: <1189895463.04.0.394988652508.issue1165@psf.upfronthosting.co.za> Changes by Martin v. L?wis: ---------- dependencies: - Elemental Security contribution - pgen2 package, --install-base not honored on win32 __________________________________ Tracker __________________________________ From report at bugs.python.org Sun Sep 16 00:31:11 2007 From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=) Date: Sat, 15 Sep 2007 22:31:11 -0000 Subject: [issue1165] Should itertools.count work for arbitrary integers? Message-ID: <1189895471.96.0.984872867988.issue1165@psf.upfronthosting.co.za> Changes by Martin v. L?wis: ---------- keywords: +py3k -patch __________________________________ Tracker __________________________________ From report at bugs.python.org Sun Sep 16 00:33:02 2007 From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=) Date: Sat, 15 Sep 2007 22:33:02 -0000 Subject: [issue1166] NameError when calling malloc Message-ID: <1189895582.06.0.817696932453.issue1166@psf.upfronthosting.co.za> Martin v. L?wis added the comment: I doubt you are esr, although I'm uncertain how you hijacked his account. Please stop spamming this tracker. ---------- nosy: +loewis resolution: -> invalid status: open -> closed __________________________________ Tracker __________________________________ From report at bugs.python.org Sun Sep 16 02:17:02 2007 From: report at bugs.python.org (Brett Cannon) Date: Sun, 16 Sep 2007 00:17:02 -0000 Subject: [issue1134] Parsing a simple script eats all of your memory Message-ID: <1189901822.73.0.891620551926.issue1134@psf.upfronthosting.co.za> Brett Cannon added the comment: Note the patch is inlined in a message. ---------- keywords: +patch, py3k nosy: +brett.cannon __________________________________ Tracker __________________________________ From report at bugs.python.org Sun Sep 16 04:19:01 2007 From: report at bugs.python.org (Guido van Rossum) Date: Sun, 16 Sep 2007 02:19:01 -0000 Subject: [issue1164] tp_print slots don't release the GIL Message-ID: <1189909141.08.0.147655949454.issue1164@psf.upfronthosting.co.za> Guido van Rossum added the comment: Looks Good, except I think it's a bad idea to release/acquire the GIL for each character when writing the repr() of a string. Given that the string is immutable and its refcount kept alive by the caller I don't see a reason why you can't just reference the object without holding the GIL. (Also you might want to copy the size into a local variable, it won't change...) __________________________________ Tracker __________________________________ From report at bugs.python.org Sun Sep 16 04:34:21 2007 From: report at bugs.python.org (Paul F. Dubois) Date: Sun, 16 Sep 2007 02:34:21 -0000 Subject: [issue1165] Should itertools.count work for arbitrary integers? Message-ID: <1189910061.31.0.332719001131.issue1165@psf.upfronthosting.co.za> Changes by Paul F. Dubois: __________________________________ Tracker __________________________________ From report at bugs.python.org Sun Sep 16 04:34:59 2007 From: report at bugs.python.org (Paul F. Dubois) Date: Sun, 16 Sep 2007 02:34:59 -0000 Subject: [issue1165] Should itertools.count work for arbitrary integers? Message-ID: <1189910099.53.0.290606103701.issue1165@psf.upfronthosting.co.za> Changes by Paul F. Dubois: ---------- nosy: -esr __________________________________ Tracker __________________________________ From report at bugs.python.org Sun Sep 16 04:57:41 2007 From: report at bugs.python.org (Brett Cannon) Date: Sun, 16 Sep 2007 02:57:41 -0000 Subject: [issue1164] tp_print slots don't release the GIL Message-ID: <1189911461.3.0.392091414899.issue1164@psf.upfronthosting.co.za> Brett Cannon added the comment: Good point. I changed it on my machine and it cut that whole section down to a single release/acquire. I will go ahead and do this for the other types and then upload another patch to be reviewed when it's ready. __________________________________ Tracker __________________________________ From report at bugs.python.org Sun Sep 16 05:37:32 2007 From: report at bugs.python.org (Brett Cannon) Date: Sun, 16 Sep 2007 03:37:32 -0000 Subject: [issue1164] tp_print slots don't release the GIL Message-ID: <1189913852.7.0.416656713166.issue1164@psf.upfronthosting.co.za> Brett Cannon added the comment: OK, every PyTypeObject in Objects and Modules has its tp_print release the GIL. Once someone OKs the patch I will apply it. __________________________________ Tracker __________________________________ -------------- next part -------------- A non-text attachment was scrubbed... Name: GIL_release_tp_print.diff Type: application/octet-stream Size: 9004 bytes Desc: not available Url : http://mail.python.org/pipermail/python-bugs-list/attachments/20070916/8647b2b3/attachment.obj From report at bugs.python.org Sun Sep 16 07:08:44 2007 From: report at bugs.python.org (sligocki) Date: Sun, 16 Sep 2007 05:08:44 -0000 Subject: [issue1727780] 64/32-bit issue when unpickling random.Random Message-ID: <1189919324.54.0.450122996136.issue1727780@psf.upfronthosting.co.za> Changes by sligocki: ---------- versions: +Python 2.5 -Python 2.4 _____________________________________ Tracker _____________________________________ From report at bugs.python.org Sun Sep 16 07:14:41 2007 From: report at bugs.python.org (sligocki) Date: Sun, 16 Sep 2007 05:14:41 -0000 Subject: [issue1727780] 64/32-bit issue when unpickling random.Random Message-ID: <1189919681.59.0.303789648609.issue1727780@psf.upfronthosting.co.za> sligocki added the comment: I've had this same problem with 2.5.1 Pickling random.getstate() on 64bit and then loading it back with random.setstate() on 32bit does not work (crashes because of trying cast 64bit ints to 32bit). The other way around is even worse. It loads but is in a faulty state, where for example: >>> random.randrange(1000) 49801980494 This seems like a bug to me. ---------- nosy: +sligocki _____________________________________ Tracker _____________________________________ From report at bugs.python.org Sun Sep 16 07:37:52 2007 From: report at bugs.python.org (Ian Kelly) Date: Sun, 16 Sep 2007 05:37:52 -0000 Subject: [issue1167] gdbm/ndbm 1.8.1+ needs libgdbm_compat.so Message-ID: <1189921072.53.0.557521657427.issue1167@psf.upfronthosting.co.za> New submission from Ian Kelly: The ndbm functions in gdbm 1.8.1+ require the gdbm_compat library in addition to gdbm. ---------- components: Build, Extension Modules files: gdbm_ndbm.diff messages: 55939 nosy: ikelly severity: normal status: open title: gdbm/ndbm 1.8.1+ needs libgdbm_compat.so type: compile error versions: Python 2.5, Python 2.6, Python 3.0 __________________________________ Tracker __________________________________ -------------- next part -------------- A non-text attachment was scrubbed... Name: gdbm_ndbm.diff Type: application/octet-stream Size: 1019 bytes Desc: not available Url : http://mail.python.org/pipermail/python-bugs-list/attachments/20070916/7067ae9e/attachment.obj From report at bugs.python.org Sun Sep 16 07:37:52 2007 From: report at bugs.python.org (Ian Kelly) Date: Sun, 16 Sep 2007 05:37:52 -0000 Subject: [issue1167] gdbm/ndbm 1.8.1+ needs libgdbm_compat.so Message-ID: <1189921072.53.0.557521657427.issue1167@psf.upfronthosting.co.za> New submission from Ian Kelly: The ndbm functions in gdbm 1.8.1+ require the gdbm_compat library in addition to gdbm. ---------- components: Build, Extension Modules files: gdbm_ndbm.diff messages: 55939 nosy: ikelly severity: normal status: open title: gdbm/ndbm 1.8.1+ needs libgdbm_compat.so type: compile error versions: Python 2.5, Python 2.6, Python 3.0 __________________________________ Tracker __________________________________ -------------- next part -------------- A non-text attachment was scrubbed... Name: gdbm_ndbm.diff Type: application/octet-stream Size: 1019 bytes Desc: not available Url : http://mail.python.org/pipermail/python-bugs-list/attachments/20070916/7067ae9e/attachment-0003.obj From report at bugs.python.org Sun Sep 16 09:31:20 2007 From: report at bugs.python.org (Nusret BALCI) Date: Sun, 16 Sep 2007 07:31:20 -0000 Subject: [issue1168] complex arithmetic: strange results with "imag" Message-ID: <1189927880.3.0.518995379378.issue1168@psf.upfronthosting.co.za> New submission from Nusret BALCI: "imag" returns incorrect results if invoked on a literal number. Looks like a bug. >>> 1-2j (1-2j) >>> 1-2j.real 1.0 >>> 1-2j.imag -1.0 >>> 1-4j.imag -3.0 >>> (1-4j).imag -4.0 >>> ---------- messages: 55940 nosy: newman severity: normal status: open title: complex arithmetic: strange results with "imag" type: behavior versions: Python 2.5, Python 3.0 __________________________________ Tracker __________________________________ From report at bugs.python.org Sun Sep 16 09:31:20 2007 From: report at bugs.python.org (Nusret BALCI) Date: Sun, 16 Sep 2007 07:31:20 -0000 Subject: [issue1168] complex arithmetic: strange results with "imag" Message-ID: <1189927880.3.0.518995379378.issue1168@psf.upfronthosting.co.za> New submission from Nusret BALCI: "imag" returns incorrect results if invoked on a literal number. Looks like a bug. >>> 1-2j (1-2j) >>> 1-2j.real 1.0 >>> 1-2j.imag -1.0 >>> 1-4j.imag -3.0 >>> (1-4j).imag -4.0 >>> ---------- messages: 55940 nosy: newman severity: normal status: open title: complex arithmetic: strange results with "imag" type: behavior versions: Python 2.5, Python 3.0 __________________________________ Tracker __________________________________ From report at bugs.python.org Sun Sep 16 10:13:23 2007 From: report at bugs.python.org (Gabriel Genellina) Date: Sun, 16 Sep 2007 08:13:23 -0000 Subject: [issue1168] complex arithmetic: strange results with "imag" Message-ID: <1189930403.15.0.503102909059.issue1168@psf.upfronthosting.co.za> Gabriel Genellina added the comment: Note that there are no complex literals in Python, only imaginary literals. 1-4j is an expression, not a literal. So 1-4j.imag means 1-(4j.imag) = 1-4 = -3 See http://docs.python.org/ref/numbers.html#l2h-16 (I'd close this as not a bug) ---------- nosy: +gagenellina __________________________________ Tracker __________________________________ From report at bugs.python.org Sun Sep 16 10:19:54 2007 From: report at bugs.python.org (Georg Brandl) Date: Sun, 16 Sep 2007 08:19:54 -0000 Subject: [issue1168] complex arithmetic: strange results with "imag" In-Reply-To: <1189930403.15.0.503102909059.issue1168@psf.upfronthosting.co.za> Message-ID: <46ECE734.8080809@gmx.net> Georg Brandl added the comment: Exactly. ---------- nosy: +georg.brandl resolution: -> invalid status: open -> closed __________________________________ Tracker __________________________________ From report at bugs.python.org Sun Sep 16 17:11:24 2007 From: report at bugs.python.org (Alexey Suda-Chen) Date: Sun, 16 Sep 2007 15:11:24 -0000 Subject: [issue1134] Parsing a simple script eats all of your memory Message-ID: <1189955484.22.0.840601920575.issue1134@psf.upfronthosting.co.za> Alexey Suda-Chen added the comment: Oops, i see there are two bugs. Previously i have fixed multiline strings only. I think it will be: Index: tokenizer.c =================================================================== --- tokenizer.c (revision 58161) +++ tokenizer.c (working copy) @@ -395,6 +395,7 @@ goto error; buflen = size; } + memcpy(s, buf, buflen); s[buflen] = '\0'; if (buflen == 0) /* EOF */ @@ -402,6 +403,12 @@ if (allocated) { Py_DECREF(bufobj); } + + if ( bufobj == tok->decoding_buffer ){ + Py_XDECREF(tok->decoding_buffer); + tok->decoding_buffer = 0; + } + return s; error: __________________________________ Tracker __________________________________ From report at bugs.python.org Sun Sep 16 17:52:10 2007 From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=) Date: Sun, 16 Sep 2007 15:52:10 -0000 Subject: [issue1167] gdbm/ndbm 1.8.1+ needs libgdbm_compat.so Message-ID: <1189957930.64.0.980694563858.issue1167@psf.upfronthosting.co.za> Changes by Martin v. L?wis: ---------- keywords: +patch __________________________________ Tracker __________________________________ From report at bugs.python.org Sun Sep 16 17:53:17 2007 From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=) Date: Sun, 16 Sep 2007 15:53:17 -0000 Subject: [issue1146] TextWrap vs words 1-character shorter than the width Message-ID: <1189957997.62.0.347652303039.issue1146@psf.upfronthosting.co.za> Changes by Martin v. L?wis: ---------- keywords: +patch __________________________________ Tracker __________________________________ From report at bugs.python.org Sun Sep 16 18:05:31 2007 From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=) Date: Sun, 16 Sep 2007 16:05:31 -0000 Subject: [issue1727780] 64/32-bit issue when unpickling random.Random Message-ID: <1189958731.03.0.992406365392.issue1727780@psf.upfronthosting.co.za> Martin v. L?wis added the comment: Would anybody of you like to work on a patch? ---------- nosy: +loewis _____________________________________ Tracker _____________________________________ From report at bugs.python.org Sun Sep 16 18:07:42 2007 From: report at bugs.python.org (Daniele Varrazzo) Date: Sun, 16 Sep 2007 16:07:42 -0000 Subject: [issue1169] Option -OO doesn't remove docstrings from functions Message-ID: <1189958862.36.0.812206723561.issue1169@psf.upfronthosting.co.za> New submission from Daniele Varrazzo: The issue was already addressed in Issue1722485. The fix applied in rev. 55732, 55733 only fixes module and class docstrings, not function docstrings. The attached patch fixed the issue for function docstrings too. ---------- components: None files: fix_function_docstring.patch messages: 55945 nosy: piro severity: normal status: open title: Option -OO doesn't remove docstrings from functions type: compile error versions: Python 2.5 __________________________________ Tracker __________________________________ -------------- next part -------------- A non-text attachment was scrubbed... Name: fix_function_docstring.patch Type: text/x-patch Size: 419 bytes Desc: not available Url : http://mail.python.org/pipermail/python-bugs-list/attachments/20070916/41418fd7/attachment.bin From report at bugs.python.org Sun Sep 16 18:07:42 2007 From: report at bugs.python.org (Daniele Varrazzo) Date: Sun, 16 Sep 2007 16:07:42 -0000 Subject: [issue1169] Option -OO doesn't remove docstrings from functions Message-ID: <1189958862.36.0.812206723561.issue1169@psf.upfronthosting.co.za> New submission from Daniele Varrazzo: The issue was already addressed in Issue1722485. The fix applied in rev. 55732, 55733 only fixes module and class docstrings, not function docstrings. The attached patch fixed the issue for function docstrings too. ---------- components: None files: fix_function_docstring.patch messages: 55945 nosy: piro severity: normal status: open title: Option -OO doesn't remove docstrings from functions type: compile error versions: Python 2.5 __________________________________ Tracker __________________________________ -------------- next part -------------- A non-text attachment was scrubbed... Name: fix_function_docstring.patch Type: text/x-patch Size: 419 bytes Desc: not available Url : http://mail.python.org/pipermail/python-bugs-list/attachments/20070916/41418fd7/attachment-0001.bin From report at bugs.python.org Sun Sep 16 18:18:38 2007 From: report at bugs.python.org (Eduardo Padoan) Date: Sun, 16 Sep 2007 16:18:38 -0000 Subject: [issue1165] Should itertools.count work for arbitrary integers? Message-ID: <1189959518.08.0.530046362285.issue1165@psf.upfronthosting.co.za> Changes by Eduardo Padoan: ---------- severity: critical -> minor __________________________________ Tracker __________________________________ From report at bugs.python.org Sun Sep 16 18:20:33 2007 From: report at bugs.python.org (Daniele Varrazzo) Date: Sun, 16 Sep 2007 16:20:33 -0000 Subject: [issue1169] Option -OO doesn't remove docstrings from functions Message-ID: <1189959633.0.0.410923298683.issue1169@psf.upfronthosting.co.za> Daniele Varrazzo added the comment: The attached file shows the issue: running with -OO no docstring should be printed. In rev 58163 the functions docstrings are still printed. __________________________________ Tracker __________________________________ -------------- next part -------------- A non-text attachment was scrubbed... Name: docstring_test.py Type: text/x-python Size: 318 bytes Desc: not available Url : http://mail.python.org/pipermail/python-bugs-list/attachments/20070916/04a78dc0/attachment.py From report at bugs.python.org Sun Sep 16 21:26:39 2007 From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=) Date: Sun, 16 Sep 2007 19:26:39 -0000 Subject: [issue1169] Option -OO doesn't remove docstrings from functions Message-ID: <1189970799.32.0.690397898687.issue1169@psf.upfronthosting.co.za> Changes by Martin v. L?wis: ---------- keywords: +patch __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Sep 17 01:22:57 2007 From: report at bugs.python.org (Raymond Hettinger) Date: Sun, 16 Sep 2007 23:22:57 -0000 Subject: [issue1165] Should itertools.count work for arbitrary integers? Message-ID: <1189984977.6.0.753499286952.issue1165@psf.upfronthosting.co.za> Changes by Raymond Hettinger: ---------- assignee: -> rhettinger nosy: +rhettinger __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Sep 17 03:21:54 2007 From: report at bugs.python.org (Skip Montanaro) Date: Mon, 17 Sep 2007 01:21:54 -0000 Subject: [issue1158] %f format for datetime objects Message-ID: <1189992114.11.0.706099900289.issue1158@psf.upfronthosting.co.za> Changes by Skip Montanaro: __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Sep 17 03:22:41 2007 From: report at bugs.python.org (Skip Montanaro) Date: Mon, 17 Sep 2007 01:22:41 -0000 Subject: [issue1158] %f format for datetime objects Message-ID: <1189992161.05.0.359808468457.issue1158@psf.upfronthosting.co.za> Skip Montanaro added the comment: Here are new patches for 2.6 and 3.0 including changes to doc and test cases. __________________________________ Tracker __________________________________ -------------- next part -------------- A non-text attachment was scrubbed... Name: dt-26.diff Type: text/x-diff Size: 4948 bytes Desc: not available Url : http://mail.python.org/pipermail/python-bugs-list/attachments/20070917/810363e8/attachment-0001.diff From report at bugs.python.org Mon Sep 17 03:23:02 2007 From: report at bugs.python.org (Skip Montanaro) Date: Mon, 17 Sep 2007 01:23:02 -0000 Subject: [issue1158] %f format for datetime objects Message-ID: <1189992182.36.0.155456569736.issue1158@psf.upfronthosting.co.za> Changes by Skip Montanaro: __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Sep 17 05:00:02 2007 From: report at bugs.python.org (Guido van Rossum) Date: Mon, 17 Sep 2007 03:00:02 -0000 Subject: [issue1164] tp_print slots don't release the GIL Message-ID: <1189998002.75.0.730479661481.issue1164@psf.upfronthosting.co.za> Guido van Rossum added the comment: looks good to me :) ---------- assignee: -> brett.cannon __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Sep 17 05:29:26 2007 From: report at bugs.python.org (Brett Cannon) Date: Mon, 17 Sep 2007 03:29:26 -0000 Subject: [issue1164] tp_print slots don't release the GIL Message-ID: <1189999766.53.0.0663064157327.issue1164@psf.upfronthosting.co.za> Brett Cannon added the comment: Applied in r58176. And I am glad this is not an issue in Py3K. =) ---------- resolution: -> fixed status: open -> closed __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Sep 17 07:48:14 2007 From: report at bugs.python.org (Sean Reifschneider) Date: Mon, 17 Sep 2007 05:48:14 -0000 Subject: [issue1597011] Reading with bz2.BZ2File() returns one garbage character Message-ID: <1190008094.74.0.282256039861.issue1597011@psf.upfronthosting.co.za> Sean Reifschneider added the comment: I have committed this into trunk and the 2.5 maintenance branch. It passes all tests and the resulting build passes the submitter-provided test. ---------- status: open -> closed _____________________________________ Tracker _____________________________________ From report at bugs.python.org Mon Sep 17 08:15:49 2007 From: report at bugs.python.org (Sean Reifschneider) Date: Mon, 17 Sep 2007 06:15:49 -0000 Subject: [issue1020] pydoc doesn't work on pyexpat Message-ID: <1190009749.7.0.386673003697.issue1020@psf.upfronthosting.co.za> Changes by Sean Reifschneider: ---------- priority: -> low __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Sep 17 08:26:32 2007 From: report at bugs.python.org (Sean Reifschneider) Date: Mon, 17 Sep 2007 06:26:32 -0000 Subject: [issue1021] logging.basicConfig does not allow to set NOTSET level Message-ID: <1190010392.82.0.972584899239.issue1021@psf.upfronthosting.co.za> Changes by Sean Reifschneider: ---------- assignee: -> vsajip nosy: +vsajip priority: -> normal __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Sep 17 08:29:23 2007 From: report at bugs.python.org (Sean Reifschneider) Date: Mon, 17 Sep 2007 06:29:23 -0000 Subject: [issue1025] tracebacks from list comps (probably other comps) don't show full stack Message-ID: <1190010563.24.0.899825455021.issue1025@psf.upfronthosting.co.za> Changes by Sean Reifschneider: ---------- priority: -> normal __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Sep 17 08:30:08 2007 From: report at bugs.python.org (Sean Reifschneider) Date: Mon, 17 Sep 2007 06:30:08 -0000 Subject: [issue1042] test_glob fails with UnicodeDecodeError Message-ID: <1190010608.66.0.463490630045.issue1042@psf.upfronthosting.co.za> Changes by Sean Reifschneider: ---------- priority: -> high __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Sep 17 08:32:37 2007 From: report at bugs.python.org (Sean Reifschneider) Date: Mon, 17 Sep 2007 06:32:37 -0000 Subject: [issue1053] bogus attributes reported in asyncore doc Message-ID: <1190010757.63.0.119791754235.issue1053@psf.upfronthosting.co.za> Changes by Sean Reifschneider: ---------- priority: -> normal __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Sep 17 08:32:54 2007 From: report at bugs.python.org (Sean Reifschneider) Date: Mon, 17 Sep 2007 06:32:54 -0000 Subject: [issue1053] bogus attributes reported in asyncore doc Message-ID: <1190010774.41.0.656241782801.issue1053@psf.upfronthosting.co.za> Changes by Sean Reifschneider: ---------- assignee: -> fdrake nosy: +fdrake __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Sep 17 08:33:42 2007 From: report at bugs.python.org (Sean Reifschneider) Date: Mon, 17 Sep 2007 06:33:42 -0000 Subject: [issue1060] zipfile cannot handle files larger than 2GB (inside archive) Message-ID: <1190010822.53.0.744610118303.issue1060@psf.upfronthosting.co.za> Changes by Sean Reifschneider: ---------- priority: -> normal __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Sep 17 08:38:24 2007 From: report at bugs.python.org (Sean Reifschneider) Date: Mon, 17 Sep 2007 06:38:24 -0000 Subject: [issue1003] zipfile password fails validation Message-ID: <1190011104.03.0.366444514631.issue1003@psf.upfronthosting.co.za> Changes by Sean Reifschneider: ---------- priority: -> normal __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Sep 17 08:39:33 2007 From: report at bugs.python.org (Sean Reifschneider) Date: Mon, 17 Sep 2007 06:39:33 -0000 Subject: [issue1067] test_smtplib failures (caused by asyncore) Message-ID: <1190011173.21.0.218510425196.issue1067@psf.upfronthosting.co.za> Changes by Sean Reifschneider: ---------- priority: -> high __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Sep 17 08:46:32 2007 From: report at bugs.python.org (Sean Reifschneider) Date: Mon, 17 Sep 2007 06:46:32 -0000 Subject: [issue1079] decode_header does not follow RFC 2047 Message-ID: <1190011592.04.0.487792279521.issue1079@psf.upfronthosting.co.za> Sean Reifschneider added the comment: Can you provide an example of an address that triggers this? Preferably in a code sample that can be used to reproduce it? Uber-ideally, a patch to the email module test suite would be great. ---------- nosy: +jafo priority: -> normal __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Sep 17 08:48:23 2007 From: report at bugs.python.org (Sean Reifschneider) Date: Mon, 17 Sep 2007 06:48:23 -0000 Subject: [issue1597011] Reading with bz2.BZ2File() returns one garbage character Message-ID: <1190011703.98.0.100670097592.issue1597011@psf.upfronthosting.co.za> Changes by Sean Reifschneider: ---------- resolution: -> fixed _____________________________________ Tracker _____________________________________ From report at bugs.python.org Mon Sep 17 08:51:05 2007 From: report at bugs.python.org (Sean Reifschneider) Date: Mon, 17 Sep 2007 06:51:05 -0000 Subject: [issue1081] file.seek allows float arguments Message-ID: <1190011865.73.0.913951136315.issue1081@psf.upfronthosting.co.za> Changes by Sean Reifschneider: ---------- assignee: -> loewis nosy: +loewis priority: -> normal __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Sep 17 09:08:40 2007 From: report at bugs.python.org (Sean Reifschneider) Date: Mon, 17 Sep 2007 07:08:40 -0000 Subject: [issue1082] platform system may be Windows or Microsoft since Vista Message-ID: <1190012920.62.0.054639329019.issue1082@psf.upfronthosting.co.za> Sean Reifschneider added the comment: Attached a patch which I *THINK* fixes this, but I don't run Windows. Can someone else check this? ---------- assignee: -> lemburg nosy: +jafo, lemburg priority: -> normal __________________________________ Tracker __________________________________ -------------- next part -------------- A non-text attachment was scrubbed... Name: python-trunk-vistaplatform.patch Type: text/x-patch Size: 699 bytes Desc: not available Url : http://mail.python.org/pipermail/python-bugs-list/attachments/20070917/80ba5602/attachment.bin From report at bugs.python.org Mon Sep 17 09:16:01 2007 From: report at bugs.python.org (Sean Reifschneider) Date: Mon, 17 Sep 2007 07:16:01 -0000 Subject: [issue1087] py3k os.popen result is not iterable, patch attached Message-ID: <1190013361.42.0.488532853708.issue1087@psf.upfronthosting.co.za> Changes by Sean Reifschneider: ---------- assignee: -> aimacintyre nosy: +aimacintyre priority: -> normal __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Sep 17 09:17:17 2007 From: report at bugs.python.org (Sean Reifschneider) Date: Mon, 17 Sep 2007 07:17:17 -0000 Subject: [issue1004] MultiMethods with type annotations in 3000 Message-ID: <1190013437.63.0.562330866525.issue1004@psf.upfronthosting.co.za> Changes by Sean Reifschneider: ---------- assignee: -> gvanrossum nosy: +gvanrossum priority: -> low __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Sep 17 09:18:13 2007 From: report at bugs.python.org (Sean Reifschneider) Date: Mon, 17 Sep 2007 07:18:13 -0000 Subject: [issue1082] platform system may be Windows or Microsoft since Vista Message-ID: <1190013493.93.0.0952718035489.issue1082@psf.upfronthosting.co.za> Sean Reifschneider added the comment: Supplied patch passes "make test", BTW. ---------- keywords: +patch __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Sep 17 09:20:24 2007 From: report at bugs.python.org (Sean Reifschneider) Date: Mon, 17 Sep 2007 07:20:24 -0000 Subject: [issue1027] uudecoding (uu.py) does not supprt base64, patch attached Message-ID: <1190013624.37.0.767534564768.issue1027@psf.upfronthosting.co.za> Changes by Sean Reifschneider: ---------- priority: -> normal __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Sep 17 09:29:30 2007 From: report at bugs.python.org (Sean Reifschneider) Date: Mon, 17 Sep 2007 07:29:30 -0000 Subject: [issue1254718] GCC detection for runtime_library_dirs when ccache is used Message-ID: <1190014170.38.0.510979459557.issue1254718@psf.upfronthosting.co.za> Sean Reifschneider added the comment: NOTE: See also issue1032 which has a patch for this. Can we come to a consensus on which one has the best patch? ---------- assignee: -> loewis nosy: +jafo, loewis _____________________________________ Tracker _____________________________________ From report at bugs.python.org Mon Sep 17 09:29:53 2007 From: report at bugs.python.org (Sean Reifschneider) Date: Mon, 17 Sep 2007 07:29:53 -0000 Subject: [issue1032] Improve the hackish runtime_library_dirs support for gcc Message-ID: <1190014193.85.0.987522368218.issue1032@psf.upfronthosting.co.za> Changes by Sean Reifschneider: ---------- assignee: -> loewis nosy: +loewis priority: -> normal __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Sep 17 09:38:01 2007 From: report at bugs.python.org (Sean Reifschneider) Date: Mon, 17 Sep 2007 07:38:01 -0000 Subject: [issue1047] py3k: corrections for test_subprocess on windows Message-ID: <1190014681.35.0.91354920606.issue1047@psf.upfronthosting.co.za> Changes by Sean Reifschneider: ---------- priority: -> low __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Sep 17 09:44:40 2007 From: report at bugs.python.org (Sean Reifschneider) Date: Mon, 17 Sep 2007 07:44:40 -0000 Subject: [issue1061] ABC caches should use weak refs Message-ID: <1190015080.6.0.176713685279.issue1061@psf.upfronthosting.co.za> Changes by Sean Reifschneider: ---------- assignee: -> georg.brandl priority: -> normal __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Sep 17 09:53:14 2007 From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=) Date: Mon, 17 Sep 2007 07:53:14 -0000 Subject: [issue1086] test_email failed Message-ID: <1190015594.28.0.687758168614.issue1086@psf.upfronthosting.co.za> Changes by Martin v. L?wis: __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Sep 17 09:53:59 2007 From: report at bugs.python.org (Sean Reifschneider) Date: Mon, 17 Sep 2007 07:53:59 -0000 Subject: [issue1086] test_email failed Message-ID: <1190015639.67.0.0275547842869.issue1086@psf.upfronthosting.co.za> Changes by Sean Reifschneider: ---------- priority: -> normal __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Sep 17 09:56:43 2007 From: report at bugs.python.org (Sean Reifschneider) Date: Mon, 17 Sep 2007 07:56:43 -0000 Subject: [issue1022] use bytes for code objects Message-ID: <1190015803.62.0.089583000448.issue1022@psf.upfronthosting.co.za> Changes by Sean Reifschneider: ---------- assignee: -> gvanrossum priority: -> low resolution: -> remind __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Sep 17 10:01:08 2007 From: report at bugs.python.org (Sean Reifschneider) Date: Mon, 17 Sep 2007 08:01:08 -0000 Subject: [issue1045] Performance regression in 2.5 Message-ID: <1190016068.87.0.277859013191.issue1045@psf.upfronthosting.co.za> Changes by Sean Reifschneider: ---------- assignee: -> tim_one nosy: +tim_one priority: -> normal __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Sep 17 10:02:56 2007 From: report at bugs.python.org (Sean Reifschneider) Date: Mon, 17 Sep 2007 08:02:56 -0000 Subject: [issue1077] itertools missing, causes interactive help to break Message-ID: <1190016176.98.0.9554196541.issue1077@psf.upfronthosting.co.za> Changes by Sean Reifschneider: ---------- assignee: -> georg.brandl priority: -> low severity: urgent -> normal __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Sep 17 10:08:43 2007 From: report at bugs.python.org (Sean Reifschneider) Date: Mon, 17 Sep 2007 08:08:43 -0000 Subject: [issue1102] Add support for _msi.Record.GetString() and _msi.Record.GetInteger() Message-ID: <1190016523.06.0.8073740938.issue1102@psf.upfronthosting.co.za> Changes by Sean Reifschneider: ---------- priority: -> normal __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Sep 17 10:11:24 2007 From: report at bugs.python.org (Sean Reifschneider) Date: Mon, 17 Sep 2007 08:11:24 -0000 Subject: [issue1109] Warning required when calling register() on an ABCMeta subclass Message-ID: <1190016684.18.0.929524423585.issue1109@psf.upfronthosting.co.za> Changes by Sean Reifschneider: ---------- assignee: -> gvanrossum nosy: +gvanrossum priority: -> normal __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Sep 17 10:14:54 2007 From: report at bugs.python.org (Sean Reifschneider) Date: Mon, 17 Sep 2007 08:14:54 -0000 Subject: [issue1110] Problems with the msi installer - python-3.0a1.msi Message-ID: <1190016894.72.0.375019709804.issue1110@psf.upfronthosting.co.za> Changes by Sean Reifschneider: ---------- assignee: -> loewis priority: -> normal __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Sep 17 10:22:28 2007 From: report at bugs.python.org (Sean Reifschneider) Date: Mon, 17 Sep 2007 08:22:28 -0000 Subject: [issue1115] Minor Change For Better cross compile Message-ID: <1190017348.19.0.135983845212.issue1115@psf.upfronthosting.co.za> Changes by Sean Reifschneider: ---------- assignee: -> loewis nosy: +loewis priority: -> low __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Sep 17 10:24:13 2007 From: report at bugs.python.org (Sean Reifschneider) Date: Mon, 17 Sep 2007 08:24:13 -0000 Subject: [issue1104] msilib.SummaryInfo.GetProperty() truncates the string by one character Message-ID: <1190017453.34.0.339311929319.issue1104@psf.upfronthosting.co.za> Changes by Sean Reifschneider: ---------- priority: -> normal __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Sep 17 10:26:29 2007 From: report at bugs.python.org (Sean Reifschneider) Date: Mon, 17 Sep 2007 08:26:29 -0000 Subject: [issue1034] [patch] Add 2to3 support for displaying warnings as Python comments Message-ID: <1190017589.85.0.339478613934.issue1034@psf.upfronthosting.co.za> Changes by Sean Reifschneider: ---------- priority: -> normal __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Sep 17 10:30:29 2007 From: report at bugs.python.org (Sean Reifschneider) Date: Mon, 17 Sep 2007 08:30:29 -0000 Subject: [issue1005] Patches to rename Queue module to queue Message-ID: <1190017829.41.0.503885205214.issue1005@psf.upfronthosting.co.za> Changes by Sean Reifschneider: ---------- priority: -> normal __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Sep 17 10:31:40 2007 From: report at bugs.python.org (Sean Reifschneider) Date: Mon, 17 Sep 2007 08:31:40 -0000 Subject: [issue1002] Patch to rename HTMLParser module to lower_case Message-ID: <1190017900.93.0.724847125193.issue1002@psf.upfronthosting.co.za> Changes by Sean Reifschneider: ---------- priority: -> normal __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Sep 17 10:35:16 2007 From: report at bugs.python.org (Sean Reifschneider) Date: Mon, 17 Sep 2007 08:35:16 -0000 Subject: [issue1108] Problem with doctest and decorated functions Message-ID: <1190018116.88.0.564486250857.issue1108@psf.upfronthosting.co.za> Changes by Sean Reifschneider: ---------- assignee: -> tim_one nosy: +tim_one priority: -> normal __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Sep 17 10:38:08 2007 From: report at bugs.python.org (Sean Reifschneider) Date: Mon, 17 Sep 2007 08:38:08 -0000 Subject: [issue1014] cgi: parse_qs and parse_qsl misbehave on empty strings Message-ID: <1190018288.33.0.838028413405.issue1014@psf.upfronthosting.co.za> Changes by Sean Reifschneider: ---------- assignee: -> gvanrossum nosy: +gvanrossum priority: -> normal __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Sep 17 10:40:51 2007 From: report at bugs.python.org (Sean Reifschneider) Date: Mon, 17 Sep 2007 08:40:51 -0000 Subject: [issue1128] msilib.Directory.make_short only handles file names with a single dot in them Message-ID: <1190018451.05.0.568470440702.issue1128@psf.upfronthosting.co.za> Changes by Sean Reifschneider: ---------- priority: -> normal __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Sep 17 10:42:58 2007 From: report at bugs.python.org (Sean Reifschneider) Date: Mon, 17 Sep 2007 08:42:58 -0000 Subject: [issue1124] Webchecker not parsing css "@import url" Message-ID: <1190018578.26.0.268516387903.issue1124@psf.upfronthosting.co.za> Changes by Sean Reifschneider: ---------- priority: -> low severity: normal -> minor status: open -> pending __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Sep 17 11:05:10 2007 From: report at bugs.python.org (Sean Reifschneider) Date: Mon, 17 Sep 2007 09:05:10 -0000 Subject: [issue1126] file.fileno and file.isatty() should be implementable by any file like object Message-ID: <1190019910.18.0.875024825832.issue1126@psf.upfronthosting.co.za> Sean Reifschneider added the comment: This is a documentation complaint, right? Perhaps more of a discussion of why not implement these attributes on file-like objects. In general, I believe the documentation is correct. Setting fileno to -1 is likely to break other things in unexpected ways. Because when opening a real file object, -1 would mean the file open failed, and the file object would not get created. The documentation is right, right? ---------- assignee: -> fdrake components: +Documentation -Library (Lib) nosy: +fdrake, jafo priority: -> low __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Sep 17 11:09:45 2007 From: report at bugs.python.org (Sean Reifschneider) Date: Mon, 17 Sep 2007 09:09:45 -0000 Subject: [issue1131] Reference Manual: "for statement" links to "break statement" Message-ID: <1190020185.2.0.309667065204.issue1131@psf.upfronthosting.co.za> Sean Reifschneider added the comment: Can I get more information about how to reproduce this? What is it you do to get to this? It sounds like you're talking about some HTML documentation, but if I go to the current documentation in the Language section, and click on the "for" section, I do get the for document: http://docs.python.org/dev/reference/compound_stmts.html#the-for-statement ---------- assignee: -> jafo nosy: +jafo priority: -> normal status: open -> pending __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Sep 17 11:12:58 2007 From: report at bugs.python.org (Sean Reifschneider) Date: Mon, 17 Sep 2007 09:12:58 -0000 Subject: [issue1137] pyexpat patch for changing buffer_size Message-ID: <1190020378.31.0.212447712483.issue1137@psf.upfronthosting.co.za> Changes by Sean Reifschneider: ---------- assignee: -> akuchling nosy: +akuchling priority: -> normal __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Sep 17 11:17:02 2007 From: report at bugs.python.org (Sean Reifschneider) Date: Mon, 17 Sep 2007 09:17:02 -0000 Subject: [issue1114] _curses issues on 64-bit big-endian (e.g, AIX) Message-ID: <1190020622.8.0.976547008234.issue1114@psf.upfronthosting.co.za> Changes by Sean Reifschneider: ---------- assignee: -> akuchling components: +Library (Lib) -Extension Modules nosy: +akuchling priority: -> normal __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Sep 17 11:44:15 2007 From: report at bugs.python.org (Sean Reifschneider) Date: Mon, 17 Sep 2007 09:44:15 -0000 Subject: [issue1140] re.sub returns str when processing empty unicode string Message-ID: <1190022255.96.0.700123274589.issue1140@psf.upfronthosting.co.za> Sean Reifschneider added the comment: Applied as revision 58179 to 2.5 maintenance branch, passes tests. ---------- nosy: +jafo priority: -> low status: open -> closed __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Sep 17 11:53:58 2007 From: report at bugs.python.org (Sean Reifschneider) Date: Mon, 17 Sep 2007 09:53:58 -0000 Subject: [issue1144] parsermodule validation out of sync with Grammar Message-ID: <1190022838.88.0.744191743468.issue1144@psf.upfronthosting.co.za> Changes by Sean Reifschneider: ---------- priority: -> normal __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Sep 17 11:57:35 2007 From: report at bugs.python.org (Sean Reifschneider) Date: Mon, 17 Sep 2007 09:57:35 -0000 Subject: [issue1530559] struct.pack raises TypeError where it used to convert Message-ID: <1190023055.14.0.998636267102.issue1530559@psf.upfronthosting.co.za> Changes by Sean Reifschneider: ---------- priority: urgent -> normal _____________________________________ Tracker _____________________________________ From report at bugs.python.org Mon Sep 17 12:01:29 2007 From: report at bugs.python.org (Sean Reifschneider) Date: Mon, 17 Sep 2007 10:01:29 -0000 Subject: [issue1692335] Fix exception pickling: Move initial args assignment to BaseException.__new__ Message-ID: <1190023289.38.0.994022245125.issue1692335@psf.upfronthosting.co.za> Sean Reifschneider added the comment: It's not clear to me what the next step is here, does one or more of the other folks need to provide some input? Georg: If you are looking for something from someone, can you assign the ticket to them? ---------- assignee: -> georg.brandl nosy: +jafo _____________________________________ Tracker _____________________________________ From report at bugs.python.org Mon Sep 17 12:13:41 2007 From: report at bugs.python.org (Shawn Ligocki) Date: Mon, 17 Sep 2007 10:13:41 -0000 Subject: [issue1727780] 64/32-bit issue when unpickling random.Random Message-ID: <1190024021.1.0.596618296563.issue1727780@psf.upfronthosting.co.za> Shawn Ligocki added the comment: I've got a patch! The problem was that the state was being cast from a C-type unsigned long to a long. On 32-bit machines this makes large 32-bit longs negative. On 64-bit machines this preserves the sign of 32-bit values (because they are stored in 64-bit longs). My patch returns the values with PyLong_FromUnsignedLong() instead of PyInt_FromLong(), therefore there is no casting to long and both 32-bit and 64-bit machines produce the same result. I added code to read states from the old (buggy) version and decypher it appropriately (from either 32-bit or 64-bit source!). In other words, old pickles can now be opened on either architecture with the new patch. This patch is taken from the svn head, but also works on Python 2.5.1 . I haven't tested this patch fully on 64-bit machine yet. I'll let you know when I have. Cheers, -Shawn _____________________________________ Tracker _____________________________________ -------------- next part -------------- A non-text attachment was scrubbed... Name: python_head_random.patch Type: text/x-diff Size: 2944 bytes Desc: not available Url : http://mail.python.org/pipermail/python-bugs-list/attachments/20070917/784ec72c/attachment.patch From report at bugs.python.org Mon Sep 17 12:16:00 2007 From: report at bugs.python.org (Sean Reifschneider) Date: Mon, 17 Sep 2007 10:16:00 -0000 Subject: [issue815646] thread unsafe file objects cause crash Message-ID: <1190024160.19.0.476805060935.issue815646@psf.upfronthosting.co.za> Sean Reifschneider added the comment: If I read the 2003 python-dev thready correctly, there isn't a solution to this. Does this need to go back to python-dev, or do we just call it "wont fix"? Or...? ---------- assignee: -> tim_one nosy: +jafo, tim_one ____________________________________ Tracker ____________________________________ From report at bugs.python.org Mon Sep 17 12:48:15 2007 From: report at bugs.python.org (Sean Reifschneider) Date: Mon, 17 Sep 2007 10:48:15 -0000 Subject: [issue1150] Rename PyBUF_WRITEABLE to PyBUF_WRITABLE Message-ID: <1190026095.63.0.197250105942.issue1150@psf.upfronthosting.co.za> Sean Reifschneider added the comment: Attached is a patch that fixes "writeable". I'm thinking, close this if the patch looks ok, and open another for a general "identify non-englishisms" ticket, once they're identified a ticket could be opened to fix them. I fixed only the PyBUF instances but also documents and comments and doc strings and printfs where it occurred. Yes? Let me know if it looks good to commit. Does this need a fix in 2to3? ---------- assignee: -> gvanrossum keywords: +patch nosy: +jafo priority: -> low __________________________________ Tracker __________________________________ -------------- next part -------------- A non-text attachment was scrubbed... Name: py3k-trunk-writeable.patch Type: text/x-patch Size: 11633 bytes Desc: not available Url : http://mail.python.org/pipermail/python-bugs-list/attachments/20070917/05371058/attachment-0001.bin From report at bugs.python.org Mon Sep 17 12:49:58 2007 From: report at bugs.python.org (Sean Reifschneider) Date: Mon, 17 Sep 2007 10:49:58 -0000 Subject: [issue1130] Idle - Save (buffer) - closes IDLE and does not save file (Windows XP) Message-ID: <1190026198.82.0.413728847754.issue1130@psf.upfronthosting.co.za> Changes by Sean Reifschneider: ---------- priority: -> normal __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Sep 17 12:50:06 2007 From: report at bugs.python.org (Peter Lloyd) Date: Mon, 17 Sep 2007 10:50:06 -0000 Subject: [issue1599254] mailbox: other programs' messages can vanish without trace Message-ID: <1190026206.29.0.365724514531.issue1599254@psf.upfronthosting.co.za> Changes by Peter Lloyd: ---------- nosy: +peter.ll _____________________________________ Tracker _____________________________________ From report at bugs.python.org Mon Sep 17 12:52:19 2007 From: report at bugs.python.org (Sean Reifschneider) Date: Mon, 17 Sep 2007 10:52:19 -0000 Subject: [issue1019] Cleanup pass on _curses and _curses_panel Message-ID: <1190026339.28.0.40541861015.issue1019@psf.upfronthosting.co.za> Changes by Sean Reifschneider: ---------- priority: -> low __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Sep 17 13:05:20 2007 From: report at bugs.python.org (Sean Reifschneider) Date: Mon, 17 Sep 2007 11:05:20 -0000 Subject: [issue1123] split(None, maxsplit) does not strip whitespace correctly Message-ID: <1190027120.19.0.201352326943.issue1123@psf.upfronthosting.co.za> Sean Reifschneider added the comment: I believe this is just a place where the documentation could be cleared up. Seems to me the confusion is from the document saying (paraphrased): "white space is removed from both ends". Perhaps it should say something like "runs of 1 or more whitespace are collapsed (up to the maximum split), and then split on" or simply "split on runs of 1 or more whitespace. In other words, 3 spaces together would be treated as a single split-point instead of 3 0-length fields separated by spaces." So, in the first example provided by "nirs" in this issue, "both ends" refers to both the left and right side of "k:". Since maxsplit is 1, the second part (v) is left untouched. This is the intended operation. This is a documentation bug, not a library bug. Fred: Thoughts on wording? ---------- assignee: -> fdrake components: +Documentation -Library (Lib) nosy: +fdrake, jafo priority: -> low __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Sep 17 13:34:24 2007 From: report at bugs.python.org (Fred L. Drake, Jr.) Date: Mon, 17 Sep 2007 11:34:24 -0000 Subject: [issue1126] file.fileno and file.isatty() should be implementable by any file like object Message-ID: <1190028864.79.0.701129651328.issue1126@psf.upfronthosting.co.za> Fred L. Drake, Jr. added the comment: The documentation does not say what's implied by msg55724; they methods can (and arguably should) be implmented by types for which they apply (for which there is a corresponding file descriptor, for example). There is an API issue here as well: what about a wrapper type that is sometimes associated with a real file, and sometimes not? I suppose in that case the factory (constructor) needs to detect the situation and return an instance of an appropriate type. The documentation is clear, so far as it goes, but is arguably incomplete. __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Sep 17 15:50:09 2007 From: report at bugs.python.org (Skip Montanaro) Date: Mon, 17 Sep 2007 13:50:09 -0000 Subject: [issue1158] %f format for datetime objects Message-ID: <1190037009.62.0.710295247678.issue1158@psf.upfronthosting.co.za> Skip Montanaro added the comment: Brett, Continuing the discussion of strptime... It returns a time.struct_time. Would it cause too much breakage (only do this in 3.0) to add a tm_usec field to the end of that object? It seems a lot of bits of code might still expect a length 9 tuple-ish thing and do this: yy, mm, dd, hh, mm, ss, wk, j, tz = time.strptime(...) If we could make that change for 3.0 that might allow strptime to parse %f format codes. S __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Sep 17 17:05:39 2007 From: report at bugs.python.org (Guido van Rossum) Date: Mon, 17 Sep 2007 15:05:39 -0000 Subject: [issue1150] Rename PyBUF_WRITEABLE to PyBUF_WRITABLE Message-ID: <1190041539.31.0.104942977853.issue1150@psf.upfronthosting.co.za> Guido van Rossum added the comment: Looks good. Check it in, with one small addition: add #define PyBUF_WRITEABLE PyBUF_WRITABLE for those NumPy folks who can't help writing the alternate spelling ('writeable' *is* in some dictionaries, though it is consistently flagged as invalid by spell checkers). ---------- assignee: gvanrossum -> jafo resolution: -> accepted __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Sep 17 17:53:56 2007 From: report at bugs.python.org (dexen deVries) Date: Mon, 17 Sep 2007 15:53:56 -0000 Subject: [issue1170] shlex have problems with parsing unicode Message-ID: <1190044436.75.0.0330375289042.issue1170@psf.upfronthosting.co.za> Changes by dexen deVries: ---------- components: Library (Lib), Unicode severity: normal status: open title: shlex have problems with parsing unicode type: behavior versions: Python 2.5 __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Sep 17 18:12:44 2007 From: report at bugs.python.org (Brett Cannon) Date: Mon, 17 Sep 2007 16:12:44 -0000 Subject: [issue1158] %f format for datetime objects In-Reply-To: <1190037009.62.0.710295247678.issue1158@psf.upfronthosting.co.za> Message-ID: Brett Cannon added the comment: In terms of strptime, I would just change _strptime.strptime() to _strptime._strptime() and have it return everything along with the microseconds measurement. Then have public functions that call that function and either strip off the microseconds or not. -Brett On 9/17/07, Skip Montanaro wrote: > > Skip Montanaro added the comment: > > Brett, > > Continuing the discussion of strptime... It returns a time.struct_time. > Would it cause too much breakage (only do this in 3.0) to add a tm_usec > field to the end of that object? It seems a lot of bits of code might > still expect a length 9 tuple-ish thing and do this: > > yy, mm, dd, hh, mm, ss, wk, j, tz = time.strptime(...) > > If we could make that change for 3.0 that might allow strptime to parse > %f format codes. > > S > > __________________________________ > Tracker > > __________________________________ > _______________________________________________ > Python-bugs-list mailing list > Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/brett%40python.org > > __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Sep 17 18:17:13 2007 From: report at bugs.python.org (dexen deVries) Date: Mon, 17 Sep 2007 16:17:13 -0000 Subject: [issue1170] shlex have problems with parsing unicode Message-ID: <1190045833.27.0.172281845017.issue1170@psf.upfronthosting.co.za> New submission from dexen deVries: Feeding unicode to shlex object created in POSIX compat mode causes UnicodeDecodeError to be raised. It appears that shlex object defines sting .wordchars, containing latin-1 (iso8859-1) encoded characters with charcodes >=128, which is used to check whether a character from input constitues a word character or not. ---------- nosy: +dexen __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Sep 17 18:20:38 2007 From: report at bugs.python.org (dexen deVries) Date: Mon, 17 Sep 2007 16:20:38 -0000 Subject: [issue1170] shlex have problems with parsing unicode Message-ID: <1190046038.92.0.0244946221114.issue1170@psf.upfronthosting.co.za> dexen deVries added the comment: A quick paste to illustrate: the exception is raised only when unicode object is passed to shlex. Warning: the cStringIO module is unsuitable for use there, only the StringIO. cStringIO does not output unicode. dexen!muraena!~$ python Python 2.5.1 (r251:54863, May 4 2007, 16:52:23) [GCC 4.1.2] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> from StringIO import StringIO >>> import shlex >>> lx = shlex.shlex( StringIO( unicode( "abc" ) ) ) >>> lx.get_token() u'abc' >>> lx = shlex.shlex( StringIO( unicode( "abc" ) ), None, True ) >>> lx.get_token() Traceback (most recent call last): File "", line 1, in File "/usr/lib/python2.5/shlex.py", line 96, in get_token raw = self.read_token() File "/usr/lib/python2.5/shlex.py", line 150, in read_token elif nextchar in self.wordchars: UnicodeDecodeError: 'ascii' codec can't decode byte 0xdf in position 63: ordinal not in range(128) >>> __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Sep 17 18:31:21 2007 From: report at bugs.python.org (dexen deVries) Date: Mon, 17 Sep 2007 16:31:21 -0000 Subject: [issue1170] shlex have problems with parsing unicode Message-ID: <1190046681.67.0.493556266041.issue1170@psf.upfronthosting.co.za> dexen deVries added the comment: One remark to previous message: the first time i created shlex object in non-POSIX mode (the default), in later it's in POSIX mode (due to the third parameter to shlex being True). The bug in question manifests only in POSIX mode. BTW, that so-called POSIX mode would be more POSIX-ish, if instead of comparing characters with a fixed, short list, would use the ctype() function as found in standard C library. The functions takes current locale (setable in process) into account when deciding what is leter, whitespace, punctuation etc. __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Sep 17 19:18:34 2007 From: report at bugs.python.org (Mathieu Fenniak) Date: Mon, 17 Sep 2007 17:18:34 -0000 Subject: [issue1171] allow subclassing of bytes type Message-ID: <1190049514.0.0.613469664366.issue1171@psf.upfronthosting.co.za> New submission from Mathieu Fenniak: Uploading patch to make bytes type subclassable. As e-mailed to python-3000 list during discussion with Guido, attached patch to make bytes type subclassable. Included are unit tests, and a minor fix for pickling subclass instances (including __dict__ in bytes_reduce). ---------- files: bytes-subclass-patch.diff messages: 55970 nosy: mfenniak severity: minor status: open title: allow subclassing of bytes type type: rfe versions: Python 3.0 __________________________________ Tracker __________________________________ -------------- next part -------------- A non-text attachment was scrubbed... Name: bytes-subclass-patch.diff Type: application/octet-stream Size: 4806 bytes Desc: not available Url : http://mail.python.org/pipermail/python-bugs-list/attachments/20070917/365ab150/attachment.obj From report at bugs.python.org Mon Sep 17 19:18:34 2007 From: report at bugs.python.org (Mathieu Fenniak) Date: Mon, 17 Sep 2007 17:18:34 -0000 Subject: [issue1171] allow subclassing of bytes type Message-ID: <1190049514.0.0.613469664366.issue1171@psf.upfronthosting.co.za> New submission from Mathieu Fenniak: Uploading patch to make bytes type subclassable. As e-mailed to python-3000 list during discussion with Guido, attached patch to make bytes type subclassable. Included are unit tests, and a minor fix for pickling subclass instances (including __dict__ in bytes_reduce). ---------- files: bytes-subclass-patch.diff messages: 55970 nosy: mfenniak severity: minor status: open title: allow subclassing of bytes type type: rfe versions: Python 3.0 __________________________________ Tracker __________________________________ -------------- next part -------------- A non-text attachment was scrubbed... Name: bytes-subclass-patch.diff Type: application/octet-stream Size: 4806 bytes Desc: not available Url : http://mail.python.org/pipermail/python-bugs-list/attachments/20070917/365ab150/attachment-0001.obj From report at bugs.python.org Mon Sep 17 19:56:12 2007 From: report at bugs.python.org (Sean Reifschneider) Date: Mon, 17 Sep 2007 17:56:12 -0000 Subject: [issue1150] Rename PyBUF_WRITEABLE to PyBUF_WRITABLE Message-ID: <1190051772.43.0.179560103639.issue1150@psf.upfronthosting.co.za> Changes by Sean Reifschneider: ---------- status: open -> closed __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Sep 17 19:57:18 2007 From: report at bugs.python.org (Sean Reifschneider) Date: Mon, 17 Sep 2007 17:57:18 -0000 Subject: [issue1150] Rename PyBUF_WRITEABLE to PyBUF_WRITABLE Message-ID: <1190051838.13.0.295550577585.issue1150@psf.upfronthosting.co.za> Sean Reifschneider added the comment: Comitted as revision 58182, with additional change mentioned by Guido. __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Sep 17 19:57:22 2007 From: report at bugs.python.org (Pat LaVarre) Date: Mon, 17 Sep 2007 17:57:22 -0000 Subject: [issue1082] platform system may be Windows or Microsoft since Vista Message-ID: <1190051842.2.0.31120144199.issue1082@psf.upfronthosting.co.za> Pat LaVarre added the comment: I recommend we reject this first draft of the python-trunk- vistaplatform.patch. I reason as follows ... ACTUAL RESULTS OF 2.5.1 PLUS PATCH IN VISTA WINDOWS: >>> import platform >>> ... >>> platform.uname() ('Microsoft', '[redacted]', 'Windows', '6.0.6000', '', '') >>> platform.system() 'Windows' >>> platform.release() 'Windows' >>> EXPECTED RESULTS OF 2.5.1 PLUS PATCH IN VISTA WINDOWS: >>> import platform >>> ... >>> platform.uname() ('Windows', '[redacted]', 'Vista', '6.0.6000', '', '') >>> platform.system() 'Windows' >>> platform.release() 'Vista' >>> ACTUAL RESULTS OF 2.5 IN SP2 XP WINDOWS: >>> import platform >>> ... >>> platform.uname() ('Windows', '[redacted]', 'XP', '5.1.2600', '', '') >>> platform.system() 'Windows' >>> platform.release() 'XP' >>> DISCUSSION: Four thoughts: 1. I think we meant to write { unameInfo[2] == 'Windows' } where we wrote { unameInfo == 'Windows' } in this patch. 2. To run the patch I created a copy of platform.py in the same folder and applied the patch by hand. I redacted the host names by hand and elided the { platform = ... } source line I wrote to let me run the patch in place of the original. 3. I think we should substitute a different kind of patch, a patch to correct the platform.uname rather than a patch to redefine platform.system and platform.version. I'd like us to hold to such cross-platform invariants as: ( platform.system() == platform.uname()[0] ) ( platform.system() == platform.uname()[2] ) Out on the web I see that we have documented these invariants. I quote: """ 14.12.1 Cross Platform uname() ... Returns a tuple of strings (system, node, release, version, machine, processor) identifying the underlying platform. """ 2007-09-17 fetch of http://docs.python.org/lib/node442.html """ near http://docs.python.org/lib/module-platform.html 4. I don't think we can totally fix this trouble in code: we have distributed 2.5.1 to Vista too massively already now. Specifically, I think we should also fix the doc to admit the hereafter frequent need for people using Python to write code such as: if not (platform.system() in ('Microsoft', 'Windows')): __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Sep 17 20:12:03 2007 From: report at bugs.python.org (Sean Reifschneider) Date: Mon, 17 Sep 2007 18:12:03 -0000 Subject: [issue1082] platform system may be Windows or Microsoft since Vista Message-ID: <1190052723.76.0.695136260117.issue1082@psf.upfronthosting.co.za> Sean Reifschneider added the comment: Attached is a patch that fixes uname() instead of the individual helpers. I agree that is the better way to do it. Again, not tested on Windows because I don't have it. What about adding a "isWindows()" sort of method that does the right thing, or "amIRunningOn('Vista')"? I suggest the latter because I imagine the former might just lead to a bunch of "Where is isX()?" for different platforms. This could implement the logic so that users don't have to know the details of this issue. __________________________________ Tracker __________________________________ -------------- next part -------------- A non-text attachment was scrubbed... Name: python-trunk-vistaplatform-v2.patch Type: text/x-patch Size: 495 bytes Desc: not available Url : http://mail.python.org/pipermail/python-bugs-list/attachments/20070917/4dc526bf/attachment-0001.bin From report at bugs.python.org Mon Sep 17 20:37:50 2007 From: report at bugs.python.org (Sean Reifschneider) Date: Mon, 17 Sep 2007 18:37:50 -0000 Subject: [issue1126] file.fileno and file.isatty() should be implementable by any file like object Message-ID: <1190054270.22.0.507585823989.issue1126@psf.upfronthosting.co.za> Sean Reifschneider added the comment: I'm thinking that nirs is not thinking of this in the "duck typing" environment. Duck typing says that you implement things that are appropriate for your object type, and code does what it needs to do. If the object doesn't support attributes that the code it's passed to needs, (it doesn't "quack like a duck"), then the code should fail. I think nirs is thinking that you have to check every attribute before you use it. But if the object you implement doesn't reasonably have a "istty" or "fileno" associated with it, the Python Way is that if you pass it to code that needs that attribute, that it bomb out. There may be cases where you might write code that checks for an attribute, say if the code can provide enhanced functionality if the attribute is available, but can still provide it's basic functionality if it does not. I'm agreeing that I don't think the documentation is incorrect in this case. I'm thinking that nirs should probably take this to the python mailing list, and if after discussion there it is believed to still be a problem, reference the thread here and re-open it. I'm going to call it closed for the moment. ---------- resolution: -> works for me status: open -> closed __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Sep 17 21:19:47 2007 From: report at bugs.python.org (Bob Kline) Date: Mon, 17 Sep 2007 19:19:47 -0000 Subject: [issue1172] Documentation for done attribute of FieldStorage class Message-ID: <1190056787.13.0.107687348277.issue1172@psf.upfronthosting.co.za> New submission from Bob Kline: I have attached a patch which adds partial documentation for the done attribute of the cgi.FieldStorage class. This addition is needed in order to make it safe to rely on the current behavior of the class, which sets this attribute to the value -1 when an uploaded file from a CGI form does not arrive intact. If I have sufficient free time to do so at some point in the future, I would like to submit a more extensive modification for the module's documentation, using a format which matches that used for most of the other modules (that is, including documentation of all of the methods and attributes intended for public use), and I'd be inclined to modify the cgi.py module itself, to use a less opaque approach for conveying the failure than the 'done' attribute. I'd want some indication that there was a reasonable chance that if I were to invest the work on this improvement the results would actually be used (I see my latest patch for the module has been languishing in the 'ignored' pile for over a year). If anyone else is doing some overhaul work in this area, please speak up so we don't end up with duplication of effort. I would think that this module would be one of the most commonly used in the entire Python library, and would thus warrant careful maintenance (including addressing all of the "XXX let's fix this ..." comments. Cheers! ---------- components: Documentation files: cgi.rst.diff messages: 55975 nosy: bkline severity: normal status: open title: Documentation for done attribute of FieldStorage class type: rfe __________________________________ Tracker __________________________________ -------------- next part -------------- A non-text attachment was scrubbed... Name: cgi.rst.diff Type: text/x-patch Size: 701 bytes Desc: not available Url : http://mail.python.org/pipermail/python-bugs-list/attachments/20070917/8ec71105/attachment.bin From report at bugs.python.org Mon Sep 17 21:19:47 2007 From: report at bugs.python.org (Bob Kline) Date: Mon, 17 Sep 2007 19:19:47 -0000 Subject: [issue1172] Documentation for done attribute of FieldStorage class Message-ID: <1190056787.13.0.107687348277.issue1172@psf.upfronthosting.co.za> New submission from Bob Kline: I have attached a patch which adds partial documentation for the done attribute of the cgi.FieldStorage class. This addition is needed in order to make it safe to rely on the current behavior of the class, which sets this attribute to the value -1 when an uploaded file from a CGI form does not arrive intact. If I have sufficient free time to do so at some point in the future, I would like to submit a more extensive modification for the module's documentation, using a format which matches that used for most of the other modules (that is, including documentation of all of the methods and attributes intended for public use), and I'd be inclined to modify the cgi.py module itself, to use a less opaque approach for conveying the failure than the 'done' attribute. I'd want some indication that there was a reasonable chance that if I were to invest the work on this improvement the results would actually be used (I see my latest patch for the module has been languishing in the 'ignored' pile for over a year). If anyone else is doing some overhaul work in this area, please speak up so we don't end up with duplication of effort. I would think that this module would be one of the most commonly used in the entire Python library, and would thus warrant careful maintenance (including addressing all of the "XXX let's fix this ..." comments. Cheers! ---------- components: Documentation files: cgi.rst.diff messages: 55975 nosy: bkline severity: normal status: open title: Documentation for done attribute of FieldStorage class type: rfe __________________________________ Tracker __________________________________ -------------- next part -------------- A non-text attachment was scrubbed... Name: cgi.rst.diff Type: text/x-patch Size: 701 bytes Desc: not available Url : http://mail.python.org/pipermail/python-bugs-list/attachments/20070917/8ec71105/attachment-0001.bin From report at bugs.python.org Mon Sep 17 22:25:40 2007 From: report at bugs.python.org (Skip Montanaro) Date: Mon, 17 Sep 2007 20:25:40 -0000 Subject: [issue1158] %f format for datetime objects In-Reply-To: Message-ID: <18158.58041.240092.984127@montanaro.dyndns.org> Skip Montanaro added the comment: Brett> In terms of strptime, I would just change _strptime.strptime() to Brett> _strptime._strptime() and have it return everything along with Brett> the microseconds measurement. Then have public functions that Brett> call that function and either strip off the microseconds or not. Sounds good. I'll work that into my patch(es). Skip __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Sep 17 22:32:35 2007 From: report at bugs.python.org (Senthil) Date: Mon, 17 Sep 2007 20:32:35 -0000 Subject: [issue1014] cgi: parse_qs and parse_qsl misbehave on empty strings Message-ID: <1190061155.69.0.630323719115.issue1014@psf.upfronthosting.co.za> Senthil added the comment: Hi Sean, This is a very minor issue (IMO) with Python 2.4. Why did you assign it to gvanrossum? Makes me wonder at your assignments. Thanks, Senthil __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Sep 17 22:35:21 2007 From: report at bugs.python.org (Marc-Andre Lemburg) Date: Mon, 17 Sep 2007 20:35:21 -0000 Subject: [issue1082] platform system may be Windows or Microsoft since Vista Message-ID: <1190061321.67.0.981755816846.issue1082@psf.upfronthosting.co.za> Marc-Andre Lemburg added the comment: A couple of notes: * platform.uname() needs to be fixed, not the individual query functions. * The third entry of uname() should return "Vista" instead of "Microsoft" on MS Vista. * A patch should go on trunk and into 2.5.2, since this is a real bug and not a feature change. Any other changes to accommodate for differences between used marketing names and underlying OS names should go into system_alias(). __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Sep 17 22:41:00 2007 From: report at bugs.python.org (Sean Reifschneider) Date: Mon, 17 Sep 2007 20:41:00 -0000 Subject: [issue1082] platform system may be Windows or Microsoft since Vista Message-ID: <1190061660.11.0.425404016148.issue1082@psf.upfronthosting.co.za> Sean Reifschneider added the comment: Shall I commit my "v2" patch then, to 2.5.2 and trunk? It has the code in the uname() method, as you say. __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Sep 17 22:44:08 2007 From: report at bugs.python.org (Marc-Andre Lemburg) Date: Mon, 17 Sep 2007 20:44:08 -0000 Subject: [issue1082] platform system may be Windows or Microsoft since Vista Message-ID: <1190061848.77.0.0956803589002.issue1082@psf.upfronthosting.co.za> Marc-Andre Lemburg added the comment: Yes, please. Thanks. ---------- assignee: lemburg -> jafo __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Sep 17 22:47:25 2007 From: report at bugs.python.org (Bruce Frederiksen) Date: Mon, 17 Sep 2007 20:47:25 -0000 Subject: [issue1173] yield expressions not documented in Language Reference Message-ID: <1190062045.35.0.384263708744.issue1173@psf.upfronthosting.co.za> Changes by Bruce Frederiksen: ---------- components: Documentation severity: minor status: open title: yield expressions not documented in Language Reference type: rfe versions: Python 2.5 __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Sep 17 22:52:42 2007 From: report at bugs.python.org (Bruce Frederiksen) Date: Mon, 17 Sep 2007 20:52:42 -0000 Subject: [issue1174] new generator methods not documented in Library Reference Message-ID: <1190062362.55.0.601253813398.issue1174@psf.upfronthosting.co.za> New submission from Bruce Frederiksen: The 2.5 library documentation mentions the new GeneratorExit exception, but does not show Generator Types with the new 'send', 'throw', 'close' and '__del__' methods. ---------- components: Documentation messages: 55981 nosy: dangyogi severity: minor status: open title: new generator methods not documented in Library Reference type: rfe versions: Python 2.5 __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Sep 17 22:52:42 2007 From: report at bugs.python.org (Bruce Frederiksen) Date: Mon, 17 Sep 2007 20:52:42 -0000 Subject: [issue1174] new generator methods not documented in Library Reference Message-ID: <1190062362.55.0.601253813398.issue1174@psf.upfronthosting.co.za> New submission from Bruce Frederiksen: The 2.5 library documentation mentions the new GeneratorExit exception, but does not show Generator Types with the new 'send', 'throw', 'close' and '__del__' methods. ---------- components: Documentation messages: 55981 nosy: dangyogi severity: minor status: open title: new generator methods not documented in Library Reference type: rfe versions: Python 2.5 __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Sep 17 22:58:59 2007 From: report at bugs.python.org (Sean Reifschneider) Date: Mon, 17 Sep 2007 20:58:59 -0000 Subject: [issue1082] platform system may be Windows or Microsoft since Vista Message-ID: <1190062739.86.0.184275595616.issue1082@psf.upfronthosting.co.za> Sean Reifschneider added the comment: Commited in trunk revision 58183 and 25-maint revision 58184. ---------- resolution: -> accepted status: open -> closed __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Sep 17 22:59:26 2007 From: report at bugs.python.org (Sean Reifschneider) Date: Mon, 17 Sep 2007 20:59:26 -0000 Subject: [issue1082] platform system may be Windows or Microsoft since Vista Message-ID: <1190062766.42.0.170126053305.issue1082@psf.upfronthosting.co.za> Changes by Sean Reifschneider: ---------- versions: +Python 2.6 __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Sep 17 23:15:48 2007 From: report at bugs.python.org (Guido van Rossum) Date: Mon, 17 Sep 2007 21:15:48 -0000 Subject: [issue1014] cgi: parse_qs and parse_qsl misbehave on empty strings Message-ID: <1190063748.86.0.0189916272804.issue1014@psf.upfronthosting.co.za> Guido van Rossum added the comment: I don't see what the problem is. You requested strict_parsing=True, and this is what strict parsing does. ---------- resolution: -> wont fix status: open -> closed __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Sep 17 23:20:47 2007 From: report at bugs.python.org (T. Middleton) Date: Mon, 17 Sep 2007 21:20:47 -0000 Subject: [issue755670] improve HTMLParser attribute processing regexps Message-ID: <1190064047.03.0.528463289405.issue755670@psf.upfronthosting.co.za> T. Middleton added the comment: I for one thank smroid for the patch. I also have hit *all* of these cases in the wild. This patch makes real-life a lot less frustrating. This patch is surely a lot more preferable than HTMLParser's tendency to just throw up its hands and quietly give up. And one might even make a case that in the horrific world of HTML "standards" case #2 and #3 can be considered actually valid (as much as it hurts to say so). ---------- nosy: +timtoo ____________________________________ Tracker ____________________________________ From report at bugs.python.org Mon Sep 17 23:47:45 2007 From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=) Date: Mon, 17 Sep 2007 21:47:45 -0000 Subject: [issue1727780] 64/32-bit issue when unpickling random.Random Message-ID: <1190065665.41.0.716014886775.issue1727780@psf.upfronthosting.co.za> Changes by Martin v. L?wis: ---------- keywords: +patch _____________________________________ Tracker _____________________________________ From report at bugs.python.org Tue Sep 18 00:16:59 2007 From: report at bugs.python.org (Martoon) Date: Mon, 17 Sep 2007 22:16:59 -0000 Subject: [issue1131] Reference Manual: "for statement" links to "break statement" Message-ID: <1190067419.3.0.834615376192.issue1131@psf.upfronthosting.co.za> Martoon added the comment: It's the Python25.chm file in the Windows distro. I don't have a linux box or a Mac, so I can't verify anything on them. I suspect it's just the .chm file in Windows. If you open it, click the "Index" tab, and select "for" or "for statement" from the keyword list, it jumps to the "break statement" page in the html view pane. I've since noticed that it incorrectly links a lot of other keywords, so it appears to be a global problem in the .chm file. Everything in the nested view in the "Contents" tab seems to link correctly. It's just the keyword list in the "Index" tab. __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Sep 18 00:30:43 2007 From: report at bugs.python.org (Sean Reifschneider) Date: Mon, 17 Sep 2007 22:30:43 -0000 Subject: [issue1131] Reference Manual: "for statement" links to "break statement" Message-ID: <1190068243.36.0.333124571355.issue1131@psf.upfronthosting.co.za> Sean Reifschneider added the comment: I don't know anything about the .chm file. Fred: Do you know where this comes from? ---------- assignee: jafo -> fdrake nosy: +fdrake status: pending -> open __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Sep 18 01:14:22 2007 From: report at bugs.python.org (Brett Cannon) Date: Mon, 17 Sep 2007 23:14:22 -0000 Subject: [issue1686386] Python SEGFAULT on tuple.__repr__ and str() Message-ID: <1190070862.56.0.174044761838.issue1686386@psf.upfronthosting.co.za> Changes by Brett Cannon: ---------- status: pending -> open _____________________________________ Tracker _____________________________________ From report at bugs.python.org Tue Sep 18 06:14:58 2007 From: report at bugs.python.org (Sean Reifschneider) Date: Tue, 18 Sep 2007 04:14:58 -0000 Subject: [issue1149] fdopen does not work as expected Message-ID: <1190088898.68.0.0546179152957.issue1149@psf.upfronthosting.co.za> Sean Reifschneider added the comment: I do not believe this is a Python problem but instead a problem with your code. I believe the problem is likely that you still have a copy of the stdout is open, the fork that is reading also gets associated with that same file. I can't point you at any specific references, but you should check Posix references or possibly other sources for more information about side-effects such as this. These interactions, I have found, can be pretty subtle, so you may need to spend some time on getting everything right. ---------- nosy: +jafo resolution: -> invalid status: open -> closed __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Sep 18 06:36:01 2007 From: report at bugs.python.org (Sean Reifschneider) Date: Tue, 18 Sep 2007 04:36:01 -0000 Subject: [issue1141] reading large files Message-ID: <1190090161.0.0.430757774012.issue1141@psf.upfronthosting.co.za> Sean Reifschneider added the comment: I'm closing this because the slow I/O issue is known and expected to be resolved as part of the Python 3.0 development. The Windows problems with missing lines should be opened as a separate issue. ---------- nosy: +jafo resolution: -> duplicate status: open -> closed __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Sep 18 07:41:26 2007 From: report at bugs.python.org (Shawn Ligocki) Date: Tue, 18 Sep 2007 05:41:26 -0000 Subject: [issue1727780] 64/32-bit issue when unpickling random.Random Message-ID: <1190094086.74.0.458977023104.issue1727780@psf.upfronthosting.co.za> Shawn Ligocki added the comment: Yep, tested it on a 64-bit machine and 2 32-bit machines and back and forth between them. It seems to resolve the problem. _____________________________________ Tracker _____________________________________ From report at bugs.python.org Tue Sep 18 07:44:29 2007 From: report at bugs.python.org (Sean Reifschneider) Date: Tue, 18 Sep 2007 05:44:29 -0000 Subject: [issue1155] Carbon.CF memory management problem Message-ID: <1190094269.19.0.825819950789.issue1155@psf.upfronthosting.co.za> Changes by Sean Reifschneider: ---------- priority: -> normal __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Sep 18 09:16:34 2007 From: report at bugs.python.org (Georg Brandl) Date: Tue, 18 Sep 2007 07:16:34 -0000 Subject: [issue1131] Reference Manual: "for statement" links to "break statement" Message-ID: <1190099794.96.0.489699227508.issue1131@psf.upfronthosting.co.za> Georg Brandl added the comment: There's nothing we can do here. There are three index entries for "for statement", which link to the for, break and continue pages. They can't be told apart, so we can't choose which one will be the first, the one to display "for statement", and which will be those to display "[Link]". ---------- nosy: +georg.brandl resolution: -> wont fix status: open -> closed __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Sep 18 09:20:14 2007 From: report at bugs.python.org (Georg Brandl) Date: Tue, 18 Sep 2007 07:20:14 -0000 Subject: [issue1173] yield expressions not documented in Language Reference Message-ID: <1190100014.33.0.710910868057.issue1173@psf.upfronthosting.co.za> New submission from Georg Brandl: This is fixed in SVN, you can view the docs e.g. here: http://docs.python.org/dev/reference/expressions#yield-expressions ---------- nosy: +georg.brandl resolution: -> out of date status: open -> closed __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Sep 18 09:21:07 2007 From: report at bugs.python.org (Georg Brandl) Date: Tue, 18 Sep 2007 07:21:07 -0000 Subject: [issue1174] new generator methods not documented in Library Reference Message-ID: <1190100067.38.0.561929065653.issue1174@psf.upfronthosting.co.za> Georg Brandl added the comment: This is fixed in SVN, you can view the docs e.g. here: http://docs.python.org/dev/reference/expressions#yield-expressions ---------- nosy: +georg.brandl resolution: -> out of date status: open -> closed __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Sep 18 12:37:34 2007 From: report at bugs.python.org (Alex Burr) Date: Tue, 18 Sep 2007 10:37:34 -0000 Subject: [issue1175] .readline() has bug WRT nonblocking files Message-ID: <1190111854.34.0.00279281221972.issue1175@psf.upfronthosting.co.za> New submission from Alex Burr: If you have made a file nonblocking using fcntl.fcntl, .readline() will discard the start of a line if you get EGAIN. It should attach the partial line to the exception somehow - or at least warn the user. I observe this on 2.3.5, but the same code exists in TRUNK ---------- components: Interpreter Core messages: 55993 nosy: ajb severity: normal status: open title: .readline() has bug WRT nonblocking files type: behavior versions: Python 2.3 __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Sep 18 12:37:34 2007 From: report at bugs.python.org (Alex Burr) Date: Tue, 18 Sep 2007 10:37:34 -0000 Subject: [issue1175] .readline() has bug WRT nonblocking files Message-ID: <1190111854.34.0.00279281221972.issue1175@psf.upfronthosting.co.za> New submission from Alex Burr: If you have made a file nonblocking using fcntl.fcntl, .readline() will discard the start of a line if you get EGAIN. It should attach the partial line to the exception somehow - or at least warn the user. I observe this on 2.3.5, but the same code exists in TRUNK ---------- components: Interpreter Core messages: 55993 nosy: ajb severity: normal status: open title: .readline() has bug WRT nonblocking files type: behavior versions: Python 2.3 __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Sep 18 13:48:48 2007 From: report at bugs.python.org (Sean Reifschneider) Date: Tue, 18 Sep 2007 11:48:48 -0000 Subject: [issue1151] "TypeError: expected string, bytes found" instead of KeyboardInterrupt Message-ID: <1190116128.73.0.885026909566.issue1151@psf.upfronthosting.co.za> Changes by Sean Reifschneider: ---------- priority: -> normal __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Sep 18 13:51:46 2007 From: report at bugs.python.org (Sean Reifschneider) Date: Tue, 18 Sep 2007 11:51:46 -0000 Subject: [issue1157] test_urllib2net fails on test_ftp Message-ID: <1190116306.23.0.341835597403.issue1157@psf.upfronthosting.co.za> Changes by Sean Reifschneider: ---------- assignee: -> jafo components: +Tests nosy: +jafo priority: -> normal __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Sep 18 14:09:46 2007 From: report at bugs.python.org (Sean Reifschneider) Date: Tue, 18 Sep 2007 12:09:46 -0000 Subject: [issue1083] Confusing error message when dividing timedelta using / Message-ID: <1190117386.37.0.231035771302.issue1083@psf.upfronthosting.co.za> Changes by Sean Reifschneider: ---------- priority: -> normal __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Sep 18 14:24:54 2007 From: report at bugs.python.org (Sean Reifschneider) Date: Tue, 18 Sep 2007 12:24:54 -0000 Subject: [issue1159] os.getenv() not updated after external module uses C putenv() Message-ID: <1190118294.79.0.305352621894.issue1159@psf.upfronthosting.co.za> Changes by Sean Reifschneider: ---------- priority: -> normal resolution: -> postponed __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Sep 18 14:26:25 2007 From: report at bugs.python.org (Sean Reifschneider) Date: Tue, 18 Sep 2007 12:26:25 -0000 Subject: [issue1161] Garbled chars in offending line of SyntaxError traceback Message-ID: <1190118385.18.0.289724172913.issue1161@psf.upfronthosting.co.za> Changes by Sean Reifschneider: ---------- priority: -> normal __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Sep 18 14:29:18 2007 From: report at bugs.python.org (Sean Reifschneider) Date: Tue, 18 Sep 2007 12:29:18 -0000 Subject: [issue1163] Patch to make py3k/Lib/test/test_thread.py use unittest Message-ID: <1190118558.25.0.205301738376.issue1163@psf.upfronthosting.co.za> Changes by Sean Reifschneider: ---------- priority: -> normal __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Sep 18 14:30:33 2007 From: report at bugs.python.org (Sean Reifschneider) Date: Tue, 18 Sep 2007 12:30:33 -0000 Subject: [issue1099] Mac compile fails with pydebug and framework enabled Message-ID: <1190118633.87.0.749794308734.issue1099@psf.upfronthosting.co.za> Changes by Sean Reifschneider: ---------- priority: -> normal __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Sep 18 14:43:18 2007 From: report at bugs.python.org (Sean Reifschneider) Date: Tue, 18 Sep 2007 12:43:18 -0000 Subject: [issue1135] xview/yview of Tix.Grid is broken Message-ID: <1190119398.08.0.991332018289.issue1135@psf.upfronthosting.co.za> Sean Reifschneider added the comment: I can verify that on Red Hat 7 Python 2.5 that the test does fail and the patch resolves it. ---------- nosy: +jafo priority: -> normal __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Sep 18 14:44:24 2007 From: report at bugs.python.org (Sean Reifschneider) Date: Tue, 18 Sep 2007 12:44:24 -0000 Subject: [issue1135] xview/yview of Tix.Grid is broken Message-ID: <1190119464.65.0.583898393473.issue1135@psf.upfronthosting.co.za> Changes by Sean Reifschneider: ---------- nosy: -jafo __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Sep 18 15:11:59 2007 From: report at bugs.python.org (Sean Reifschneider) Date: Tue, 18 Sep 2007 13:11:59 -0000 Subject: [issue1134] Parsing a simple script eats all of your memory Message-ID: <1190121119.72.0.411967893952.issue1134@psf.upfronthosting.co.za> Sean Reifschneider added the comment: Confirmed problem (used 4.5GB before I killed it), and that the second patch resolved the problem. I'm uploading the inline patch as an attachment, with the directory name in it as well (from svn diff). Bumping the priority to high because the side effect can cause all sorts of problems on a system including other processes being killed. ---------- nosy: +jafo priority: -> high __________________________________ Tracker __________________________________ -------------- next part -------------- A non-text attachment was scrubbed... Name: py3k-hungry-script.patch Type: text/x-patch Size: 516 bytes Desc: not available Url : http://mail.python.org/pipermail/python-bugs-list/attachments/20070918/de49850e/attachment.bin From report at bugs.python.org Tue Sep 18 15:14:22 2007 From: report at bugs.python.org (Sean Reifschneider) Date: Tue, 18 Sep 2007 13:14:22 -0000 Subject: [issue1134] Parsing a simple script eats all of your memory Message-ID: <1190121262.25.0.577660965905.issue1134@psf.upfronthosting.co.za> Changes by Sean Reifschneider: ---------- assignee: -> nnorwitz nosy: +nnorwitz __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Sep 18 15:30:20 2007 From: report at bugs.python.org (Sean Reifschneider) Date: Tue, 18 Sep 2007 13:30:20 -0000 Subject: [issue1157] test_urllib2net fails on test_ftp Message-ID: <1190122220.55.0.650724112955.issue1157@psf.upfronthosting.co.za> Changes by Sean Reifschneider: ---------- assignee: jafo -> nobody nosy: +nobody __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Sep 18 16:37:40 2007 From: report at bugs.python.org (Sean Reifschneider) Date: Tue, 18 Sep 2007 14:37:40 -0000 Subject: [issue1167] gdbm/ndbm 1.8.1+ needs libgdbm_compat.so Message-ID: <1190126260.54.0.443975866505.issue1167@psf.upfronthosting.co.za> Changes by Sean Reifschneider: ---------- priority: -> normal __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Sep 18 16:39:07 2007 From: report at bugs.python.org (Sean Reifschneider) Date: Tue, 18 Sep 2007 14:39:07 -0000 Subject: [issue1169] Option -OO doesn't remove docstrings from functions Message-ID: <1190126347.23.0.227043362567.issue1169@psf.upfronthosting.co.za> Changes by Sean Reifschneider: ---------- assignee: -> georg.brandl nosy: +georg.brandl priority: -> normal __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Sep 18 17:11:19 2007 From: report at bugs.python.org (Sean Reifschneider) Date: Tue, 18 Sep 2007 15:11:19 -0000 Subject: [issue1175] .readline() has bug WRT nonblocking files Message-ID: <1190128279.44.0.546002916304.issue1175@psf.upfronthosting.co.za> Sean Reifschneider added the comment: Doesn't the exception count as warning the user? We probably don't want to change readline to return a partial line in this case. An exception could be added for EGAIN that includes the partial line. Another option would be to just document the behavior for readline or fcntl. What is the right behavior for a non-blocking readline? Obviously, it can't return a None and buffer the line. Another option would be to define readline as a blocking operation and enable buffering before starting the readline, and possibly revert it when done. Opinions? ---------- components: +Library (Lib) -Interpreter Core nosy: +jafo priority: -> low type: behavior -> rfe versions: +Python 2.4, Python 2.5, Python 2.6 __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Sep 18 17:15:02 2007 From: report at bugs.python.org (Sean Reifschneider) Date: Tue, 18 Sep 2007 15:15:02 -0000 Subject: [issue1170] shlex have problems with parsing unicode Message-ID: <1190128502.42.0.443038262617.issue1170@psf.upfronthosting.co.za> Changes by Sean Reifschneider: ---------- priority: -> normal __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Sep 18 17:15:55 2007 From: report at bugs.python.org (Sean Reifschneider) Date: Tue, 18 Sep 2007 15:15:55 -0000 Subject: [issue1171] allow subclassing of bytes type Message-ID: <1190128555.75.0.368417149917.issue1171@psf.upfronthosting.co.za> Changes by Sean Reifschneider: ---------- assignee: -> gvanrossum keywords: +patch, py3k nosy: +gvanrossum priority: -> normal __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Sep 18 17:27:28 2007 From: report at bugs.python.org (Sean Reifschneider) Date: Tue, 18 Sep 2007 15:27:28 -0000 Subject: [issue1172] Documentation for done attribute of FieldStorage class Message-ID: <1190129248.21.0.00143921905047.issue1172@psf.upfronthosting.co.za> Sean Reifschneider added the comment: Patch looks good to me. Fred? Comments on "should I do more fixes": Just straight documentation changes are, in my experience, fairly likely to be processed quickly. Changes to the code may take quite a lot more discussion. Smaller, individual patches are likely to be taken much more than large mega patches that change many things. So, my recommendation would be to do individual efforts: Fix the current documentation, fix "XXX fix me" parts, do enhancements. I understand where you're coming from, I spent a full day implementing string.rsplit() including documentation, only to have it languish for around a year before other people re-opening the rejected submission finally got it accepted. However, python definitely benefits from the attention. Sometimes things do get dropped, because of other commitments from the maintainers. Assign your issue that has been ignored to me and I'll take a look at it. ---------- assignee: -> fdrake keywords: +patch nosy: +fdrake, jafo priority: -> normal versions: +Python 2.6 __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Sep 18 17:40:36 2007 From: report at bugs.python.org (Alex Burr) Date: Tue, 18 Sep 2007 15:40:36 -0000 Subject: [issue1175] .readline() has bug WRT nonblocking files Message-ID: <1190130036.49.0.593154021309.issue1175@psf.upfronthosting.co.za> Alex Burr added the comment: The exception would count as a warning if it wasn't EGAIN. One expects to catch EGAIN and try again. The current situation is unfortunate because it *nearly* works. My scenario is: I'm driving GDB/MI via popen2.Popen3 ( gdbCommand, False,1). It works for most GDB commands, but sometimes GDB returns a huge line and I get EGAIN in the middle. (For my purposes, I've worked round it, by avoiding the command which generates a long line) __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Sep 18 17:46:52 2007 From: report at bugs.python.org (Sean Reifschneider) Date: Tue, 18 Sep 2007 15:46:52 -0000 Subject: [issue1175] .readline() has bug WRT nonblocking files Message-ID: <1190130412.55.0.563149904161.issue1175@psf.upfronthosting.co.za> Sean Reifschneider added the comment: Why are you putting the file in non-blocking mode? Why not just reading in blocking mode? If you want to do other work when a line is not available, you could use select to check to see if there's data ready via a small or 0 timeout. __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Sep 18 18:25:13 2007 From: report at bugs.python.org (Alex Burr) Date: Tue, 18 Sep 2007 16:25:13 -0000 Subject: [issue1175] .readline() has bug WRT nonblocking files Message-ID: <1190132713.36.0.51002200136.issue1175@psf.upfronthosting.co.za> Alex Burr added the comment: I don't need to change my code as I have now worked round the problem, but for an example of why someone might want nonblocking mode: It was not actually in order to do any more work, but because I was managing both input and output to gdb in one thread (for simplicity). I therefore needed to collect everything gdb had printed out, but not try to read any more and cause a block because then I could not give GDB its next command, and gdb would not give me any more until I did. I think I did try select, but if I recall correctly, that doesn't work well with .readline() either. I can't remember why, though. __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Sep 18 18:55:19 2007 From: report at bugs.python.org (Fred L. Drake, Jr.) Date: Tue, 18 Sep 2007 16:55:19 -0000 Subject: [issue1172] Documentation for done attribute of FieldStorage class Message-ID: <1190134519.2.0.584886597166.issue1172@psf.upfronthosting.co.za> Fred L. Drake, Jr. added the comment: Looks good to me too. This should be committed. ---------- assignee: fdrake -> jafo resolution: -> accepted versions: +Python 2.5, Python 3.0 __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Sep 18 18:59:53 2007 From: report at bugs.python.org (Sergio Correia) Date: Tue, 18 Sep 2007 16:59:53 -0000 Subject: [issue1176] str.split() takes no keyword arguments (Should this be expected?) Message-ID: <1190134792.72.0.164099608894.issue1176@psf.upfronthosting.co.za> New submission from Sergio Correia: str.split() does not accept maxsplits as a keyword argument. If i want to split a string, and, say, get its first word, I do this: >>> 'SPAM eggs eggs spam spam ham'.split(None, 1)[0] 'SPAM' However, as documented on help(str.split), the separator is optional, so I expected this to work: >>> 'SPAM eggs eggs spam spam ham'.split(maxsplit=1) Traceback (most recent call last): File "", line 1, in 'SPAM eggs eggs spam spam ham'.split(maxsplit=1) TypeError: split() takes no keyword arguments I feel allowing keyword arguments is convenient, but is there a reason behind not allowing them? ---------- components: Library (Lib) messages: 56002 nosy: sergioc severity: minor status: open title: str.split() takes no keyword arguments (Should this be expected?) type: behavior versions: Python 2.5 __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Sep 18 18:59:52 2007 From: report at bugs.python.org (Sergio Correia) Date: Tue, 18 Sep 2007 16:59:52 -0000 Subject: [issue1176] str.split() takes no keyword arguments (Should this be expected?) Message-ID: <1190134792.72.0.164099608894.issue1176@psf.upfronthosting.co.za> New submission from Sergio Correia: str.split() does not accept maxsplits as a keyword argument. If i want to split a string, and, say, get its first word, I do this: >>> 'SPAM eggs eggs spam spam ham'.split(None, 1)[0] 'SPAM' However, as documented on help(str.split), the separator is optional, so I expected this to work: >>> 'SPAM eggs eggs spam spam ham'.split(maxsplit=1) Traceback (most recent call last): File "", line 1, in 'SPAM eggs eggs spam spam ham'.split(maxsplit=1) TypeError: split() takes no keyword arguments I feel allowing keyword arguments is convenient, but is there a reason behind not allowing them? ---------- components: Library (Lib) messages: 56002 nosy: sergioc severity: minor status: open title: str.split() takes no keyword arguments (Should this be expected?) type: behavior versions: Python 2.5 __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Sep 18 19:01:46 2007 From: report at bugs.python.org (Sergio Correia) Date: Tue, 18 Sep 2007 17:01:46 -0000 Subject: [issue1176] str.split() takes no keyword arguments (Should this be expected?) Message-ID: <1190134906.02.0.727718447329.issue1176@psf.upfronthosting.co.za> Sergio Correia added the comment: As a side note, this is slightly related with: http://mail.python.org/pipermail/python-dev/2000-October/009694.html http://bugs.python.org/issue1123 (but check the date of the first link!) __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Sep 18 19:59:21 2007 From: report at bugs.python.org (Bob Kline) Date: Tue, 18 Sep 2007 17:59:21 -0000 Subject: [issue1172] Documentation for done attribute of FieldStorage class Message-ID: <1190138361.96.0.744877832122.issue1172@psf.upfronthosting.co.za> Bob Kline added the comment: Thanks for the very quick follow-up. I may be shooting myself in the foot here, but Sean's encouragement about getting patches to the actual code lead me to wonder if it might be better to go straight for the optimal solution here. As I implied in my original message for this issue, there are approaches for exposing the ability to detect failure which would be more straightforward than testing for field.done == -1. A step in the right direction might be an attribute named something like 'incomplete' (True|False). Or perhaps an access method? Based on my more recent experience with getting code patches accepted, I had settled on just documenting the existing code more fully as a minimal solution, but if Sean's more optimistic advice is justified, I'd be happy to wait a little longer for a cleaner solution (and to pitch in for the work to create it, if that's appropriate). I know I have more than one bit of Python code I wrote years ago for situations similar to this where if I had to do it over again I would have thrown an exception, and maybe that's the right thing to do here, with an optional argument to the constructor which suppresses the exception. Perhaps Guido might want to weigh in with his own preferences (this is his code, and he's still listed as the current maintainer of the module). But I'd rather have the documentation patch for the existing code than nothing at all. Cheers, Bob __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Sep 18 20:09:00 2007 From: report at bugs.python.org (Bob Kline) Date: Tue, 18 Sep 2007 18:09:00 -0000 Subject: [issue1172] Documentation for done attribute of FieldStorage class Message-ID: <1190138940.3.0.570149418362.issue1172@psf.upfronthosting.co.za> Bob Kline added the comment: Sean Reifschneider wrote: > Assign your issue that has been ignored to me and I'll take a > look at it. I tried, but it doesn't look like I have sufficient permission to change the assignment. It's http://bugs.python.org/issue1541463 Thanks! __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Sep 18 20:38:59 2007 From: report at bugs.python.org (Pat LaVarre) Date: Tue, 18 Sep 2007 18:38:59 -0000 Subject: [issue1082] platform system may be Windows or Microsoft since Vista Message-ID: <1190140739.33.0.1809920402.issue1082@psf.upfronthosting.co.za> Pat LaVarre added the comment: Works for me. I tried python-trunk-vistaplatform-v2.patch in one sample of 2006-11 RTM Vista plus 2.5.1 Python plus this patch. I quote: >>> import platform >>> platform.uname() ('Windows', '[redacted]', 'Vista', '6.0.6000', '', '') >>> platform.system() 'Windows' >>> platform.version() '6.0.6000' >>> __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Sep 18 20:51:33 2007 From: report at bugs.python.org (Pat LaVarre) Date: Tue, 18 Sep 2007 18:51:33 -0000 Subject: [issue1082] platform system may be Windows or Microsoft since Vista Message-ID: <1190141493.02.0.349689865426.issue1082@psf.upfronthosting.co.za> Pat LaVarre added the comment: --- USAGE: I agree we should let people in future write: if not platform.system('Windows'): rather than: if not (platform.system() in ('Microsoft', 'Windows')): now that our people can no longer rely on Python in Vista correctly understanding the plain human intent of such code fragments as: if platform.system() != 'Windows': --- DRAFT SPEC: platform.system(name = None) returns the system name if name is None, else returns the system name if name is a well-known alias of the system name, else returns None. The string 'Mac OS X' is a well-known alias for the system 'Darwin'. The string 'Windows' is a well-known alias for the system 'Microsoft' in 2.5.1 Python on Vista. The system name is itself a well-known alias of the system name. For example, 'Darwin' is a well-known alias of the 'Darwin' system that is sold as the kernel of 'Mac OS X'. Etc. __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Sep 18 22:03:02 2007 From: report at bugs.python.org (=?utf-8?q?=0A=09=09=09=09=09Jim_Jewett=0A=09=09=09=09?=) Date: Tue, 18 Sep 2007 20:03:02 -0000 Subject: [issue1778443] robotparser.py fixes Message-ID: <1190145782.57.0.112155259629.issue1778443@psf.upfronthosting.co.za> Jim Jewett added the comment: On line 108 (new 104), spaces should probably be added on both sides of the comparison operator, instead of only after the ">=". The "%s" changes might end up getting changed again as part of 2to3, but this is a clear improvement over status quo, particularly with the loops. I recommend applying. ---------- nosy: +jimjjewett _____________________________________ Tracker _____________________________________ From report at bugs.python.org Tue Sep 18 22:22:53 2007 From: report at bugs.python.org (=?utf-8?q?=0A=09=09=09=09=09Jim_Jewett=0A=09=09=09=09?=) Date: Tue, 18 Sep 2007 20:22:53 -0000 Subject: [issue1177] urllib* 20x responses not OK? Message-ID: <1190146973.85.0.192058090901.issue1177@psf.upfronthosting.co.za> New submission from Jim Jewett : Under the http protocol, any 2xx response is OK. urllib.py and urllib2.py hardcoded only response 200 (the most common). http://bugs.python.org/issue912845 added 206 as acceptable to urllib2, but not any other 20x responses. (It also didn't fix urllib.) Suggested for 2.6, as it does change behavior. (Also see duplicate http://bugs.python.org/issue971965 which I will try to close after opening this. ) ---------- components: Library (Lib) messages: 56009 nosy: jimjjewett severity: normal status: open title: urllib* 20x responses not OK? type: behavior versions: Python 2.6 __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Sep 18 22:22:54 2007 From: report at bugs.python.org (=?utf-8?q?=0A=09=09=09=09=09Jim_Jewett=0A=09=09=09=09?=) Date: Tue, 18 Sep 2007 20:22:54 -0000 Subject: [issue1177] urllib* 20x responses not OK? Message-ID: <1190146973.85.0.192058090901.issue1177@psf.upfronthosting.co.za> New submission from Jim Jewett : Under the http protocol, any 2xx response is OK. urllib.py and urllib2.py hardcoded only response 200 (the most common). http://bugs.python.org/issue912845 added 206 as acceptable to urllib2, but not any other 20x responses. (It also didn't fix urllib.) Suggested for 2.6, as it does change behavior. (Also see duplicate http://bugs.python.org/issue971965 which I will try to close after opening this. ) ---------- components: Library (Lib) messages: 56009 nosy: jimjjewett severity: normal status: open title: urllib* 20x responses not OK? type: behavior versions: Python 2.6 __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Sep 18 22:25:44 2007 From: report at bugs.python.org (=?utf-8?q?=0A=09=09=09=09=09Jim_Jewett=0A=09=09=09=09?=) Date: Tue, 18 Sep 2007 20:25:44 -0000 Subject: [issue971965] urllib2 raises exception with non-200 success codes. Message-ID: <1190147144.58.0.385827545962.issue971965@psf.upfronthosting.co.za> Jim Jewett added the comment: (Attempting to) close; superceded by bugs.python.org/issue1177 ---------- nosy: +jimjjewett type: -> behavior ____________________________________ Tracker ____________________________________ From report at bugs.python.org Tue Sep 18 22:43:07 2007 From: report at bugs.python.org (Facundo Batista) Date: Tue, 18 Sep 2007 20:43:07 -0000 Subject: [issue1177] urllib* 20x responses not OK? Message-ID: <1190148187.6.0.837297324825.issue1177@psf.upfronthosting.co.za> Facundo Batista added the comment: It should behave as you say, yes. I fixed the class HTTPErrorProcessor(BaseHandler) regarding this issue, to not raise an error if response is 2xx (see rev 54927). Regards, ---------- nosy: +facundobatista __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Sep 18 22:50:30 2007 From: report at bugs.python.org (Marc-Andre Lemburg) Date: Tue, 18 Sep 2007 20:50:30 -0000 Subject: [issue1082] platform system may be Windows or Microsoft since Vista Message-ID: <1190148630.68.0.090377247267.issue1082@psf.upfronthosting.co.za> Marc-Andre Lemburg added the comment: Pat, we already have system_alias() for exactly the purpose you suggested. Software relying on platform.system() reporting "Vista" will have to use Python 2.5.2 as minimum Python version system requirement - pretty much the same as with all other bug fixes. __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Sep 18 22:56:40 2007 From: report at bugs.python.org (Pat LaVarre) Date: Tue, 18 Sep 2007 20:56:40 -0000 Subject: [issue1082] platform system may be Windows or Microsoft since Vista Message-ID: <1190149000.55.0.400885176801.issue1082@psf.upfronthosting.co.za> Pat LaVarre added the comment: Thanks for the cultural education of 2.5.1 isn't supposed to work, I didn't know that. Also I'm glad to hear this is fixed for 2.5.2 already. Sorry I'm too new & ignorant to understand why you believe this is fixed. I don't see that we already have a way to say things like: if not platform.system('Linux'): Do we have a way to say things like that? My first Googles, tried here now at Mac OS X, give me useless suggestions like: >>> platform.platform(aliased=True) 'Darwin-9.0.0b5-i386-32bit' >>> platform.system_alias(platform.system(), platform.release(), platform.version()) ('Darwin', '9.0.0b5', 'Darwin Kernel Version 9.0.0b5: Fri Aug 17 17:24:24 PDT 2007; root:xnu-1182~1/RELEASE_I386') >>> Practically speaking, I was getting by ok with: if platform.system() != 'Windows': Until that broke in Vista plus 2.5.1. __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Sep 18 23:18:01 2007 From: report at bugs.python.org (Sean Reifschneider) Date: Tue, 18 Sep 2007 21:18:01 -0000 Subject: [issue1176] str.split() takes no keyword arguments (Should this be expected?) Message-ID: <1190150281.79.0.606821050579.issue1176@psf.upfronthosting.co.za> Changes by Sean Reifschneider: ---------- priority: -> normal __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Sep 18 23:18:50 2007 From: report at bugs.python.org (Sean Reifschneider) Date: Tue, 18 Sep 2007 21:18:50 -0000 Subject: [issue1177] urllib* 20x responses not OK? Message-ID: <1190150330.59.0.0120422406378.issue1177@psf.upfronthosting.co.za> Sean Reifschneider added the comment: Facundo: Should this be closed? ---------- nosy: +jafo priority: -> normal __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Sep 18 23:24:29 2007 From: report at bugs.python.org (Sean Reifschneider) Date: Tue, 18 Sep 2007 21:24:29 -0000 Subject: [issue1175] .readline() has bug WRT nonblocking files Message-ID: <1190150669.73.0.0554042714469.issue1175@psf.upfronthosting.co.za> Sean Reifschneider added the comment: Arguably, you should be using "select" and "read" (instead of readline) for this operation. That's what I've done in the past when doing something similar. Specifically, I believe I have looped reading into a buffer with read, and using select with a timeout (even a fraction of a second can work) until the timeout triggers. This way I don't block, but I also don't run into problems with the system call returning an error. I avoid using readline in this case because I don't expect it to work well on the stdout of an interactive command. You may also want to look at the pty module. I guess I'd say this should probably go to the python mailing list for further discussion. Can you post a message there about it? __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Sep 18 23:30:46 2007 From: report at bugs.python.org (=?utf-8?q?=0A=09=09=09=09=09Jim_Jewett=0A=09=09=09=09?=) Date: Tue, 18 Sep 2007 21:30:46 -0000 Subject: [issue1177] urllib* 20x responses not OK? Message-ID: <1190151046.54.0.397574358474.issue1177@psf.upfronthosting.co.za> Jim Jewett added the comment: Jafo: His fix is great for urllib2, but the same issue applies to the original urllib. The ticket should not be closed until a similar fix is made to lines 330 and 417 of urllib.py. That is, change "if errcode == 200:" to "if 200 <= errcode < 300:" (Or, if rejecting the change, add a comment saying that it is left that way intentionally for backwards compatibility.) -jJ __________________________________ Tracker __________________________________ From report at bugs.python.org Wed Sep 19 00:03:31 2007 From: report at bugs.python.org (Tal Einat) Date: Tue, 18 Sep 2007 22:03:31 -0000 Subject: [issue1178] IDLE - add "paste code" functionality Message-ID: <1190153010.77.0.038299898053.issue1178@psf.upfronthosting.co.za> New submission from Tal Einat: Patch adding a 'Paste Code' item to the 'Edit' menu, as well as hotkeys. Using 'Paste Code' instead of the normal paste will remove prompts ('>>> ' or '... ') from the code, and also remove empty lines if pasting to a shell window. This allows easily copy/pasting code between shell and editor windows, as well as easily pasting code from other applications (e.g. a web browser) into IDLE. This patch uses IDLE's PyParse.py for parsing code, and Tk's clipboard API for interaction with the clipboard (it changes the clipboard's contents, generates a normal paste event, and changes the contents back). Test only on WinXP SP2 so far, needs to be tested on other platforms, especially the clipboard interaction. ---------- components: IDLE files: IDLE_paste_code.070918.patch messages: 56017 nosy: taleinat severity: minor status: open title: IDLE - add "paste code" functionality type: behavior versions: Python 2.6 __________________________________ Tracker __________________________________ -------------- next part -------------- A non-text attachment was scrubbed... Name: IDLE_paste_code.070918.patch Type: application/octet-stream Size: 5292 bytes Desc: not available Url : http://mail.python.org/pipermail/python-bugs-list/attachments/20070918/173a1838/attachment-0002.obj From report at bugs.python.org Wed Sep 19 00:03:30 2007 From: report at bugs.python.org (Tal Einat) Date: Tue, 18 Sep 2007 22:03:30 -0000 Subject: [issue1178] IDLE - add "paste code" functionality Message-ID: <1190153010.77.0.038299898053.issue1178@psf.upfronthosting.co.za> New submission from Tal Einat: Patch adding a 'Paste Code' item to the 'Edit' menu, as well as hotkeys. Using 'Paste Code' instead of the normal paste will remove prompts ('>>> ' or '... ') from the code, and also remove empty lines if pasting to a shell window. This allows easily copy/pasting code between shell and editor windows, as well as easily pasting code from other applications (e.g. a web browser) into IDLE. This patch uses IDLE's PyParse.py for parsing code, and Tk's clipboard API for interaction with the clipboard (it changes the clipboard's contents, generates a normal paste event, and changes the contents back). Test only on WinXP SP2 so far, needs to be tested on other platforms, especially the clipboard interaction. ---------- components: IDLE files: IDLE_paste_code.070918.patch messages: 56017 nosy: taleinat severity: minor status: open title: IDLE - add "paste code" functionality type: behavior versions: Python 2.6 __________________________________ Tracker __________________________________ -------------- next part -------------- A non-text attachment was scrubbed... Name: IDLE_paste_code.070918.patch Type: application/octet-stream Size: 5292 bytes Desc: not available Url : http://mail.python.org/pipermail/python-bugs-list/attachments/20070918/173a1838/attachment-0003.obj From report at bugs.python.org Wed Sep 19 01:40:00 2007 From: report at bugs.python.org (Sean Reifschneider) Date: Tue, 18 Sep 2007 23:40:00 -0000 Subject: [issue1172] Documentation for done attribute of FieldStorage class Message-ID: <1190158800.55.0.108600043105.issue1172@psf.upfronthosting.co.za> Sean Reifschneider added the comment: Committed in trunk revision 58199 Committed in 25-maint revision 58200 Committed in py3k revision 58201 ---------- status: open -> closed __________________________________ Tracker __________________________________ From report at bugs.python.org Wed Sep 19 01:45:43 2007 From: report at bugs.python.org (Sean Reifschneider) Date: Tue, 18 Sep 2007 23:45:43 -0000 Subject: [issue1178] IDLE - add "paste code" functionality Message-ID: <1190159143.17.0.326339249845.issue1178@psf.upfronthosting.co.za> Changes by Sean Reifschneider: ---------- assignee: -> ronaldoussoren keywords: +patch nosy: +ronaldoussoren priority: -> low type: behavior -> rfe __________________________________ Tracker __________________________________ From report at bugs.python.org Wed Sep 19 01:46:27 2007 From: report at bugs.python.org (Sean Reifschneider) Date: Tue, 18 Sep 2007 23:46:27 -0000 Subject: [issue1178] IDLE - add "paste code" functionality Message-ID: <1190159187.71.0.834184500482.issue1178@psf.upfronthosting.co.za> Changes by Sean Reifschneider: ---------- assignee: ronaldoussoren -> nobody nosy: +nobody __________________________________ Tracker __________________________________ From report at bugs.python.org Wed Sep 19 02:49:10 2007 From: report at bugs.python.org (Sean Reifschneider) Date: Wed, 19 Sep 2007 00:49:10 -0000 Subject: [issue1745035] DoS smtpd vulnerability Message-ID: <1190162950.81.0.0324882995728.issue1745035@psf.upfronthosting.co.za> Sean Reifschneider added the comment: Patch is inline above. RFC2822 says lines MUST be less than 998 bytes long, so this should be fine. What does this do when a line longer than 4096 bytes is found? Does it report an error to the SMTP client? That's my only concern. ---------- assignee: -> barry keywords: +patch nosy: +barry, jafo _____________________________________ Tracker _____________________________________ From report at bugs.python.org Wed Sep 19 03:02:34 2007 From: report at bugs.python.org (Ismail Donmez) Date: Wed, 19 Sep 2007 01:02:34 -0000 Subject: [issue1179] [CVE-2007-4965] Integer overflow in imageop module Message-ID: <1190163754.35.0.664170861932.issue1179@psf.upfronthosting.co.za> New submission from Ismail Donmez: As reported at http://lists.grok.org.uk/pipermail/full-disclosure/2007-September/065826.html . There is an integer overflow in imageop module which results in an interpreter crash. Original proof of concept code is attached. ---------- components: Library (Lib) files: poc.py messages: 56020 nosy: cartman severity: normal status: open title: [CVE-2007-4965] Integer overflow in imageop module type: security versions: Python 2.5 __________________________________ Tracker __________________________________ -------------- next part -------------- A non-text attachment was scrubbed... Name: poc.py Type: text/x-python Size: 263 bytes Desc: not available Url : http://mail.python.org/pipermail/python-bugs-list/attachments/20070919/d6fc562e/attachment.py From report at bugs.python.org Wed Sep 19 03:02:34 2007 From: report at bugs.python.org (Ismail Donmez) Date: Wed, 19 Sep 2007 01:02:34 -0000 Subject: [issue1179] [CVE-2007-4965] Integer overflow in imageop module Message-ID: <1190163754.35.0.664170861932.issue1179@psf.upfronthosting.co.za> New submission from Ismail Donmez: As reported at http://lists.grok.org.uk/pipermail/full-disclosure/2007-September/065826.html . There is an integer overflow in imageop module which results in an interpreter crash. Original proof of concept code is attached. ---------- components: Library (Lib) files: poc.py messages: 56020 nosy: cartman severity: normal status: open title: [CVE-2007-4965] Integer overflow in imageop module type: security versions: Python 2.5 __________________________________ Tracker __________________________________ -------------- next part -------------- A non-text attachment was scrubbed... Name: poc.py Type: text/x-python Size: 263 bytes Desc: not available Url : http://mail.python.org/pipermail/python-bugs-list/attachments/20070919/d6fc562e/attachment-0001.py From report at bugs.python.org Wed Sep 19 04:22:39 2007 From: report at bugs.python.org (Brett Cannon) Date: Wed, 19 Sep 2007 02:22:39 -0000 Subject: [issue1123] split(None, maxsplit) does not strip whitespace correctly Message-ID: <1190168559.73.0.873935488914.issue1123@psf.upfronthosting.co.za> Brett Cannon added the comment: The algorithm is actually kind of odd:: >>> " a b".split(None, 0) ['a b'] >>> "a b ".split(None, 0) ['a b '] >>> "a b ".split(None, 1) ['a', 'b '] So trailing whitespace on the original string is stripped only if the number of splits is great enough to lead to a possible split past the last element. But leading whitespace is always removed. Basically the algorithm stops looking for whitespace once it has encountered maxsplit instances of contiguous whitespace plus leading whitespace. ---------- nosy: +brett.cannon __________________________________ Tracker __________________________________ From report at bugs.python.org Wed Sep 19 04:27:43 2007 From: report at bugs.python.org (Sean Reifschneider) Date: Wed, 19 Sep 2007 02:27:43 -0000 Subject: [issue1179] [CVE-2007-4965] Integer overflow in imageop module Message-ID: <1190168863.59.0.582741056168.issue1179@psf.upfronthosting.co.za> Sean Reifschneider added the comment: It's unclear if this only causes a crash or if it can inject data. Referenced mailing list post points out where one error is. ---------- nosy: +jafo priority: -> high __________________________________ Tracker __________________________________ From report at bugs.python.org Wed Sep 19 04:28:12 2007 From: report at bugs.python.org (Brett Cannon) Date: Wed, 19 Sep 2007 02:28:12 -0000 Subject: [issue1176] str.split() takes no keyword arguments (Should this be expected?) Message-ID: <1190168892.13.0.110657951042.issue1176@psf.upfronthosting.co.za> Brett Cannon added the comment: This is expected as str.split() is implemented in C and C code only has keyword arguments if someone puts in the time and effort to support them. Support could be added if so desired. But it does slow down argument passing. If you look you will notice that none of str's methods have keyword support. Changing this to an rfe. ---------- nosy: +brett.cannon priority: normal -> low type: behavior -> rfe __________________________________ Tracker __________________________________ From report at bugs.python.org Wed Sep 19 04:42:36 2007 From: report at bugs.python.org (Sean Reifschneider) Date: Wed, 19 Sep 2007 02:42:36 -0000 Subject: [issue1123] split(None, maxsplit) does not strip whitespace correctly Message-ID: <1190169756.1.0.807085455037.issue1123@psf.upfronthosting.co.za> Sean Reifschneider added the comment: In looking at the current documentation: http://docs.python.org/dev/library/string.html#string.split I don't see the wording the original poster mentions. The current documentation of the separator is clear and reasonable. I'm going to call this closed, unless someone can suggest specific wording changes to the document let's call this done. ---------- resolution: -> invalid status: open -> closed __________________________________ Tracker __________________________________ From report at bugs.python.org Wed Sep 19 05:01:35 2007 From: report at bugs.python.org (Vladimir Konjkov) Date: Wed, 19 Sep 2007 03:01:35 -0000 Subject: [issue1722225] Build on QNX Message-ID: <1190170895.6.0.269632404137.issue1722225@psf.upfronthosting.co.za> Vladimir Konjkov added the comment: However, I don't understand this entire point: What do you mean by "using TCGETA requires that struct termio be defined"? How is TCGETA defined to produce such a dependency? TCGETA is a constant, right? ------------------------------------------------------------------- terminal I/O control has three different implementations under SVR4, BSD, and POSIX.1. SVR4 uses the termio structure, and various ioctl calls (such as TCGETA, TCSETA, TCSETAW, and TCSETAF) on a terminal device to obtain and set parameters with the termio structure. Under POSIX, the termios struct is used, along with various functions defined by POSIX.1, such as tcsetattr and tcgetattr. Under QNX - is POSIX implimentation with functions tcsetattr and tcgetattr defined, but in that included in define MACROS TCGETA, TCSETA, TCSETAW, and TCSETAF. That's why we need or simlink . Why do you want TCGETA, TCSETA, TCSETAW, and TCSETAF in Python if there is POSIX tcsetattr and tcgetattr functions? _____________________________________ Tracker _____________________________________ From report at bugs.python.org Wed Sep 19 06:12:51 2007 From: report at bugs.python.org (Nir Soffer) Date: Wed, 19 Sep 2007 04:12:51 -0000 Subject: [issue1123] split(None, maxsplit) does not strip whitespace correctly Message-ID: <1190175171.06.0.892508548582.issue1123@psf.upfronthosting.co.za> Nir Soffer added the comment: I quoted str.split docs: - http://docs.python.org/lib/string-methods.html - http://docs.python.org/dev/library/stdtypes.html - http://docs.python.org/dev/3.0/library/stdtypes.html string.split doc does it explain this: >>> ' a b '.split(None, 1) ['a', 'b '] >>> ' a b '.split(None, 2) ['a', 'b'] .split method docs is more clear and describe this in a very simple way. This is a better description of the current behavior: "If sep is not specified or is None, a different splitting algorithm is applied. First, whitespace characters (spaces, tabs, newlines, returns, and formfeeds) are stripped from the start of the string. Then, words are separated by arbitrary length strings of whitespace characters. Consecutive whitespace delimiters are treated as a single delimiter ("' 1 \t 2 \n 3 '.split()" returns "['1', '2', '3']"). If maxsplit is nonzero, at most maxsplit number of splits occur, and the remainder of the string is returned as the final element of the list, unless it is empty. Splitting an empty string or a string consisting of just whitespace returns an empty list." __________________________________ Tracker __________________________________ From report at bugs.python.org Wed Sep 19 07:22:23 2007 From: report at bugs.python.org (Vladimir Konjkov) Date: Wed, 19 Sep 2007 05:22:23 -0000 Subject: [issue1722225] Build on QNX Message-ID: <1190179343.07.0.283236632495.issue1722225@psf.upfronthosting.co.za> Vladimir Konjkov added the comment: addition TCGETA is a constant. That's right! under QNX4 TCGETA defined as MACRO in . That's right! in Modules/termios.c there's #include That's right too! What's problem after all? Problem is that MACRO definition of TCGETA need sizeof(struct termio), that's (struct termio) defined in . But not included in instead of it included in and we need, if we want to have TCGETA, start with that's included both and too and do it right way! It's clearly now? _____________________________________ Tracker _____________________________________ From report at bugs.python.org Wed Sep 19 08:20:44 2007 From: report at bugs.python.org (Georg Brandl) Date: Wed, 19 Sep 2007 06:20:44 -0000 Subject: [issue971965] urllib2 raises exception with non-200 success codes. Message-ID: <1190182844.32.3.84934430815e-05.issue971965@psf.upfronthosting.co.za> Changes by Georg Brandl: ---------- resolution: -> duplicate status: open -> closed superseder: -> urllib* 20x responses not OK? ____________________________________ Tracker ____________________________________ From report at bugs.python.org Wed Sep 19 08:36:27 2007 From: report at bugs.python.org (Georg Brandl) Date: Wed, 19 Sep 2007 06:36:27 -0000 Subject: [issue1135] xview/yview of Tix.Grid is broken Message-ID: <1190183787.75.0.573861581209.issue1135@psf.upfronthosting.co.za> Georg Brandl added the comment: IMO the patch is not complete, the xview method should rather be implemented like these in Tkinter.py. Assigning to Martin. ---------- assignee: -> loewis nosy: +georg.brandl, loewis __________________________________ Tracker __________________________________ From report at bugs.python.org Wed Sep 19 08:37:38 2007 From: report at bugs.python.org (Georg Brandl) Date: Wed, 19 Sep 2007 06:37:38 -0000 Subject: [issue1169] Option -OO doesn't remove docstrings from functions Message-ID: <1190183858.59.0.684338554953.issue1169@psf.upfronthosting.co.za> Georg Brandl added the comment: Fixed in rev. 58204, 58205 (2.5). ---------- resolution: -> fixed status: open -> closed __________________________________ Tracker __________________________________ From report at bugs.python.org Wed Sep 19 09:55:19 2007 From: report at bugs.python.org (Sean Reifschneider) Date: Wed, 19 Sep 2007 07:55:19 -0000 Subject: [issue1177] urllib* 20x responses not OK? Message-ID: <1190188519.35.0.445270291698.issue1177@psf.upfronthosting.co.za> Sean Reifschneider added the comment: Ported code change to urllib, passes tests, committed as revision 58206 ---------- resolution: -> accepted status: open -> closed __________________________________ Tracker __________________________________ From report at bugs.python.org Wed Sep 19 10:06:20 2007 From: report at bugs.python.org (Georg Brandl) Date: Wed, 19 Sep 2007 08:06:20 -0000 Subject: [issue1177] urllib* 20x responses not OK? Message-ID: <1190189180.46.0.914800143238.issue1177@psf.upfronthosting.co.za> Georg Brandl added the comment: This might need at least a NEWS entry, if not a documentation clarification. ---------- nosy: +georg.brandl __________________________________ Tracker __________________________________ From report at bugs.python.org Wed Sep 19 10:12:00 2007 From: report at bugs.python.org (Sean Reifschneider) Date: Wed, 19 Sep 2007 08:12:00 -0000 Subject: [issue1541463] Optimizations for cgi.FieldStorage methods Message-ID: <1190189520.83.0.747108576187.issue1541463@psf.upfronthosting.co.za> Sean Reifschneider added the comment: Georg: This has been assigned to you, do you have any thoughts on this? If you don't, please assign back to me. ---------- keywords: +py3k nosy: +jafo _____________________________________ Tracker _____________________________________ From report at bugs.python.org Wed Sep 19 10:19:46 2007 From: report at bugs.python.org (Sean Reifschneider) Date: Wed, 19 Sep 2007 08:19:46 -0000 Subject: [issue1177] urllib* 20x responses not OK? Message-ID: <1190189986.47.0.0598480098638.issue1177@psf.upfronthosting.co.za> Sean Reifschneider added the comment: Facundo, can you do a NEWS update on this? ---------- assignee: -> facundobatista keywords: +patch status: closed -> open __________________________________ Tracker __________________________________ From report at bugs.python.org Wed Sep 19 11:19:36 2007 From: report at bugs.python.org (Georg Brandl) Date: Wed, 19 Sep 2007 09:19:36 -0000 Subject: [issue1541463] Optimizations for cgi.FieldStorage methods Message-ID: <1190193576.45.0.985039215673.issue1541463@psf.upfronthosting.co.za> Georg Brandl added the comment: Thanks for notifying me. The tracker currently doesn't send notifications if you only set the assignee, but don't include a message. I hope this will be fixed soon. The __nonzero__() is unproblematic. The keys() produced in this way will have an unpredictable order, while the original way preserves the order of names in self.list. I don't know whether that would cause problems. ---------- keywords: +patch -py3k _____________________________________ Tracker _____________________________________ From report at bugs.python.org Wed Sep 19 11:27:24 2007 From: report at bugs.python.org (Sean Reifschneider) Date: Wed, 19 Sep 2007 09:27:24 -0000 Subject: [issue1541463] Optimizations for cgi.FieldStorage methods Message-ID: <1190194044.14.0.350062996035.issue1541463@psf.upfronthosting.co.za> Sean Reifschneider added the comment: Thanks for correcting my mis-click on the "patch" item, gbot. As far as the order goes, is this something that needs to be discussed on c.l.p, or should we assign it to someone else who might have an opinion on it? _____________________________________ Tracker _____________________________________ From report at bugs.python.org Wed Sep 19 13:55:17 2007 From: report at bugs.python.org (=?utf-8?q?=0A=09=09=09=09=09Hirokazu_Yamamoto=0A=09=09=09=09?=) Date: Wed, 19 Sep 2007 11:55:17 -0000 Subject: [issue1135] xview/yview of Tix.Grid is broken Message-ID: <1190202917.76.0.146447375706.issue1135@psf.upfronthosting.co.za> Hirokazu Yamamoto added the comment: OK, how about this patch? I extracted [xy]view{,_moveto,_scroll} as mixin class [XY]View, and included them. It seems working. __________________________________ Tracker __________________________________ -------------- next part -------------- A non-text attachment was scrubbed... Name: xview_yview.patch Type: text/x-patch Size: 11828 bytes Desc: not available Url : http://mail.python.org/pipermail/python-bugs-list/attachments/20070919/47cdf0fe/attachment.bin From report at bugs.python.org Wed Sep 19 16:05:44 2007 From: report at bugs.python.org (Facundo Batista) Date: Wed, 19 Sep 2007 14:05:44 -0000 Subject: [issue1177] urllib* 20x responses not OK? Message-ID: <1190210744.87.0.595730259037.issue1177@psf.upfronthosting.co.za> Facundo Batista added the comment: Done, rev 58207. ---------- resolution: accepted -> fixed status: open -> closed __________________________________ Tracker __________________________________ From report at bugs.python.org Wed Sep 19 16:40:22 2007 From: report at bugs.python.org (Bob Kline) Date: Wed, 19 Sep 2007 14:40:22 -0000 Subject: [issue1541463] Optimizations for cgi.FieldStorage methods Message-ID: <1190212822.07.0.543447872169.issue1541463@psf.upfronthosting.co.za> Bob Kline added the comment: Please note that the documentation of the keys() method of the FieldStorage class (both in the method's docstring as well as in the separate library manual) describes the method as a "dictionary style keys() method." Section 3.8 of the documentation has this to say about the keys() method of a dictionary: "Keys and values are listed in an arbitrary order which is non-random, varies across Python implementations, and depends on the dictionary's history of insertions and deletions." I believe the proposed implementation conforms with this specified behavior. _____________________________________ Tracker _____________________________________ From report at bugs.python.org Wed Sep 19 16:45:48 2007 From: report at bugs.python.org (Georg Brandl) Date: Wed, 19 Sep 2007 14:45:48 -0000 Subject: [issue1541463] Optimizations for cgi.FieldStorage methods Message-ID: <1190213148.42.0.945776999188.issue1541463@psf.upfronthosting.co.za> Georg Brandl added the comment: While this is true, there may be code relying on the current behavior, and to break that for a tiny performance gain is gratuitous breakage and should be avoided. _____________________________________ Tracker _____________________________________ From report at bugs.python.org Wed Sep 19 17:20:58 2007 From: report at bugs.python.org (Bob Kline) Date: Wed, 19 Sep 2007 15:20:58 -0000 Subject: [issue1541463] Optimizations for cgi.FieldStorage methods Message-ID: <1190215258.05.0.167590022971.issue1541463@psf.upfronthosting.co.za> Bob Kline added the comment: I'm not sure I would characterize a speedup of several orders of magnitude a "tiny performance gain." We had scripts with very large numbers of fields which were actually timing out. While I understand and agree with the principle of breaking as little existing code as possible, when programmers have actually been told that the method behaves the way the dictionary keys() method behaves it seems unreasonable to assume that the method will preserve the original order of fields (whatever that might mean for multiply-occurring field names). _____________________________________ Tracker _____________________________________ From report at bugs.python.org Wed Sep 19 19:22:28 2007 From: report at bugs.python.org (Guido van Rossum) Date: Wed, 19 Sep 2007 17:22:28 -0000 Subject: [issue1175] .readline() has bug WRT nonblocking files Message-ID: <1190222548.12.0.150543068797.issue1175@psf.upfronthosting.co.za> Guido van Rossum added the comment: readline() goes through C stdio which makes it impossible to get non-blocking I/O right. You should be using raw os.read() calls (until python 3000 which will remove Python's reliance on C stdio). ---------- nosy: +gvanrossum resolution: -> wont fix status: open -> closed __________________________________ Tracker __________________________________ From report at bugs.python.org Wed Sep 19 19:25:50 2007 From: report at bugs.python.org (Guido van Rossum) Date: Wed, 19 Sep 2007 17:25:50 -0000 Subject: [issue1179] [CVE-2007-4965] Integer overflow in imageop module Message-ID: <1190222750.32.0.760048815206.issue1179@psf.upfronthosting.co.za> Guido van Rossum added the comment: Cartman, please refrain from using vulgarities in your sample code. It's hard to take a bug report seriously with such variable names. ---------- nosy: +gvanrossum __________________________________ Tracker __________________________________ From report at bugs.python.org Wed Sep 19 19:57:19 2007 From: report at bugs.python.org (Facundo Batista) Date: Wed, 19 Sep 2007 17:57:19 -0000 Subject: [issue1772851] Decimal and long hash, compatibly and efficiently Message-ID: <1190224639.17.0.419438994194.issue1772851@psf.upfronthosting.co.za> Facundo Batista added the comment: Applied the patchs long_hash.patch (rev 58208) and decimal_hash_v2.patch (rev 58211) ---------- resolution: -> fixed status: open -> closed _____________________________________ Tracker _____________________________________ From report at bugs.python.org Wed Sep 19 21:58:22 2007 From: report at bugs.python.org (Michael Hoffman) Date: Wed, 19 Sep 2007 19:58:22 -0000 Subject: [issue1180] Option to ignore ~/.pydistutils.cfg Message-ID: <1190231902.87.0.178158778799.issue1180@psf.upfronthosting.co.za> Changes by Michael Hoffman: ---------- components: Distutils severity: normal status: open title: Option to ignore ~/.pydistutils.cfg type: rfe versions: Python 2.6 __________________________________ Tracker __________________________________ From report at bugs.python.org Wed Sep 19 22:00:08 2007 From: report at bugs.python.org (Michael Hoffman) Date: Wed, 19 Sep 2007 20:00:08 -0000 Subject: [issue1180] Option to ignore ~/.pydistutils.cfg Message-ID: <1190232008.41.0.541816468426.issue1180@psf.upfronthosting.co.za> New submission from Michael Hoffman: It would be useful if setup.py instances had an option to ignore ~/.pydistutils.cfg or substitute it with another file. For example, this would be highly useful to people who maintain a system site-packages directory along with one in their own home directory. ---------- nosy: +hoffman __________________________________ Tracker __________________________________ From report at bugs.python.org Wed Sep 19 22:00:26 2007 From: report at bugs.python.org (Michael Hoffman) Date: Wed, 19 Sep 2007 20:00:26 -0000 Subject: [issue1180] Option to ignore or substitute ~/.pydistutils.cfg Message-ID: <1190232026.5.0.176755281775.issue1180@psf.upfronthosting.co.za> Changes by Michael Hoffman: ---------- title: Option to ignore ~/.pydistutils.cfg -> Option to ignore or substitute ~/.pydistutils.cfg __________________________________ Tracker __________________________________ From report at bugs.python.org Wed Sep 19 22:14:03 2007 From: report at bugs.python.org (Sean Reifschneider) Date: Wed, 19 Sep 2007 20:14:03 -0000 Subject: [issue1180] Option to ignore or substitute ~/.pydistutils.cfg Message-ID: <1190232843.59.0.982627049776.issue1180@psf.upfronthosting.co.za> Changes by Sean Reifschneider: ---------- priority: -> normal __________________________________ Tracker __________________________________ From report at bugs.python.org Wed Sep 19 22:16:31 2007 From: report at bugs.python.org (Sean Reifschneider) Date: Wed, 19 Sep 2007 20:16:31 -0000 Subject: [issue1179] [CVE-2007-4965] Integer overflow in imageop module Message-ID: <1190232991.59.0.0797645586326.issue1179@psf.upfronthosting.co.za> Sean Reifschneider added the comment: Guido: That code came from the full-disclosure list posting, I think cartman was just passing it on. __________________________________ Tracker __________________________________ From report at bugs.python.org Wed Sep 19 22:18:57 2007 From: report at bugs.python.org (Michael Hoffman) Date: Wed, 19 Sep 2007 20:18:57 -0000 Subject: [issue1643369] function breakpoints in pdb Message-ID: <1190233137.72.0.00726746761636.issue1643369@psf.upfronthosting.co.za> Michael Hoffman added the comment: Agree with isandler. This is not a bug. ---------- nosy: +hoffman _____________________________________ Tracker _____________________________________ From report at bugs.python.org Wed Sep 19 23:03:52 2007 From: report at bugs.python.org (James Antill) Date: Wed, 19 Sep 2007 21:03:52 -0000 Subject: [issue1179] [CVE-2007-4965] Integer overflow in imageop module Message-ID: <1190235832.3.0.139916129466.issue1179@psf.upfronthosting.co.za> James Antill added the comment: So I think this is all the places integer overflow checking is needed in imageop.c and rbgimgmodule.c. There might be checks here which can't be exploited anyway, and I haven't checked any other files yet. Feel free to comment. Ps. This is against the 2.5 in Fedora-7, but it should apply to upstream. ---------- nosy: +nevyn __________________________________ Tracker __________________________________ From report at bugs.python.org Wed Sep 19 23:05:04 2007 From: report at bugs.python.org (James Antill) Date: Wed, 19 Sep 2007 21:05:04 -0000 Subject: [issue1179] [CVE-2007-4965] Integer overflow in imageop module Message-ID: <1190235904.16.0.0615807010733.issue1179@psf.upfronthosting.co.za> Changes by James Antill: __________________________________ Tracker __________________________________ From report at bugs.python.org Wed Sep 19 23:38:22 2007 From: report at bugs.python.org (Martin Horcicka) Date: Wed, 19 Sep 2007 21:38:22 -0000 Subject: [issue1181] Redefine clear() for os.environ to use unsetenv() if possible Message-ID: <1190237902.57.0.871382719483.issue1181@psf.upfronthosting.co.za> New submission from Martin Horcicka: This patch makes os.environ.clear() to have the same effect as: for name in os.environ.keys(): del os.environ[name] I believe that most people expect the effects to be the same anyway. The practical benefit is a simpler redefinition of the whole environment if desired (e.g. in scripts run via sudo on unix systems). ---------- components: Library (Lib) files: os.py.patch messages: 56048 nosy: horcicka severity: normal status: open title: Redefine clear() for os.environ to use unsetenv() if possible type: behavior __________________________________ Tracker __________________________________ -------------- next part -------------- A non-text attachment was scrubbed... Name: os.py.patch Type: text/x-patch Size: 967 bytes Desc: not available Url : http://mail.python.org/pipermail/python-bugs-list/attachments/20070919/955263b9/attachment-0002.bin From report at bugs.python.org Wed Sep 19 23:38:22 2007 From: report at bugs.python.org (Martin Horcicka) Date: Wed, 19 Sep 2007 21:38:22 -0000 Subject: [issue1181] Redefine clear() for os.environ to use unsetenv() if possible Message-ID: <1190237902.57.0.871382719483.issue1181@psf.upfronthosting.co.za> New submission from Martin Horcicka: This patch makes os.environ.clear() to have the same effect as: for name in os.environ.keys(): del os.environ[name] I believe that most people expect the effects to be the same anyway. The practical benefit is a simpler redefinition of the whole environment if desired (e.g. in scripts run via sudo on unix systems). ---------- components: Library (Lib) files: os.py.patch messages: 56048 nosy: horcicka severity: normal status: open title: Redefine clear() for os.environ to use unsetenv() if possible type: behavior __________________________________ Tracker __________________________________ -------------- next part -------------- A non-text attachment was scrubbed... Name: os.py.patch Type: text/x-patch Size: 967 bytes Desc: not available Url : http://mail.python.org/pipermail/python-bugs-list/attachments/20070919/955263b9/attachment-0003.bin From report at bugs.python.org Wed Sep 19 23:38:38 2007 From: report at bugs.python.org (Ismail Donmez) Date: Wed, 19 Sep 2007 21:38:38 -0000 Subject: [issue1179] [CVE-2007-4965] Integer overflow in imageop module Message-ID: <1190237918.31.0.0542698400699.issue1179@psf.upfronthosting.co.za> Ismail Donmez added the comment: Guido, The poc is taken as is, sorry. __________________________________ Tracker __________________________________ From report at bugs.python.org Wed Sep 19 23:44:16 2007 From: report at bugs.python.org (Sean Reifschneider) Date: Wed, 19 Sep 2007 21:44:16 -0000 Subject: [issue1181] Redefine clear() for os.environ to use unsetenv() if possible Message-ID: <1190238256.87.0.483348036806.issue1181@psf.upfronthosting.co.za> Changes by Sean Reifschneider: ---------- keywords: +patch priority: -> normal __________________________________ Tracker __________________________________ From report at bugs.python.org Thu Sep 20 00:07:02 2007 From: report at bugs.python.org (James Antill) Date: Wed, 19 Sep 2007 22:07:02 -0000 Subject: [issue1179] [CVE-2007-4965] Integer overflow in imageop module Message-ID: <1190239622.51.0.295419012174.issue1179@psf.upfronthosting.co.za> James Antill added the comment: And now the obvious typo fix, *sigh*. __________________________________ Tracker __________________________________ -------------- next part -------------- A non-text attachment was scrubbed... Name: python-2.5.CVE-2007-4965-int-overflow.patch Type: text/x-patch Size: 6730 bytes Desc: not available Url : http://mail.python.org/pipermail/python-bugs-list/attachments/20070919/14145f89/attachment.bin From report at bugs.python.org Thu Sep 20 00:24:31 2007 From: report at bugs.python.org (Ismail Donmez) Date: Wed, 19 Sep 2007 22:24:31 -0000 Subject: [issue1179] [CVE-2007-4965] Integer overflow in imageop module Message-ID: <1190240671.29.0.785569259222.issue1179@psf.upfronthosting.co.za> Ismail Donmez added the comment: nevyn: Your patch cleanly applies to python 2.4.4 and fixes the interpreter crash with poc.py Thanks. __________________________________ Tracker __________________________________ From report at bugs.python.org Thu Sep 20 00:56:18 2007 From: report at bugs.python.org (Guido van Rossum) Date: Wed, 19 Sep 2007 22:56:18 -0000 Subject: [issue1179] [CVE-2007-4965] Integer overflow in imageop module Message-ID: <1190242578.56.0.446958293119.issue1179@psf.upfronthosting.co.za> Guido van Rossum added the comment: Hm. First of all, it seems the imageop module has completely missed the Py_ssize_t changes. Second, I don't think that "if ( x != len / y )" is a valid replacement for "if ( x*y != len )" -- consider x==5, y==2, len==11. ---------- priority: high -> __________________________________ Tracker __________________________________ From report at bugs.python.org Thu Sep 20 03:30:23 2007 From: report at bugs.python.org (James Antill) Date: Thu, 20 Sep 2007 01:30:23 -0000 Subject: [issue1179] [CVE-2007-4965] Integer overflow in imageop module Message-ID: <1190251823.41.0.521345231953.issue1179@psf.upfronthosting.co.za> James Antill added the comment: Guido: It's true that that len can be slightly bigger than x*y, the big thing is that it can't be smaller so we can malloc(len) and use upto x*y (which was my main focus). I first looked at any of this code today, but I didn't see any reason that having len be slightly larger would be a problem ... and in pretty much all cases it'll be len == x*y. However we could have both cases covered by doing: if ( (len != x*y) || (x != (len / y)) ) ...but esp. at that point it seems like we'd want some interface so that we could just do something like: if ( check_mutliplies2(len, x, y) ) __________________________________ Tracker __________________________________ From report at bugs.python.org Thu Sep 20 06:55:22 2007 From: report at bugs.python.org (Brett Cannon) Date: Thu, 20 Sep 2007 04:55:22 -0000 Subject: [issue1076790] test test_codecs failed Message-ID: <1190264122.81.0.213049582831.issue1076790@psf.upfronthosting.co.za> Changes by Brett Cannon: ---------- keywords: +patch _____________________________________ Tracker _____________________________________ From report at bugs.python.org Thu Sep 20 06:56:47 2007 From: report at bugs.python.org (=?utf-8?q?=0A=09=09=09=09=09Reinhard_Speyerer=0A=09=09=09=09?=) Date: Thu, 20 Sep 2007 04:56:47 -0000 Subject: [issue1053365] nntplib: add support for NNTP over SSL Message-ID: <1190264207.98.0.539990445339.issue1053365@psf.upfronthosting.co.za> Changes by Reinhard Speyerer : _____________________________________ Tracker _____________________________________ From report at bugs.python.org Thu Sep 20 07:01:12 2007 From: report at bugs.python.org (Brett Cannon) Date: Thu, 20 Sep 2007 05:01:12 -0000 Subject: [issue1023290] proposed struct module format code addition Message-ID: <1190264472.17.0.598449775397.issue1023290@psf.upfronthosting.co.za> Changes by Brett Cannon: ---------- keywords: +patch _____________________________________ Tracker _____________________________________ From report at bugs.python.org Thu Sep 20 08:56:32 2007 From: report at bugs.python.org (Sean Reifschneider) Date: Thu, 20 Sep 2007 06:56:32 -0000 Subject: [issue1178] IDLE - add "paste code" functionality Message-ID: <1190271392.18.0.796898989716.issue1178@psf.upfronthosting.co.za> Changes by Sean Reifschneider: __________________________________ Tracker __________________________________ From report at bugs.python.org Thu Sep 20 10:47:33 2007 From: report at bugs.python.org (Georg Brandl) Date: Thu, 20 Sep 2007 08:47:33 -0000 Subject: [issue1692335] Fix exception pickling: Move initial args assignment to BaseException.__new__ Message-ID: <1190278053.17.0.320204212555.issue1692335@psf.upfronthosting.co.za> Georg Brandl added the comment: IMO zseil's latest patch is the best one, but I need any other developer to review and approve it. _____________________________________ Tracker _____________________________________ From report at bugs.python.org Thu Sep 20 16:13:49 2007 From: report at bugs.python.org (Raghuram Devarakonda) Date: Thu, 20 Sep 2007 14:13:49 -0000 Subject: [issue1181] Redefine clear() for os.environ to use unsetenv() if possible Message-ID: <1190297629.8.0.697186778618.issue1181@psf.upfronthosting.co.za> Changes by Raghuram Devarakonda: ---------- nosy: +draghuram __________________________________ Tracker __________________________________ From report at bugs.python.org Thu Sep 20 18:06:32 2007 From: report at bugs.python.org (Georg Brandl) Date: Thu, 20 Sep 2007 16:06:32 -0000 Subject: [issue1541463] Optimizations for cgi.FieldStorage methods Message-ID: <1190304392.55.0.323928547591.issue1541463@psf.upfronthosting.co.za> Georg Brandl added the comment: Okay, you've convinced me. Committed rev. 58218. ---------- resolution: -> accepted status: open -> closed _____________________________________ Tracker _____________________________________ From report at bugs.python.org Thu Sep 20 18:26:58 2007 From: report at bugs.python.org (=?utf-8?q?=0A=09=09=09=09=09Hirokazu_Yamamoto=0A=09=09=09=09?=) Date: Thu, 20 Sep 2007 16:26:58 -0000 Subject: [issue1182] Paticular decimal mod operation wrongly output NaN. Message-ID: <1190305618.56.0.684353803069.issue1182@psf.upfronthosting.co.za> New submission from Hirokazu Yamamoto : Following code illegally print "NaN" on Python2.5. from decimal import * d1 = Decimal("23.08589694291355371979265447") d2 = Decimal("2.302585092994045640179914546844") print d1 % d2 Python2.6(trunk) print 0.06004601297309731799350900156 ---------- components: Library (Lib) messages: 56056 nosy: ocean-city severity: normal status: open title: Paticular decimal mod operation wrongly output NaN. type: behavior versions: Python 2.5 __________________________________ Tracker __________________________________ From report at bugs.python.org Thu Sep 20 18:26:58 2007 From: report at bugs.python.org (=?utf-8?q?=0A=09=09=09=09=09Hirokazu_Yamamoto=0A=09=09=09=09?=) Date: Thu, 20 Sep 2007 16:26:58 -0000 Subject: [issue1182] Paticular decimal mod operation wrongly output NaN. Message-ID: <1190305618.56.0.684353803069.issue1182@psf.upfronthosting.co.za> New submission from Hirokazu Yamamoto : Following code illegally print "NaN" on Python2.5. from decimal import * d1 = Decimal("23.08589694291355371979265447") d2 = Decimal("2.302585092994045640179914546844") print d1 % d2 Python2.6(trunk) print 0.06004601297309731799350900156 ---------- components: Library (Lib) messages: 56056 nosy: ocean-city severity: normal status: open title: Paticular decimal mod operation wrongly output NaN. type: behavior versions: Python 2.5 __________________________________ Tracker __________________________________ From report at bugs.python.org Thu Sep 20 18:40:25 2007 From: report at bugs.python.org (Georg Brandl) Date: Thu, 20 Sep 2007 16:40:25 -0000 Subject: [issue1686386] Python SEGFAULT on tuple.__repr__ and str() Message-ID: <1190306425.42.0.948805143807.issue1686386@psf.upfronthosting.co.za> Georg Brandl added the comment: I don't have a specific opinion on this; the usage of Py_EnterRecursiveCall/Py_ReprEnter certainly looks correct. ---------- assignee: georg.brandl -> brett.cannon _____________________________________ Tracker _____________________________________ From report at bugs.python.org Thu Sep 20 18:41:20 2007 From: report at bugs.python.org (Georg Brandl) Date: Thu, 20 Sep 2007 16:41:20 -0000 Subject: [issue1182] Paticular decimal mod operation wrongly output NaN. Message-ID: <1190306480.23.0.202940281334.issue1182@psf.upfronthosting.co.za> Changes by Georg Brandl: ---------- assignee: -> facundobatista nosy: +facundobatista __________________________________ Tracker __________________________________ From report at bugs.python.org Thu Sep 20 18:42:42 2007 From: report at bugs.python.org (Georg Brandl) Date: Thu, 20 Sep 2007 16:42:42 -0000 Subject: [issue1696444] Adding an index method to tuples Message-ID: <1190306562.39.0.397668753816.issue1696444@psf.upfronthosting.co.za> Changes by Georg Brandl: ---------- components: +Interpreter Core -None type: -> rfe versions: +Python 2.6, Python 3.0 _____________________________________ Tracker _____________________________________ From report at bugs.python.org Thu Sep 20 18:46:17 2007 From: report at bugs.python.org (Georg Brandl) Date: Thu, 20 Sep 2007 16:46:17 -0000 Subject: [issue1176] str.split() takes no keyword arguments (Should this be expected?) Message-ID: <1190306777.2.0.887491025033.issue1176@psf.upfronthosting.co.za> Georg Brandl added the comment: Added to the documentation that string methods don't take keyword args in rev. 58219. Closing this as "works for me". ---------- nosy: +georg.brandl resolution: -> works for me status: open -> closed __________________________________ Tracker __________________________________ From report at bugs.python.org Thu Sep 20 18:47:01 2007 From: report at bugs.python.org (Georg Brandl) Date: Thu, 20 Sep 2007 16:47:01 -0000 Subject: [issue1613130] str.split creates new string even if pattern not found Message-ID: <1190306821.03.0.480854409651.issue1613130@psf.upfronthosting.co.za> Changes by Georg Brandl: ---------- type: -> rfe versions: +Python 2.6, Python 3.0 _____________________________________ Tracker _____________________________________ From report at bugs.python.org Thu Sep 20 18:59:08 2007 From: report at bugs.python.org (Sergio Correia) Date: Thu, 20 Sep 2007 16:59:08 -0000 Subject: [issue1176] str.split() takes no keyword arguments (Should this be expected?) Message-ID: <1190307548.6.0.460559651768.issue1176@psf.upfronthosting.co.za> Sergio Correia added the comment: Thanks for the update, Sergio __________________________________ Tracker __________________________________ From report at bugs.python.org Thu Sep 20 19:20:11 2007 From: report at bugs.python.org (Guido van Rossum) Date: Thu, 20 Sep 2007 17:20:11 -0000 Subject: [issue1181] Redefine clear() for os.environ to use unsetenv() if possible Message-ID: <1190308811.56.0.524334466863.issue1181@psf.upfronthosting.co.za> Guido van Rossum added the comment: Sounds like a good idea. Anyone care to check it in? ---------- nosy: +gvanrossum __________________________________ Tracker __________________________________ From report at bugs.python.org Thu Sep 20 19:28:22 2007 From: report at bugs.python.org (Sean Reifschneider) Date: Thu, 20 Sep 2007 17:28:22 -0000 Subject: [issue1179] [CVE-2007-4965] Integer overflow in imageop module Message-ID: <1190309302.16.0.468398629677.issue1179@psf.upfronthosting.co.za> Changes by Sean Reifschneider: ---------- priority: -> high __________________________________ Tracker __________________________________ From report at bugs.python.org Thu Sep 20 19:32:51 2007 From: report at bugs.python.org (Sean Reifschneider) Date: Thu, 20 Sep 2007 17:32:51 -0000 Subject: [issue1719423] Python package support not properly documented Message-ID: <1190309571.39.0.155614058081.issue1719423@psf.upfronthosting.co.za> Changes by Sean Reifschneider: ---------- priority: high -> normal resolution: -> remind status: open -> pending _____________________________________ Tracker _____________________________________ From report at bugs.python.org Thu Sep 20 19:38:34 2007 From: report at bugs.python.org (Sean Reifschneider) Date: Thu, 20 Sep 2007 17:38:34 -0000 Subject: [issue1643369] pdb find_function does not find Class methods. Message-ID: <1190309914.18.0.793436642702.issue1643369@psf.upfronthosting.co.za> Changes by Sean Reifschneider: ---------- priority: high -> low title: function breakpoints in pdb -> pdb find_function does not find Class methods. type: -> rfe _____________________________________ Tracker _____________________________________ From report at bugs.python.org Thu Sep 20 19:39:57 2007 From: report at bugs.python.org (Sean Reifschneider) Date: Thu, 20 Sep 2007 17:39:57 -0000 Subject: [issue1643369] pdb find_function does not find Class methods. Message-ID: <1190309997.34.0.482258134916.issue1643369@psf.upfronthosting.co.za> Changes by Sean Reifschneider: ---------- severity: normal -> minor _____________________________________ Tracker _____________________________________ From report at bugs.python.org Thu Sep 20 19:46:04 2007 From: report at bugs.python.org (Raghuram Devarakonda) Date: Thu, 20 Sep 2007 17:46:04 -0000 Subject: [issue1181] Redefine clear() for os.environ to use unsetenv() if possible Message-ID: <1190310364.31.0.176372318233.issue1181@psf.upfronthosting.co.za> Raghuram Devarakonda added the comment: Shouldn't the first clear() in the patch say "del self.data[key.upper()]" instead of "del self.data[key]"? I also think the patch should include doc change. __________________________________ Tracker __________________________________ From report at bugs.python.org Thu Sep 20 19:46:25 2007 From: report at bugs.python.org (Sean Reifschneider) Date: Thu, 20 Sep 2007 17:46:25 -0000 Subject: [issue1170766] weakref.proxy incorrect behaviour Message-ID: <1190310385.41.0.599068728357.issue1170766@psf.upfronthosting.co.za> Sean Reifschneider added the comment: Raymond: Is this still a problem, or should we close it because the reported issue is resolved and 2.4 is no longer maintained? ---------- assignee: -> rhettinger nosy: +jafo priority: high -> low resolution: -> accepted type: -> behavior _____________________________________ Tracker _____________________________________ From report at bugs.python.org Thu Sep 20 19:52:17 2007 From: report at bugs.python.org (Guido van Rossum) Date: Thu, 20 Sep 2007 17:52:17 -0000 Subject: [issue1181] Redefine clear() for os.environ to use unsetenv() if possible In-Reply-To: <1190310364.31.0.176372318233.issue1181@psf.upfronthosting.co.za> Message-ID: Guido van Rossum added the comment: On 9/20/07, Raghuram Devarakonda wrote: > Shouldn't the first clear() in the patch say "del > self.data[key.upper()]" instead of "del self.data[key]"? I also think > the patch should include doc change. I don't think so -- it goes over self.data.keys() which means they are already uppercase. All of this would be unnecessary if clear() in UserDict were to be changed to for key in self.keys(): del self[key] But that's a much more pervasive change... __________________________________ Tracker __________________________________ From report at bugs.python.org Thu Sep 20 19:59:03 2007 From: report at bugs.python.org (Georg Brandl) Date: Thu, 20 Sep 2007 17:59:03 -0000 Subject: [issue1181] Redefine clear() for os.environ to use unsetenv() if possible Message-ID: <1190311143.68.0.894499163573.issue1181@psf.upfronthosting.co.za> Georg Brandl added the comment: Committed, incl. docs, as rev. 58221. ---------- assignee: -> georg.brandl nosy: +georg.brandl resolution: -> accepted status: open -> closed __________________________________ Tracker __________________________________ From report at bugs.python.org Thu Sep 20 21:35:42 2007 From: report at bugs.python.org (David Ripton) Date: Thu, 20 Sep 2007 19:35:42 -0000 Subject: [issue1183] race in SocketServer.ForkingMixIn.collect_children Message-ID: <1190316942.33.0.242562253308.issue1183@psf.upfronthosting.co.za> New submission from David Ripton: CentOS Linux 5, Python 2.4.3 (but code appears unchanged in 2.5 and trunk, so I don't believe this bug has already been fixed) We have an xmlrpc server that subclasses DocXMLRPCServer.DocXMLRPCServer and SocketServer.ForkingMixIn. Under load, it sometimes crashes with an error in SocketServer.ForkingMixIn.collect_children The bug is that collect_children calls os.waitpid with pid 0, so it waits for any child. But then it assumes that the pid found was in the list self.active_children, and attempts to remove it from that list without a try block. However, another call to collect_children could have already removed it, so we get "ValueError: list.remove(x): x not in list" The fix is just adding a try/except block around the attempt to remove pid from self.active children. diff -u SocketServer.py /tmp/SocketServer.py --- SocketServer.py 2007-08-27 10:52:24.000000000 -0400 +++ /tmp/SocketServer.py 2007-09-20 15:34:00.000000000 -0400 @@ -421,7 +421,10 @@ except os.error: pid = None if not pid: break - self.active_children.remove(pid) + try: + self.active_children.remove(pid) + except ValueError: + pass def process_request(self, request, client_address): """Fork a new subprocess to process the request.""" ---------- components: Library (Lib) messages: 56065 nosy: dripton severity: normal status: open title: race in SocketServer.ForkingMixIn.collect_children type: crash versions: Python 2.4 __________________________________ Tracker __________________________________ From report at bugs.python.org Thu Sep 20 21:35:42 2007 From: report at bugs.python.org (David Ripton) Date: Thu, 20 Sep 2007 19:35:42 -0000 Subject: [issue1183] race in SocketServer.ForkingMixIn.collect_children Message-ID: <1190316942.33.0.242562253308.issue1183@psf.upfronthosting.co.za> New submission from David Ripton: CentOS Linux 5, Python 2.4.3 (but code appears unchanged in 2.5 and trunk, so I don't believe this bug has already been fixed) We have an xmlrpc server that subclasses DocXMLRPCServer.DocXMLRPCServer and SocketServer.ForkingMixIn. Under load, it sometimes crashes with an error in SocketServer.ForkingMixIn.collect_children The bug is that collect_children calls os.waitpid with pid 0, so it waits for any child. But then it assumes that the pid found was in the list self.active_children, and attempts to remove it from that list without a try block. However, another call to collect_children could have already removed it, so we get "ValueError: list.remove(x): x not in list" The fix is just adding a try/except block around the attempt to remove pid from self.active children. diff -u SocketServer.py /tmp/SocketServer.py --- SocketServer.py 2007-08-27 10:52:24.000000000 -0400 +++ /tmp/SocketServer.py 2007-09-20 15:34:00.000000000 -0400 @@ -421,7 +421,10 @@ except os.error: pid = None if not pid: break - self.active_children.remove(pid) + try: + self.active_children.remove(pid) + except ValueError: + pass def process_request(self, request, client_address): """Fork a new subprocess to process the request.""" ---------- components: Library (Lib) messages: 56065 nosy: dripton severity: normal status: open title: race in SocketServer.ForkingMixIn.collect_children type: crash versions: Python 2.4 __________________________________ Tracker __________________________________ From report at bugs.python.org Fri Sep 21 00:51:46 2007 From: report at bugs.python.org (Amaury Forgeot d'Arc) Date: Thu, 20 Sep 2007 22:51:46 -0000 Subject: [issue1185] py3k: Completely remove nb_coerce slot Message-ID: <1190328705.55.0.555438383037.issue1185@psf.upfronthosting.co.za> New submission from Amaury Forgeot d'Arc: Arguments coercion has been removed in py3k for a while, but there are still some traces of it. This patch removes the nb_coerce slot and the last usages of __coerce__. Documentation is also updated: Py_TPFLAGS_CHECKTYPES does not exists anymore. Note: I ran the testsuite on Windows only. ---------- components: Interpreter Core files: nocoerce.diff messages: 56067 nosy: amaury.forgeotdarc severity: normal status: open title: py3k: Completely remove nb_coerce slot type: rfe versions: Python 3.0 __________________________________ Tracker __________________________________ -------------- next part -------------- A non-text attachment was scrubbed... Name: nocoerce.diff Type: application/octet-stream Size: 11152 bytes Desc: not available Url : http://mail.python.org/pipermail/python-bugs-list/attachments/20070920/7914859d/attachment-0001.obj From report at bugs.python.org Fri Sep 21 00:51:45 2007 From: report at bugs.python.org (Amaury Forgeot d'Arc) Date: Thu, 20 Sep 2007 22:51:45 -0000 Subject: [issue1185] py3k: Completely remove nb_coerce slot Message-ID: <1190328705.55.0.555438383037.issue1185@psf.upfronthosting.co.za> New submission from Amaury Forgeot d'Arc: Arguments coercion has been removed in py3k for a while, but there are still some traces of it. This patch removes the nb_coerce slot and the last usages of __coerce__. Documentation is also updated: Py_TPFLAGS_CHECKTYPES does not exists anymore. Note: I ran the testsuite on Windows only. ---------- components: Interpreter Core files: nocoerce.diff messages: 56067 nosy: amaury.forgeotdarc severity: normal status: open title: py3k: Completely remove nb_coerce slot type: rfe versions: Python 3.0 __________________________________ Tracker __________________________________ -------------- next part -------------- A non-text attachment was scrubbed... Name: nocoerce.diff Type: application/octet-stream Size: 11152 bytes Desc: not available Url : http://mail.python.org/pipermail/python-bugs-list/attachments/20070920/7914859d/attachment-0002.obj From report at bugs.python.org Fri Sep 21 04:16:16 2007 From: report at bugs.python.org (Sean Reifschneider) Date: Fri, 21 Sep 2007 02:16:16 -0000 Subject: [issue1183] race in SocketServer.ForkingMixIn.collect_children Message-ID: <1190340976.44.0.991785739802.issue1183@psf.upfronthosting.co.za> Changes by Sean Reifschneider: ---------- keywords: +patch priority: -> normal __________________________________ Tracker __________________________________ From report at bugs.python.org Fri Sep 21 04:19:32 2007 From: report at bugs.python.org (Sean Reifschneider) Date: Fri, 21 Sep 2007 02:19:32 -0000 Subject: [issue1184] test fixes for immutable bytes change Message-ID: <1190341172.85.0.256915087118.issue1184@psf.upfronthosting.co.za> Changes by Sean Reifschneider: ---------- keywords: +patch, py3k priority: -> normal __________________________________ Tracker __________________________________ From report at bugs.python.org Fri Sep 21 04:20:16 2007 From: report at bugs.python.org (Sean Reifschneider) Date: Fri, 21 Sep 2007 02:20:16 -0000 Subject: [issue1185] py3k: Completely remove nb_coerce slot Message-ID: <1190341216.26.0.446366974148.issue1185@psf.upfronthosting.co.za> Changes by Sean Reifschneider: ---------- keywords: +patch, py3k priority: -> normal __________________________________ Tracker __________________________________ From report at bugs.python.org Fri Sep 21 06:49:44 2007 From: report at bugs.python.org (Stephen Warren) Date: Fri, 21 Sep 2007 04:49:44 -0000 Subject: [issue1578269] Add os.link() and os.symlink() support for Windows Message-ID: <1190350184.76.0.451014954335.issue1578269@psf.upfronthosting.co.za> Stephen Warren added the comment: I'd say that junction points were a great way to expose this feature under Win32 - after all, isn't it specifically what they were designed for? Incidentally, at least one other application uses them for exactly this purpose; a commercial source control tool named Accurev supports checked-in symlinks on Windows as well as *nix etc. The added advantage of junction points over whatever new API Vista exposes is that it'll work on at least XP (maybe even Win2K?) ---------- nosy: +swarren _____________________________________ Tracker _____________________________________ From report at bugs.python.org Fri Sep 21 07:29:52 2007 From: report at bugs.python.org (Stephen Warren) Date: Fri, 21 Sep 2007 05:29:52 -0000 Subject: [issue1704287] must run "make" before "make install" Message-ID: <1190352592.64.0.789881483382.issue1704287@psf.upfronthosting.co.za> Stephen Warren added the comment: I can confirm this happens for me too, also on CentOS 5, with SVN 2.5 HEAD as of now. It seems that this problem occurs, whilst running the first compileall command for the libinstall target: Compiling /somewhere/lib/python2.5/test/test_multibytecodec.py ... Sorry: UnicodeError: ("\\N escapes not supported (can't load unicodedatamodule)",) ---------- nosy: +swarren _____________________________________ Tracker _____________________________________ From report at bugs.python.org Fri Sep 21 07:44:04 2007 From: report at bugs.python.org (Sean Reifschneider) Date: Fri, 21 Sep 2007 05:44:04 -0000 Subject: [issue1704287] UnicodeError in compileall if "make install" is run before "make". Message-ID: <1190353444.5.0.543651223517.issue1704287@psf.upfronthosting.co.za> Changes by Sean Reifschneider: ---------- title: must run "make" before "make install" -> UnicodeError in compileall if "make install" is run before "make". _____________________________________ Tracker _____________________________________ From report at bugs.python.org Fri Sep 21 08:04:31 2007 From: report at bugs.python.org (Stephen Warren) Date: Fri, 21 Sep 2007 06:04:31 -0000 Subject: [issue1704287] UnicodeError in compileall if "make install" is run before "make". Message-ID: <1190354670.99.0.379555905636.issue1704287@psf.upfronthosting.co.za> Stephen Warren added the comment: The attached patch should solve the problem by adding appropriate dependencies to the libinstall target. I have tested: ./configure; make install but not yet: ./configure; make all install ./configure; make all; make install Note: I introduced a new "build_all" phony target so that both all and libinstall could depend on this, rather than making libinstall either: * depend on all (which I guess would cause nasty looping dependencies if one were to run "make all install") * duplicate all the dependencies of all, thus causing a maintenance issue Possibly, the new dependencies should be added to install instead of libinstall? Alternatively, I guess one could make "all" touch a file, and "install" or "libinstall" validate that the file exists, and error out if it doesn't. _____________________________________ Tracker _____________________________________ -------------- next part -------------- A non-text attachment was scrubbed... Name: py_1704287.diff Type: application/octet-stream Size: 1227 bytes Desc: not available Url : http://mail.python.org/pipermail/python-bugs-list/attachments/20070921/509af3be/attachment.obj From report at bugs.python.org Fri Sep 21 08:08:51 2007 From: report at bugs.python.org (Sean Reifschneider) Date: Fri, 21 Sep 2007 06:08:51 -0000 Subject: [issue1704287] UnicodeError in compileall if "make install" is run before "make". Message-ID: <1190354931.1.0.0655500329842.issue1704287@psf.upfronthosting.co.za> Changes by Sean Reifschneider: ---------- keywords: +patch _____________________________________ Tracker _____________________________________ From report at bugs.python.org Fri Sep 21 08:31:47 2007 From: report at bugs.python.org (Stephen Warren) Date: Fri, 21 Sep 2007 06:31:47 -0000 Subject: [issue1704287] UnicodeError in compileall if "make install" is run before "make". Message-ID: <1190356307.38.0.454156499877.issue1704287@psf.upfronthosting.co.za> Stephen Warren added the comment: Now, I have also tested: ./configure; make all install ./configure; make all; make install The "install" piece of each of the above doesn't seem to accidentally duplicate any of the building work, so the patch seems to check out OK - no negative side-effects. _____________________________________ Tracker _____________________________________ From report at bugs.python.org Fri Sep 21 08:34:59 2007 From: report at bugs.python.org (Sean Reifschneider) Date: Fri, 21 Sep 2007 06:34:59 -0000 Subject: [issue1704287] UnicodeError in compileall if "make install" is run before "make". Message-ID: <1190356499.55.0.904200564428.issue1704287@psf.upfronthosting.co.za> Sean Reifschneider added the comment: I can verify that this happens in trunk (2.6) on CentOS 5, 32-bit. Patch review looks good, and solves the problem. I've committed it to trunk as revision 58225. ---------- nosy: +jafo resolution: -> accepted status: open -> closed type: -> behavior versions: +Python 2.6 _____________________________________ Tracker _____________________________________ From report at bugs.python.org Fri Sep 21 09:56:13 2007 From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=) Date: Fri, 21 Sep 2007 07:56:13 -0000 Subject: [issue1185] py3k: Completely remove nb_coerce slot Message-ID: <1190361373.99.0.587634475748.issue1185@psf.upfronthosting.co.za> Changes by Martin v. L?wis: ---------- keywords: -py3k __________________________________ Tracker __________________________________ From report at bugs.python.org Fri Sep 21 11:11:54 2007 From: report at bugs.python.org (Sean Reifschneider) Date: Fri, 21 Sep 2007 09:11:54 -0000 Subject: [issue478407] Need Windows os.link() support Message-ID: <1190365914.97.0.140100721296.issue478407@psf.upfronthosting.co.za> Changes by Sean Reifschneider: ---------- keywords: +patch superseder: -> Add os.link() and os.symlink() support for Windows ____________________________________ Tracker ____________________________________ From report at bugs.python.org Fri Sep 21 11:25:47 2007 From: report at bugs.python.org (Sean Reifschneider) Date: Fri, 21 Sep 2007 09:25:47 -0000 Subject: [issue1578269] Add os.link() and os.symlink() support for Windows Message-ID: <1190366747.55.0.126633564901.issue1578269@psf.upfronthosting.co.za> Sean Reifschneider added the comment: swarren: According to the wikipedi article on junction points: They can only be used on folders, not files. They are being replaced by symbolic links. The latter I take to mean junction points are being phased out, but I couldn't find any information one way or another on it. http://en.wikipedia.org/wiki/NTFS_junction_point ---------- nosy: +jafo _____________________________________ Tracker _____________________________________ From report at bugs.python.org Fri Sep 21 11:51:55 2007 From: report at bugs.python.org (Michael Hoffman) Date: Fri, 21 Sep 2007 09:51:55 -0000 Subject: [issue1186] optparse documentation: -- being collapsed to - in HTML Message-ID: <1190368314.95.0.279950247421.issue1186@psf.upfronthosting.co.za> New submission from Michael Hoffman: See where it says 'either "-" or "-" can be option arguments'. One of these should be --. The same error occurs several times on the same page. Not a problem in the Optik docs at . ---------- components: Documentation messages: 56074 nosy: gward, hoffman severity: normal status: open title: optparse documentation: -- being collapsed to - in HTML versions: Python 2.5 __________________________________ Tracker __________________________________ From report at bugs.python.org Fri Sep 21 11:51:54 2007 From: report at bugs.python.org (Michael Hoffman) Date: Fri, 21 Sep 2007 09:51:54 -0000 Subject: [issue1186] optparse documentation: -- being collapsed to - in HTML Message-ID: <1190368314.95.0.279950247421.issue1186@psf.upfronthosting.co.za> New submission from Michael Hoffman: See where it says 'either "-" or "-" can be option arguments'. One of these should be --. The same error occurs several times on the same page. Not a problem in the Optik docs at . ---------- components: Documentation messages: 56074 nosy: gward, hoffman severity: normal status: open title: optparse documentation: -- being collapsed to - in HTML versions: Python 2.5 __________________________________ Tracker __________________________________ From report at bugs.python.org Fri Sep 21 18:04:03 2007 From: report at bugs.python.org (Stephen Warren) Date: Fri, 21 Sep 2007 16:04:03 -0000 Subject: [issue1578269] Add os.link() and os.symlink() support for Windows Message-ID: <1190390643.14.0.221342773755.issue1578269@psf.upfronthosting.co.za> Stephen Warren added the comment: Hmm. I just tested Accurev - whatever it does, it works for files too. That said, it could be making hard-links, which I guess could be different. Additionally, the sysinternals "junction" utility doesn't find any junction points when probing the link files. I'll see if I can find out how they implemented it... _____________________________________ Tracker _____________________________________ From report at bugs.python.org Fri Sep 21 18:48:03 2007 From: report at bugs.python.org (Guido van Rossum) Date: Fri, 21 Sep 2007 16:48:03 -0000 Subject: [issue1186] optparse documentation: -- being collapsed to - in HTML Message-ID: <1190393283.01.0.643646263095.issue1186@psf.upfronthosting.co.za> Guido van Rossum added the comment: This is only a problem with the 2.5 latex docs. ---------- assignee: -> fdrake nosy: +fdrake, gvanrossum __________________________________ Tracker __________________________________ From report at bugs.python.org Fri Sep 21 18:45:54 2007 From: report at bugs.python.org (Guido van Rossum) Date: Fri, 21 Sep 2007 16:45:54 -0000 Subject: [issue1185] py3k: Completely remove nb_coerce slot Message-ID: <1190393154.96.0.00984737106019.issue1185@psf.upfronthosting.co.za> Guido van Rossum added the comment: Can you redo the patch while keeping the slot *position* (though not the name or type)? The wasted space is minimal (4-8 bytes per type or class object) and it means a lot for third party code if the positional struct initialization never breaks due to insertion or removal of a slot. Since everyone has a zero here anyway, I propose to name the slot nb_reserved and make its type int. ---------- nosy: +gvanrossum __________________________________ Tracker __________________________________ From report at bugs.python.org Fri Sep 21 20:03:08 2007 From: report at bugs.python.org (Stephen Warren) Date: Fri, 21 Sep 2007 18:03:08 -0000 Subject: [issue1578269] Add os.link() and os.symlink() support for Windows Message-ID: <1190397788.72.0.876137224824.issue1578269@psf.upfronthosting.co.za> Stephen Warren added the comment: It seems that Accurev uses junction points for directories, and hard-links for files. That's probably a little to disparate to implement in Python? Also, I tried sysinternals' junction.exe and whilst it allows one to create junction points that point at files, you can't actually read the file via the junction point - so it does seem that they only work for directories:-( Oh well, lets hope whatever new Vista API exists works better... _____________________________________ Tracker _____________________________________ From report at bugs.python.org Fri Sep 21 20:42:09 2007 From: report at bugs.python.org (Andrew Nissen) Date: Fri, 21 Sep 2007 18:42:09 -0000 Subject: [issue1187] pipe fd handling issues in subprocess.py on POSIX Message-ID: <1190400129.03.0.21752289973.issue1187@psf.upfronthosting.co.za> New submission from Andrew Nissen: Revision 53293 appears to have missed some of the logic inherent in the previous code. There also appears to be problems with the way that the dup2 calls are made that can result in a behavior different then intended under a number of circumstances. fix_fileno.py demonstrates the improper behavior ---------- components: Library (Lib) files: fix_fileno.py messages: 56079 nosy: anissen severity: minor status: open title: pipe fd handling issues in subprocess.py on POSIX type: behavior versions: Python 2.4 __________________________________ Tracker __________________________________ -------------- next part -------------- A non-text attachment was scrubbed... Name: fix_fileno.py Type: text/x-python Size: 515 bytes Desc: not available Url : http://mail.python.org/pipermail/python-bugs-list/attachments/20070921/b9cc658e/attachment.py From report at bugs.python.org Fri Sep 21 20:42:09 2007 From: report at bugs.python.org (Andrew Nissen) Date: Fri, 21 Sep 2007 18:42:09 -0000 Subject: [issue1187] pipe fd handling issues in subprocess.py on POSIX Message-ID: <1190400129.03.0.21752289973.issue1187@psf.upfronthosting.co.za> New submission from Andrew Nissen: Revision 53293 appears to have missed some of the logic inherent in the previous code. There also appears to be problems with the way that the dup2 calls are made that can result in a behavior different then intended under a number of circumstances. fix_fileno.py demonstrates the improper behavior ---------- components: Library (Lib) files: fix_fileno.py messages: 56079 nosy: anissen severity: minor status: open title: pipe fd handling issues in subprocess.py on POSIX type: behavior versions: Python 2.4 __________________________________ Tracker __________________________________ -------------- next part -------------- A non-text attachment was scrubbed... Name: fix_fileno.py Type: text/x-python Size: 515 bytes Desc: not available Url : http://mail.python.org/pipermail/python-bugs-list/attachments/20070921/b9cc658e/attachment-0001.py From report at bugs.python.org Fri Sep 21 20:44:00 2007 From: report at bugs.python.org (Andrew Nissen) Date: Fri, 21 Sep 2007 18:44:00 -0000 Subject: [issue1187] pipe fd handling issues in subprocess.py on POSIX Message-ID: <1190400240.52.0.0766800808428.issue1187@psf.upfronthosting.co.za> Andrew Nissen added the comment: This patch (subprocess.fix_fileno.udiff) made against subprocess.py (Revision 55604)appears to give the desired behavior __________________________________ Tracker __________________________________ -------------- next part -------------- A non-text attachment was scrubbed... Name: subprocess.fix_fileno.udiff Type: application/octet-stream Size: 1636 bytes Desc: not available Url : http://mail.python.org/pipermail/python-bugs-list/attachments/20070921/5ead9967/attachment.obj From report at bugs.python.org Fri Sep 21 22:20:22 2007 From: report at bugs.python.org (Neil Schemenauer) Date: Fri, 21 Sep 2007 20:20:22 -0000 Subject: [issue1185] py3k: Completely remove nb_coerce slot Message-ID: <1190406022.11.0.0667295890889.issue1185@psf.upfronthosting.co.za> Neil Schemenauer added the comment: I made the changes as suggest by Guido. Commited as SVN rev 58226. Thanks for the patch. ---------- nosy: +nas __________________________________ Tracker __________________________________ From report at bugs.python.org Fri Sep 21 22:21:42 2007 From: report at bugs.python.org (Guido van Rossum) Date: Fri, 21 Sep 2007 20:21:42 -0000 Subject: [issue1185] py3k: Completely remove nb_coerce slot Message-ID: <1190406102.79.0.606898257426.issue1185@psf.upfronthosting.co.za> Guido van Rossum added the comment: Thanks Neil! ---------- resolution: -> accepted status: open -> closed __________________________________ Tracker __________________________________ From report at bugs.python.org Fri Sep 21 23:32:25 2007 From: report at bugs.python.org (Neil Schemenauer) Date: Fri, 21 Sep 2007 21:32:25 -0000 Subject: [issue1134] Parsing a simple script eats all of your memory Message-ID: <1190410345.88.0.23857791988.issue1134@psf.upfronthosting.co.za> Neil Schemenauer added the comment: It looks to me like fp_readl is no longer working as designed and the patch is not really the right fix. The use of "decoding_buffer" is tricky and I think the conversion to bytes screwed it up. It might be clearer to have a separate "decoding_overflow" struct member that's used for overflow rather than overloading "decoding_buffer". ---------- nosy: +nas __________________________________ Tracker __________________________________ From report at bugs.python.org Sat Sep 22 01:39:02 2007 From: report at bugs.python.org (Sean Reifschneider) Date: Fri, 21 Sep 2007 23:39:02 -0000 Subject: [issue1578269] Add os.link() and os.symlink() support for Windows Message-ID: <1190417942.0.0.101182651724.issue1578269@psf.upfronthosting.co.za> Sean Reifschneider added the comment: If the file links are on the same volume, it's probably using hard links. Symbolic links can cross file-systems, of course. So it sounds like the Junction Points aren't going to work to replace symlinks, and they'll be Vista only. _____________________________________ Tracker _____________________________________ From report at bugs.python.org Sat Sep 22 02:33:37 2007 From: report at bugs.python.org (=?utf-8?q?=0A=09=09=09=09=09Philip_Jenvey=0A=09=09=09=09?=) Date: Sat, 22 Sep 2007 00:33:37 -0000 Subject: [issue1188] universal newlines doesn't identify CRLF during tell() Message-ID: <1190421217.52.0.890075732591.issue1188@psf.upfronthosting.co.za> New submission from Philip Jenvey : tell() will skip the next LF (after a CR sets f_skipnextlf) when universal newline support is enabled; essentially doing part of the work of read(). However it does not identify CRLF as a newline, as read() would, e.g.: >>> open('/tmp/crlf', 'wb').write('CRLF\r\nEOF') >>> fp = open('/tmp/crlf', 'U') >>> fp.read() 'CRLF\nEOF' >>> fp.newlines # correct when read()ing '\r\n' >>> fp = open('/tmp/crlf', 'U') >>> fp.readline() 'CRLF\n' >>> fp.newlines >>> fp.tell() 6L >>> fp.newlines # tell() skipped ahead.. >>> fp.readline() 'EOF' >>> fp.newlines # ..but never identified CRLF >>> The following patch makes tell() mark CRLF as a newline in this case, and ensures so with an added test to test_univnewlines.py. It's against trunk, r28227 ---------- components: Library (Lib) files: univnewline_tell-r58227.diff messages: 56085 nosy: pjenvey severity: normal status: open title: universal newlines doesn't identify CRLF during tell() versions: Python 2.6 __________________________________ Tracker __________________________________ -------------- next part -------------- A non-text attachment was scrubbed... Name: univnewline_tell-r58227.diff Type: application/octet-stream Size: 1003 bytes Desc: not available Url : http://mail.python.org/pipermail/python-bugs-list/attachments/20070922/0e5ec3d1/attachment.obj From report at bugs.python.org Sat Sep 22 02:33:37 2007 From: report at bugs.python.org (=?utf-8?q?=0A=09=09=09=09=09Philip_Jenvey=0A=09=09=09=09?=) Date: Sat, 22 Sep 2007 00:33:37 -0000 Subject: [issue1188] universal newlines doesn't identify CRLF during tell() Message-ID: <1190421217.52.0.890075732591.issue1188@psf.upfronthosting.co.za> New submission from Philip Jenvey : tell() will skip the next LF (after a CR sets f_skipnextlf) when universal newline support is enabled; essentially doing part of the work of read(). However it does not identify CRLF as a newline, as read() would, e.g.: >>> open('/tmp/crlf', 'wb').write('CRLF\r\nEOF') >>> fp = open('/tmp/crlf', 'U') >>> fp.read() 'CRLF\nEOF' >>> fp.newlines # correct when read()ing '\r\n' >>> fp = open('/tmp/crlf', 'U') >>> fp.readline() 'CRLF\n' >>> fp.newlines >>> fp.tell() 6L >>> fp.newlines # tell() skipped ahead.. >>> fp.readline() 'EOF' >>> fp.newlines # ..but never identified CRLF >>> The following patch makes tell() mark CRLF as a newline in this case, and ensures so with an added test to test_univnewlines.py. It's against trunk, r28227 ---------- components: Library (Lib) files: univnewline_tell-r58227.diff messages: 56085 nosy: pjenvey severity: normal status: open title: universal newlines doesn't identify CRLF during tell() versions: Python 2.6 __________________________________ Tracker __________________________________ -------------- next part -------------- A non-text attachment was scrubbed... Name: univnewline_tell-r58227.diff Type: application/octet-stream Size: 1003 bytes Desc: not available Url : http://mail.python.org/pipermail/python-bugs-list/attachments/20070922/0e5ec3d1/attachment-0001.obj From report at bugs.python.org Sat Sep 22 02:35:10 2007 From: report at bugs.python.org (=?utf-8?q?=0A=09=09=09=09=09Philip_Jenvey=0A=09=09=09=09?=) Date: Sat, 22 Sep 2007 00:35:10 -0000 Subject: [issue1188] universal newlines doesn't identify CRLF during tell() Message-ID: <1190421310.85.0.580484298308.issue1188@psf.upfronthosting.co.za> Philip Jenvey added the comment: make that against r58227 __________________________________ Tracker __________________________________ From report at bugs.python.org Sat Sep 22 02:35:28 2007 From: report at bugs.python.org (=?utf-8?q?=0A=09=09=09=09=09Philip_Jenvey=0A=09=09=09=09?=) Date: Sat, 22 Sep 2007 00:35:28 -0000 Subject: [issue1188] universal newlines doesn't identify CRLF during tell() Message-ID: <1190421328.78.0.440343088701.issue1188@psf.upfronthosting.co.za> Changes by Philip Jenvey : ---------- type: -> behavior __________________________________ Tracker __________________________________ From report at bugs.python.org Sat Sep 22 02:44:25 2007 From: report at bugs.python.org (Amaury Forgeot d'Arc) Date: Sat, 22 Sep 2007 00:44:25 -0000 Subject: [issue1189] Documentation for tp_as_number tp_as_sequence tp_as_mapping Message-ID: <1190421865.82.0.564547764267.issue1189@psf.upfronthosting.co.za> New submission from Amaury Forgeot d'Arc: This patch adds documentation for all the fields in the tp_as_number, tp_as_sequence and tp_as_mapping structures. It may not be complete, but is still better than the XXX in the current docs. This is my first contribution to the doc, feel free to amend it! This patch describes the python3.0 situation, which is simpler since the removal of coercion. It can serve as a start for 2.6 as well; a second patch about coercion will follow. PS: it's really a pleasure to use the new ReST format. ---------- components: Documentation files: numbermethods-py3k.diff messages: 56087 nosy: amaury.forgeotdarc severity: normal status: open title: Documentation for tp_as_number tp_as_sequence tp_as_mapping versions: Python 3.0 __________________________________ Tracker __________________________________ -------------- next part -------------- A non-text attachment was scrubbed... Name: numbermethods-py3k.diff Type: application/octet-stream Size: 7835 bytes Desc: not available Url : http://mail.python.org/pipermail/python-bugs-list/attachments/20070922/76a80e17/attachment-0002.obj From report at bugs.python.org Sat Sep 22 02:44:25 2007 From: report at bugs.python.org (Amaury Forgeot d'Arc) Date: Sat, 22 Sep 2007 00:44:25 -0000 Subject: [issue1189] Documentation for tp_as_number tp_as_sequence tp_as_mapping Message-ID: <1190421865.82.0.564547764267.issue1189@psf.upfronthosting.co.za> New submission from Amaury Forgeot d'Arc: This patch adds documentation for all the fields in the tp_as_number, tp_as_sequence and tp_as_mapping structures. It may not be complete, but is still better than the XXX in the current docs. This is my first contribution to the doc, feel free to amend it! This patch describes the python3.0 situation, which is simpler since the removal of coercion. It can serve as a start for 2.6 as well; a second patch about coercion will follow. PS: it's really a pleasure to use the new ReST format. ---------- components: Documentation files: numbermethods-py3k.diff messages: 56087 nosy: amaury.forgeotdarc severity: normal status: open title: Documentation for tp_as_number tp_as_sequence tp_as_mapping versions: Python 3.0 __________________________________ Tracker __________________________________ -------------- next part -------------- A non-text attachment was scrubbed... Name: numbermethods-py3k.diff Type: application/octet-stream Size: 7835 bytes Desc: not available Url : http://mail.python.org/pipermail/python-bugs-list/attachments/20070922/76a80e17/attachment-0003.obj From report at bugs.python.org Sat Sep 22 07:40:19 2007 From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=) Date: Sat, 22 Sep 2007 05:40:19 -0000 Subject: [issue1189] Documentation for tp_as_number tp_as_sequence tp_as_mapping Message-ID: <1190439619.17.0.344880545309.issue1189@psf.upfronthosting.co.za> Changes by Martin v. L?wis: ---------- keywords: +patch __________________________________ Tracker __________________________________ From report at bugs.python.org Sat Sep 22 10:31:36 2007 From: report at bugs.python.org (Georg Brandl) Date: Sat, 22 Sep 2007 08:31:36 -0000 Subject: [issue1189] Documentation for tp_as_number tp_as_sequence tp_as_mapping Message-ID: <1190449896.68.0.203974108655.issue1189@psf.upfronthosting.co.za> Changes by Georg Brandl: ---------- assignee: -> georg.brandl nosy: +georg.brandl __________________________________ Tracker __________________________________ From report at bugs.python.org Sat Sep 22 17:00:37 2007 From: report at bugs.python.org (Quentin Gallet-Gilles) Date: Sat, 22 Sep 2007 15:00:37 -0000 Subject: [issue1127] No tests for inspect.getfullargspec() Message-ID: <1190473237.21.0.273293940058.issue1127@psf.upfronthosting.co.za> New submission from Quentin Gallet-Gilles: I created 4 tests, see attached 'test_getfullargspec.diff' patch. 2 tests verify that getargspec raises ValueError when trying to call it with the function containing keyword-only arguments or annotations. The 2 others call getfullargspec and check everything returned is as expected. Are some more tests needed ? ---------- nosy: +quentin.gallet-gilles __________________________________ Tracker __________________________________ -------------- next part -------------- A non-text attachment was scrubbed... Name: test_getfullargspec.diff Type: text/x-patch Size: 3551 bytes Desc: not available Url : http://mail.python.org/pipermail/python-bugs-list/attachments/20070922/c5af6793/attachment.bin From report at bugs.python.org Sat Sep 22 19:08:31 2007 From: report at bugs.python.org (Michael Lawrence) Date: Sat, 22 Sep 2007 17:08:31 -0000 Subject: [issue1190] Windows rants& sugestions. Message-ID: <1190480911.5.0.176921994431.issue1190@psf.upfronthosting.co.za> New submission from Michael Lawrence: TCL Perl , resources , sometimes with the python tool kit , i'd want certin compontents removed , namely tcl/tk ; on a custom Installer Do you have windows TCL/TK (YES/no) (Yes) and the gui option panel to repoiit items add perl ruby ponteirs etc. Alt Python (type) I/E Unix or Cygwin ALT perl , Iterix is a real sweet set of tools , But mainly Adding Path Statments and getting rid of other Python interpriters, and just using main python, version'd python is nice but , often force C:\Python for windows i just wish you could index other dirs of python code , etc and compile them to pyc with a right click option. some programs use full blown python stubs , anyhow with a path option etc , be nice to not have orphaned stubs, etc. Juice and others use older python compiler etc, a script to hunt down compile > default python = C:\Python\python.exe etc. also lib paths on python for windows \python\lib-ver keep scripts for migration. etc. just for sake of argument give upgrade ease and less python25; 25; 26 ; 30b folders and for testing can put the stable into main |python|bin beta into |python|testing|bin etc. thouse are my few irks with windows , having main tcl path specified is resonable because with a utility it is eassy to script-name.tcl > filename.dll , wich offers some speed. I dont program to much but , I do try not to have wastes of disk space. just the option of setting TCL/TK , perl ruby etc for python to call from default location would be a plus , and would save some disk space. and if the tcl/tk were updated wouldnt break links. and if jsee or just the java plugin were installed to have system vabiles etc for usage. PATHEXT add item for executable , can add ruby perl etc to it as well for py or pyc, this too would force a default python interpriter, option. the curent python for widows is alot faster than the older mini ones in other apps. anyhow thats my 2 ? cents ---------- components: Windows messages: 56089 nosy: wolfstar359 severity: minor status: open title: Windows rants& sugestions. type: resource usage __________________________________ Tracker __________________________________ From report at bugs.python.org Sat Sep 22 19:08:31 2007 From: report at bugs.python.org (Michael Lawrence) Date: Sat, 22 Sep 2007 17:08:31 -0000 Subject: [issue1190] Windows rants& sugestions. Message-ID: <1190480911.5.0.176921994431.issue1190@psf.upfronthosting.co.za> New submission from Michael Lawrence: TCL Perl , resources , sometimes with the python tool kit , i'd want certin compontents removed , namely tcl/tk ; on a custom Installer Do you have windows TCL/TK (YES/no) (Yes) and the gui option panel to repoiit items add perl ruby ponteirs etc. Alt Python (type) I/E Unix or Cygwin ALT perl , Iterix is a real sweet set of tools , But mainly Adding Path Statments and getting rid of other Python interpriters, and just using main python, version'd python is nice but , often force C:\Python for windows i just wish you could index other dirs of python code , etc and compile them to pyc with a right click option. some programs use full blown python stubs , anyhow with a path option etc , be nice to not have orphaned stubs, etc. Juice and others use older python compiler etc, a script to hunt down compile > default python = C:\Python\python.exe etc. also lib paths on python for windows \python\lib-ver keep scripts for migration. etc. just for sake of argument give upgrade ease and less python25; 25; 26 ; 30b folders and for testing can put the stable into main |python|bin beta into |python|testing|bin etc. thouse are my few irks with windows , having main tcl path specified is resonable because with a utility it is eassy to script-name.tcl > filename.dll , wich offers some speed. I dont program to much but , I do try not to have wastes of disk space. just the option of setting TCL/TK , perl ruby etc for python to call from default location would be a plus , and would save some disk space. and if the tcl/tk were updated wouldnt break links. and if jsee or just the java plugin were installed to have system vabiles etc for usage. PATHEXT add item for executable , can add ruby perl etc to it as well for py or pyc, this too would force a default python interpriter, option. the curent python for widows is alot faster than the older mini ones in other apps. anyhow thats my 2 ? cents ---------- components: Windows messages: 56089 nosy: wolfstar359 severity: minor status: open title: Windows rants& sugestions. type: resource usage __________________________________ Tracker __________________________________ From report at bugs.python.org Sat Sep 22 19:19:28 2007 From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=) Date: Sat, 22 Sep 2007 17:19:28 -0000 Subject: [issue1190] Windows rants& sugestions. Message-ID: <1190481568.1.0.960854708045.issue1190@psf.upfronthosting.co.za> Martin v. L?wis added the comment: Unfortunately, I fail to understand what kind of problem you are reporting. Please report only one issue per bug report, and try to come up with some title more descriptive than "rants & suggestions". Please follow this form when reporting bugs, or suggesting improvements: 1. what did you do? 2. what happened? 3. what did you expect to happen instead? Please try to use full English sentences (ask somebody who knows English well for help in case you don't speak it well yourself). ---------- nosy: +loewis resolution: -> invalid status: open -> closed __________________________________ Tracker __________________________________ From report at bugs.python.org Sat Sep 22 19:27:49 2007 From: report at bugs.python.org (Brett Cannon) Date: Sat, 22 Sep 2007 17:27:49 -0000 Subject: [issue1127] No tests for inspect.getfullargspec() Message-ID: <1190482069.84.0.18960079325.issue1127@psf.upfronthosting.co.za> Brett Cannon added the comment: Won't know if more tests are needed until the patch is reviewed. Thanks for the work so far, though! ---------- assignee: -> brett.cannon keywords: +patch nosy: +brett.cannon __________________________________ Tracker __________________________________ From report at bugs.python.org Sat Sep 22 22:18:25 2007 From: report at bugs.python.org (Guido van Rossum) Date: Sat, 22 Sep 2007 20:18:25 -0000 Subject: [issue1188] universal newlines doesn't identify CRLF during tell() Message-ID: <1190492305.91.0.0101590769537.issue1188@psf.upfronthosting.co.za> Guido van Rossum added the comment: Thanks! Committed revision 58232. ---------- assignee: -> gvanrossum nosy: +gvanrossum resolution: -> accepted status: open -> closed __________________________________ Tracker __________________________________ From report at bugs.python.org Sun Sep 23 00:25:28 2007 From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=) Date: Sat, 22 Sep 2007 22:25:28 -0000 Subject: [issue1187] pipe fd handling issues in subprocess.py on POSIX Message-ID: <1190499928.42.0.647821891925.issue1187@psf.upfronthosting.co.za> Changes by Martin v. L?wis: ---------- keywords: +patch __________________________________ Tracker __________________________________ From report at bugs.python.org Sun Sep 23 01:28:43 2007 From: report at bugs.python.org (Bryan Henderson) Date: Sat, 22 Sep 2007 23:28:43 -0000 Subject: [issue1191] Berkeley DB prerequisite inconsistent Message-ID: <1190503722.68.0.665728858894.issue1191@psf.upfronthosting.co.za> New submission from Bryan Henderson: There's some inconsistency among the code and documentation as to the required level of Berkeley DB. I don't know what the proper resolution, but I'm sure someone familiar with the history of this code does. Something needs to be done to reduce the amount of time it takes someone (as it did me) to deal with not having the expected level of Berkeley DB installed. I attached a file with a detailed explanation of my observations. ---------- components: Build files: problem_description.txt messages: 56093 nosy: giraffedata severity: normal status: open title: Berkeley DB prerequisite inconsistent type: compile error versions: Python 2.5 __________________________________ Tracker __________________________________ -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: problem_description.txt Url: http://mail.python.org/pipermail/python-bugs-list/attachments/20070922/433629b5/attachment-0001.txt From report at bugs.python.org Sun Sep 23 01:28:42 2007 From: report at bugs.python.org (Bryan Henderson) Date: Sat, 22 Sep 2007 23:28:42 -0000 Subject: [issue1191] Berkeley DB prerequisite inconsistent Message-ID: <1190503722.68.0.665728858894.issue1191@psf.upfronthosting.co.za> New submission from Bryan Henderson: There's some inconsistency among the code and documentation as to the required level of Berkeley DB. I don't know what the proper resolution, but I'm sure someone familiar with the history of this code does. Something needs to be done to reduce the amount of time it takes someone (as it did me) to deal with not having the expected level of Berkeley DB installed. I attached a file with a detailed explanation of my observations. ---------- components: Build files: problem_description.txt messages: 56093 nosy: giraffedata severity: normal status: open title: Berkeley DB prerequisite inconsistent type: compile error versions: Python 2.5 __________________________________ Tracker __________________________________ -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: problem_description.txt Url: http://mail.python.org/pipermail/python-bugs-list/attachments/20070922/433629b5/attachment-0002.txt From report at bugs.python.org Sun Sep 23 05:54:51 2007 From: report at bugs.python.org (Sean Reifschneider) Date: Sun, 23 Sep 2007 03:54:51 -0000 Subject: [issue1191] bsddb does not build with bsddb lib v3.1. Message-ID: <1190519691.63.0.257555017093.issue1191@psf.upfronthosting.co.za> Sean Reifschneider added the comment: Bringing attachment inline here: ================================ The Python manual for module 'bsddb'says it requires a Berkeley DB library 3.3 - 4.4. But the build tools do not check this. If that's the requirement, they should. Instead, I see in _bsddb.c lots of code explicitly intended for Berkeley DB < 3.3. If this code is dead, it probably should be cleaned out, and whether it is cleaned out or not, comments in _bsddb.c should indicate what its Berkeley DB level requirement is (and why). Indeed, _bsddb.c does not compile for Berkeley DB 3.1 (at least as installed on my system). That's because it refers to macro DB_FAST_STAT even though it does not exist in Berkeley DB before Release 3.3. However, other parts of the code are designed to handle the absence of DB_FAST_STAT in older Berkeley DB, so I just put the appropriate "if (DBVER >= 33)" in and it compiled. The next inconsistency is that the 'dbhash' module insists, at run time, on Berkeley DB version 3.2 or better. If 'bsddb' must have at least 3.3, then this check is superfluous. A bigger problem is that the error message it gives when you don't have 3.2 or better is the misleading, "correct BerkeleyDB symbols not found." What would be better is, "You have Berkeley DB 3.1. You need at least 3.2." FWIW, I removed the check and 'dbhash' worked for my purposes with Berkeley DB 3.1. Maybe the documented 3.3 prerequisite is too strong, and it should be more specific about what doesn't work with older versions. This all comes from Python 2.5. ---------- components: +Library (Lib) -Build nosy: +jafo priority: -> low severity: normal -> minor title: Berkeley DB prerequisite inconsistent -> bsddb does not build with bsddb lib v3.1. __________________________________ Tracker __________________________________ From report at bugs.python.org Sun Sep 23 06:08:43 2007 From: report at bugs.python.org (Sean Reifschneider) Date: Sun, 23 Sep 2007 04:08:43 -0000 Subject: [issue1187] pipe fd handling issues in subprocess.py on POSIX Message-ID: <1190520523.4.0.7071284441.issue1187@psf.upfronthosting.co.za> Changes by Sean Reifschneider: ---------- assignee: -> astrand nosy: +astrand priority: -> normal versions: +Python 2.6 -Python 2.4 __________________________________ Tracker __________________________________ From report at bugs.python.org Sun Sep 23 08:20:04 2007 From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=) Date: Sun, 23 Sep 2007 06:20:04 -0000 Subject: [issue1064] Test issue Message-ID: <1190528404.04.0.926118076744.issue1064@psf.upfronthosting.co.za> Martin v. L?wis added the comment: Compare From headers ---------- assignee: georg.brandl -> nosy: -georg.brandl __________________________________ Tracker __________________________________ From report at bugs.python.org Sun Sep 23 10:32:57 2007 From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=) Date: Sun, 23 Sep 2007 08:32:57 -0000 Subject: [issue1727780] 64/32-bit issue when unpickling random.Random Message-ID: <1190536377.18.0.542768813547.issue1727780@psf.upfronthosting.co.za> Changes by Martin v. L?wis: ---------- assignee: -> loewis severity: normal -> major _____________________________________ Tracker _____________________________________ From report at bugs.python.org Sun Sep 23 18:56:03 2007 From: report at bugs.python.org (Tal Einat) Date: Sun, 23 Sep 2007 16:56:03 -0000 Subject: [issue1130] Idle - Save (buffer) - closes IDLE and does not save file (Windows XP) Message-ID: <1190566563.05.0.829357268495.issue1130@psf.upfronthosting.co.za> New submission from Tal Einat: The saving bug is a string/bytes issue, simply fixed by replaced line 366 in Lib\idlelib\IOBinding.py with: chars = chars.replace(b"\n", self.eol_convention.encode('ASCII')) ---------- nosy: +taleinat __________________________________ Tracker __________________________________ From report at bugs.python.org Sun Sep 23 20:47:51 2007 From: report at bugs.python.org (=?utf-8?q?=0A=09=09=09=09=09Hirokazu_Yamamoto=0A=09=09=09=09?=) Date: Sun, 23 Sep 2007 18:47:51 -0000 Subject: [issue1182] Paticular decimal mod operation wrongly output NaN. Message-ID: <1190573270.96.0.3765331284.issue1182@psf.upfronthosting.co.za> Hirokazu Yamamoto added the comment: I tracked down, and I noticed following code was invoked. Lib/decimal.py (release-maint25 Decimal#_rescale) 1912: if watchexp and digits > context.prec: 1913: return context._raise_error(InvalidOperation, 'Rescale > prec') from decimal import * d = Decimal("23.08589694291355371979265447") print d % Decimal("2.302585092994045640179914546844") # NaN print Decimal("0.060046012973097317993509001560")._rescale(-30) # error Length of decimal seems to be important, so I changed length and it seemed working. print d % Decimal("2.302585092994045640179914547") # 0.060046012973097317993509000 Maybe is this intended behavior? Still I feel 2.6's behavior is less suprising though... __________________________________ Tracker __________________________________ From report at bugs.python.org Sun Sep 23 21:10:00 2007 From: report at bugs.python.org (Fredrik Lundh) Date: Sun, 23 Sep 2007 19:10:00 -0000 Subject: [issue1160] Medium size regexp crashes python Message-ID: <1190574600.55.0.276315240503.issue1160@psf.upfronthosting.co.za> Fredrik Lundh added the comment: Well, I'm not sure 81k qualifies as "medium sized", really. If you look at the size distribution for typical RE:s (which are usually handwritten, not machine generated), that's one or two orders of magnitude larger than "medium". (And even if this was guaranteed to work on all Python builds, my guess is that performance would be pretty bad compared to a using a minimal RE and checking potential matches against a set. The "|" operator is mostly O(N), not O(1).) As for fixing this, the "byte code" used by the RE engine uses a word size equal to the Unicode character size (sizeof(Py_UNICODE)) for the given platform. I don't think it would be that hard to set it to 32 bits also on platforms using 16-bit Unicode characters (if anyone would like to experiment, just set SRE_CODE to "unsigned long" in sre.h and see what happens when you run the test suite). __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Sep 24 05:39:00 2007 From: report at bugs.python.org (Robert T McQuaid) Date: Mon, 24 Sep 2007 03:39:00 -0000 Subject: [issue1192] Python 3 documents crash Firefox Message-ID: <1190605139.92.0.443157487158.issue1192@psf.upfronthosting.co.za> New submission from Robert T McQuaid: I downloaded python-3.0a1.msi for Windows XP and after install converted the documentation from chm format to html with the hh.exe utility in XP. The resulting files crashed Firefox version 2.0 (it slowly chokes to death in a dozen operations), but worked fine on Opera 9.21. ---------- components: Documentation messages: 56099 nosy: rtmq severity: minor status: open title: Python 3 documents crash Firefox type: behavior versions: Python 3.0 __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Sep 24 05:38:59 2007 From: report at bugs.python.org (Robert T McQuaid) Date: Mon, 24 Sep 2007 03:38:59 -0000 Subject: [issue1192] Python 3 documents crash Firefox Message-ID: <1190605139.92.0.443157487158.issue1192@psf.upfronthosting.co.za> New submission from Robert T McQuaid: I downloaded python-3.0a1.msi for Windows XP and after install converted the documentation from chm format to html with the hh.exe utility in XP. The resulting files crashed Firefox version 2.0 (it slowly chokes to death in a dozen operations), but worked fine on Opera 9.21. ---------- components: Documentation messages: 56099 nosy: rtmq severity: minor status: open title: Python 3 documents crash Firefox type: behavior versions: Python 3.0 __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Sep 24 05:52:48 2007 From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=) Date: Mon, 24 Sep 2007 03:52:48 -0000 Subject: [issue1192] Python 3 documents crash Firefox Message-ID: <1190605968.38.0.280136356003.issue1192@psf.upfronthosting.co.za> Martin v. L?wis added the comment: Why do you think this is a bug in Python? If Firefox crashes, isn't this rather a bug in Firefox? Please report it at bugzilla.mozilla.com. Closing as third-party bug. ---------- nosy: +loewis resolution: -> invalid status: open -> closed versions: +3rd party -Python 3.0 __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Sep 24 06:51:54 2007 From: report at bugs.python.org (Fan Decheng) Date: Mon, 24 Sep 2007 04:51:54 -0000 Subject: [issue1193] os.system() encoding bug on Windows Message-ID: <1190609513.75.0.19939188132.issue1193@psf.upfronthosting.co.za> New submission from Fan Decheng: Python 3.0 uses utf-8 encoding, but os.system() when running on Windows uses the system default encoding, which may be "cp936" or "mbcs". They are incompatible. ---------- components: Library (Lib) messages: 56101 nosy: r_mosaic severity: major status: open title: os.system() encoding bug on Windows type: behavior versions: Python 3.0 __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Sep 24 06:51:53 2007 From: report at bugs.python.org (Fan Decheng) Date: Mon, 24 Sep 2007 04:51:53 -0000 Subject: [issue1193] os.system() encoding bug on Windows Message-ID: <1190609513.75.0.19939188132.issue1193@psf.upfronthosting.co.za> New submission from Fan Decheng: Python 3.0 uses utf-8 encoding, but os.system() when running on Windows uses the system default encoding, which may be "cp936" or "mbcs". They are incompatible. ---------- components: Library (Lib) messages: 56101 nosy: r_mosaic severity: major status: open title: os.system() encoding bug on Windows type: behavior versions: Python 3.0 __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Sep 24 08:21:50 2007 From: report at bugs.python.org (Fan Decheng) Date: Mon, 24 Sep 2007 06:21:50 -0000 Subject: [issue1193] os.system() encoding bug on Windows Message-ID: <1190614910.6.0.665355811077.issue1193@psf.upfronthosting.co.za> Fan Decheng added the comment: Steps to reproduce: 1. Use a Windows, with system default encoding to cp936 (Chinese PRC, or Simplified Chinese) in Regional Options. 2. Open Python 3.0 (command line). 3. Type: import os import sys os.system(("echo " + sys.stdin.readline().rstrip("\n")).encode("cp936")) (in stdin type:) ? Result: The output from "echo" would be utf-8 mistakenly used as cp936: ?? Expected result: The "echo" command outputs "?". Comments: I guess os.system can recoding the string before sending the string out. This may be done in the C part of Python. BTW, The os.popen() function is correct. __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Sep 24 08:26:40 2007 From: report at bugs.python.org (Fan Decheng) Date: Mon, 24 Sep 2007 06:26:40 -0000 Subject: [issue1194] The reduce() documentation is lost in Python 3.0a1 Message-ID: <1190615200.14.0.737231266393.issue1194@psf.upfronthosting.co.za> New submission from Fan Decheng: The reduce() documentation is lost in Python 3.0a1. In the documentation, functools.reduce() points onto itself, so no further explanation can be found. ---------- components: Documentation messages: 56103 nosy: r_mosaic severity: minor status: open title: The reduce() documentation is lost in Python 3.0a1 type: rfe versions: Python 3.0 __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Sep 24 08:26:40 2007 From: report at bugs.python.org (Fan Decheng) Date: Mon, 24 Sep 2007 06:26:40 -0000 Subject: [issue1194] The reduce() documentation is lost in Python 3.0a1 Message-ID: <1190615200.14.0.737231266393.issue1194@psf.upfronthosting.co.za> New submission from Fan Decheng: The reduce() documentation is lost in Python 3.0a1. In the documentation, functools.reduce() points onto itself, so no further explanation can be found. ---------- components: Documentation messages: 56103 nosy: r_mosaic severity: minor status: open title: The reduce() documentation is lost in Python 3.0a1 type: rfe versions: Python 3.0 __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Sep 24 09:00:03 2007 From: report at bugs.python.org (Georg Brandl) Date: Mon, 24 Sep 2007 07:00:03 -0000 Subject: [issue1194] The reduce() documentation is lost in Python 3.0a1 Message-ID: <1190617203.65.0.511169462676.issue1194@psf.upfronthosting.co.za> Georg Brandl added the comment: This is already fixed in SVN. ---------- nosy: +georg.brandl resolution: -> out of date status: open -> closed __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Sep 24 09:01:03 2007 From: report at bugs.python.org (Georg Brandl) Date: Mon, 24 Sep 2007 07:01:03 -0000 Subject: [issue1186] optparse documentation: -- being collapsed to - in HTML Message-ID: <1190617263.05.0.834982407547.issue1186@psf.upfronthosting.co.za> Georg Brandl added the comment: Indeed, and I can remember trying to get around that, but didn't achieve anything... I'll close it as won't fix. ---------- nosy: +georg.brandl resolution: -> wont fix status: open -> closed __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Sep 24 10:23:45 2007 From: report at bugs.python.org (Michael Hoffman) Date: Mon, 24 Sep 2007 08:23:45 -0000 Subject: [issue1186] optparse documentation: -- being collapsed to - in HTML Message-ID: <1190622225.83.0.45580422705.issue1186@psf.upfronthosting.co.za> Michael Hoffman added the comment: At the very least could you change the "--" to be the verbatim class that shows up properly beneath? There has to be another solution that would result in the docs at least being correct even if we can't get LaTeX to do exactly what we want. __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Sep 24 10:37:27 2007 From: report at bugs.python.org (Michael Hoffman) Date: Mon, 24 Sep 2007 08:37:27 -0000 Subject: [issue1186] optparse documentation: -- being collapsed to - in HTML Message-ID: <1190623047.63.0.310850411763.issue1186@psf.upfronthosting.co.za> Michael Hoffman added the comment: Also, see http://bugs.python.org/issue798006 which shows how to fix a similar problem elsewhere in the docs. __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Sep 24 11:07:45 2007 From: report at bugs.python.org (Fan Decheng) Date: Mon, 24 Sep 2007 09:07:45 -0000 Subject: [issue1193] os.system() encoding bug on Windows Message-ID: <1190624864.98.0.151987147641.issue1193@psf.upfronthosting.co.za> Fan Decheng added the comment: A note about reproducing: since Windows 2000 all language packs can be installed easily using the Regional Options in the Control Panel. Even on an English version of Windows, character set mappings and fonts of other languages can be installed. __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Sep 24 12:48:56 2007 From: report at bugs.python.org (Rebecca Breu) Date: Mon, 24 Sep 2007 10:48:56 -0000 Subject: [issue1195] Problems on Linux with Ctrl-D and Ctrl-C during raw_input Message-ID: <1190630936.13.0.318924236509.issue1195@psf.upfronthosting.co.za> New submission from Rebecca Breu: Run the program: while True: try: s = raw_input('> ') except: pass Press Ctrl-D and then Ctrl-C, and you get Traceback (most recent call last): File "test.py", line 5, in ? s = raw_input('> ') KeyboardInterrupt Pressing just Ctrl-D or Ctrl-C continues the loop as expected, Ctrl-D after Ctrl-C works, too. Only Ctrl-C after Ctrl-D sucks, even when you try to catch "EOFError" and "KeybordInterrupt" explicitly. The problem occurs with Python 2.4 and 2.5 on Debian testing, friends confirmed the error under Ubuntu/2.5 and Gentoo/?. The error does not occur when you import readline first. Ah, and by the way: http://docs.python.org/lib/reporting-bugs.html still links to the sourceforce bucktracker. ---------- components: None messages: 56109 nosy: Rebecca severity: normal status: open title: Problems on Linux with Ctrl-D and Ctrl-C during raw_input versions: Python 2.5 __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Sep 24 12:48:56 2007 From: report at bugs.python.org (Rebecca Breu) Date: Mon, 24 Sep 2007 10:48:56 -0000 Subject: [issue1195] Problems on Linux with Ctrl-D and Ctrl-C during raw_input Message-ID: <1190630936.13.0.318924236509.issue1195@psf.upfronthosting.co.za> New submission from Rebecca Breu: Run the program: while True: try: s = raw_input('> ') except: pass Press Ctrl-D and then Ctrl-C, and you get Traceback (most recent call last): File "test.py", line 5, in ? s = raw_input('> ') KeyboardInterrupt Pressing just Ctrl-D or Ctrl-C continues the loop as expected, Ctrl-D after Ctrl-C works, too. Only Ctrl-C after Ctrl-D sucks, even when you try to catch "EOFError" and "KeybordInterrupt" explicitly. The problem occurs with Python 2.4 and 2.5 on Debian testing, friends confirmed the error under Ubuntu/2.5 and Gentoo/?. The error does not occur when you import readline first. Ah, and by the way: http://docs.python.org/lib/reporting-bugs.html still links to the sourceforce bucktracker. ---------- components: None messages: 56109 nosy: Rebecca severity: normal status: open title: Problems on Linux with Ctrl-D and Ctrl-C during raw_input versions: Python 2.5 __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Sep 24 14:04:16 2007 From: report at bugs.python.org (Tim Delaney) Date: Mon, 24 Sep 2007 12:04:16 -0000 Subject: [issue1196] int() documentation does not specify default radix Message-ID: <1190635456.12.0.478143217592.issue1196@psf.upfronthosting.co.za> New submission from Tim Delaney: The int() documentation (section 2.1) does not specify the default radix used. Alternatively, it does not specify the default behaviour for string parsing. Experimentally, it's parsing with a default radix of 10 - I recall in an earlier version of Python it parsed with a default radix of zero (i.e. dependent on the string contents). I would suggest the following text: int( [x[, radix]]) Convert a string or number to a plain integer. If the argument is a string, it must contain a possibly signed decimal number representable as a Python integer, possibly embedded in whitespace. The radix parameter gives the base for the conversion and may be any integer in the range [2, 36], or zero. If radix is zero, the proper radix is guessed based on the contents of string; the interpretation is the same as for integer literals. If radix is specified and x is not a string, TypeError is raised. If radix is not specified, and x is a string, the interpretation is as if a radix of 10 was specified. Otherwise, the argument may be a plain or long integer or a floating point number. Conversion of floating point numbers to integers truncates (towards zero). If the argument is outside the integer range a long object will be returned instead. If no arguments are given, returns 0. ---------- components: Documentation messages: 56110 nosy: tcdelaney severity: normal status: open title: int() documentation does not specify default radix versions: Python 2.5 __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Sep 24 14:04:16 2007 From: report at bugs.python.org (Tim Delaney) Date: Mon, 24 Sep 2007 12:04:16 -0000 Subject: [issue1196] int() documentation does not specify default radix Message-ID: <1190635456.12.0.478143217592.issue1196@psf.upfronthosting.co.za> New submission from Tim Delaney: The int() documentation (section 2.1) does not specify the default radix used. Alternatively, it does not specify the default behaviour for string parsing. Experimentally, it's parsing with a default radix of 10 - I recall in an earlier version of Python it parsed with a default radix of zero (i.e. dependent on the string contents). I would suggest the following text: int( [x[, radix]]) Convert a string or number to a plain integer. If the argument is a string, it must contain a possibly signed decimal number representable as a Python integer, possibly embedded in whitespace. The radix parameter gives the base for the conversion and may be any integer in the range [2, 36], or zero. If radix is zero, the proper radix is guessed based on the contents of string; the interpretation is the same as for integer literals. If radix is specified and x is not a string, TypeError is raised. If radix is not specified, and x is a string, the interpretation is as if a radix of 10 was specified. Otherwise, the argument may be a plain or long integer or a floating point number. Conversion of floating point numbers to integers truncates (towards zero). If the argument is outside the integer range a long object will be returned instead. If no arguments are given, returns 0. ---------- components: Documentation messages: 56110 nosy: tcdelaney severity: normal status: open title: int() documentation does not specify default radix versions: Python 2.5 __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Sep 24 16:20:12 2007 From: report at bugs.python.org (Christian Meesters) Date: Mon, 24 Sep 2007 14:20:12 -0000 Subject: [issue1197] logging: formatter does not accept %(funcName)s properly Message-ID: <1190643612.63.0.246555298929.issue1197@psf.upfronthosting.co.za> Changes by Christian Meesters: ---------- components: Library (Lib) severity: minor status: open title: logging: formatter does not accept %(funcName)s properly type: behavior versions: Python 2.5 __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Sep 24 16:27:30 2007 From: report at bugs.python.org (Christian Meesters) Date: Mon, 24 Sep 2007 14:27:30 -0000 Subject: [issue1197] logging: formatter does not accept %(funcName)s properly Message-ID: <1190644050.62.0.462485295954.issue1197@psf.upfronthosting.co.za> New submission from Christian Meesters: Adding %(funcName)s to a formatter will only insert the calling logging function (e.g. "info" for logging.info) into messages not the function where the message comes from: logging.Formatter('%(levelname)-8s %(funcName)s %(message)s' def foo(): logging.info("test") will insert 'INFO info test' in the log instead of 'INFO foo test' ---------- nosy: +CM __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Sep 24 16:49:49 2007 From: report at bugs.python.org (Georg Brandl) Date: Mon, 24 Sep 2007 14:49:49 -0000 Subject: [issue1195] Problems on Linux with Ctrl-D and Ctrl-C during raw_input Message-ID: <1190645389.03.0.0615325426759.issue1195@psf.upfronthosting.co.za> Georg Brandl added the comment: There are a few other issues about raw_input and signals in the tracker, possibly this is just another incarnation... The docs tracker link is fixed, but needs a rebuild on the server. ---------- nosy: +georg.brandl __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Sep 24 16:50:59 2007 From: report at bugs.python.org (=?utf-8?q?=0A=09=09=09=09=09Jim_Jewett=0A=09=09=09=09?=) Date: Mon, 24 Sep 2007 14:50:59 -0000 Subject: [issue1177] urllib* 20x responses not OK? Message-ID: <1190645459.88.0.160872080668.issue1177@psf.upfronthosting.co.za> Jim Jewett added the comment: The change still missed the httpS copy. I'm attaching a minimal change. I think it might be better to just combine the methods -- as was already done in Py3K. Unfortunately, the py3K code doesn't run cleanly in 2.5, and I haven't yet had a chance to test a backported equivalent. (Hopefully tonight.) __________________________________ Tracker __________________________________ -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: urllib26min2xx.txt Url: http://mail.python.org/pipermail/python-bugs-list/attachments/20070924/85fca558/attachment.txt From report at bugs.python.org Mon Sep 24 16:51:04 2007 From: report at bugs.python.org (=?utf-8?q?=0A=09=09=09=09=09Mark_Dickinson=0A=09=09=09=09?=) Date: Mon, 24 Sep 2007 14:51:04 -0000 Subject: [issue1182] Paticular decimal mod operation wrongly output NaN. Message-ID: <1190645464.57.0.270794073978.issue1182@psf.upfronthosting.co.za> Mark Dickinson added the comment: There's a bug on line 1341 of decimal.py. That line currently reads: otherside = otherside._rescale(exp, context=context) It should read: otherside = otherside._rescale(exp, context=context, watchexp=0) ---------- nosy: +marketdickinson __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Sep 24 18:16:23 2007 From: report at bugs.python.org (=?utf-8?q?=0A=09=09=09=09=09Mark_Dickinson=0A=09=09=09=09?=) Date: Mon, 24 Sep 2007 16:16:23 -0000 Subject: [issue1182] Paticular decimal mod operation wrongly output NaN. Message-ID: <1190650583.14.0.198320352221.issue1182@psf.upfronthosting.co.za> Mark Dickinson added the comment: I should have said that the bug I mentioned above is just one of a number of bugs (mostly in division, addition and square root) that have been corrected in the trunk. Some of these fixes should probably be backported. But the decimal module has also had significant new functionality added since Python 2.5, which is going to make sorting out which pieces to backport tricky. Actually, I guess it's possible to argue that the entire new decimal.py module should be backported for inclusion in Python 2.5.2: the new functionality was added to comply with the IBM Decimal Arithmetic specification, and the comments in the decimal module explicitly say that non-compliance with an update specification should be regarded as a bug. So almost all the changes are bugfixes, in some sense... Facundo, what do you think? __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Sep 24 19:17:07 2007 From: report at bugs.python.org (Sean Reifschneider) Date: Mon, 24 Sep 2007 17:17:07 -0000 Subject: [issue1195] Problems on Linux with Ctrl-D and Ctrl-C during raw_input Message-ID: <1190654227.18.0.155276418906.issue1195@psf.upfronthosting.co.za> Changes by Sean Reifschneider: ---------- components: +Library (Lib) -None priority: -> normal type: -> behavior __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Sep 24 19:18:10 2007 From: report at bugs.python.org (Sean Reifschneider) Date: Mon, 24 Sep 2007 17:18:10 -0000 Subject: [issue1197] logging: formatter does not accept %(funcName)s properly Message-ID: <1190654290.09.0.408747958526.issue1197@psf.upfronthosting.co.za> Changes by Sean Reifschneider: ---------- priority: -> normal __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Sep 24 19:19:53 2007 From: report at bugs.python.org (Sean Reifschneider) Date: Mon, 24 Sep 2007 17:19:53 -0000 Subject: [issue1196] int() documentation does not specify default radix Message-ID: <1190654393.55.0.149636817474.issue1196@psf.upfronthosting.co.za> Changes by Sean Reifschneider: ---------- priority: -> normal __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Sep 24 19:22:05 2007 From: report at bugs.python.org (Sean Reifschneider) Date: Mon, 24 Sep 2007 17:22:05 -0000 Subject: [issue1193] os.system() encoding bug on Windows Message-ID: <1190654525.2.0.962771129481.issue1193@psf.upfronthosting.co.za> Changes by Sean Reifschneider: ---------- priority: -> normal severity: major -> normal __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Sep 24 19:32:42 2007 From: report at bugs.python.org (Paul F. Dubois) Date: Mon, 24 Sep 2007 17:32:42 -0000 Subject: [issue1002] Patch to rename HTMLParser module to lower_case Message-ID: <1190655162.03.0.402394446363.issue1002@psf.upfronthosting.co.za> Paul F. Dubois added the comment: Testing auditor, this change should get this issue assigned to Collin. ---------- nosy: +dubois __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Sep 24 19:47:57 2007 From: report at bugs.python.org (Georg Brandl) Date: Mon, 24 Sep 2007 17:47:57 -0000 Subject: [issue1196] int() documentation does not specify default radix Message-ID: <1190656077.76.0.482242987872.issue1196@psf.upfronthosting.co.za> Changes by Georg Brandl: ---------- assignee: -> georg.brandl nosy: +georg.brandl __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Sep 24 19:48:22 2007 From: report at bugs.python.org (Paul F. Dubois) Date: Mon, 24 Sep 2007 17:48:22 -0000 Subject: [issue1002] Patch to rename HTMLParser module to lower_case Message-ID: <1190656102.77.0.977615789617.issue1002@psf.upfronthosting.co.za> Paul F. Dubois added the comment: yet another test __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Sep 24 19:49:05 2007 From: report at bugs.python.org (Paul F. Dubois) Date: Mon, 24 Sep 2007 17:49:05 -0000 Subject: [issue1002] Patch to rename HTMLParser module to lower_case Message-ID: <1190656145.07.0.863111090683.issue1002@psf.upfronthosting.co.za> Changes by Paul F. Dubois: __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Sep 24 19:49:13 2007 From: report at bugs.python.org (Paul F. Dubois) Date: Mon, 24 Sep 2007 17:49:13 -0000 Subject: [issue1002] Patch to rename HTMLParser module to lower_case Message-ID: <1190656153.36.0.497842161115.issue1002@psf.upfronthosting.co.za> Changes by Paul F. Dubois: __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Sep 24 19:56:35 2007 From: report at bugs.python.org (Georg Brandl) Date: Mon, 24 Sep 2007 17:56:35 -0000 Subject: [issue1186] optparse documentation: -- being collapsed to - in HTML Message-ID: <1190656595.92.0.88742890234.issue1186@psf.upfronthosting.co.za> Georg Brandl added the comment: Okay, applied that workaround in rev. 58243. ---------- assignee: fdrake -> georg.brandl __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Sep 24 19:59:39 2007 From: report at bugs.python.org (Georg Brandl) Date: Mon, 24 Sep 2007 17:59:39 -0000 Subject: [issue1196] int() documentation does not specify default radix Message-ID: <1190656779.4.0.721586037704.issue1196@psf.upfronthosting.co.za> Georg Brandl added the comment: The default radix is, and was always AFAICS, 10. I've now documented that in rev. 58244, 58245. ---------- resolution: -> fixed status: open -> closed __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Sep 24 20:05:34 2007 From: report at bugs.python.org (Georg Brandl) Date: Mon, 24 Sep 2007 18:05:34 -0000 Subject: [issue1189] Documentation for tp_as_number tp_as_sequence tp_as_mapping Message-ID: <1190657134.43.0.0139863800987.issue1189@psf.upfronthosting.co.za> Georg Brandl added the comment: Committed in 3k branch as rev. 58246. Just open a new issue for the 2.6 docs when they are ready :) ---------- resolution: -> accepted status: open -> closed __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Sep 24 20:08:38 2007 From: report at bugs.python.org (Georg Brandl) Date: Mon, 24 Sep 2007 18:08:38 -0000 Subject: [issue1177] urllib* 20x responses not OK? Message-ID: <1190657318.87.0.28829993071.issue1177@psf.upfronthosting.co.za> Georg Brandl added the comment: Applied your patch as r58247. __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Sep 24 20:10:27 2007 From: report at bugs.python.org (Paul F. Dubois) Date: Mon, 24 Sep 2007 18:10:27 -0000 Subject: [issue1002] Patch to rename HTMLParser module to lower_case Message-ID: <1190657427.74.0.500043706538.issue1002@psf.upfronthosting.co.za> Paul F. Dubois added the comment: Hoping I have learned to spell, another test. ---------- assignee: -> collinwinter __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Sep 24 20:12:05 2007 From: report at bugs.python.org (Paul F. Dubois) Date: Mon, 24 Sep 2007 18:12:05 -0000 Subject: [issue1198] Test of 2to3 component auditor Message-ID: <1190657525.85.0.487762391432.issue1198@psf.upfronthosting.co.za> New submission from Paul F. Dubois: This is a test issue, please ignore. ---------- assignee: collinwinter components: 2to3 (2.x to 3.0 conversion tool) messages: 56123 nosy: collinwinter, dubois severity: minor status: open title: Test of 2to3 component auditor __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Sep 24 20:12:06 2007 From: report at bugs.python.org (Paul F. Dubois) Date: Mon, 24 Sep 2007 18:12:06 -0000 Subject: [issue1198] Test of 2to3 component auditor Message-ID: <1190657525.85.0.487762391432.issue1198@psf.upfronthosting.co.za> New submission from Paul F. Dubois: This is a test issue, please ignore. ---------- assignee: collinwinter components: 2to3 (2.x to 3.0 conversion tool) messages: 56123 nosy: collinwinter, dubois severity: minor status: open title: Test of 2to3 component auditor __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Sep 24 20:12:18 2007 From: report at bugs.python.org (Paul F. Dubois) Date: Mon, 24 Sep 2007 18:12:18 -0000 Subject: [issue1198] Test of 2to3 component auditor Message-ID: <1190657538.26.0.860011213284.issue1198@psf.upfronthosting.co.za> Changes by Paul F. Dubois: ---------- status: open -> closed __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Sep 25 02:31:57 2007 From: report at bugs.python.org (Amaury Forgeot d'Arc) Date: Tue, 25 Sep 2007 00:31:57 -0000 Subject: [issue1199] Documentation for tp_as_number... version 2.6 Message-ID: <1190680317.48.0.930951647845.issue1199@psf.upfronthosting.co.za> New submission from Amaury Forgeot d'Arc: This patch is similar to http://bugs.python.org/issue1189, but in line with python svn trunk (and 2.5 most probably as well): documentation of all slots of tp_as_number, tp_as_mapping, tp_as_sequence. The main difference with 3.0 is the coercion. ---------- components: Documentation files: numbermethods-2.6.diff messages: 56124 nosy: amaury.forgeotdarc severity: normal status: open title: Documentation for tp_as_number... version 2.6 versions: Python 2.6 __________________________________ Tracker __________________________________ -------------- next part -------------- A non-text attachment was scrubbed... Name: numbermethods-2.6.diff Type: application/octet-stream Size: 9865 bytes Desc: not available Url : http://mail.python.org/pipermail/python-bugs-list/attachments/20070925/5a2cc7d2/attachment.obj From report at bugs.python.org Tue Sep 25 02:31:58 2007 From: report at bugs.python.org (Amaury Forgeot d'Arc) Date: Tue, 25 Sep 2007 00:31:58 -0000 Subject: [issue1199] Documentation for tp_as_number... version 2.6 Message-ID: <1190680317.48.0.930951647845.issue1199@psf.upfronthosting.co.za> New submission from Amaury Forgeot d'Arc: This patch is similar to http://bugs.python.org/issue1189, but in line with python svn trunk (and 2.5 most probably as well): documentation of all slots of tp_as_number, tp_as_mapping, tp_as_sequence. The main difference with 3.0 is the coercion. ---------- components: Documentation files: numbermethods-2.6.diff messages: 56124 nosy: amaury.forgeotdarc severity: normal status: open title: Documentation for tp_as_number... version 2.6 versions: Python 2.6 __________________________________ Tracker __________________________________ -------------- next part -------------- A non-text attachment was scrubbed... Name: numbermethods-2.6.diff Type: application/octet-stream Size: 9865 bytes Desc: not available Url : http://mail.python.org/pipermail/python-bugs-list/attachments/20070925/5a2cc7d2/attachment-0003.obj From report at bugs.python.org Tue Sep 25 05:37:43 2007 From: report at bugs.python.org (Senthil) Date: Tue, 25 Sep 2007 03:37:43 -0000 Subject: [issue1675455] Use getaddrinfo() in urllib2.py for IPv6 support Message-ID: <1190691463.92.0.278275951475.issue1675455@psf.upfronthosting.co.za> Senthil added the comment: Hi, The patch attached required a complete rewrite. I am attaching the modified patch, which will just substitute socket.gethostbyname with a function gethost_addrinfo which internally uses getaddrinfo and takes care of the IPv4 or IPv6 addresses translation. jjlee, skip: let me know your comments on this. One note we have to keep in mind is, testing on IPv6 address. For eg. on my system /etc/hosts 10.98.1.6 goofy.goofy.com #fe80::219:5bff:fefd:6270 localhost 127.0.0.1 localhost test_urllib2 will PASS for the above. But if I uncomment the IPv6 address, opening the local file fails. I am not sure how local file access is done with IPv6 and should urllib2 (local file opening function) itself needs to be modified. Shall check into that, with next version. ---------- nosy: +orsenthil _____________________________________ Tracker _____________________________________ -------------- next part -------------- A non-text attachment was scrubbed... Name: urllib2-getaddrinfo.patch Type: text/x-diff Size: 2457 bytes Desc: not available Url : http://mail.python.org/pipermail/python-bugs-list/attachments/20070925/be83570f/attachment.patch From report at bugs.python.org Tue Sep 25 05:38:12 2007 From: report at bugs.python.org (Senthil) Date: Tue, 25 Sep 2007 03:38:12 -0000 Subject: [issue1675455] Use getaddrinfo() in urllib2.py for IPv6 support Message-ID: <1190691492.16.0.606257926543.issue1675455@psf.upfronthosting.co.za> Changes by Senthil: _____________________________________ Tracker _____________________________________ From report at bugs.python.org Tue Sep 25 06:52:11 2007 From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=) Date: Tue, 25 Sep 2007 04:52:11 -0000 Subject: [issue1199] Documentation for tp_as_number... version 2.6 Message-ID: <1190695931.29.0.0205313822359.issue1199@psf.upfronthosting.co.za> Changes by Martin v. L?wis: ---------- keywords: +patch __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Sep 25 06:53:34 2007 From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=) Date: Tue, 25 Sep 2007 04:53:34 -0000 Subject: [issue1179] [CVE-2007-4965] Integer overflow in imageop module Message-ID: <1190696014.32.0.290161025505.issue1179@psf.upfronthosting.co.za> Changes by Martin v. L?wis: ---------- keywords: +patch __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Sep 25 07:25:31 2007 From: report at bugs.python.org (Jeffrey Yasskin) Date: Tue, 25 Sep 2007 05:25:31 -0000 Subject: [issue1200] Allow array.array to be parsed by the t# format unit. Message-ID: <1190697931.82.0.81567230307.issue1200@psf.upfronthosting.co.za> New submission from Jeffrey Yasskin: This changes PyArg_ParseTuple()'s "t#" to request a PyBUF_SIMPLE buffer like all of the other buffer-using format units instead of PyBUF_CHARACTER. Objects with multi-byte units wind up byte-order-dependent. Alternately, it might make sense to have array.array('b') and array.array('B') accept the PyBUF_CHARACTER flag. I haven't actually tested this patch on a big-endian machine. ---------- components: Interpreter Core files: let_t_format_take_array.patch messages: 56126 nosy: jyasskin severity: normal status: open title: Allow array.array to be parsed by the t# format unit. type: behavior versions: Python 3.0 __________________________________ Tracker __________________________________ -------------- next part -------------- A non-text attachment was scrubbed... Name: let_t_format_take_array.patch Type: application/octet-stream Size: 4198 bytes Desc: not available Url : http://mail.python.org/pipermail/python-bugs-list/attachments/20070925/8549bd6b/attachment-0002.obj From report at bugs.python.org Tue Sep 25 07:25:32 2007 From: report at bugs.python.org (Jeffrey Yasskin) Date: Tue, 25 Sep 2007 05:25:32 -0000 Subject: [issue1200] Allow array.array to be parsed by the t# format unit. Message-ID: <1190697931.82.0.81567230307.issue1200@psf.upfronthosting.co.za> New submission from Jeffrey Yasskin: This changes PyArg_ParseTuple()'s "t#" to request a PyBUF_SIMPLE buffer like all of the other buffer-using format units instead of PyBUF_CHARACTER. Objects with multi-byte units wind up byte-order-dependent. Alternately, it might make sense to have array.array('b') and array.array('B') accept the PyBUF_CHARACTER flag. I haven't actually tested this patch on a big-endian machine. ---------- components: Interpreter Core files: let_t_format_take_array.patch messages: 56126 nosy: jyasskin severity: normal status: open title: Allow array.array to be parsed by the t# format unit. type: behavior versions: Python 3.0 __________________________________ Tracker __________________________________ -------------- next part -------------- A non-text attachment was scrubbed... Name: let_t_format_take_array.patch Type: application/octet-stream Size: 4198 bytes Desc: not available Url : http://mail.python.org/pipermail/python-bugs-list/attachments/20070925/8549bd6b/attachment-0003.obj From report at bugs.python.org Tue Sep 25 07:27:44 2007 From: report at bugs.python.org (Georg Brandl) Date: Tue, 25 Sep 2007 05:27:44 -0000 Subject: [issue1199] Documentation for tp_as_number... version 2.6 Message-ID: <1190698064.65.0.10124786144.issue1199@psf.upfronthosting.co.za> Changes by Georg Brandl: ---------- assignee: -> georg.brandl nosy: +georg.brandl __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Sep 25 08:05:05 2007 From: report at bugs.python.org (Jeffrey Yasskin) Date: Tue, 25 Sep 2007 06:05:05 -0000 Subject: [issue1184] test fixes for immutable bytes change Message-ID: <1190700305.25.0.562513019739.issue1184@psf.upfronthosting.co.za> Jeffrey Yasskin added the comment: To be precise, this change makes bytes immutable but does not give it a __hash__ method or change the values its iterator returns. __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Sep 25 10:27:01 2007 From: report at bugs.python.org (zip) Date: Tue, 25 Sep 2007 08:27:01 -0000 Subject: [issue1201] Error in array concept Message-ID: <1190708820.99.0.177688390446.issue1201@psf.upfronthosting.co.za> New submission from zip: http://docs.python.org/tut/node5.html The best way to remember how slices work is to think of the indices as pointing between characters, with the left edge of the first character numbered 0. Then the right edge of the last character of a string of n characters has index n, for example: -- This is not possible because counting starts from 0 so the last charater must be n-1. ---------- components: Documentation messages: 56129 nosy: zip severity: minor status: open title: Error in array concept versions: Python 3.0 __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Sep 25 10:27:01 2007 From: report at bugs.python.org (zip) Date: Tue, 25 Sep 2007 08:27:01 -0000 Subject: [issue1201] Error in array concept Message-ID: <1190708820.99.0.177688390446.issue1201@psf.upfronthosting.co.za> New submission from zip: http://docs.python.org/tut/node5.html The best way to remember how slices work is to think of the indices as pointing between characters, with the left edge of the first character numbered 0. Then the right edge of the last character of a string of n characters has index n, for example: -- This is not possible because counting starts from 0 so the last charater must be n-1. ---------- components: Documentation messages: 56129 nosy: zip severity: minor status: open title: Error in array concept versions: Python 3.0 __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Sep 25 13:31:11 2007 From: report at bugs.python.org (Armin Rigo) Date: Tue, 25 Sep 2007 11:31:11 -0000 Subject: [issue1202] zlib.crc32() and adler32() return value Message-ID: <1190719871.47.0.233788425538.issue1202@psf.upfronthosting.co.za> New submission from Armin Rigo: The functions zlib.crc32() and zlib.adler32() return a signed value in the range(-2147483648, 2147483648) on 32-bit platforms, but an unsigned value in the range(0, 4294967296) on 64-bit platforms. This means that half the possible answers are numerically different on these two kinds of platforms. Ideally, this should be fixed by having them always return unsigned numbers (their C return type is unsigned too). It's unclear if we can do this without breaking existing code, though :-( ---------- components: Extension Modules messages: 56130 nosy: arigo severity: normal status: open title: zlib.crc32() and adler32() return value type: behavior __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Sep 25 13:31:11 2007 From: report at bugs.python.org (Armin Rigo) Date: Tue, 25 Sep 2007 11:31:11 -0000 Subject: [issue1202] zlib.crc32() and adler32() return value Message-ID: <1190719871.47.0.233788425538.issue1202@psf.upfronthosting.co.za> New submission from Armin Rigo: The functions zlib.crc32() and zlib.adler32() return a signed value in the range(-2147483648, 2147483648) on 32-bit platforms, but an unsigned value in the range(0, 4294967296) on 64-bit platforms. This means that half the possible answers are numerically different on these two kinds of platforms. Ideally, this should be fixed by having them always return unsigned numbers (their C return type is unsigned too). It's unclear if we can do this without breaking existing code, though :-( ---------- components: Extension Modules messages: 56130 nosy: arigo severity: normal status: open title: zlib.crc32() and adler32() return value type: behavior __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Sep 25 14:53:06 2007 From: report at bugs.python.org (Alan McIntyre) Date: Tue, 25 Sep 2007 12:53:06 -0000 Subject: [issue1201] Error in array concept Message-ID: <1190724786.48.0.78408289139.issue1201@psf.upfronthosting.co.za> Alan McIntyre added the comment: The last character is n-1, but the section you quote says the *right edge* of the last character (not the last character itself) has index n; this seems correct in the context of the mnemonic scheme. ---------- nosy: +alanmcintyre __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Sep 25 18:29:23 2007 From: report at bugs.python.org (Bill Janssen) Date: Tue, 25 Sep 2007 16:29:23 -0000 Subject: [issue1203] ctypes doesn't work on Mac with --disable-toolbox-glue Message-ID: <1190737763.36.0.452761453951.issue1203@psf.upfronthosting.co.za> New submission from Bill Janssen: If you build Python with --disable-toolbox-glue on OS X, the attempt to import ctypes fails because it critically depends on "gestalt", one of the modules in the toolbox. It only uses this to check whether the OS level is 10.4 or something earlier, and only once, at load. Might be a good idea to substitute a check which doesn't require the toolbox, such as looking at platform.release(). ---------- components: Library (Lib), Macintosh messages: 56132 nosy: janssen severity: normal status: open title: ctypes doesn't work on Mac with --disable-toolbox-glue type: behavior versions: Python 2.6, Python 3.0 __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Sep 25 18:29:23 2007 From: report at bugs.python.org (Bill Janssen) Date: Tue, 25 Sep 2007 16:29:23 -0000 Subject: [issue1203] ctypes doesn't work on Mac with --disable-toolbox-glue Message-ID: <1190737763.36.0.452761453951.issue1203@psf.upfronthosting.co.za> New submission from Bill Janssen: If you build Python with --disable-toolbox-glue on OS X, the attempt to import ctypes fails because it critically depends on "gestalt", one of the modules in the toolbox. It only uses this to check whether the OS level is 10.4 or something earlier, and only once, at load. Might be a good idea to substitute a check which doesn't require the toolbox, such as looking at platform.release(). ---------- components: Library (Lib), Macintosh messages: 56132 nosy: janssen severity: normal status: open title: ctypes doesn't work on Mac with --disable-toolbox-glue type: behavior versions: Python 2.6, Python 3.0 __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Sep 25 18:49:54 2007 From: report at bugs.python.org (Thomas Heller) Date: Tue, 25 Sep 2007 16:49:54 -0000 Subject: [issue1203] ctypes doesn't work on Mac with --disable-toolbox-glue Message-ID: <1190738994.09.0.0200812959968.issue1203@psf.upfronthosting.co.za> Thomas Heller added the comment: Would you like to prepare a patch? I have no idea how the return values of gestalt.gestalt("sysv") and platform.release() relate to each other... ---------- nosy: +theller __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Sep 25 18:54:35 2007 From: report at bugs.python.org (Bill Janssen) Date: Tue, 25 Sep 2007 16:54:35 -0000 Subject: [issue1203] ctypes doesn't work on Mac with --disable-toolbox-glue Message-ID: <1190739275.24.0.17009669928.issue1203@psf.upfronthosting.co.za> Bill Janssen added the comment: Here's a patch against the trunk. I've only tried it on OS X 10.4.10, and only with test_ctypes. Ideally, we should test on an earlier version of OS X, but I don't have one handy. __________________________________ Tracker __________________________________ -------------- next part -------------- A non-text attachment was scrubbed... Name: p Type: application/octet-stream Size: 899 bytes Desc: not available Url : http://mail.python.org/pipermail/python-bugs-list/attachments/20070925/07ebf905/attachment.obj From report at bugs.python.org Tue Sep 25 19:02:08 2007 From: report at bugs.python.org (Thomas Heller) Date: Tue, 25 Sep 2007 17:02:08 -0000 Subject: [issue1203] ctypes doesn't work on Mac with --disable-toolbox-glue Message-ID: <1190739728.09.0.161585643044.issue1203@psf.upfronthosting.co.za> Thomas Heller added the comment: On the mac where I have access to platform.release() returns the string '8.10.0'. gestalt.gestalt("sysv") returns 0x1049. Your patch does not look correct to me. __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Sep 25 19:24:19 2007 From: report at bugs.python.org (Guido van Rossum) Date: Tue, 25 Sep 2007 17:24:19 -0000 Subject: [issue1200] Allow array.array to be parsed by the t# format unit. Message-ID: <1190741059.93.0.161191601923.issue1200@psf.upfronthosting.co.za> Guido van Rossum added the comment: Hm, doesn't this make t and t# identical to s and s#? Or if there are still differences, are they still relevant? I vaguely recall that t and t# were introduced as variants of s and s# that requested char buffers. Since we're phasing out the whole idea of char buffers, perhaps there's no longer a need for the distinction? ---------- nosy: +gvanrossum __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Sep 25 19:30:38 2007 From: report at bugs.python.org (Bill Janssen) Date: Tue, 25 Sep 2007 17:30:38 -0000 Subject: [issue1203] ctypes doesn't work on Mac with --disable-toolbox-glue Message-ID: <1190741438.3.0.363827047292.issue1203@psf.upfronthosting.co.za> Bill Janssen added the comment: Sorry, you're absolutely right. Here's a corrected patch. __________________________________ Tracker __________________________________ -------------- next part -------------- A non-text attachment was scrubbed... Name: p Type: application/octet-stream Size: 950 bytes Desc: not available Url : http://mail.python.org/pipermail/python-bugs-list/attachments/20070925/e2df97c4/attachment-0001.obj From report at bugs.python.org Tue Sep 25 19:30:40 2007 From: report at bugs.python.org (Guido van Rossum) Date: Tue, 25 Sep 2007 17:30:40 -0000 Subject: [issue1201] Error in array concept Message-ID: <1190741440.12.0.0428491306465.issue1201@psf.upfronthosting.co.za> Changes by Guido van Rossum: ---------- resolution: -> invalid status: open -> closed __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Sep 25 19:30:48 2007 From: report at bugs.python.org (Bill Janssen) Date: Tue, 25 Sep 2007 17:30:48 -0000 Subject: [issue1203] ctypes doesn't work on Mac with --disable-toolbox-glue Message-ID: <1190741448.93.0.402186216378.issue1203@psf.upfronthosting.co.za> Changes by Bill Janssen: __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Sep 25 20:29:27 2007 From: report at bugs.python.org (Guido van Rossum) Date: Tue, 25 Sep 2007 18:29:27 -0000 Subject: [issue1200] Allow array.array to be parsed by the t# format unit. Message-ID: <1190744967.47.0.113047923855.issue1200@psf.upfronthosting.co.za> Guido van Rossum added the comment: Never mind. s/s# has explicit support for unicode. There is no t; t# requires a buffer that's not unicode (that's what PyBUF_CHARACTER amounts to). If there's one area I'd love to refactor it's getargs.c. What a sprawling mess! Also, we should kill PyBUF_CHARACTER completely. __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Sep 25 21:16:12 2007 From: report at bugs.python.org (Thomas Heller) Date: Tue, 25 Sep 2007 19:16:12 -0000 Subject: [issue1203] ctypes doesn't work on Mac with --disable-toolbox-glue Message-ID: <1190747772.87.0.458261693853.issue1203@psf.upfronthosting.co.za> Thomas Heller added the comment: This patch looks better. However, the 'os.uname()' function seems to return the information that we need; so I updated the patch to use this instead. Can you please proofread it (osx.patch) ? __________________________________ Tracker __________________________________ -------------- next part -------------- A non-text attachment was scrubbed... Name: osx.patch Type: text/x-patch Size: 930 bytes Desc: not available Url : http://mail.python.org/pipermail/python-bugs-list/attachments/20070925/9221ae0b/attachment.bin From report at bugs.python.org Tue Sep 25 21:34:08 2007 From: report at bugs.python.org (Mike Beachy) Date: Tue, 25 Sep 2007 19:34:08 -0000 Subject: [issue1204] readline configuration for shared libs w/o curses dependencies Message-ID: <1190748848.08.0.561409665353.issue1204@psf.upfronthosting.co.za> New submission from Mike Beachy: For RHEL 3 (and it also appears RHEL 4 and 5) the libreadline shared lib has no specified lib requirement that satisfies the tgetent and related symbols. (These symbols are provided by ncursesw, ncurses, curses, termcap as noted in the python setup.py.) The configure script does not add these required libs in for the readline tests, and so the autoconf tests will fail and it will incorrectly determine that readline is not present (and so not define HAVE_RL_COMPLETION_MATCHES etc.) I guess this generally does not prevent the readline module from being compiled since setup.py does its own search for readline and adds in the needed curses library. It does prevent proper declaration of the completion_matches function, however. On 32 bit systems this doesn't matter but on 64 bit ones it does as the undeclared (but present in libreadline) completion_matches returns a char **. The fix checked in with r54874 after the 2.5.1 release (issue 1703270) to Modules/readline.c fixes the problem for completion_matches specifically, but the problem of incorrect determination of readline presence still exists. Attached is a patch to fix the problem: it adds the necessary additional library to the temporary LIBS definition in the readline tests, using the same order of curses libs specified in setup.py. (The patch includes the changes for the configure script in addition to configure.in.) ---------- components: Installation files: full.patch messages: 56140 nosy: mbeachy severity: normal status: open title: readline configuration for shared libs w/o curses dependencies type: compile error versions: Python 2.5 __________________________________ Tracker __________________________________ -------------- next part -------------- A non-text attachment was scrubbed... Name: full.patch Type: text/x-patch Size: 3595 bytes Desc: not available Url : http://mail.python.org/pipermail/python-bugs-list/attachments/20070925/7d6dc67f/attachment.bin From report at bugs.python.org Tue Sep 25 21:34:08 2007 From: report at bugs.python.org (Mike Beachy) Date: Tue, 25 Sep 2007 19:34:08 -0000 Subject: [issue1204] readline configuration for shared libs w/o curses dependencies Message-ID: <1190748848.08.0.561409665353.issue1204@psf.upfronthosting.co.za> New submission from Mike Beachy: For RHEL 3 (and it also appears RHEL 4 and 5) the libreadline shared lib has no specified lib requirement that satisfies the tgetent and related symbols. (These symbols are provided by ncursesw, ncurses, curses, termcap as noted in the python setup.py.) The configure script does not add these required libs in for the readline tests, and so the autoconf tests will fail and it will incorrectly determine that readline is not present (and so not define HAVE_RL_COMPLETION_MATCHES etc.) I guess this generally does not prevent the readline module from being compiled since setup.py does its own search for readline and adds in the needed curses library. It does prevent proper declaration of the completion_matches function, however. On 32 bit systems this doesn't matter but on 64 bit ones it does as the undeclared (but present in libreadline) completion_matches returns a char **. The fix checked in with r54874 after the 2.5.1 release (issue 1703270) to Modules/readline.c fixes the problem for completion_matches specifically, but the problem of incorrect determination of readline presence still exists. Attached is a patch to fix the problem: it adds the necessary additional library to the temporary LIBS definition in the readline tests, using the same order of curses libs specified in setup.py. (The patch includes the changes for the configure script in addition to configure.in.) ---------- components: Installation files: full.patch messages: 56140 nosy: mbeachy severity: normal status: open title: readline configuration for shared libs w/o curses dependencies type: compile error versions: Python 2.5 __________________________________ Tracker __________________________________ -------------- next part -------------- A non-text attachment was scrubbed... Name: full.patch Type: text/x-patch Size: 3595 bytes Desc: not available Url : http://mail.python.org/pipermail/python-bugs-list/attachments/20070925/7d6dc67f/attachment-0001.bin From report at bugs.python.org Wed Sep 26 00:42:34 2007 From: report at bugs.python.org (Vinay Sajip) Date: Tue, 25 Sep 2007 22:42:34 -0000 Subject: [issue1197] logging: formatter does not accept %(funcName)s properly Message-ID: <1190760154.81.0.394588214446.issue1197@psf.upfronthosting.co.za> Vinay Sajip added the comment: This is not a logging bug, but related to #1180193. See http://bugs.python.org/issue1180193 ---------- assignee: -> vsajip nosy: +vsajip resolution: -> duplicate status: open -> closed __________________________________ Tracker __________________________________ From report at bugs.python.org Wed Sep 26 05:09:28 2007 From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=) Date: Wed, 26 Sep 2007 03:09:28 -0000 Subject: [issue1204] readline configuration for shared libs w/o curses dependencies Message-ID: <1190776168.51.0.72393473045.issue1204@psf.upfronthosting.co.za> Changes by Martin v. L?wis: ---------- keywords: +patch __________________________________ Tracker __________________________________ From report at bugs.python.org Wed Sep 26 09:55:35 2007 From: report at bugs.python.org (Francesco Cosoleto) Date: Wed, 26 Sep 2007 07:55:35 -0000 Subject: [issue1205] urllib fail to read URL contents, urllib2 crash Python Message-ID: <1190793332.9.0.29899287923.issue1205@psf.upfronthosting.co.za> New submission from Francesco Cosoleto: urllib fail to read URL contents, urllib2 crash Python Python version: ------------------------- Python 2.5.1 (r251:54863, May 18 2007, 16:56:43) [GCC 3.4.4 (cygming special, gdc 0.12, using dmd 0.125)] Python 2.5.1 (r251:54863, Apr 18 2007, 08:51:08) [MSC v.1310 32 bit (Intel)] on win32 Python 2.4.4 (#2, Aug 16 2007, 00:34:54) [GCC 4.1.3 20070812 (prerelease) (Debian 4.1.2-15)] on linux2 ------------------------- Working with GNU wget: ------------------------- $ wget -S http://www.recherche.fr/encyclopedie/Thomas-Robert_Bugeaud --08:42:21-- http://www.recherche.fr/encyclopedie/Thomas-Robert_Bugeaud => `Thomas-Robert_Bugeaud' Risoluzione di www.recherche.fr in corso... 88.191.11.214 Connessione a www.recherche.fr|88.191.11.214:80... connesso. HTTP richiesta inviata, aspetto la risposta... HTTP/1.1 200 OK Date: Wed, 26 Sep 2007 06:42:53 GMT Server: Apache/2.2.3 (Debian) PHP/5.2.3-0.dotdeb.1 with Suhosin-Patch X-Powered-By: PHP/5.2.3-0.dotdeb.1 Keep-Alive: timeout=15, max=100 Connection: Keep-Alive Transfer-Encoding: chunked Content-Type: text/html; charset=UTF-8 Lunghezza: non specificato [text/html] [ <=> ] 267,080 --.--K/s 08:42:42 (14.11 KB/s) - "Thomas-Robert_Bugeaud" salvato [267080] ------------------------- Python: ------------------------- >>> import urllib >>> a = urllib.urlopen('http://www.recherche.fr/encyclopedie/Thomas- Robert_Bugeaud') >>> c = a.read(1024*1024*2) >>> len(c) 1035220 >>> c[63000:64000] 'he.fr en page d\'accueil
\n Partenaires : Cartes\n postales  Rencontres\n gratuites\n   Noms\n de domaine gratuits  Encyclopedia 

\n

\n\n

\n \n \n\n\n\r\n\x00\x00\x00\x00\x00\x00\x00 \x00\x00[...omission...]\x00\x00\x00\x00' ------------------------- As above, but with urllib2 module instead of urllib: ------------------------- File "/usr/lib/python2.5/socket.py", line 291, in read data = self._sock.recv(recv_size) File "/usr/lib/python2.5/httplib.py", line 509, in read return self._read_chunked(amt) File "/usr/lib/python2.5/httplib.py", line 548, in _read_chunked chunk_left = int(line, 16) ValueError: invalid literal for int() with base 16: '\x00\x00\x00\x00 \x00\x00\x00\x00\x00\x00\x00[...omission...]\x00\x00\x00\x00\x00\x00\x00 \ ------------------------- As above, but with Python 2.4: ------------------------- >>> import urllib2 >>> a = urllib2.urlopen('http://www.recherche.fr/encyclopedie/Thomas- Robert_Bugeaud') >>> >>> c = a.read(1024*1024*2) Traceback (most recent call last): File "", line 1, in ? File "/usr/lib/python2.4/socket.py", line 295, in read data = self._sock.recv(recv_size) File "/usr/lib/python2.4/httplib.py", line 460, in read return self._read_chunked(amt) File "/usr/lib/python2.4/httplib.py", line 499, in _read_chunked chunk_left = int(line, 16) ValueError: invalid literal for int(): ------------------------- Regards, Francesco Cosoleto ---------- components: None messages: 56143 nosy: cosoleto severity: normal status: open title: urllib fail to read URL contents, urllib2 crash Python type: crash versions: Python 2.5 __________________________________ Tracker __________________________________ From report at bugs.python.org Wed Sep 26 09:55:33 2007 From: report at bugs.python.org (Francesco Cosoleto) Date: Wed, 26 Sep 2007 07:55:33 -0000 Subject: [issue1205] urllib fail to read URL contents, urllib2 crash Python Message-ID: <1190793332.9.0.29899287923.issue1205@psf.upfronthosting.co.za> New submission from Francesco Cosoleto: urllib fail to read URL contents, urllib2 crash Python Python version: ------------------------- Python 2.5.1 (r251:54863, May 18 2007, 16:56:43) [GCC 3.4.4 (cygming special, gdc 0.12, using dmd 0.125)] Python 2.5.1 (r251:54863, Apr 18 2007, 08:51:08) [MSC v.1310 32 bit (Intel)] on win32 Python 2.4.4 (#2, Aug 16 2007, 00:34:54) [GCC 4.1.3 20070812 (prerelease) (Debian 4.1.2-15)] on linux2 ------------------------- Working with GNU wget: ------------------------- $ wget -S http://www.recherche.fr/encyclopedie/Thomas-Robert_Bugeaud --08:42:21-- http://www.recherche.fr/encyclopedie/Thomas-Robert_Bugeaud => `Thomas-Robert_Bugeaud' Risoluzione di www.recherche.fr in corso... 88.191.11.214 Connessione a www.recherche.fr|88.191.11.214:80... connesso. HTTP richiesta inviata, aspetto la risposta... HTTP/1.1 200 OK Date: Wed, 26 Sep 2007 06:42:53 GMT Server: Apache/2.2.3 (Debian) PHP/5.2.3-0.dotdeb.1 with Suhosin-Patch X-Powered-By: PHP/5.2.3-0.dotdeb.1 Keep-Alive: timeout=15, max=100 Connection: Keep-Alive Transfer-Encoding: chunked Content-Type: text/html; charset=UTF-8 Lunghezza: non specificato [text/html] [ <=> ] 267,080 --.--K/s 08:42:42 (14.11 KB/s) - "Thomas-Robert_Bugeaud" salvato [267080] ------------------------- Python: ------------------------- >>> import urllib >>> a = urllib.urlopen('http://www.recherche.fr/encyclopedie/Thomas- Robert_Bugeaud') >>> c = a.read(1024*1024*2) >>> len(c) 1035220 >>> c[63000:64000] 'he.fr en page d\'accueil
\n Partenaires : Cartes\n postales  Rencontres\n gratuites\n   Noms\n de domaine gratuits  Encyclopedia 

\n

\n\n

\n \n \n\n\n\r\n\x00\x00\x00\x00\x00\x00\x00 \x00\x00[...omission...]\x00\x00\x00\x00' ------------------------- As above, but with urllib2 module instead of urllib: ------------------------- File "/usr/lib/python2.5/socket.py", line 291, in read data = self._sock.recv(recv_size) File "/usr/lib/python2.5/httplib.py", line 509, in read return self._read_chunked(amt) File "/usr/lib/python2.5/httplib.py", line 548, in _read_chunked chunk_left = int(line, 16) ValueError: invalid literal for int() with base 16: '\x00\x00\x00\x00 \x00\x00\x00\x00\x00\x00\x00[...omission...]\x00\x00\x00\x00\x00\x00\x00 \ ------------------------- As above, but with Python 2.4: ------------------------- >>> import urllib2 >>> a = urllib2.urlopen('http://www.recherche.fr/encyclopedie/Thomas- Robert_Bugeaud') >>> >>> c = a.read(1024*1024*2) Traceback (most recent call last): File "", line 1, in ? File "/usr/lib/python2.4/socket.py", line 295, in read data = self._sock.recv(recv_size) File "/usr/lib/python2.4/httplib.py", line 460, in read return self._read_chunked(amt) File "/usr/lib/python2.4/httplib.py", line 499, in _read_chunked chunk_left = int(line, 16) ValueError: invalid literal for int(): ------------------------- Regards, Francesco Cosoleto ---------- components: None messages: 56143 nosy: cosoleto severity: normal status: open title: urllib fail to read URL contents, urllib2 crash Python type: crash versions: Python 2.5 __________________________________ Tracker __________________________________ From report at bugs.python.org Wed Sep 26 16:07:54 2007 From: report at bugs.python.org (Gabriel Genellina) Date: Wed, 26 Sep 2007 14:07:54 -0000 Subject: [issue1205] urllib fail to read URL contents, urllib2 crash Python Message-ID: <1190815674.57.0.150807839533.issue1205@psf.upfronthosting.co.za> Gabriel Genellina added the comment: This is a server bug. Internet Explorer 6 can't show the page either. The response is malformed; it uses chunked transfer, and RFC2616 section 3.6.1 says "The chunk-size field is a string of hex digits indicating the size of the chunk. The chunked encoding is ended by any chunk whose size is zero[...]" After the (first and only) chunk of around 63K, should come a 0-length chunk: a line with one or more digits "0" followed by CR+LF. But the server is not sending that last chunk, instead it sends lots of nul bytes, until eventually a CR,LF sequence arrives. Neither IE nor Python can handle that (IE keeps requesting the page again and again). wget is apparently a lot more relaxed and decides that the first chunk is good enough. Perhaps urllib/urllib2 could handle the error and raise a more meaningful exception in this case, but just ignoring the error doesn't appear to be the right thing IMHO. ---------- nosy: +gagenellina __________________________________ Tracker __________________________________ From report at bugs.python.org Wed Sep 26 18:48:42 2007 From: report at bugs.python.org (Oleg Broytmann) Date: Wed, 26 Sep 2007 16:48:42 -0000 Subject: [issue1206] logging/__init__.py Message-ID: <1190825322.64.0.711764543828.issue1206@psf.upfronthosting.co.za> New submission from Oleg Broytmann: See the thread in the python-dev mailing list: http://mail.python.org/pipermail/python-dev/2007-September/074732.html ---------- components: Library (Lib) files: __init__.py.patch messages: 56145 nosy: phd severity: minor status: open title: logging/__init__.py versions: Python 2.5 __________________________________ Tracker __________________________________ -------------- next part -------------- A non-text attachment was scrubbed... Name: __init__.py.patch Type: text/x-diff Size: 541 bytes Desc: not available Url : http://mail.python.org/pipermail/python-bugs-list/attachments/20070926/938081f5/attachment.patch From report at bugs.python.org Wed Sep 26 18:48:43 2007 From: report at bugs.python.org (Oleg Broytmann) Date: Wed, 26 Sep 2007 16:48:43 -0000 Subject: [issue1206] logging/__init__.py Message-ID: <1190825322.64.0.711764543828.issue1206@psf.upfronthosting.co.za> New submission from Oleg Broytmann: See the thread in the python-dev mailing list: http://mail.python.org/pipermail/python-dev/2007-September/074732.html ---------- components: Library (Lib) files: __init__.py.patch messages: 56145 nosy: phd severity: minor status: open title: logging/__init__.py versions: Python 2.5 __________________________________ Tracker __________________________________ -------------- next part -------------- A non-text attachment was scrubbed... Name: __init__.py.patch Type: text/x-diff Size: 541 bytes Desc: not available Url : http://mail.python.org/pipermail/python-bugs-list/attachments/20070926/938081f5/attachment-0001.patch From report at bugs.python.org Wed Sep 26 18:51:11 2007 From: report at bugs.python.org (Guido van Rossum) Date: Wed, 26 Sep 2007 16:51:11 -0000 Subject: [issue1202] zlib.crc32() and adler32() return value Message-ID: <1190825471.28.0.752115884573.issue1202@psf.upfronthosting.co.za> Guido van Rossum added the comment: Since it's basically a magic cookie, not a meaningful numeric value, I'd propose sticking with backwards compatibility and fixing the 64-bit version to return a signed version. return x - ((x & 0x80000000) <<1) anyone? ---------- nosy: +gvanrossum __________________________________ Tracker __________________________________ From report at bugs.python.org Wed Sep 26 18:51:45 2007 From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=) Date: Wed, 26 Sep 2007 16:51:45 -0000 Subject: [issue1206] logging/__init__.py Message-ID: <1190825505.82.0.352777740402.issue1206@psf.upfronthosting.co.za> Changes by Martin v. L?wis: ---------- keywords: +patch __________________________________ Tracker __________________________________ From report at bugs.python.org Wed Sep 26 18:55:10 2007 From: report at bugs.python.org (Guido van Rossum) Date: Wed, 26 Sep 2007 16:55:10 -0000 Subject: [issue1205] urllib fail to read URL contents, urllib2 crash Python Message-ID: <1190825710.47.0.00752259168953.issue1205@psf.upfronthosting.co.za> Guido van Rossum added the comment: Maybe the French internet is incompatible with the rest of the world? :-) ---------- nosy: +gvanrossum __________________________________ Tracker __________________________________ From report at bugs.python.org Wed Sep 26 21:25:04 2007 From: report at bugs.python.org (Bluebird) Date: Wed, 26 Sep 2007 19:25:04 -0000 Subject: [issue1207] Load tests from path (patch included) Message-ID: <1190834704.12.0.956914269209.issue1207@psf.upfronthosting.co.za> New submission from Bluebird: Something very nice about unittest is that it can find automatically the TestCase that you declare, and the test methods of every test case. This makes the operation of adding or removing tests very simple. For test modules however, there is nothing to automatically load all the modules of a given directory. I think that would be very helpful. Here is my proposal, to add to the set of TestLoader methods: ============================ def loadTestsFromPath( path='', filePattern='test*.py' ): '''Load all the TestCase in all the module of the given path. path: directory containing test files filePattern: glob pattern to find test modules inside path. Default is test*.py The path will be converted into an import statement so anything that can not be imported will not work. The path must be relative to the current directory, and can not include '.' and '..' directories. To simply load all the test files of the current directories, pass an empty path (the default). Return a test suite containing all the tests. ''' if len(path) == 0: pathPattern = filePattern else: pathPattern = path + '/' + filePattern pathPattern = os.path.normpath( pathPattern ) fileList = glob.glob( pathPattern ) mainSuite = TestSuite() for f in fileList: importName = f[:-3] importName = importName.replace( '\\', '.' ) importName = importName.replace( '/', '.' ) suite = defaultTestLoader.loadTestsFromName(importName) mainSuite._tests.extend( suite._tests ) return mainSuite =================== I use it like this: on my project, I have the following directory organisation: vy + run_all_tests.py + tests - run_tests.py - test_xxx.py - test_yyy.py + libvy + tests - run_tests.py - test_xxx.py - test_yyy.py + qvy + tests - run_tests.py - test_xxx.py - test_yyy.py I can do either: - cd libvy/tests && python run_tests.py - cd qvy/tests && python run_tests.py - cd tests && python run_tests.py - run_all_tests.py Each time I add a new test module, it is automatically picked up by the test runners thank to the loadFromPath() feature. It makes it easy to maintain the global test suite that runs all the tests. That's the most important one because that test suite is responsible for non regression. run_tests.py: ============= if __name__ == '__main__': mainSuite = TestSuite() mainSuite._tests.extend( loadTestsFromPath('.')._tests ) ttr = TextTestRunner(verbosity=2) ttr.run( mainSuite ) run_all_tests.py: ================= if __name__ == '__main__': mainSuite = TestSuite() mainSuite._tests.extend( loadTestsFromPath( 'libvy/tests' )._tests ) mainSuite._tests.extend( loadTestsFromPath( 'qvy/tests' )._tests ) mainSuite._tests.extend( loadTestsFromPath( 'tests' )._tests ) ttr = TextTestRunner(verbosity=2) ttr.run( mainSuite ) ---------- components: Tests messages: 56148 nosy: bluebird severity: normal status: open title: Load tests from path (patch included) type: rfe versions: Python 2.5 __________________________________ Tracker __________________________________ From report at bugs.python.org Wed Sep 26 21:25:04 2007 From: report at bugs.python.org (Bluebird) Date: Wed, 26 Sep 2007 19:25:04 -0000 Subject: [issue1207] Load tests from path (patch included) Message-ID: <1190834704.12.0.956914269209.issue1207@psf.upfronthosting.co.za> New submission from Bluebird: Something very nice about unittest is that it can find automatically the TestCase that you declare, and the test methods of every test case. This makes the operation of adding or removing tests very simple. For test modules however, there is nothing to automatically load all the modules of a given directory. I think that would be very helpful. Here is my proposal, to add to the set of TestLoader methods: ============================ def loadTestsFromPath( path='', filePattern='test*.py' ): '''Load all the TestCase in all the module of the given path. path: directory containing test files filePattern: glob pattern to find test modules inside path. Default is test*.py The path will be converted into an import statement so anything that can not be imported will not work. The path must be relative to the current directory, and can not include '.' and '..' directories. To simply load all the test files of the current directories, pass an empty path (the default). Return a test suite containing all the tests. ''' if len(path) == 0: pathPattern = filePattern else: pathPattern = path + '/' + filePattern pathPattern = os.path.normpath( pathPattern ) fileList = glob.glob( pathPattern ) mainSuite = TestSuite() for f in fileList: importName = f[:-3] importName = importName.replace( '\\', '.' ) importName = importName.replace( '/', '.' ) suite = defaultTestLoader.loadTestsFromName(importName) mainSuite._tests.extend( suite._tests ) return mainSuite =================== I use it like this: on my project, I have the following directory organisation: vy + run_all_tests.py + tests - run_tests.py - test_xxx.py - test_yyy.py + libvy + tests - run_tests.py - test_xxx.py - test_yyy.py + qvy + tests - run_tests.py - test_xxx.py - test_yyy.py I can do either: - cd libvy/tests && python run_tests.py - cd qvy/tests && python run_tests.py - cd tests && python run_tests.py - run_all_tests.py Each time I add a new test module, it is automatically picked up by the test runners thank to the loadFromPath() feature. It makes it easy to maintain the global test suite that runs all the tests. That's the most important one because that test suite is responsible for non regression. run_tests.py: ============= if __name__ == '__main__': mainSuite = TestSuite() mainSuite._tests.extend( loadTestsFromPath('.')._tests ) ttr = TextTestRunner(verbosity=2) ttr.run( mainSuite ) run_all_tests.py: ================= if __name__ == '__main__': mainSuite = TestSuite() mainSuite._tests.extend( loadTestsFromPath( 'libvy/tests' )._tests ) mainSuite._tests.extend( loadTestsFromPath( 'qvy/tests' )._tests ) mainSuite._tests.extend( loadTestsFromPath( 'tests' )._tests ) ttr = TextTestRunner(verbosity=2) ttr.run( mainSuite ) ---------- components: Tests messages: 56148 nosy: bluebird severity: normal status: open title: Load tests from path (patch included) type: rfe versions: Python 2.5 __________________________________ Tracker __________________________________ From report at bugs.python.org Wed Sep 26 22:34:54 2007 From: report at bugs.python.org (Martin Horcicka) Date: Wed, 26 Sep 2007 20:34:54 -0000 Subject: [issue1208] Match object should be guaranteed to always be true Message-ID: <1190838894.61.0.476932713989.issue1208@psf.upfronthosting.co.za> New submission from Martin Horcicka: Many people expect the match object from the re module to always be true. They use it this way: if regexp.match(string): do_something() Some people do not expect it and use it differently: if regexp.match(string) is not None: do_something() Even in the standard library both ways are used. The first way is simpler and nicer and thus better, in my opinion. Current implementation of the match object (implemented as _sre.SRE_Match object in Modules/_sre.c) seems to guarantee the trueness (someone should check it) but in fact, there is no guarantee described in the documentation. ---------- components: Documentation, Library (Lib) messages: 56149 nosy: horcicka severity: normal status: open title: Match object should be guaranteed to always be true type: behavior __________________________________ Tracker __________________________________ From report at bugs.python.org Wed Sep 26 22:34:54 2007 From: report at bugs.python.org (Martin Horcicka) Date: Wed, 26 Sep 2007 20:34:54 -0000 Subject: [issue1208] Match object should be guaranteed to always be true Message-ID: <1190838894.61.0.476932713989.issue1208@psf.upfronthosting.co.za> New submission from Martin Horcicka: Many people expect the match object from the re module to always be true. They use it this way: if regexp.match(string): do_something() Some people do not expect it and use it differently: if regexp.match(string) is not None: do_something() Even in the standard library both ways are used. The first way is simpler and nicer and thus better, in my opinion. Current implementation of the match object (implemented as _sre.SRE_Match object in Modules/_sre.c) seems to guarantee the trueness (someone should check it) but in fact, there is no guarantee described in the documentation. ---------- components: Documentation, Library (Lib) messages: 56149 nosy: horcicka severity: normal status: open title: Match object should be guaranteed to always be true type: behavior __________________________________ Tracker __________________________________ From report at bugs.python.org Thu Sep 27 02:23:46 2007 From: report at bugs.python.org (=?utf-8?q?=0A=09=09=09=09=09Jim_Jewett=0A=09=09=09=09?=) Date: Thu, 27 Sep 2007 00:23:46 -0000 Subject: [issue1209] IOError won't accept tuples longer than 3 Message-ID: <1190852626.6.0.0118628699735.issue1209@psf.upfronthosting.co.za> New submission from Jim Jewett : EnvironmentError (including subclass IOError) has special treatment when constructed with a 2-tuple or 3-tuple. A four-tuple turns off this special treatment (and was used by urllib for that reason). As of 2.5, a four-tuple raises a TypeError instead of just turning off the special treatment. ---------- components: Extension Modules messages: 56150 nosy: jimjjewett severity: normal status: open title: IOError won't accept tuples longer than 3 type: behavior versions: Python 2.5 __________________________________ Tracker __________________________________ From report at bugs.python.org Thu Sep 27 02:23:46 2007 From: report at bugs.python.org (=?utf-8?q?=0A=09=09=09=09=09Jim_Jewett=0A=09=09=09=09?=) Date: Thu, 27 Sep 2007 00:23:46 -0000 Subject: [issue1209] IOError won't accept tuples longer than 3 Message-ID: <1190852626.6.0.0118628699735.issue1209@psf.upfronthosting.co.za> New submission from Jim Jewett : EnvironmentError (including subclass IOError) has special treatment when constructed with a 2-tuple or 3-tuple. A four-tuple turns off this special treatment (and was used by urllib for that reason). As of 2.5, a four-tuple raises a TypeError instead of just turning off the special treatment. ---------- components: Extension Modules messages: 56150 nosy: jimjjewett severity: normal status: open title: IOError won't accept tuples longer than 3 type: behavior versions: Python 2.5 __________________________________ Tracker __________________________________ From report at bugs.python.org Thu Sep 27 05:21:31 2007 From: report at bugs.python.org (=?utf-8?q?=0A=09=09=09=09=09jos=0A=09=09=09=09?=) Date: Thu, 27 Sep 2007 03:21:31 -0000 Subject: [issue1205] urllib fail to read URL contents, urllib2 crash Python Message-ID: <1190863291.01.0.498135059883.issue1205@psf.upfronthosting.co.za> jos added the comment: Firefox 2.0.0.7 and Safari 2.0.4 can who this page. In my opinion, Python urllib should be more practical and provide a way to read this kind of page. "In general, an implementation must be conservative in its sending behavior, and liberal in its receiving behavior." [RFC 791 3.2] ---------- nosy: +josm __________________________________ Tracker __________________________________ From report at bugs.python.org Thu Sep 27 07:36:27 2007 From: report at bugs.python.org (Vinay Sajip) Date: Thu, 27 Sep 2007 05:36:27 -0000 Subject: [issue1760556] logging.FileHandler may throw exception in flush() Message-ID: <1190871387.79.0.97909547668.issue1760556@psf.upfronthosting.co.za> Vinay Sajip added the comment: Fix checked in to trunk: r58268 ---------- resolution: -> fixed status: open -> closed _____________________________________ Tracker _____________________________________ From report at bugs.python.org Thu Sep 27 07:39:21 2007 From: report at bugs.python.org (Vinay Sajip) Date: Thu, 27 Sep 2007 05:39:21 -0000 Subject: [issue1021] logging.basicConfig does not allow to set NOTSET level Message-ID: <1190871561.77.0.887786164174.issue1021@psf.upfronthosting.co.za> New submission from Vinay Sajip: Fix checked in to trunk - r58269. ---------- resolution: -> fixed status: open -> closed __________________________________ Tracker __________________________________ From report at bugs.python.org Thu Sep 27 07:49:35 2007 From: report at bugs.python.org (Robert T McQuaid) Date: Thu, 27 Sep 2007 05:49:35 -0000 Subject: [issue1210] imaplib does not run under Python 3 Message-ID: <1190872174.76.0.553436258502.issue1210@psf.upfronthosting.co.za> New submission from Robert T McQuaid: imaplib does not run under Python 3. The following two-line python program, named testimap.py, works when run from a Windows XP system shell prompt using Python 2.5.1, but fails with Python 3.0. It appears that the logic does not follow the distinction between characters and bytes in Python 3. import imaplib mail=imaplib.IMAP4("mail.rtmq.infosathse.com") e:\python25\python testimap.py e:\python30\python testimap.py 2>f:syserr The last line produced the trace: Traceback (most recent call last): File "testimap.py", line 10, in mail=imaplib.IMAP4("mail.rtmq.infosathse.com") File "e:\python30\lib\imaplib.py", line 184, in __init__ self.welcome = self._get_response() File "e:\python30\lib\imaplib.py", line 962, in _get_response self._append_untagged(typ, dat) File "e:\python30\lib\imaplib.py", line 800, in _append_untagged if typ in ur: TypeError: unhashable type: 'bytes' ---------- components: Library (Lib) messages: 56154 nosy: rtmq severity: normal status: open title: imaplib does not run under Python 3 type: crash versions: Python 3.0 __________________________________ Tracker __________________________________ From report at bugs.python.org Thu Sep 27 07:49:34 2007 From: report at bugs.python.org (Robert T McQuaid) Date: Thu, 27 Sep 2007 05:49:34 -0000 Subject: [issue1210] imaplib does not run under Python 3 Message-ID: <1190872174.76.0.553436258502.issue1210@psf.upfronthosting.co.za> New submission from Robert T McQuaid: imaplib does not run under Python 3. The following two-line python program, named testimap.py, works when run from a Windows XP system shell prompt using Python 2.5.1, but fails with Python 3.0. It appears that the logic does not follow the distinction between characters and bytes in Python 3. import imaplib mail=imaplib.IMAP4("mail.rtmq.infosathse.com") e:\python25\python testimap.py e:\python30\python testimap.py 2>f:syserr The last line produced the trace: Traceback (most recent call last): File "testimap.py", line 10, in mail=imaplib.IMAP4("mail.rtmq.infosathse.com") File "e:\python30\lib\imaplib.py", line 184, in __init__ self.welcome = self._get_response() File "e:\python30\lib\imaplib.py", line 962, in _get_response self._append_untagged(typ, dat) File "e:\python30\lib\imaplib.py", line 800, in _append_untagged if typ in ur: TypeError: unhashable type: 'bytes' ---------- components: Library (Lib) messages: 56154 nosy: rtmq severity: normal status: open title: imaplib does not run under Python 3 type: crash versions: Python 3.0 __________________________________ Tracker __________________________________ From report at bugs.python.org Thu Sep 27 07:53:27 2007 From: report at bugs.python.org (Vinay Sajip) Date: Thu, 27 Sep 2007 05:53:27 -0000 Subject: [issue1752539] RotatingFileHandler.doRollover behave wrong vs. log4j's Message-ID: <1190872407.71.0.828640241588.issue1752539@psf.upfronthosting.co.za> Vinay Sajip added the comment: I have now had some more time to think about this issue. I don't believe any changes are warranted, because "Errors should never pass silently. Unless explicitly silenced." and since rename errors are usually due to application- or environment-specific conditions, you need to handle these in application code. If logging continues to use the existing log file because renaming fails, then it does not behave according to expectations - e.g. maximum sizes on log files will not be honoured. Likewise, logging does not attempt to use makedirs() to ensure that the parent directory path is created first - a typo in the path would lead to an unexpected location for the log file. While Python logging borrowed a lot from log4j, it is far from a straight port; the Zen of Python is different from the Zen of Java. ---------- resolution: -> invalid status: open -> closed _____________________________________ Tracker _____________________________________ From report at bugs.python.org Thu Sep 27 08:10:00 2007 From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=) Date: Thu, 27 Sep 2007 06:10:00 -0000 Subject: [issue1210] imaplib does not run under Python 3 Message-ID: <1190873400.4.0.500183888618.issue1210@psf.upfronthosting.co.za> Martin v. L?wis added the comment: Would you like to work on a patch? ---------- nosy: +loewis __________________________________ Tracker __________________________________ From report at bugs.python.org Thu Sep 27 08:19:25 2007 From: report at bugs.python.org (Vinay Sajip) Date: Thu, 27 Sep 2007 06:19:25 -0000 Subject: [issue1711603] syslog syscall support for SysLogLogger Message-ID: <1190873965.72.0.633799679989.issue1711603@psf.upfronthosting.co.za> Vinay Sajip added the comment: It's only a bug when it doesn't work according to design. The present design seems adequate in that it allows syslogging via UDP or domain sockets. No one else has asked for the functionality of using system calls. BTW I note that Metalog's home page says it's a modern replacement for syslogd and klogd - so one might have reasonably expected socket support. You can avoid having to patch Python each time by the simple expedient of creating a SysLogHandler subclass (a one-time operation) and using it in place of the included SysLogHandler. ---------- status: open -> closed _____________________________________ Tracker _____________________________________ From report at bugs.python.org Thu Sep 27 08:20:42 2007 From: report at bugs.python.org (Georg Brandl) Date: Thu, 27 Sep 2007 06:20:42 -0000 Subject: [issue1209] IOError won't accept tuples longer than 3 Message-ID: <1190874042.26.0.745386516142.issue1209@psf.upfronthosting.co.za> Georg Brandl added the comment: Wasn't that already fixed in #1566800? ---------- nosy: +georg.brandl resolution: -> out of date status: open -> closed __________________________________ Tracker __________________________________ From report at bugs.python.org Thu Sep 27 08:27:09 2007 From: report at bugs.python.org (Georg Brandl) Date: Thu, 27 Sep 2007 06:27:09 -0000 Subject: [issue1208] Match object should be guaranteed to always be true Message-ID: <1190874429.24.0.27168759733.issue1208@psf.upfronthosting.co.za> Georg Brandl added the comment: Fixed in the docs as r58270. ---------- nosy: +georg.brandl resolution: -> fixed status: open -> closed __________________________________ Tracker __________________________________ From report at bugs.python.org Thu Sep 27 08:52:25 2007 From: report at bugs.python.org (=?utf-8?q?=0A=09=09=09=09=09Luke-Jr=0A=09=09=09=09?=) Date: Thu, 27 Sep 2007 06:52:25 -0000 Subject: [issue1711603] syslog syscall support for SysLogLogger Message-ID: <1190875945.53.0.285313769907.issue1711603@psf.upfronthosting.co.za> Luke-Jr added the comment: So label it a "design flaw" if not a bug. Syscalls are the primary and only guaranteed method of writing to the system log. Very few applications or users use sockets for syslog, and socket support should only be required when logging to a remote system. Even if this is treated as a 'feature' (which it clearly is more than), it should still be merged into the current development branch. _____________________________________ Tracker _____________________________________ From report at bugs.python.org Thu Sep 27 09:37:14 2007 From: report at bugs.python.org (Vinay Sajip) Date: Thu, 27 Sep 2007 07:37:14 -0000 Subject: [issue1206] logging/__init__.py Message-ID: <1190878634.73.0.520634262744.issue1206@psf.upfronthosting.co.za> Vinay Sajip added the comment: Fix checked into trunk: r58272 ---------- nosy: +vsajip resolution: -> fixed status: open -> closed __________________________________ Tracker __________________________________ From report at bugs.python.org Thu Sep 27 16:22:43 2007 From: report at bugs.python.org (Raghuram Devarakonda) Date: Thu, 27 Sep 2007 14:22:43 -0000 Subject: [issue1210] imaplib does not run under Python 3 Message-ID: <1190902963.4.0.842551496683.issue1210@psf.upfronthosting.co.za> Changes by Raghuram Devarakonda: ---------- nosy: +draghuram __________________________________ Tracker __________________________________ From report at bugs.python.org Thu Sep 27 16:31:23 2007 From: report at bugs.python.org (Guido van Rossum) Date: Thu, 27 Sep 2007 14:31:23 -0000 Subject: [issue1205] urllib fail to read URL contents, urllib2 crash Python Message-ID: <1190903483.93.0.361668841975.issue1205@psf.upfronthosting.co.za> Guido van Rossum added the comment: > In my opinion, Python urllib "should" be more practical and > provide a way to read this kind of page. [quotes mine] Totally agreed. Someone "should" submit a patch. __________________________________ Tracker __________________________________ From report at bugs.python.org Thu Sep 27 16:39:47 2007 From: report at bugs.python.org (Raghuram Devarakonda) Date: Thu, 27 Sep 2007 14:39:47 -0000 Subject: [issue1210] imaplib does not run under Python 3 Message-ID: <1190903987.12.0.173251805058.issue1210@psf.upfronthosting.co.za> Raghuram Devarakonda added the comment: Just to further understand the issue, I added "imaplib.Debug=5" and here is the output preceding the exception stack trace(I replaced the real IMAP server name) *************** 20:19.52 imaplib version 2.58 20:19.52 new IMAP4 connection, tag=LOLD 20:19.52 < * OK Microsoft Exchange Server 2003 IMAP4rev1 server version 6.5.7638.1 (imapserver.com) ready. 20:19.52 matched r'\* (?P[A-Z-]+)( (?P.*))?' => (b'OK', b' Microsoft Exchange Server 2003 IMAP4rev1 server version 6.5.7638.1 (imapserver.com) ready.', b'Microsoft Exchange Server 2003 IMAP4rev1 server version 6.5.7638.1 (imapserver.com) ready.') *************** So it appears that the response is of type "bytes" which in turn is due to reading the socket in binary mode (self.file = self.sock.makefile('rb')). I would like to see how the problem can be fixed but any pointers are appreciated. __________________________________ Tracker __________________________________ From report at bugs.python.org Thu Sep 27 16:59:41 2007 From: report at bugs.python.org (Peter Harris) Date: Thu, 27 Sep 2007 14:59:41 -0000 Subject: [issue1211] cleanup patch for 3.0 tutorial/interpreter.rst Message-ID: <1190905181.89.0.902267878315.issue1211@psf.upfronthosting.co.za> New submission from Peter Harris: Proposed cleanup patch for tutorial/interpreter.rst ---------- components: Documentation files: interpreter.diff messages: 56164 nosy: scav severity: normal status: open title: cleanup patch for 3.0 tutorial/interpreter.rst versions: Python 3.0 __________________________________ Tracker __________________________________ -------------- next part -------------- A non-text attachment was scrubbed... Name: interpreter.diff Type: application/octet-stream Size: 2197 bytes Desc: not available Url : http://mail.python.org/pipermail/python-bugs-list/attachments/20070927/589afca7/attachment.obj From report at bugs.python.org Thu Sep 27 16:59:42 2007 From: report at bugs.python.org (Peter Harris) Date: Thu, 27 Sep 2007 14:59:42 -0000 Subject: [issue1211] cleanup patch for 3.0 tutorial/interpreter.rst Message-ID: <1190905181.89.0.902267878315.issue1211@psf.upfronthosting.co.za> New submission from Peter Harris: Proposed cleanup patch for tutorial/interpreter.rst ---------- components: Documentation files: interpreter.diff messages: 56164 nosy: scav severity: normal status: open title: cleanup patch for 3.0 tutorial/interpreter.rst versions: Python 3.0 __________________________________ Tracker __________________________________ -------------- next part -------------- A non-text attachment was scrubbed... Name: interpreter.diff Type: application/octet-stream Size: 2197 bytes Desc: not available Url : http://mail.python.org/pipermail/python-bugs-list/attachments/20070927/589afca7/attachment-0001.obj From report at bugs.python.org Thu Sep 27 17:09:33 2007 From: report at bugs.python.org (Peter Harris) Date: Thu, 27 Sep 2007 15:09:33 -0000 Subject: [issue1212] 3.0 tutorial/introduction.rst mentions 'long' Message-ID: <1190905773.75.0.769437858357.issue1212@psf.upfronthosting.co.za> New submission from Peter Harris: Remove reference to 'long' in tutorial/introduction.rst. Patch attached. ---------- components: Documentation files: introduction.diff messages: 56165 nosy: scav severity: normal status: open title: 3.0 tutorial/introduction.rst mentions 'long' versions: Python 3.0 __________________________________ Tracker __________________________________ -------------- next part -------------- A non-text attachment was scrubbed... Name: introduction.diff Type: application/octet-stream Size: 566 bytes Desc: not available Url : http://mail.python.org/pipermail/python-bugs-list/attachments/20070927/0c753b60/attachment.obj From report at bugs.python.org Thu Sep 27 17:09:34 2007 From: report at bugs.python.org (Peter Harris) Date: Thu, 27 Sep 2007 15:09:34 -0000 Subject: [issue1212] 3.0 tutorial/introduction.rst mentions 'long' Message-ID: <1190905773.75.0.769437858357.issue1212@psf.upfronthosting.co.za> New submission from Peter Harris: Remove reference to 'long' in tutorial/introduction.rst. Patch attached. ---------- components: Documentation files: introduction.diff messages: 56165 nosy: scav severity: normal status: open title: 3.0 tutorial/introduction.rst mentions 'long' versions: Python 3.0 __________________________________ Tracker __________________________________ -------------- next part -------------- A non-text attachment was scrubbed... Name: introduction.diff Type: application/octet-stream Size: 566 bytes Desc: not available Url : http://mail.python.org/pipermail/python-bugs-list/attachments/20070927/0c753b60/attachment-0001.obj From report at bugs.python.org Thu Sep 27 17:44:39 2007 From: report at bugs.python.org (Peter Harris) Date: Thu, 27 Sep 2007 15:44:39 -0000 Subject: [issue1213] 3.0 tutorial/classes.rst patch Message-ID: <1190907879.6.0.718273481834.issue1213@psf.upfronthosting.co.za> New submission from Peter Harris: I think this wording is a little clearer and removes implied reference to earlier Python versions, while still giving a simplistic tutorial-level idea of what the MRO is. YMMV, so please disregard if I've made it worse. ---------- components: Documentation files: classes.diff messages: 56166 nosy: scav severity: normal status: open title: 3.0 tutorial/classes.rst patch versions: Python 3.0 __________________________________ Tracker __________________________________ -------------- next part -------------- A non-text attachment was scrubbed... Name: classes.diff Type: application/octet-stream Size: 1697 bytes Desc: not available Url : http://mail.python.org/pipermail/python-bugs-list/attachments/20070927/a916b18e/attachment-0001.obj From report at bugs.python.org Thu Sep 27 17:44:39 2007 From: report at bugs.python.org (Peter Harris) Date: Thu, 27 Sep 2007 15:44:39 -0000 Subject: [issue1213] 3.0 tutorial/classes.rst patch Message-ID: <1190907879.6.0.718273481834.issue1213@psf.upfronthosting.co.za> New submission from Peter Harris: I think this wording is a little clearer and removes implied reference to earlier Python versions, while still giving a simplistic tutorial-level idea of what the MRO is. YMMV, so please disregard if I've made it worse. ---------- components: Documentation files: classes.diff messages: 56166 nosy: scav severity: normal status: open title: 3.0 tutorial/classes.rst patch versions: Python 3.0 __________________________________ Tracker __________________________________ -------------- next part -------------- A non-text attachment was scrubbed... Name: classes.diff Type: application/octet-stream Size: 1697 bytes Desc: not available Url : http://mail.python.org/pipermail/python-bugs-list/attachments/20070927/a916b18e/attachment-0002.obj From report at bugs.python.org Thu Sep 27 18:09:50 2007 From: report at bugs.python.org (Thomas Lee) Date: Thu, 27 Sep 2007 16:09:50 -0000 Subject: [issue1145] Allow str.join to join non-string types (as per PEP 3100) Message-ID: <1190909390.85.0.66602273502.issue1145@psf.upfronthosting.co.za> Thomas Lee added the comment: Is there anything else you need from me for this one Guido? __________________________________ Tracker __________________________________ From report at bugs.python.org Thu Sep 27 18:25:56 2007 From: report at bugs.python.org (steenie) Date: Thu, 27 Sep 2007 16:25:56 -0000 Subject: [issue1214] Timeout in CGIXMLRPCRequestHandler under IIS Message-ID: <1190910356.54.0.93332478952.issue1214@psf.upfronthosting.co.za> New submission from steenie: Using CGIXMLRPCRequestHandler results in a timeout if running behind Internet Information Server/CGI. Maybe there is no eof on sys.stdin under IIS and python continues to read even if there is no more data available. The same runs without problems under Apache/CGI. Reading only os.environ['CONTENT_LENGTH'] bytes from sys.stdin will as well work under IIS (see patch). ---------- components: Windows files: SimpleXMLRPCServer.diff messages: 56168 nosy: steenie severity: normal status: open title: Timeout in CGIXMLRPCRequestHandler under IIS versions: Python 2.5, Python 2.6 __________________________________ Tracker __________________________________ -------------- next part -------------- A non-text attachment was scrubbed... Name: SimpleXMLRPCServer.diff Type: text/x-patch Size: 647 bytes Desc: not available Url : http://mail.python.org/pipermail/python-bugs-list/attachments/20070927/8ecb9ab4/attachment.bin From report at bugs.python.org Thu Sep 27 18:25:56 2007 From: report at bugs.python.org (steenie) Date: Thu, 27 Sep 2007 16:25:56 -0000 Subject: [issue1214] Timeout in CGIXMLRPCRequestHandler under IIS Message-ID: <1190910356.54.0.93332478952.issue1214@psf.upfronthosting.co.za> New submission from steenie: Using CGIXMLRPCRequestHandler results in a timeout if running behind Internet Information Server/CGI. Maybe there is no eof on sys.stdin under IIS and python continues to read even if there is no more data available. The same runs without problems under Apache/CGI. Reading only os.environ['CONTENT_LENGTH'] bytes from sys.stdin will as well work under IIS (see patch). ---------- components: Windows files: SimpleXMLRPCServer.diff messages: 56168 nosy: steenie severity: normal status: open title: Timeout in CGIXMLRPCRequestHandler under IIS versions: Python 2.5, Python 2.6 __________________________________ Tracker __________________________________ -------------- next part -------------- A non-text attachment was scrubbed... Name: SimpleXMLRPCServer.diff Type: text/x-patch Size: 647 bytes Desc: not available Url : http://mail.python.org/pipermail/python-bugs-list/attachments/20070927/8ecb9ab4/attachment-0001.bin From report at bugs.python.org Thu Sep 27 19:05:24 2007 From: report at bugs.python.org (Miki Tebeka) Date: Thu, 27 Sep 2007 17:05:24 -0000 Subject: [issue1215] Python hang when catching a segfault Message-ID: <1190912724.9.0.418130471784.issue1215@psf.upfronthosting.co.za> New submission from Miki Tebeka: The following code hangs Python: #!/usr/bin/env python import segfault import signal from os import _exit from sys import stdout def handler(signal, stackframe): print "OUCH" stdout.flush() _exit(1) if __name__ == "__main__": from sys import argv signal.signal(signal.SIGSEGV, handler) segfault.segfault() segfault is the following C module: #include static PyObject * segfault(PyObject *self, PyObject *args) { char *c; c = 0; *c = 'a'; return Py_BuildValue(""); } static PyMethodDef Methods[] = { { "segfault", segfault, METH_VARARGS, "will segfault"}, {NULL, NULL, 0, NULL} /* Sentinel */ }; PyMODINIT_FUNC initsegfault(void) { Py_InitModule("segfault", Methods); } ---------- components: Interpreter Core messages: 56169 nosy: tebeka severity: normal status: open title: Python hang when catching a segfault type: crash versions: Python 2.5 __________________________________ Tracker __________________________________ From report at bugs.python.org Thu Sep 27 19:05:24 2007 From: report at bugs.python.org (Miki Tebeka) Date: Thu, 27 Sep 2007 17:05:24 -0000 Subject: [issue1215] Python hang when catching a segfault Message-ID: <1190912724.9.0.418130471784.issue1215@psf.upfronthosting.co.za> New submission from Miki Tebeka: The following code hangs Python: #!/usr/bin/env python import segfault import signal from os import _exit from sys import stdout def handler(signal, stackframe): print "OUCH" stdout.flush() _exit(1) if __name__ == "__main__": from sys import argv signal.signal(signal.SIGSEGV, handler) segfault.segfault() segfault is the following C module: #include static PyObject * segfault(PyObject *self, PyObject *args) { char *c; c = 0; *c = 'a'; return Py_BuildValue(""); } static PyMethodDef Methods[] = { { "segfault", segfault, METH_VARARGS, "will segfault"}, {NULL, NULL, 0, NULL} /* Sentinel */ }; PyMODINIT_FUNC initsegfault(void) { Py_InitModule("segfault", Methods); } ---------- components: Interpreter Core messages: 56169 nosy: tebeka severity: normal status: open title: Python hang when catching a segfault type: crash versions: Python 2.5 __________________________________ Tracker __________________________________ From report at bugs.python.org Thu Sep 27 19:54:12 2007 From: report at bugs.python.org (Karthik Rajagopalan) Date: Thu, 27 Sep 2007 17:54:12 -0000 Subject: [issue1216] Python2.5.1 fails to compile under VC.NET2002 ( 7.0 ) Message-ID: <1190915652.22.0.762495234548.issue1216@psf.upfronthosting.co.za> New submission from Karthik Rajagopalan: Hi, We see following compiler error when 'Python2.5.1' is compiled under VC.NET 2002 ( 7.0.9466 ). This happens in 'pythoncore' project: ------ Build started: Project: pythoncore, Configuration: Release Win32 ------ Compiling... zutil.c .... .... sha512module.c \python-build\Python-2.5.1\Modules\sha512module.c(146) : error C2059: syntax error : 'bad suffix on number' \python-build\Python-2.5.1\Modules\sha512module.c(146) : error C2146: syntax error : missing ')' before identifier 'L' \python-build\Python-2.5.1\Modules\sha512module.c(146) : error C2144: syntax error : '' should be preceded by '' \python-build\Python-2.5.1\Modules\sha512module.c(146) : error C2144: syntax error : '' should be preceded by '' \python-build\Python-2.5.1\Modules\sha512module.c(146) : error C2143: syntax error : missing ')' before 'identifier' \python-build\Python-2.5.1\Modules\sha512module.c(146) : error C2059: syntax error : 'bad suffix on number' The fix for the above problem is given below where _MSC_VER is increased more than 1300 that has LL and ULL literal suffix. VC.NET2002 is a C89 compiler and it doesn't have LL and ULL support. /* VC 7.1 has them and VC 6.0 does not. VC 6.0 has a version number of 1200. Microsoft eMbedded Visual C++ 4.0 has a version number of 1201 and doesn't define these. If some compiler does not provide them, modify the #if appropriately. */ #if defined(_MSC_VER) #if _MSC_VER > 1300 #define HAVE_UINTPTR_T 1 #define HAVE_INTPTR_T 1 #else /* VC6 & eVC4 don't support the C99 LL suffix for 64-bit integer literals */ #define Py_LL(x) x##I64 #define Py_ULL(x) Py_LL(x##U) #endif /* _MSC_VER > 1300 */ #endif /* _MSC_VER */ #endif Please let me know your comments and if the fix looks rights, please incorporate in your future release. -Karthik Rajagopalan D.E.Shaw India Software Pvt Ltd ---------- messages: 56176 nosy: kartlee severity: normal status: open title: Python2.5.1 fails to compile under VC.NET2002 ( 7.0 ) type: compile error versions: Python 2.5 __________________________________ Tracker __________________________________ From report at bugs.python.org Thu Sep 27 19:54:12 2007 From: report at bugs.python.org (Karthik Rajagopalan) Date: Thu, 27 Sep 2007 17:54:12 -0000 Subject: [issue1216] Python2.5.1 fails to compile under VC.NET2002 ( 7.0 ) Message-ID: <1190915652.22.0.762495234548.issue1216@psf.upfronthosting.co.za> New submission from Karthik Rajagopalan: Hi, We see following compiler error when 'Python2.5.1' is compiled under VC.NET 2002 ( 7.0.9466 ). This happens in 'pythoncore' project: ------ Build started: Project: pythoncore, Configuration: Release Win32 ------ Compiling... zutil.c .... .... sha512module.c \python-build\Python-2.5.1\Modules\sha512module.c(146) : error C2059: syntax error : 'bad suffix on number' \python-build\Python-2.5.1\Modules\sha512module.c(146) : error C2146: syntax error : missing ')' before identifier 'L' \python-build\Python-2.5.1\Modules\sha512module.c(146) : error C2144: syntax error : '' should be preceded by '' \python-build\Python-2.5.1\Modules\sha512module.c(146) : error C2144: syntax error : '' should be preceded by '' \python-build\Python-2.5.1\Modules\sha512module.c(146) : error C2143: syntax error : missing ')' before 'identifier' \python-build\Python-2.5.1\Modules\sha512module.c(146) : error C2059: syntax error : 'bad suffix on number' The fix for the above problem is given below where _MSC_VER is increased more than 1300 that has LL and ULL literal suffix. VC.NET2002 is a C89 compiler and it doesn't have LL and ULL support. /* VC 7.1 has them and VC 6.0 does not. VC 6.0 has a version number of 1200. Microsoft eMbedded Visual C++ 4.0 has a version number of 1201 and doesn't define these. If some compiler does not provide them, modify the #if appropriately. */ #if defined(_MSC_VER) #if _MSC_VER > 1300 #define HAVE_UINTPTR_T 1 #define HAVE_INTPTR_T 1 #else /* VC6 & eVC4 don't support the C99 LL suffix for 64-bit integer literals */ #define Py_LL(x) x##I64 #define Py_ULL(x) Py_LL(x##U) #endif /* _MSC_VER > 1300 */ #endif /* _MSC_VER */ #endif Please let me know your comments and if the fix looks rights, please incorporate in your future release. -Karthik Rajagopalan D.E.Shaw India Software Pvt Ltd ---------- messages: 56176 nosy: kartlee severity: normal status: open title: Python2.5.1 fails to compile under VC.NET2002 ( 7.0 ) type: compile error versions: Python 2.5 __________________________________ Tracker __________________________________ From report at bugs.python.org Thu Sep 27 20:01:45 2007 From: report at bugs.python.org (Guido van Rossum) Date: Thu, 27 Sep 2007 18:01:45 -0000 Subject: [issue1145] Allow str.join to join non-string types (as per PEP 3100) Message-ID: <1190916105.51.0.360455212162.issue1145@psf.upfronthosting.co.za> Guido van Rossum added the comment: Patience? :-) Seriously, I'd lost track of this. It's now submitted: Committed revision 58276. __________________________________ Tracker __________________________________ From report at bugs.python.org Thu Sep 27 20:13:54 2007 From: report at bugs.python.org (Guido van Rossum) Date: Thu, 27 Sep 2007 18:13:54 -0000 Subject: [issue1145] Allow str.join to join non-string types (as per PEP 3100) Message-ID: <1190916834.71.0.665750215865.issue1145@psf.upfronthosting.co.za> Changes by Guido van Rossum: ---------- resolution: -> accepted status: open -> closed __________________________________ Tracker __________________________________ From report at bugs.python.org Thu Sep 27 20:22:44 2007 From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=) Date: Thu, 27 Sep 2007 18:22:44 -0000 Subject: [issue1211] cleanup patch for 3.0 tutorial/interpreter.rst Message-ID: <1190917364.22.0.884069050016.issue1211@psf.upfronthosting.co.za> Changes by Martin v. L?wis: ---------- keywords: +patch __________________________________ Tracker __________________________________ From report at bugs.python.org Thu Sep 27 20:24:54 2007 From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=) Date: Thu, 27 Sep 2007 18:24:54 -0000 Subject: [issue1212] 3.0 tutorial/introduction.rst mentions 'long' Message-ID: <1190917494.75.0.716373668931.issue1212@psf.upfronthosting.co.za> Changes by Martin v. L?wis: ---------- keywords: +patch __________________________________ Tracker __________________________________ From report at bugs.python.org Thu Sep 27 20:25:06 2007 From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=) Date: Thu, 27 Sep 2007 18:25:06 -0000 Subject: [issue1213] 3.0 tutorial/classes.rst patch Message-ID: <1190917506.9.0.49553661198.issue1213@psf.upfronthosting.co.za> Changes by Martin v. L?wis: ---------- keywords: +patch __________________________________ Tracker __________________________________ From report at bugs.python.org Thu Sep 27 20:25:20 2007 From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=) Date: Thu, 27 Sep 2007 18:25:20 -0000 Subject: [issue1214] Timeout in CGIXMLRPCRequestHandler under IIS Message-ID: <1190917520.24.0.592260815594.issue1214@psf.upfronthosting.co.za> Changes by Martin v. L?wis: ---------- keywords: +patch __________________________________ Tracker __________________________________ From report at bugs.python.org Thu Sep 27 21:27:17 2007 From: report at bugs.python.org (Skip Montanaro) Date: Thu, 27 Sep 2007 19:27:17 -0000 Subject: [issue1218] Restrict Google search to docs when in the docs subtree? Message-ID: <1190921237.18.0.0623041657599.issue1218@psf.upfronthosting.co.za> New submission from Skip Montanaro: It was reported to webmaster at python.org today that Thomas Heller's pyhelp.cgi script is not available (yields 403 Forbidden). For the time being I removed that link from http://www.python.org/doc/. Still, there is the Google search box at the top of the page. Alas, that only restricts the search to www.python.org. It would be nice if on those pages under the /doc/... tree the relevant parameter (sitesearch?) restricted the search to the doc tree. Can this be done easily? (On a related note, shouldn't the website be listed as a separate component in the classification section?) ---------- components: Documentation messages: 56179 nosy: skip.montanaro priority: normal severity: normal status: open title: Restrict Google search to docs when in the docs subtree? type: behavior __________________________________ Tracker __________________________________ From report at bugs.python.org Thu Sep 27 21:27:17 2007 From: report at bugs.python.org (Skip Montanaro) Date: Thu, 27 Sep 2007 19:27:17 -0000 Subject: [issue1218] Restrict Google search to docs when in the docs subtree? Message-ID: <1190921237.18.0.0623041657599.issue1218@psf.upfronthosting.co.za> New submission from Skip Montanaro: It was reported to webmaster at python.org today that Thomas Heller's pyhelp.cgi script is not available (yields 403 Forbidden). For the time being I removed that link from http://www.python.org/doc/. Still, there is the Google search box at the top of the page. Alas, that only restricts the search to www.python.org. It would be nice if on those pages under the /doc/... tree the relevant parameter (sitesearch?) restricted the search to the doc tree. Can this be done easily? (On a related note, shouldn't the website be listed as a separate component in the classification section?) ---------- components: Documentation messages: 56179 nosy: skip.montanaro priority: normal severity: normal status: open title: Restrict Google search to docs when in the docs subtree? type: behavior __________________________________ Tracker __________________________________ From report at bugs.python.org Thu Sep 27 21:18:56 2007 From: report at bugs.python.org (=?utf-8?q?=0A=09=09=09=09=09Andres_Riancho=0A=09=09=09=09?=) Date: Thu, 27 Sep 2007 19:18:56 -0000 Subject: [issue1217] infinite loop in re module Message-ID: <1190920735.17.0.528461177884.issue1217@psf.upfronthosting.co.za> New submission from Andres Riancho : dz0 at dz0cybsec:/tmp$ python Python 2.4.4 (#2, Aug 16 2007, 02:03:40) [GCC 4.1.3 20070812 (prerelease) (Debian 4.1.2-15)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> import re >>> re.findall( '.*://(.*):(.*)@.*' , file('a.txt').read() ) ===!infinite loop here!=== ===!execute "kill pid"!=== Terminated dz0 at dz0cybsec:/tmp$ dz0 at dz0cybsec:/tmp$ dpkg -l python Desired=Unknown/Install/Remove/Purge/Hold | Status=Not/Installed/Config-files/Unpacked/Failed-config/Half-installed |/ Err?=(none)/Hold/Reinst-required/X=both-problems (Status,Err: uppercase=bad) ||/ Name Version Description +++-=================================-=================================-================================================================================== ii python 2.4.4-6 An interactive high-level object-oriented language (default version) dz0 at dz0cybsec:/tmp$ dz0 at dz0cybsec:/tmp$ uname -a Linux dz0cybsec 2.6.21-2-k7 #1 SMP Wed Jul 11 04:29:08 UTC 2007 i686 GNU/Linux dz0 at dz0cybsec:/tmp$ See attached a.txt file. ---------- components: Regular Expressions files: a.txt messages: 56178 nosy: andresriancho severity: normal status: open title: infinite loop in re module type: resource usage versions: Python 2.4 __________________________________ Tracker __________________________________ -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: a.txt Url: http://mail.python.org/pipermail/python-bugs-list/attachments/20070927/fd7c8e91/attachment-0001.txt From report at bugs.python.org Thu Sep 27 21:18:55 2007 From: report at bugs.python.org (=?utf-8?q?=0A=09=09=09=09=09Andres_Riancho=0A=09=09=09=09?=) Date: Thu, 27 Sep 2007 19:18:55 -0000 Subject: [issue1217] infinite loop in re module Message-ID: <1190920735.17.0.528461177884.issue1217@psf.upfronthosting.co.za> New submission from Andres Riancho : dz0 at dz0cybsec:/tmp$ python Python 2.4.4 (#2, Aug 16 2007, 02:03:40) [GCC 4.1.3 20070812 (prerelease) (Debian 4.1.2-15)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> import re >>> re.findall( '.*://(.*):(.*)@.*' , file('a.txt').read() ) ===!infinite loop here!=== ===!execute "kill pid"!=== Terminated dz0 at dz0cybsec:/tmp$ dz0 at dz0cybsec:/tmp$ dpkg -l python Desired=Unknown/Install/Remove/Purge/Hold | Status=Not/Installed/Config-files/Unpacked/Failed-config/Half-installed |/ Err?=(none)/Hold/Reinst-required/X=both-problems (Status,Err: uppercase=bad) ||/ Name Version Description +++-=================================-=================================-================================================================================== ii python 2.4.4-6 An interactive high-level object-oriented language (default version) dz0 at dz0cybsec:/tmp$ dz0 at dz0cybsec:/tmp$ uname -a Linux dz0cybsec 2.6.21-2-k7 #1 SMP Wed Jul 11 04:29:08 UTC 2007 i686 GNU/Linux dz0 at dz0cybsec:/tmp$ See attached a.txt file. ---------- components: Regular Expressions files: a.txt messages: 56178 nosy: andresriancho severity: normal status: open title: infinite loop in re module type: resource usage versions: Python 2.4 __________________________________ Tracker __________________________________ -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: a.txt Url: http://mail.python.org/pipermail/python-bugs-list/attachments/20070927/fd7c8e91/attachment-0003.txt From report at bugs.python.org Thu Sep 27 23:04:09 2007 From: report at bugs.python.org (Brett Cannon) Date: Thu, 27 Sep 2007 21:04:09 -0000 Subject: [issue1217] infinite loop in re module Message-ID: <1190927048.98.0.715191122363.issue1217@psf.upfronthosting.co.za> Brett Cannon added the comment: I am not convinced this an infinite loop but more of a poor-performing regex over a large string. You have three greedy quantifiers in that regex. That means the first one is going to consume the entire file, and then you begin back-off looking for '://'. Once that is found you consume the rest of the string again and then back off looking for ':'. Then the rest of the string is consumed and then back-off begins for '@' which should fail since I can't find a single instance of '@'. But that is a lot of backing off over a large string which has a ton of partial matches before failure occurs when looking for the '@'. It looks like you are trying to match a URL, which means you probably want something more specific than '.' for those greedy quantifiers. Closing as invalid. ---------- assignee: -> brett.cannon nosy: +brett.cannon resolution: -> invalid status: open -> closed __________________________________ Tracker __________________________________ From report at bugs.python.org Thu Sep 27 23:10:58 2007 From: report at bugs.python.org (=?utf-8?q?=0A=09=09=09=09=09Andres_Riancho=0A=09=09=09=09?=) Date: Thu, 27 Sep 2007 21:10:58 -0000 Subject: [issue1217] infinite loop in re module Message-ID: <1190927458.45.0.00904946727546.issue1217@psf.upfronthosting.co.za> Andres Riancho added the comment: Have you tested it ? Is the re.findall() finishing it's work ? I left it working for 5 minutes or more, and got no response. Cheers, __________________________________ Tracker __________________________________ From report at bugs.python.org Fri Sep 28 04:14:08 2007 From: report at bugs.python.org (=?utf-8?q?=0A=09=09=09=09=09Andres_Riancho=0A=09=09=09=09?=) Date: Fri, 28 Sep 2007 02:14:08 -0000 Subject: [issue1217] infinite loop in re module Message-ID: <1190945648.08.0.112937409804.issue1217@psf.upfronthosting.co.za> Andres Riancho added the comment: I think this should be reopened. The findall call is running for 3 hours now. I think that it's a clear case of an infinite loop. __________________________________ Tracker __________________________________ From report at bugs.python.org Fri Sep 28 05:18:04 2007 From: report at bugs.python.org (=?utf-8?q?=0A=09=09=09=09=09jos=0A=09=09=09=09?=) Date: Fri, 28 Sep 2007 03:18:04 -0000 Subject: [issue1205] urllib fail to read URL contents, urllib2 crash Python Message-ID: <1190949484.44.0.594549551846.issue1205@psf.upfronthosting.co.za> jos added the comment: Attached a patch for this problem. This one just ignores the buggy chunk-size and close the connection. As gagenellina said earlier, this might not be a good way to fix this, but I could not come up with better solution. __________________________________ Tracker __________________________________ -------------- next part -------------- A non-text attachment was scrubbed... Name: httplib.diff Type: application/octet-stream Size: 649 bytes Desc: not available Url : http://mail.python.org/pipermail/python-bugs-list/attachments/20070928/69fcb5ee/attachment.obj From report at bugs.python.org Fri Sep 28 05:23:45 2007 From: report at bugs.python.org (Brett Cannon) Date: Fri, 28 Sep 2007 03:23:45 -0000 Subject: [issue1217] infinite loop in re module Message-ID: <1190949825.36.0.0756843254155.issue1217@psf.upfronthosting.co.za> Brett Cannon added the comment: If you chop out a bunch of the text it finishes fine. I more succinct example that triggers the infinite recursion is necessary before I will believe this is not just because the regex has horrible performance thanks to its backtracking requirements. __________________________________ Tracker __________________________________ From report at bugs.python.org Fri Sep 28 06:37:49 2007 From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=) Date: Fri, 28 Sep 2007 04:37:49 -0000 Subject: [issue1218] Restrict Google search to docs when in the docs subtree? Message-ID: <1190954269.32.0.388843147486.issue1218@psf.upfronthosting.co.za> Martin v. L?wis added the comment: Website issues are not tracked in this tracker. See http://wiki.python.org/moin/PythonWebsiteCreatingNewTickets ---------- nosy: +loewis __________________________________ Tracker __________________________________ From report at bugs.python.org Fri Sep 28 13:07:32 2007 From: report at bugs.python.org (Peter Harris) Date: Fri, 28 Sep 2007 11:07:32 -0000 Subject: [issue1219] 3.0 library/stdtypes.rst patch Message-ID: <1190977652.36.0.432494906754.issue1219@psf.upfronthosting.co.za> New submission from Peter Harris: Cleanup (removal of 2.x references, long etc. ). I'm not 100% sure I've got the rich-comparison stuff correct. ---------- components: Documentation files: stdtypes.diff messages: 56186 nosy: scav severity: normal status: open title: 3.0 library/stdtypes.rst patch versions: Python 3.0 __________________________________ Tracker __________________________________ -------------- next part -------------- A non-text attachment was scrubbed... Name: stdtypes.diff Type: application/octet-stream Size: 11433 bytes Desc: not available Url : http://mail.python.org/pipermail/python-bugs-list/attachments/20070928/22596581/attachment-0002.obj From report at bugs.python.org Fri Sep 28 13:07:32 2007 From: report at bugs.python.org (Peter Harris) Date: Fri, 28 Sep 2007 11:07:32 -0000 Subject: [issue1219] 3.0 library/stdtypes.rst patch Message-ID: <1190977652.36.0.432494906754.issue1219@psf.upfronthosting.co.za> New submission from Peter Harris: Cleanup (removal of 2.x references, long etc. ). I'm not 100% sure I've got the rich-comparison stuff correct. ---------- components: Documentation files: stdtypes.diff messages: 56186 nosy: scav severity: normal status: open title: 3.0 library/stdtypes.rst patch versions: Python 3.0 __________________________________ Tracker __________________________________ -------------- next part -------------- A non-text attachment was scrubbed... Name: stdtypes.diff Type: application/octet-stream Size: 11433 bytes Desc: not available Url : http://mail.python.org/pipermail/python-bugs-list/attachments/20070928/22596581/attachment-0003.obj From report at bugs.python.org Fri Sep 28 13:13:26 2007 From: report at bugs.python.org (Georg Brandl) Date: Fri, 28 Sep 2007 11:13:26 -0000 Subject: [issue1219] 3.0 library/stdtypes.rst patch Message-ID: <1190978006.78.0.0825011148028.issue1219@psf.upfronthosting.co.za> Changes by Georg Brandl: ---------- assignee: -> georg.brandl keywords: +patch nosy: +georg.brandl __________________________________ Tracker __________________________________ From report at bugs.python.org Fri Sep 28 15:13:48 2007 From: report at bugs.python.org (Georg Brandl) Date: Fri, 28 Sep 2007 13:13:48 -0000 Subject: [issue1213] 3.0 tutorial/classes.rst patch Message-ID: <1190985228.75.0.654575873018.issue1213@psf.upfronthosting.co.za> Georg Brandl added the comment: Thanks, committed in r58281. ---------- nosy: +georg.brandl resolution: -> accepted status: open -> closed __________________________________ Tracker __________________________________ From report at bugs.python.org Fri Sep 28 15:14:04 2007 From: report at bugs.python.org (Georg Brandl) Date: Fri, 28 Sep 2007 13:14:04 -0000 Subject: [issue1212] 3.0 tutorial/introduction.rst mentions 'long' Message-ID: <1190985244.89.0.160356423077.issue1212@psf.upfronthosting.co.za> Georg Brandl added the comment: Thanks, committed in r58281. ---------- nosy: +georg.brandl resolution: -> accepted status: open -> closed __________________________________ Tracker __________________________________ From report at bugs.python.org Fri Sep 28 15:14:33 2007 From: report at bugs.python.org (Georg Brandl) Date: Fri, 28 Sep 2007 13:14:33 -0000 Subject: [issue1211] cleanup patch for 3.0 tutorial/interpreter.rst Message-ID: <1190985273.26.0.792330915956.issue1211@psf.upfronthosting.co.za> Georg Brandl added the comment: Thanks, committed in r58281. (I reordered the encoding section a bit.) ---------- nosy: +georg.brandl resolution: -> accepted status: open -> closed __________________________________ Tracker __________________________________ From report at bugs.python.org Fri Sep 28 15:39:39 2007 From: report at bugs.python.org (Georg Brandl) Date: Fri, 28 Sep 2007 13:39:39 -0000 Subject: [issue1219] 3.0 library/stdtypes.rst patch Message-ID: <1190986779.12.0.218512525992.issue1219@psf.upfronthosting.co.za> Georg Brandl added the comment: Extended and committed in r58282. ---------- resolution: -> accepted status: open -> closed __________________________________ Tracker __________________________________ From report at bugs.python.org Fri Sep 28 18:33:17 2007 From: report at bugs.python.org (Skip Montanaro) Date: Fri, 28 Sep 2007 16:33:17 -0000 Subject: [issue1218] Restrict Google search to docs when in the docs subtree? In-Reply-To: <1190954269.32.0.388843147486.issue1218@psf.upfronthosting.co.za> Message-ID: <18173.11465.582035.967638@montanaro.dyndns.org> Skip Montanaro added the comment: Martin> Website issues are not tracked in this tracker. See Martin> http://wiki.python.org/moin/PythonWebsiteCreatingNewTickets Is there some reason at this point that we need to maintain two separate trackers? A ton of work went into making our Roundup instance what the key players wanted. Why not use it to track website issues as well? With them separate you have two communities of maintainers and triage folks who are mostly disjoint. I assume there would be some trac-to-roundup conversion necessary. Perhaps something like that already exists. Skip __________________________________ Tracker __________________________________ From report at bugs.python.org Fri Sep 28 20:31:17 2007 From: report at bugs.python.org (Guido van Rossum) Date: Fri, 28 Sep 2007 18:31:17 -0000 Subject: [issue1215] Python hang when catching a segfault Message-ID: <1191004277.87.0.543834518405.issue1215@psf.upfronthosting.co.za> Guido van Rossum added the comment: Why is this a Python bug? ---------- nosy: +gvanrossum __________________________________ Tracker __________________________________ From report at bugs.python.org Fri Sep 28 20:41:35 2007 From: report at bugs.python.org (Raghuram Devarakonda) Date: Fri, 28 Sep 2007 18:41:35 -0000 Subject: [issue1210] imaplib does not run under Python 3 Message-ID: <1191004895.97.0.348856313996.issue1210@psf.upfronthosting.co.za> Raghuram Devarakonda added the comment: I have gone through the python-3000 discussions about similar problems in other stdlib modules (email, imghdr, sndhdr etc) and found PEP 3137 (Immutable Bytes and Mutable Buffer). Since that work is in progress, I don't think it is worthwhile to fix this problem at this point. __________________________________ Tracker __________________________________ From report at bugs.python.org Fri Sep 28 21:59:03 2007 From: report at bugs.python.org (Miki Tebeka) Date: Fri, 28 Sep 2007 19:59:03 -0000 Subject: [issue1215] Python hang when catching a segfault Message-ID: <1191009543.48.0.366240678986.issue1215@psf.upfronthosting.co.za> Miki Tebeka added the comment: Because it hangs Python :) I know, "while 1: pass" also hangs Python, however it'll nice if this behaviour was documented or (IMO better) that Python will raise an InvalidArgument exception on SIGSEGV (like it does for SIGKILL). __________________________________ Tracker __________________________________ From report at bugs.python.org Fri Sep 28 23:03:15 2007 From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=) Date: Fri, 28 Sep 2007 21:03:15 -0000 Subject: [issue1218] Restrict Google search to docs when in the docs subtree? In-Reply-To: <18173.11465.582035.967638@montanaro.dyndns.org> Message-ID: <46FD6C11.7080706@v.loewis.de> Martin v. L?wis added the comment: > Is there some reason at this point that we need to maintain two separate > trackers? I don't know - I explained what is, not what should be. Whether or not pydotorg people want to use the tracker, I can't tell. Regards, Martin __________________________________ Tracker __________________________________ From report at bugs.python.org Sat Sep 29 04:46:11 2007 From: report at bugs.python.org (Zooko O'Whielacronx) Date: Sat, 29 Sep 2007 02:46:11 -0000 Subject: [issue766910] fix one or two bugs in trace.py In-Reply-To: <1188352055.61.0.902775161564.issue766910@psf.upfronthosting.co.za> Message-ID: <3CD64F22-A140-450E-94D4-1DE6C6D99145@zooko.com> Zooko O'Whielacronx added the comment: Hi! Sorry it took me so long to look at this. I just checked the source in current trunk, and the relevant code is the same so this patch is still useful. (See the initial post for details.) Here is an updated version of the patch which simply removes some dead code and updates a URL: regards, Zooko diff -rN -u old-up/setuptools-0.6c7/ez_setup.py new-up/ setuptools-0.6c7/ez_setup.py --- old-up/setuptools-0.6c7/ez_setup.py 2007-09-28 16:41:24.000000000 -0600 +++ new-up/setuptools-0.6c7/ez_setup.py 2007-09-28 16:41:25.000000000 -0600 @@ -1,4 +1,4 @@ -#!python +#!/usr/bin/env python """Bootstrap setuptools installation If you want to use setuptools in your package's setup.py, just include this @@ -13,7 +13,7 @@ This file can also be run as a script to install or upgrade setuptools. """ -import sys +import os, re, subprocess, sys DEFAULT_VERSION = "0.6c7" DEFAULT_URL = "http://pypi.python.org/packages/%s/s/setuptools/" % sys.version[:3] @@ -44,8 +44,6 @@ 'setuptools-0.6c6-py2.5.egg': 'b2f8a7520709a5b34f80946de5f02f53', } -import sys, os - def _validate_md5(egg_name, data): if egg_name in md5_data: from md5 import md5 @@ -58,6 +56,42 @@ sys.exit(2) return data +# The following code to parse versions is copied from pkg_resources.py so that +# we can parse versions without importing that module. +component_re = re.compile(r'(\d+ | [a-z]+ | \.| -)', re.VERBOSE) +replace = {'pre':'c', 'preview':'c','-':'final-','rc':'c','dev':'@'}.get + +def _parse_version_parts(s): + for part in component_re.split(s): + part = replace(part,part) + if not part or part=='.': + continue + if part[:1] in '0123456789': + yield part.zfill(8) # pad for numeric comparison + else: + yield '*'+part + + yield '*final' # ensure that alpha/beta/candidate are before final + +def parse_version(s): + parts = [] + for part in _parse_version_parts(s.lower()): + if part.startswith('*'): + if part<'*final': # remove '-' before a prerelease tag + while parts and parts[-1]=='*final-': parts.pop() + # remove trailing zeros from each series of numeric parts + while parts and parts[-1]=='00000000': + parts.pop() + parts.append(part) + return tuple(parts) + +def setuptools_is_new_enough(required_version): + """Return True if setuptools is already installed and has a version + number >= required_version.""" + sub = subprocess.Popen([sys.executable, "-c", "import setuptools;print setuptools.__version__"], stdout=subprocess.PIPE) + verstr = sub.stdout.read().strip() + ver = parse_version(verstr) + return ver and ver >= parse_version(required_version) def use_setuptools( version=DEFAULT_VERSION, download_base=DEFAULT_URL, to_dir=os.curdir, @@ -74,32 +108,11 @@ this routine will print a message to ``sys.stderr`` and raise SystemExit in an attempt to abort the calling script. """ - try: - import setuptools - if setuptools.__version__ == '0.0.1': - print >>sys.stderr, ( - "You have an obsolete version of setuptools installed. Please\n" - "remove it from your system entirely before rerunning this script." - ) - sys.exit(2) - except ImportError: + if not setuptools_is_new_enough(version): egg = download_setuptools(version, download_base, to_dir, download_delay) sys.path.insert(0, egg) import setuptools; setuptools.bootstrap_install_from = egg - import pkg_resources - try: - pkg_resources.require("setuptools>="+version) - - except pkg_resources.VersionConflict, e: - # XXX could we install in a subprocess here? - print >>sys.stderr, ( - "The required version of setuptools (>=%s) is not available, and\n" - "can't be installed while this script is running. Please install\n" - " a more recent version first.\n\n(Currently using %r)" - ) % (version, e.args[0]) - sys.exit(2) - def download_setuptools( version=DEFAULT_VERSION, download_base=DEFAULT_URL, to_dir=os.curdir, delay = 15 @@ -150,9 +163,14 @@ def main(argv, version=DEFAULT_VERSION): """Install or upgrade setuptools and EasyInstall""" - try: - import setuptools - except ImportError: + if setuptools_is_new_enough(version): + if argv: + from setuptools.command.easy_install import main + main(argv) + else: + print "Setuptools version",version,"or greater has been installed." + print '(Run "ez_setup.py -U setuptools" to reinstall or upgrade.)' + else: egg = None try: egg = download_setuptools(version, delay=0) @@ -162,31 +180,6 @@ finally: if egg and os.path.exists(egg): os.unlink(egg) - else: - if setuptools.__version__ == '0.0.1': - # tell the user to uninstall obsolete version - use_setuptools(version) - - req = "setuptools>="+version - import pkg_resources - try: - pkg_resources.require(req) - except pkg_resources.VersionConflict: - try: - from setuptools.command.easy_install import main - except ImportError: - from easy_install import main - main(list(argv)+[download_setuptools(delay=0)]) - sys.exit(0) # try to force an exit - else: - if argv: - from setuptools.command.easy_install import main - main(argv) - else: - print "Setuptools version",version,"or greater has been installed." - print '(Run "ez_setup.py -U setuptools" to reinstall or upgrade.)' - - def update_md5(filenames): """Update our built-in md5 registry""" ____________________________________ Tracker ____________________________________ -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: trace-dir.patch.txt Url: http://mail.python.org/pipermail/python-bugs-list/attachments/20070929/182aa6a7/attachment-0002.txt -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: unnamed Url: http://mail.python.org/pipermail/python-bugs-list/attachments/20070929/182aa6a7/attachment-0003.txt From report at bugs.python.org Sat Sep 29 04:50:15 2007 From: report at bugs.python.org (Zooko O'Whielacronx) Date: Sat, 29 Sep 2007 02:50:15 -0000 Subject: [issue766910] fix one or two bugs in trace.py In-Reply-To: <3CD64F22-A140-450E-94D4-1DE6C6D99145@zooko.com> Message-ID: <90235D0F-5F45-4998-830D-4BFB9D651579@zooko.com> Zooko O'Whielacronx added the comment: > Here is an updated version of the patch which simply removes some > dead code and updates a URL: > > regards, > > Zooko > > diff -rN -u old-up/setuptools-0.6c7/ez_setup.py new-up/ > setuptools-0.6c7/ez_setup.py > --- old-up/setuptools-0.6c7/ez_setup.py 2007-09-28 > 16:41:24.000000000 -0600 > +++ new-up/setuptools-0.6c7/ez_setup.py 2007-09-28 > 16:41:25.000000000 -0600 Oops, the in-lined patch contents were a different patch entirely, but the attached patch file was correct. Just for completeness, here is the correct in-lined patch contents: Index: Lib/trace.py =================================================================== --- Lib/trace.py (revision 58282) +++ Lib/trace.py (working copy) @@ -85,7 +85,12 @@ -r, --report Generate a report from a counts file; do not execute any code. `--file' must specify the results file to read, which must have been created in a previous run - with `--count --file=FILE'. + with `--count --file=FILE'. If --coverdir is not + specified, the .cover files will be written into the + directory that the modules were in when the report was + generated. Whether or not --coverdir is specified, + --report will always create the cover file directory if + necessary. Modifiers: -f, --file= File to accumulate counts over several runs. @@ -197,6 +202,33 @@ filename, ext = os.path.splitext(base) return filename +# The following function is copied from the fileutil module from the pyutil +# project: +# http://pypi.python.org/pypi/pyutil +# We use this function instead of os.makedirs() so that we don't get a +# spurious exception when someone else creates the directory at the same +# moment we do. (For example, another thread or process that is also running +# trace.) +def make_dirs(dirname, mode=0777): + """ + A threadsafe and idempotent version of os.makedirs(). If the dir already + exists, do nothing and return without raising an exception. If this call + creates the dir, return without raising an exception. If there is an + error that prevents creation or if the directory gets deleted after + make_dirs() creates it and before make_dirs() checks that it exists, raise + an exception. + """ + tx = None + try: + os.makedirs(dirname, mode) + except OSError, x: + tx = x + + if not os.path.isdir(dirname): + if tx: + raise tx + raise exceptions.IOError, "unknown error prevented creation of directory, or deleted the directory immediately after creation: % s" % dirname # careful not to construct an IOError with a 2-tuple, as that has a special meaning... + class CoverageResults: def __init__(self, counts=None, calledfuncs=None, infile=None, callers=None, outfile=None): @@ -290,15 +322,15 @@ if filename.endswith((".pyc", ".pyo")): filename = filename[:-1] - if coverdir is None: + if coverdir is not None: + dir = coverdir + modulename = fullmodname(filename) + else: dir = os.path.dirname(os.path.abspath(filename)) modulename = modname(filename) - else: - dir = coverdir - if not os.path.exists(dir): - os.makedirs(dir) - modulename = fullmodname(filename) + make_dirs(dir) + # If desired, get a list of the line numbers which represent # executable content (returned as a dict for better lookup speed) if show_missing: ____________________________________ Tracker ____________________________________ From report at bugs.python.org Sun Sep 30 05:27:53 2007 From: report at bugs.python.org (Justin Bronn) Date: Sun, 30 Sep 2007 03:27:53 -0000 Subject: [issue1220] popen3 website documentation inconsistency Message-ID: <1191122873.79.0.547825097703.issue1220@psf.upfronthosting.co.za> New submission from Justin Bronn: The Python website says that the following tuple is returned from popen3: "Returns the file objects (child_stdout, child_stdin, child_stderr)." See http://docs.python.org/lib/module-popen2.html. However, the docstring of popen3 gets the order right (using Python 2.5.1): "The file objects (child_stdin, child_stdout, child_stderr) are returned." See `help(os.popen3)`. ---------- components: Documentation messages: 56198 nosy: jbronn severity: normal status: open title: popen3 website documentation inconsistency versions: Python 2.5 __________________________________ Tracker __________________________________ From report at bugs.python.org Sun Sep 30 05:27:54 2007 From: report at bugs.python.org (Justin Bronn) Date: Sun, 30 Sep 2007 03:27:54 -0000 Subject: [issue1220] popen3 website documentation inconsistency Message-ID: <1191122873.79.0.547825097703.issue1220@psf.upfronthosting.co.za> New submission from Justin Bronn: The Python website says that the following tuple is returned from popen3: "Returns the file objects (child_stdout, child_stdin, child_stderr)." See http://docs.python.org/lib/module-popen2.html. However, the docstring of popen3 gets the order right (using Python 2.5.1): "The file objects (child_stdin, child_stdout, child_stderr) are returned." See `help(os.popen3)`. ---------- components: Documentation messages: 56198 nosy: jbronn severity: normal status: open title: popen3 website documentation inconsistency versions: Python 2.5 __________________________________ Tracker __________________________________ From report at bugs.python.org Sun Sep 30 14:39:04 2007 From: report at bugs.python.org (helmut) Date: Sun, 30 Sep 2007 12:39:04 -0000 Subject: [issue1221] email.Utils.parseaddr("a(WRONG)@b") Message-ID: <1191155944.58.0.169174625904.issue1221@psf.upfronthosting.co.za> New submission from helmut: >>> email.Utils.parseaddr("a(WRONG)@b") ('WRONG WRONG', 'a at b') I believe this is wrong. ---------- components: Library (Lib) messages: 56199 nosy: helmut severity: normal status: open title: email.Utils.parseaddr("a(WRONG)@b") type: behavior versions: Python 2.4, Python 2.5 __________________________________ Tracker __________________________________ From report at bugs.python.org Sun Sep 30 14:39:04 2007 From: report at bugs.python.org (helmut) Date: Sun, 30 Sep 2007 12:39:04 -0000 Subject: [issue1221] email.Utils.parseaddr("a(WRONG)@b") Message-ID: <1191155944.58.0.169174625904.issue1221@psf.upfronthosting.co.za> New submission from helmut: >>> email.Utils.parseaddr("a(WRONG)@b") ('WRONG WRONG', 'a at b') I believe this is wrong. ---------- components: Library (Lib) messages: 56199 nosy: helmut severity: normal status: open title: email.Utils.parseaddr("a(WRONG)@b") type: behavior versions: Python 2.4, Python 2.5 __________________________________ Tracker __________________________________ From report at bugs.python.org Sun Sep 30 16:15:46 2007 From: report at bugs.python.org (de la Musse) Date: Sun, 30 Sep 2007 14:15:46 -0000 Subject: [issue1222] locale.format bug if thousand separator is space (french separator as example) Message-ID: <1191161746.29.0.966883903443.issue1222@psf.upfronthosting.co.za> Changes by de la Musse: ---------- components: Library (Lib) severity: normal status: open title: locale.format bug if thousand separator is space (french separator as example) type: behavior versions: Python 2.4 __________________________________ Tracker __________________________________ From report at bugs.python.org Sun Sep 30 19:17:48 2007 From: report at bugs.python.org (de la Musse) Date: Sun, 30 Sep 2007 17:17:48 -0000 Subject: [issue1222] locale.format bug if thousand separator is space (french separator as example) Message-ID: <1191172668.69.0.513518274707.issue1222@psf.upfronthosting.co.za> New submission from de la Musse: locale.format function delete spaces in result which is a problem when thousand separator is space (in French for example). The problem seems in the code below (extract from locale.py): 145 while seps: 146 # If the number was formatted for a specific width, then it 147 # might have been filled with spaces to the left or right. If 148 # so, kill as much spaces as there where separators. 149 # Leading zeroes as fillers are not yet dealt with, as it is 150 # not clear how they should interact with grouping. 151 sp = result.find(" ") 152 if sp==-1:break 153 result = result[:sp]+result[sp+1:] 154 seps -= 1 Example : >>> import locale >>> locale.setlocale(locale.LC_NUMERIC) 'C' >>> locale.setlocale(locale.LC_NUMERIC, "fr_FR.UTF-8") 'fr_FR.UTF-8' >>> locale.format("%.2f", 12345.67, True) '12345,67' The correct result is '12 345,67' not '12345,67' and if I call >>> locale.format("%9.2f", 12345.67, True) '12 345,67' the result is correct Is this behavior correct or a bug? ---------- nosy: +edlm10 __________________________________ Tracker __________________________________ From report at bugs.python.org Sun Sep 30 19:45:02 2007 From: report at bugs.python.org (Georg Brandl) Date: Sun, 30 Sep 2007 17:45:02 -0000 Subject: [issue1221] email.Utils.parseaddr("a(WRONG)@b") Message-ID: <1191174302.42.0.3789927169.issue1221@psf.upfronthosting.co.za> Changes by Georg Brandl: ---------- assignee: -> barry nosy: +barry __________________________________ Tracker __________________________________ From report at bugs.python.org Sun Sep 30 21:32:01 2007 From: report at bugs.python.org (Brett Cannon) Date: Sun, 30 Sep 2007 19:32:01 -0000 Subject: [issue1631171] implement warnings module in C Message-ID: <1191180721.4.0.351731970889.issue1631171@psf.upfronthosting.co.za> Changes by Brett Cannon: ---------- assignee: -> brett.cannon nosy: +brett.cannon _____________________________________ Tracker _____________________________________ From report at bugs.python.org Sun Sep 30 21:46:02 2007 From: report at bugs.python.org (Brett Cannon) Date: Sun, 30 Sep 2007 19:46:02 -0000 Subject: [issue1686386] Python SEGFAULT on tuple.__repr__ and str() Message-ID: <1191181562.89.0.379452927604.issue1686386@psf.upfronthosting.co.za> Brett Cannon added the comment: Applied in r58288. If I did something stupid or people don't want the overhead they can yell at the commit. =) ---------- resolution: -> fixed status: open -> closed _____________________________________ Tracker _____________________________________ From report at bugs.python.org Sun Sep 30 22:37:42 2007 From: report at bugs.python.org (Brett Cannon) Date: Sun, 30 Sep 2007 20:37:42 -0000 Subject: [issue1686386] Python SEGFAULT on tuple.__repr__ and str() Message-ID: <1191184662.56.0.929134158923.issue1686386@psf.upfronthosting.co.za> Brett Cannon added the comment: And fixed in r58289. _____________________________________ Tracker _____________________________________