From report at bugs.python.org Sat Oct 1 02:24:38 2011 From: report at bugs.python.org (Alexander) Date: Sat, 01 Oct 2011 00:24:38 +0000 Subject: [New-bugs-announce] [issue13082] Can't open new window in python Message-ID: <1317428678.05.0.613085535741.issue13082@psf.upfronthosting.co.za> New submission from Alexander : When I try to open a new window in python to actually type a program and not just make single python instructions (this is while running on IDLE), python stops working and I have to force quit ---------- assignee: ronaldoussoren components: Macintosh messages: 144711 nosy: Reason2Rage, ronaldoussoren priority: normal severity: normal status: open title: Can't open new window in python type: crash versions: Python 3.2 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Oct 1 03:50:51 2011 From: report at bugs.python.org (STINNER Victor) Date: Sat, 01 Oct 2011 01:50:51 +0000 Subject: [New-bugs-announce] [issue13083] _sre: getstring() releases the buffer before using it Message-ID: <1317433851.47.0.137164360321.issue13083@psf.upfronthosting.co.za> New submission from STINNER Victor : getstring() of the _sre module contains the following code: ------------- ... buffer = Py_TYPE(string)->tp_as_buffer; if (!buffer || !buffer->bf_getbuffer || (*buffer->bf_getbuffer)(string, &view, PyBUF_SIMPLE) < 0) { PyErr_SetString(PyExc_TypeError, "expected string or buffer"); return NULL; } /* determine buffer size */ bytes = view.len; ptr = view.buf; /* Release the buffer immediately --- possibly dangerous but doing something else would require some re-factoring */ PyBuffer_Release(&view); ... ------------- getstring() is used to initialize a state or a pattern. State and pattern have destructors (pattern_dealloc() and state_fini()), so it should be possible to keep the view active and call PyBuffer_Release() in the destructor. ---------- components: Library (Lib) messages: 144714 nosy: haypo, pitrou priority: normal severity: normal status: open title: _sre: getstring() releases the buffer before using it versions: Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Oct 1 11:48:23 2011 From: report at bugs.python.org (Stefan Krah) Date: Sat, 01 Oct 2011 09:48:23 +0000 Subject: [New-bugs-announce] [issue13084] test_signal failure Message-ID: <1317462503.63.0.0518543153457.issue13084@psf.upfronthosting.co.za> New submission from Stefan Krah : Got this failure on Debian lenny amd64: [1/1] test_signal test test_signal failed -- Traceback (most recent call last): File "/home/stefan/cpython/Lib/test/test_signal.py", line 339, in test_pending """, *signals) File "/home/stefan/cpython/Lib/test/test_signal.py", line 263, in check_wakeup assert_python_ok('-c', code) File "/home/stefan/cpython/Lib/test/script_helper.py", line 50, in assert_python_ok return _assert_python(True, *args, **env_vars) File "/home/stefan/cpython/Lib/test/script_helper.py", line 42, in _assert_python "stderr follows:\n%s" % (rc, err.decode('ascii', 'ignore'))) AssertionError: Process return code is 1, stderr follows: Traceback (most recent call last): File "", line 41, in File "", line 16, in check_signum Exception: (10, 12) != (12, 10) 1 test failed: test_signal [103837 refs] ---------- components: Tests messages: 144718 nosy: skrah priority: normal severity: normal status: open title: test_signal failure versions: Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Oct 1 11:51:39 2011 From: report at bugs.python.org (Stefan Krah) Date: Sat, 01 Oct 2011 09:51:39 +0000 Subject: [New-bugs-announce] [issue13085] : memory leaks Message-ID: <1317462699.45.0.870961708747.issue13085@psf.upfronthosting.co.za> New submission from Stefan Krah : I think a couple of leaks were introduced by the pep-393 changes (see the patch). ---------- components: Interpreter Core files: pep-393-leaks.diff keywords: patch messages: 144719 nosy: haypo, loewis, skrah priority: normal severity: normal stage: patch review status: open title: : memory leaks type: resource usage versions: Python 3.3 Added file: http://bugs.python.org/file23281/pep-393-leaks.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Oct 1 12:57:42 2011 From: report at bugs.python.org (Larry Hastings) Date: Sat, 01 Oct 2011 10:57:42 +0000 Subject: [New-bugs-announce] [issue13086] Update howto/cporting.rst so it talks about 3.x instead of 3.0 Message-ID: <1317466662.3.0.331555988129.issue13086@psf.upfronthosting.co.za> New submission from Larry Hastings : The title of howto/cporting.rst is "Porting Extension Modules To 3.0". It then talks about 3.0 in a whole bunch of places. Considering that we're working on 3.3, and considering that 3.0 is end-of-lifed (not even meriting a branch in hg), wouldn't it be better for the document to talk about "3.x"? It already talks about "2.x" in several places, so it's not like this would confuse the reader. Alternatively, we could remove the ".0" (and maybe the ".x"s) so the document talks about porting from "Python 2" to "Python 3". I'd be happy to make the patch / check in the change. ---------- assignee: larry components: Documentation messages: 144721 nosy: larry priority: low severity: normal status: open title: Update howto/cporting.rst so it talks about 3.x instead of 3.0 type: feature request versions: Python 3.1, Python 3.2, Python 3.3, Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Oct 2 00:32:49 2011 From: report at bugs.python.org (John O'Connor) Date: Sat, 01 Oct 2011 22:32:49 +0000 Subject: [New-bugs-announce] [issue13087] C BufferedReader seek() is inconsistent with UnsupportedOperation for unseekable streams Message-ID: <1317508369.4.0.585699022019.issue13087@psf.upfronthosting.co.za> New submission from John O'Connor : The C implementation of BufferedReader.seek() does not throw an UnsupportedOperation exception when its underlying stream is unseekable IF the current buffer can accommodate the seek in memory. It probably saves a few cycles for the seekable streams but, I think currently, it is inconsistent with the _pyio implementation and documentation. ---------- components: IO files: unseekable.patch keywords: patch messages: 144751 nosy: haypo, jcon, pitrou priority: normal severity: normal status: open title: C BufferedReader seek() is inconsistent with UnsupportedOperation for unseekable streams type: behavior versions: Python 3.2, Python 3.3 Added file: http://bugs.python.org/file23287/unseekable.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Oct 2 01:32:57 2011 From: report at bugs.python.org (STINNER Victor) Date: Sat, 01 Oct 2011 23:32:57 +0000 Subject: [New-bugs-announce] [issue13088] Add Py_hexdigits constant: use one unique constant to format a digit to hexadecimal Message-ID: <1317511977.11.0.738521421258.issue13088@psf.upfronthosting.co.za> New submission from STINNER Victor : CPython source code contains a lot of duplicate "0123456789abcdef" constants, declared as static variables. Attached patch uses one unique variable. Use also Py_hexdigit instead of ((c>9) ? c+'a'-10 : c + '0') in binascii, _hashopenssl, md5, sha1, sha256 and sha512 modules. ---------- files: hexdigits.patch keywords: patch messages: 144754 nosy: haypo priority: normal severity: normal status: open title: Add Py_hexdigits constant: use one unique constant to format a digit to hexadecimal versions: Python 3.3 Added file: http://bugs.python.org/file23288/hexdigits.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Oct 2 10:50:16 2011 From: report at bugs.python.org (Stefan Krah) Date: Sun, 02 Oct 2011 08:50:16 +0000 Subject: [New-bugs-announce] [issue13089] parsetok.c: memory leak Message-ID: <1317545416.55.0.717898890924.issue13089@psf.upfronthosting.co.za> New submission from Stefan Krah : Seen in test_mailbox: ==31621== 6 bytes in 2 blocks are definitely lost in loss record 27 of 10,370 ==31621== at 0x4C2154B: malloc (vg_replace_malloc.c:236) ==31621== by 0x5271A5: parsetok (parsetok.c:179) ==31621== by 0x526E8A: PyParser_ParseStringFlagsFilenameEx (parsetok.c:67) ==31621== by 0x4BC385: PyParser_ASTFromString (pythonrun.c:1898) ==31621== by 0x4BC1E1: Py_CompileStringExFlags (pythonrun.c:1842) ==31621== by 0x478AB8: builtin_compile (bltinmodule.c:626) ==31621== by 0x5759F3: PyCFunction_Call (methodobject.c:84) ==31621== by 0x48F2CF: ext_do_call (ceval.c:4292) ==31621== by 0x489992: PyEval_EvalFrameEx (ceval.c:2646) ==31621== by 0x48E67B: fast_function (ceval.c:4068) ==31621== by 0x48E3C7: call_function (ceval.c:4001) ==31621== by 0x4895E1: PyEval_EvalFrameEx (ceval.c:2605) ---------- components: Interpreter Core messages: 144763 nosy: skrah priority: normal severity: normal stage: needs patch status: open title: parsetok.c: memory leak type: resource usage versions: Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Oct 2 11:10:29 2011 From: report at bugs.python.org (Stefan Krah) Date: Sun, 02 Oct 2011 09:10:29 +0000 Subject: [New-bugs-announce] [issue13090] posix_read: memory leak Message-ID: <1317546629.79.0.861373881282.issue13090@psf.upfronthosting.co.za> New submission from Stefan Krah : Seen in test_multiprocessing: ==31662== 37 bytes in 1 blocks are definitely lost in loss record 629 of 10,548 ==31662== at 0x4C2154B: malloc (vg_replace_malloc.c:236) ==31662== by 0x53BBE9: PyBytes_FromStringAndSize (bytesobject.c:98) ==31662== by 0x4E2363: posix_read (posixmodule.c:6980) ==31662== by 0x5759D8: PyCFunction_Call (methodobject.c:81) ==31662== by 0x48E294: call_function (ceval.c:3980) ==31662== by 0x4895E1: PyEval_EvalFrameEx (ceval.c:2605) ==31662== by 0x48C54F: PyEval_EvalCodeEx (ceval.c:3355) ==31662== by 0x48E786: fast_function (ceval.c:4078) ==31662== by 0x48E3C7: call_function (ceval.c:4001) ==31662== by 0x4895E1: PyEval_EvalFrameEx (ceval.c:2605) ==31662== by 0x48C54F: PyEval_EvalCodeEx (ceval.c:3355) ==31662== by 0x48E786: fast_function (ceval.c:4078) ---------- components: Extension Modules messages: 144764 nosy: skrah priority: normal severity: normal stage: needs patch status: open title: posix_read: memory leak type: resource usage versions: Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Oct 2 11:11:58 2011 From: report at bugs.python.org (Stefan Krah) Date: Sun, 02 Oct 2011 09:11:58 +0000 Subject: [New-bugs-announce] [issue13091] ctypes: memory leak Message-ID: <1317546718.25.0.742978918789.issue13091@psf.upfronthosting.co.za> New submission from Stefan Krah : Seen in test_multiprocessing: ==31662== 44 bytes in 1 blocks are definitely lost in loss record 687 of 10,548 ==31662== at 0x4C2154B: malloc (vg_replace_malloc.c:236) ==31662== by 0x41CC27: PyMem_Malloc (object.c:1699) ==31662== by 0x127D9F51: resize (callproc.c:1664) ==31662== by 0x5759D8: PyCFunction_Call (methodobject.c:81) ==31662== by 0x48E294: call_function (ceval.c:3980) ==31662== by 0x4895E1: PyEval_EvalFrameEx (ceval.c:2605) ==31662== by 0x48E67B: fast_function (ceval.c:4068) ==31662== by 0x48E3C7: call_function (ceval.c:4001) ==31662== by 0x4895E1: PyEval_EvalFrameEx (ceval.c:2605) ==31662== by 0x48C54F: PyEval_EvalCodeEx (ceval.c:3355) ==31662== by 0x48E786: fast_function (ceval.c:4078) ==31662== by 0x48E3C7: call_function (ceval.c:4001) ---------- components: Extension Modules messages: 144765 nosy: skrah priority: normal severity: normal stage: needs patch status: open title: ctypes: memory leak type: resource usage versions: Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Oct 2 11:49:05 2011 From: report at bugs.python.org (Stefan Krah) Date: Sun, 02 Oct 2011 09:49:05 +0000 Subject: [New-bugs-announce] [issue13092] pep-393: memory leaks #2 Message-ID: <1317548945.05.0.236513746453.issue13092@psf.upfronthosting.co.za> New submission from Stefan Krah : I found a couple of additional leaks related to the PEP-393 changes. ---------- components: Interpreter Core files: pep-393-leaks-2.diff keywords: patch messages: 144767 nosy: loewis, skrah priority: normal severity: normal stage: patch review status: open title: pep-393: memory leaks #2 type: resource usage versions: Python 3.3 Added file: http://bugs.python.org/file23293/pep-393-leaks-2.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Oct 2 17:39:15 2011 From: report at bugs.python.org (Stefan Krah) Date: Sun, 02 Oct 2011 15:39:15 +0000 Subject: [New-bugs-announce] [issue13093] Redundant code in PyUnicode_EncodeDecimal() Message-ID: <1317569955.86.0.21646060057.issue13093@psf.upfronthosting.co.za> New submission from Stefan Krah : I can't see what this code is supposed to accomplish (see patch): while (collend < end) { if ((0 < *collend && *collend < 256) || !Py_UNICODE_ISSPACE(*collend) || Py_UNICODE_TODECIMAL(*collend)) break; } Since 'collend' and 'end' don't change in the loop, it would be infinite if the 'if' condition evaluated to false. But the 'if' condition is always true. ---------- components: Interpreter Core files: encode_decimal_redundant_code.diff keywords: needs review, patch messages: 144774 nosy: skrah priority: normal severity: normal stage: patch review status: open title: Redundant code in PyUnicode_EncodeDecimal() type: behavior versions: Python 3.3 Added file: http://bugs.python.org/file23295/encode_decimal_redundant_code.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Oct 3 16:39:57 2011 From: report at bugs.python.org (=?utf-8?b?VG9tw6HFoSBEdm/FmcOhaw==?=) Date: Mon, 03 Oct 2011 14:39:57 +0000 Subject: [New-bugs-announce] [issue13094] setattr misbehaves when used with lambdas inside for loop Message-ID: <1317652797.3.0.357677492942.issue13094@psf.upfronthosting.co.za> New submission from Tom?? Dvo??k : I have this python script, and run it in python 2.7.2 (installed from EPD_free 7.1-2 (32-bit), but I guess this has nothing to do with EPD. ----8<---fail.py------ class X(object): pass x = X() items = ["foo", "bar", "baz"] for each in items: setattr(x, each, lambda: each) print("foo", x.foo()) print("bar", x.bar()) print("baz", x.baz()) ----8<---fail.py------ I'd naively expect it to print ('foo', 'foo') ('bar', 'bar') ('baz', 'baz') ,but it surprisingly (and annoyingly) outputs ('foo', 'baz') ('bar', 'baz') ('baz', 'baz') Please, tell me that this is a bug :) I'd hate it if this was the intended behaviour. I spent two hours today before I found out this was the cause of my program to fail. Best regards, Tom?? Dvo??k ---------- components: None messages: 144819 nosy: Tom??.Dvo??k priority: normal severity: normal status: open title: setattr misbehaves when used with lambdas inside for loop versions: Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Oct 3 20:39:55 2011 From: report at bugs.python.org (Cal Leeming) Date: Mon, 03 Oct 2011 18:39:55 +0000 Subject: [New-bugs-announce] [issue13095] Support for splitting lists/tuples into chunks Message-ID: <1317667195.74.0.956951285114.issue13095@psf.upfronthosting.co.za> New submission from Cal Leeming : After a while of digging around, I noticed that the core libs don't provide an easy way of splitting a list/tuple into chunks - as per the following discussion: http://www.aspwinhost.com/In-what-way-do-you-split-an-list-into-evenly-sized-chunks-on-Python/ Therefore, I'd like to +1 feature request this. Any thoughts?? Cal ---------- components: Library (Lib) messages: 144831 nosy: sleepycal priority: normal severity: normal status: open title: Support for splitting lists/tuples into chunks type: feature request _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Oct 4 05:47:39 2011 From: report at bugs.python.org (Meador Inge) Date: Tue, 04 Oct 2011 03:47:39 +0000 Subject: [New-bugs-announce] [issue13096] ctypes: segfault with large POINTER type names Message-ID: <1317700059.13.0.375039668353.issue13096@psf.upfronthosting.co.za> New submission from Meador Inge : Reproducible in 2.7 and tip: [meadori at motherbrain cpython]$ ./python Python 3.3.0a0 (default:61de28fa5537+d05350c14e77+, Oct 3 2011, 21:47:04) [GCC 4.6.0 20110603 (Red Hat 4.6.0-10)] on linux Type "help", "copyright", "credits" or "license" for more information. >>> from ctypes import * >>> T = type('x' * 2 ** 25, (Structure,), {}) >>> p = POINTER(T) Segmentation fault (core dumped) ---------- components: Extension Modules, ctypes messages: 144850 nosy: amaury.forgeotdarc, belopolsky, meador.inge priority: normal severity: normal stage: needs patch status: open title: ctypes: segfault with large POINTER type names type: crash versions: Python 2.7, Python 3.2, Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Oct 4 05:57:17 2011 From: report at bugs.python.org (Meador Inge) Date: Tue, 04 Oct 2011 03:57:17 +0000 Subject: [New-bugs-announce] [issue13097] ctypes: segfault with large number of callback arguments Message-ID: <1317700637.71.0.186696346618.issue13097@psf.upfronthosting.co.za> New submission from Meador Inge : Reproducible in 2.7 and tip: [meadori at motherbrain cpython]$ ./python Python 3.3.0a0 (default:61de28fa5537+d05350c14e77+, Oct 3 2011, 21:47:04) [GCC 4.6.0 20110603 (Red Hat 4.6.0-10)] on linux Type "help", "copyright", "credits" or "license" for more information. >>> from ctypes import * >>> NARGS = 2 ** 20 >>> proto = CFUNCTYPE(None, *(c_int,) * NARGS) >>> def func(*args): ... return (1, "abc", None) ... >>> cb = proto(func) >>> cb(*(1,) * NARGS) Segmentation fault (core dumped) ---------- components: ctypes messages: 144852 nosy: amaury.forgeotdarc, belopolsky, meador.inge priority: normal severity: normal stage: needs patch status: open title: ctypes: segfault with large number of callback arguments type: crash versions: Python 2.7, Python 3.2, Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Oct 4 11:52:30 2011 From: report at bugs.python.org (Antoine Pitrou) Date: Tue, 04 Oct 2011 09:52:30 +0000 Subject: [New-bugs-announce] [issue13098] the struct module should support storage for size_t / Py_ssize_t C types Message-ID: <1317721950.11.0.748294685734.issue13098@psf.upfronthosting.co.za> New submission from Antoine Pitrou : Title says it all. ---------- components: Library (Lib) messages: 144867 nosy: mark.dickinson, meador.inge, pitrou, skrah priority: normal severity: normal stage: needs patch status: open title: the struct module should support storage for size_t / Py_ssize_t C types type: feature request versions: Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Oct 4 12:46:39 2011 From: report at bugs.python.org (Thomas Kluyver) Date: Tue, 04 Oct 2011 10:46:39 +0000 Subject: [New-bugs-announce] [issue13099] Sqlite3 & turkish locale Message-ID: <1317725199.69.0.486458552577.issue13099@psf.upfronthosting.co.za> New submission from Thomas Kluyver : When using sqlite3 with the Turkish locale, cursor.lastrowid is not accessible after an insert statement if "INSERT" is upper case. I believe that the cause is that the detect_statement_kind function [1] calls the locale-dependent C function tolower(). The Turkish locale specifies a different case mapping for I (to a dotless lowercase i: ?), so it's not recognised as an insert statement, which looks like it will cause the transaction to be committed immediately. See also the discussion on issue 1813 [2], and a Redhat bug with a test case for this [3]. [1] http://hg.python.org/cpython/file/c4b6d9312da1/Modules/_sqlite/cursor.c#l41 [2] http://bugs.python.org/issue1813 [3] https://bugzilla.redhat.com/show_bug.cgi?id=720209 ---------- components: Extension Modules messages: 144873 nosy: takluyver priority: normal severity: normal status: open title: Sqlite3 & turkish locale versions: Python 2.7, Python 3.2 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Oct 4 19:11:58 2011 From: report at bugs.python.org (STINNER Victor) Date: Tue, 04 Oct 2011 17:11:58 +0000 Subject: [New-bugs-announce] [issue13100] sre_compile._optimize_unicode() needs a cleanup Message-ID: <1317748318.81.0.992039803801.issue13100@psf.upfronthosting.co.za> New submission from STINNER Victor : The following comment is wrong, except IndexError: # non-BMP characters; XXX now they should work return charset sys.maxunicode != 65535 is now always true in Python 3.3 if sys.maxunicode != 65535: # XXX: negation does not work with big charsets # XXX2: now they should work, but removing this will make the # charmap 17 times bigger return charset See the related commit: f39b26ca7f3d (from issue #13054). ---------- components: Library (Lib), Regular Expressions, Unicode messages: 144905 nosy: ezio.melotti, haypo, pitrou priority: normal severity: normal status: open title: sre_compile._optimize_unicode() needs a cleanup versions: Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Oct 4 20:36:49 2011 From: report at bugs.python.org (Brian Curtin) Date: Tue, 04 Oct 2011 18:36:49 +0000 Subject: [New-bugs-announce] [issue13101] Module Doc viewer closes when browser window closes on Windows 8 Message-ID: <1317753409.09.0.358970019617.issue13101@psf.upfronthosting.co.za> New submission from Brian Curtin : Reported by Ryan Wells (v-rywel at microsoft.com) of Microsoft, in reference to a problem with the Module Doc viewer on Windows 8 when using Internet Explorer 10. This was reported on 3.2.2, but it's likely the same on 2.7. Reference #: 70652 Description of the Problem: The application Python Module Doc is automatically closed when Internet Explorer 10 is closed. Steps to Reproduce: 1. Install Windows Developer Preview 2. Install Python 3.2.2 3. Launch Module Doc. Start Menu -> All Program -> Python -> Manual Docs 4. Click on the button open browser 5. It should open the site http://localhost:7464/ In Internet Explorer 10 and the contents should be displayed 6. Should be able to view list of Modules, Scripts, DLLs, and Libraries etc. 7. Close Internet Explorer Expected Result: Internet Explorer 10 should only get closed and we should be able to work with the application Module Doc. Actual Result: The application Module Doc is closed with Internet Explorer 10. Developer Notes: There is likely a difference in return values between IE8 and IE9/10 when launched from the app. ---------- assignee: docs at python components: Documentation, Windows messages: 144918 nosy: brian.curtin, docs at python priority: normal severity: normal status: open title: Module Doc viewer closes when browser window closes on Windows 8 type: behavior versions: Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Oct 4 22:11:54 2011 From: report at bugs.python.org (Glenn Washburn) Date: Tue, 04 Oct 2011 20:11:54 +0000 Subject: [New-bugs-announce] [issue13102] xml.dom.minidom does not support default namespaces Message-ID: <1317759114.05.0.782450819911.issue13102@psf.upfronthosting.co.za> New submission from Glenn Washburn : When using getAttributeNS, attributes with no namespace should be considered as having the default namespace for that scope. See examples in http://www.w3.org/TR/REC-xml-names/#defaulting. Python's xml.dom.minidom will always set the namespace to None for attributes that have no namespace prefix. I've attached a test program to illustrate this issue in action. The output I get is: [((None, u'attr'), u'value1')] [(('http://www.w3.org/2000/xmlns/', 'xmlns'), u'http://path/to/ns2#'), ((None, u'attr'), u'value2')] [((u'http://path/to/ns2#', u'attr'), u'value3')] Successfully got child3 attr value In the first two cases the namespaceURI is None, but it should be set to the default namespace specified in the root element. I believe this problem occurs with all *NS functions. Not tested in 3.x. ---------- components: XML files: test.py messages: 144924 nosy: crass priority: normal severity: normal status: open title: xml.dom.minidom does not support default namespaces type: behavior versions: Python 2.6, Python 2.7 Added file: http://bugs.python.org/file23313/test.py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Oct 4 22:41:19 2011 From: report at bugs.python.org (Xavier de Gaye) Date: Tue, 04 Oct 2011 20:41:19 +0000 Subject: [New-bugs-announce] [issue13103] copy of an asyncore dispatcher causes infinite recursion Message-ID: <1317760879.94.0.397539088986.issue13103@psf.upfronthosting.co.za> New submission from Xavier de Gaye : A regression occurs in python 3.2 when doing a copy of an asyncore dispatcher. $ python3.1 Python 3.1.2 (r312:79147, Apr 4 2010, 17:46:48) [GCC 4.3.2] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> import asyncore, copy >>> copy.copy(asyncore.dispatcher()) $ python3.2 Python 3.2 (r32:88445, Jun 18 2011, 20:30:18) [GCC 4.3.2] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> import asyncore, copy >>> copy.copy(asyncore.dispatcher()) Traceback (most recent call last): File "", line 1, in File "/usr/local/lib/python3.2/copy.py", line 97, in copy return _reconstruct(x, rv, 0) File "/usr/local/lib/python3.2/copy.py", line 291, in _reconstruct if hasattr(y, '__setstate__'): File "/usr/local/lib/python3.2/asyncore.py", line 410, in __getattr__ retattr = getattr(self.socket, attr) .... File "/usr/local/lib/python3.2/asyncore.py", line 410, in __getattr__ retattr = getattr(self.socket, attr) File "/usr/local/lib/python3.2/asyncore.py", line 410, in __getattr__ retattr = getattr(self.socket, attr) RuntimeError: maximum recursion depth exceeded while calling a Python object This occurs after the 'copy' module has created the new instance with __new__(). This new instance does not have the 'socket' attribute, hence the infinite recursion. Adding the following methods to the dispatcher class, fixes the infinite recursion: def __getstate__(self): state = self.__dict__.copy() return state def __setstate__(self, state): self.__dict__.update(state) But it does not explain why the recursion occurs in 3.2 and not in 3.1. ---------- components: Extension Modules messages: 144925 nosy: xdegaye priority: normal severity: normal status: open title: copy of an asyncore dispatcher causes infinite recursion type: behavior versions: Python 3.2 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Oct 5 01:02:51 2011 From: report at bugs.python.org (Deokhwan Kim) Date: Tue, 04 Oct 2011 23:02:51 +0000 Subject: [New-bugs-announce] [issue13104] urllib.request.thishost() returns a garbage value Message-ID: <1317769371.74.0.590194297783.issue13104@psf.upfronthosting.co.za> New submission from Deokhwan Kim : There is a minor typo in Lib/urllib/request.py:thishost(). Because of it, the thishost() function is returning a garbage value: >>> import urllib.request >>> urllib.request.thishost() ('XXXXXXX.XXXXX.XXX.com', ['X.XXXXX.XXX.com'], ['123.45.67.89']) It is expected to return the IP addresses of the current host, so the correct return value would be like: >>> urllib.request.thishost.__doc__ 'Return the IP addresses of the current host.' >>> urllib.request.thishost() ('127.0.0.1', '127.0.1.1') The attached patch will fix the mistake . ---------- components: Library (Lib) files: thishost.patch keywords: patch messages: 144929 nosy: dkim priority: normal severity: normal status: open title: urllib.request.thishost() returns a garbage value type: behavior versions: Python 3.2 Added file: http://bugs.python.org/file23316/thishost.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Oct 5 01:24:16 2011 From: report at bugs.python.org (Larry Hastings) Date: Tue, 04 Oct 2011 23:24:16 +0000 Subject: [New-bugs-announce] [issue13105] Please elaborate on how 2.x and 3.x are different heads Message-ID: <1317770656.72.0.880626385137.issue13105@psf.upfronthosting.co.za> New submission from Larry Hastings : It wasn't clear to me after reading the "Forward Porting" section exactly what was going on. Nick Coghlan spelled it out for me in a private email, and suggested that maybe this stuff should be in the devguide proper. Here's some specific stuff that I didn't understand until Nick explained it to me with simple words: * 2.x and 3.x have separate heads in the same repository * Since they're totally divorced, the order you check in to 2.x and 3.x does not matter * DO NOT MERGE between 2.x and 3.x * Branches that are in security-fix-only mode (e.g. 3.1) don't get bugfixes or documentation fixes (surely mentioned elsewhere, but I personally would have been helped with a reminder) I suggest it'd be clearer to start with discussing "2.x and 3.x are separate heads", and *then* move on to "But when merging changes solely inside a major version" and talk about forward-porting. Would you be interested in a patch? ---------- components: Devguide messages: 144930 nosy: larry priority: normal severity: normal status: open title: Please elaborate on how 2.x and 3.x are different heads type: feature request _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Oct 5 04:11:49 2011 From: report at bugs.python.org (Aaron Staley) Date: Wed, 05 Oct 2011 02:11:49 +0000 Subject: [New-bugs-announce] [issue13106] Incorrect pool.py distributed with Python 2.7 windows 32bit Message-ID: <1317780709.51.0.218213650028.issue13106@psf.upfronthosting.co.za> New submission from Aaron Staley : The multiprocess/pool.py distributed with the Python 2.7.2 Windows Installer is different from the one distributed with the 64 bit windows installer or source tarball - and is buggy. Specifically, see Pool._terminate_pool: def _terminate_pool(cls, taskqueue, inqueue, outqueue, pool, worker_handler, task_handler, result_handler, cache): # this is guaranteed to only be called once debug('finalizing pool') worker_handler._state = TERMINATE task_handler._state = TERMINATE taskqueue.put(None) # THIS LINE MISSING! Without that line, termination may deadlock during Pool._help_stuff_finish. The consequence to the user is the interpreter not shutting down. ---------- components: Windows messages: 144934 nosy: Aaron.Staley priority: normal severity: normal status: open title: Incorrect pool.py distributed with Python 2.7 windows 32bit versions: Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Oct 5 13:08:23 2011 From: report at bugs.python.org (Adam Byrtek) Date: Wed, 05 Oct 2011 11:08:23 +0000 Subject: [New-bugs-announce] [issue13107] Text width in optparse.py can become negative Message-ID: <1317812903.38.0.572106699519.issue13107@psf.upfronthosting.co.za> New submission from Adam Byrtek : Code snippet from optparse.py: 344 self.help_position = min(max_len + 2, self.max_help_position) 345 self.help_width = self.width - self.help_position Where self.width is initialized with the COLUMNS environment variable. On narrow terminals it can happen that self.help_position < self.width, leading to an exception in textwrap.py: raise ValueError("invalid width %r (must be > 0)" % self.width) ValueError: invalid width -15 (must be > 0) A reasonable workaround would be to trim part of the help text instead of causing an exception. ---------- components: Library (Lib) messages: 144947 nosy: adambyrtek priority: normal severity: normal status: open title: Text width in optparse.py can become negative type: behavior _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Oct 5 23:04:49 2011 From: report at bugs.python.org (Stefan Krah) Date: Wed, 05 Oct 2011 21:04:49 +0000 Subject: [New-bugs-announce] [issue13108] test_urllib: buildbot failure Message-ID: <1317848689.77.0.919610092444.issue13108@psf.upfronthosting.co.za> New submission from Stefan Krah : The FreeBSD-amd64 and Fedora buildbots are recently failing with: ====================================================================== ERROR: test_thishost (test.test_urllib.Utility_Tests) Test the urllib.request.thishost utility function returns a tuple ---------------------------------------------------------------------- Traceback (most recent call last): File "/home/buildbot/buildarea/3.x.krah-fedora/build/Lib/test/test_urllib.py", line 1063, in test_thishost self.assertIsInstance(urllib.request.thishost(), tuple) File "/home/buildbot/buildarea/3.x.krah-fedora/build/Lib/urllib/request.py", line 2128, in thishost _thishost = tuple(socket.gethostbyname_ex(socket.gethostname())[2]) socket.gaierror: [Errno -2] Name or service not known ---------------------------------------------------------------------- ---------- components: Tests messages: 144971 nosy: skrah priority: normal severity: normal status: open title: test_urllib: buildbot failure versions: Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Oct 5 23:08:09 2011 From: report at bugs.python.org (xy zzy) Date: Wed, 05 Oct 2011 21:08:09 +0000 Subject: [New-bugs-announce] [issue13109] telnetlib insensitive to connection loss Message-ID: <1317848889.2.0.2461830982.issue13109@psf.upfronthosting.co.za> New submission from xy zzy : Using python's telnetlib I can connect and communicate with a device. While the telnet session is active I can disconnect the network cable of the device. At this point, I would expect read_until() with a timeout to throw a socket.error, EOFError or perhaps an IOError, but what I actually get is a null string. Because I'm reading in a loop, when the cable is reconnected the device will resume communicating, and the program will continue. My best guess ts that read_until() or perhaps everything except open() is insensitive to the loss of a connection. ---------- components: IO messages: 144972 nosy: xy.zzy priority: normal severity: normal status: open title: telnetlib insensitive to connection loss type: behavior _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Oct 5 23:51:15 2011 From: report at bugs.python.org (Barry A. Warsaw) Date: Wed, 05 Oct 2011 21:51:15 +0000 Subject: [New-bugs-announce] [issue13110] test_socket.py failures on ARM Message-ID: <1317851475.03.0.915061914039.issue13110@psf.upfronthosting.co.za> New submission from Barry A. Warsaw : Initial results from warsaw-ubuntu-arm buildbot indicates two failures in test_socket.py ====================================================================== ERROR: test_create_connection_timeout (test.test_socket.NetworkConnectionNoServer) ---------------------------------------------------------------------- Traceback (most recent call last): File "/var/lib/buildbot/buildarea/2.7.warsaw-ubuntu-arm/build/Lib/test/test_socket.py", line 1198, in test_create_connection_timeout socket.create_connection((HOST, 1234)) File "/var/lib/buildbot/buildarea/2.7.warsaw-ubuntu-arm/build/Lib/socket.py", line 571, in create_connection raise err error: [Errno 97] Address family not supported by protocol ====================================================================== FAIL: test_create_connection (test.test_socket.NetworkConnectionNoServer) ---------------------------------------------------------------------- Traceback (most recent call last): File "/var/lib/buildbot/buildarea/2.7.warsaw-ubuntu-arm/build/Lib/test/test_socket.py", line 1191, in test_create_connection self.assertEqual(cm.exception.errno, errno.ECONNREFUSED) AssertionError: 97 != 111 ---------------------------------------------------------------------- I'm still investigating, but wanted to file the bug now so there's an issue number to reference. ---------- components: Tests messages: 144974 nosy: barry priority: normal severity: normal status: open title: test_socket.py failures on ARM versions: Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Oct 6 00:55:27 2011 From: report at bugs.python.org (MA S) Date: Wed, 05 Oct 2011 22:55:27 +0000 Subject: [New-bugs-announce] [issue13111] Error 2203 when installing Python/Perl? Message-ID: <1317855327.52.0.585487977144.issue13111@psf.upfronthosting.co.za> New submission from MA S : I can't install Python or Strawberry Perl on the Windows 8 Developer Preview :( I keep getting installer error 2203; the log file's attached. I really don't know what's wrong... ---------- components: Windows files: python.log messages: 144975 nosy: MA.S priority: normal severity: normal status: open title: Error 2203 when installing Python/Perl? type: crash versions: Python 2.7 Added file: http://bugs.python.org/file23320/python.log _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Oct 6 01:31:34 2011 From: report at bugs.python.org (yoch) Date: Wed, 05 Oct 2011 23:31:34 +0000 Subject: [New-bugs-announce] [issue13112] backreferences in comprehensions Message-ID: <1317857494.55.0.915280284739.issue13112@psf.upfronthosting.co.za> New submission from yoch : Hi, I would like to use backreferences in list comprehensions (or other comprehensions), such as : [[elt for elt in lst if elt] for lst in matrix if \{1}] # \{1} is back reference to [elt for elt in lst if elt] # to filter the result of the first comprehension It would be possible to do this ? Thanks ---------- messages: 144976 nosy: yoch.melka priority: normal severity: normal status: open title: backreferences in comprehensions type: feature request _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Oct 6 13:55:00 2011 From: report at bugs.python.org (telmich) Date: Thu, 06 Oct 2011 11:55:00 +0000 Subject: [New-bugs-announce] [issue13113] Wrong error message on class instance, when giving too little positional arguments Message-ID: <1317902100.22.0.844321043638.issue13113@psf.upfronthosting.co.za> New submission from telmich : I've this class: class Path: """Class that handles path related configurations""" def __init__(self, target_host, remote_user, remote_prefix, initial_manifest=False, base_dir=None, debug=False): That is falsely instantiated from a different class with these arguments: self.path = cdist.path.Path(self.target_host, initial_manifest=initial_manifest, base_dir=home, debug=debug) Which results in the following traceback: [13:40] kr:cdist% ./bin/cdist config -d localhost Traceback (most recent call last): File "./bin/cdist", line 119, in commandline() File "./bin/cdist", line 102, in commandline args.func(args) File "/home/users/nico/oeffentlich/rechner/projekte/cdist/lib/cdist/config.py", line 296, in config c = Config(host, initial_manifest=args.manifest, home=args.cdist_home, debug=args.debug) File "/home/users/nico/oeffentlich/rechner/projekte/cdist/lib/cdist/config.py", line 52, in __init__ debug=debug) TypeError: __init__() takes at least 4 arguments (5 given) Problem: - there are 5 arguments, so an error message indicating there are at least 4 needed is not helpful Proposal (pseudocode): Change to "Only %d of %d required positional arguments given" required_positional, giving_positional ---------- components: Interpreter Core messages: 145002 nosy: telmich priority: normal severity: normal status: open title: Wrong error message on class instance, when giving too little positional arguments type: behavior versions: Python 3.2 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Oct 6 15:22:42 2011 From: report at bugs.python.org (=?utf-8?b?0JrQuNGA0LjQu9C7INCa0YPQt9GM0LzQuNC90YvRhQ==?=) Date: Thu, 06 Oct 2011 13:22:42 +0000 Subject: [New-bugs-announce] [issue13114] UnicodeDecodeError in command `register` due to using not ASCII chars in long_description Message-ID: <1317907362.37.0.133459111826.issue13114@psf.upfronthosting.co.za> New submission from ?????? ????????? : Command `register` (and `check -r` too) raises the exception UnicodeDecodeError if the long_description (stored as unicode) contains not ASCII chars. This is because the Docutils, called from Distutils, accepts only ASCII or Unicode. But Distutils passes to Docutils text as a `str` (ASCII or UTF-8). PS: sorry for my English ---------- assignee: tarek components: Distutils files: trace.log messages: 145007 nosy: Cykooz, eric.araujo, tarek priority: normal severity: normal status: open title: UnicodeDecodeError in command `register` due to using not ASCII chars in long_description type: crash versions: Python 2.7 Added file: http://bugs.python.org/file23327/trace.log _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Oct 6 16:10:26 2011 From: report at bugs.python.org (Andrew Wilkins) Date: Thu, 06 Oct 2011 14:10:26 +0000 Subject: [New-bugs-announce] [issue13115] tp_as_{number, sequence, mapping} can't be set using PyType_FromSpec Message-ID: <1317910226.56.0.365091018544.issue13115@psf.upfronthosting.co.za> New submission from Andrew Wilkins : I've written an extension using Py_LIMITED_API, and I've created a type using PyType_FromSpec with the slot "Py_sq_length" defined. The slot is not being picked up, i.e. len(MyType()) fails. I can see that tp_as_sequence has not been set, which explains why. All is well if I set it manually (without Py_LIMITED_API defined), like so: MyType->tp_as_sequence = &((PyHeapTypeObject*)MyType)->as_sequence; As far as I can see (docs are lacking), there's no way of setting tp_as_number, tp_as_sequence or tp_as_mapping in types created with PyType_FromSpec. I would expect the presence of any Py_sq_* slots to set tp_as_sequence (likewise for number and mapping). ---------- components: Interpreter Core messages: 145013 nosy: awilkins priority: normal severity: normal status: open title: tp_as_{number,sequence,mapping} can't be set using PyType_FromSpec versions: Python 3.2 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Oct 6 17:42:42 2011 From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=) Date: Thu, 06 Oct 2011 15:42:42 +0000 Subject: [New-bugs-announce] [issue13116] setup.cfg in [sb]dists should be static Message-ID: <1317915762.54.0.969795427533.issue13116@psf.upfronthosting.co.za> New submission from ?ric Araujo : Some people (hi Ronny :) want to use a setup hook to get the version from the VCS, but the setup.cfg file in sdists and bdists should be fully static, because getting the VCS info is not possible and maybe for other reasons too (not requiring development dependencies for example, the same argument that makes people include generated HTML docs in sdists). The way to handle that seems simple: sdist runs setup hooks and writes back the modified config object to the setup.cfg file that?s included in sdists and bdists. Command hooks are unaffected, as are post/pre install/remove hooks (to be added in #12416). Another idea would be to split global hooks into two kinds. The code would run the volatile hooks, write the modified config as setup.cfg for *dists, and then run regular hooks. Users installing a *dist will execute the regular hooks. ---------- assignee: tarek components: Distutils2 messages: 145021 nosy: alexis, eric.araujo, tarek priority: normal severity: normal status: open title: setup.cfg in [sb]dists should be static versions: 3rd party, Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Oct 6 20:32:39 2011 From: report at bugs.python.org (=?utf-8?q?Francisco_Mart=C3=ADn_Brugu=C3=A9?=) Date: Thu, 06 Oct 2011 18:32:39 +0000 Subject: [New-bugs-announce] =?utf-8?q?=5Bissue13117=5D_Broken_links_in_th?= =?utf-8?b?ZSDigJxjb21waWxlcuKAnSBwYWdlLCBzZWN0aW9uIOKAnHJlZmVyZW5jZXM=?= =?utf-8?q?=E2=80=9D_from_the_devguide=2E?= Message-ID: <1317925959.0.0.308627128494.issue13117@psf.upfronthosting.co.za> New submission from Francisco Mart?n Brugu? : Hi, In the page http://docs.python.org/devguide/compiler.html the links in the references [1] (http://www.foretec.com/python/workshops/1998-11/proceedings/papers/montanaro/montanaro.html) and in [Wang97] (http://www.cs.princeton.edu/%7Edanwang/Papers/dsl97/dsl97.html) are broken. Cheers, francis ---------- components: Devguide messages: 145030 nosy: francismb priority: normal severity: normal status: open title: Broken links in the ?compiler? page, section ?references? from the devguide. _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Oct 6 20:35:25 2011 From: report at bugs.python.org (=?utf-8?q?F=C3=A9lix-Antoine_Fortin?=) Date: Thu, 06 Oct 2011 18:35:25 +0000 Subject: [New-bugs-announce] [issue13118] Py_BuildValue format f incorrect description. Message-ID: <1317926125.15.0.437576148609.issue13118@psf.upfronthosting.co.za> New submission from F?lix-Antoine Fortin : Python/C API Reference Manual, section Utilities, Parsing arguments and building values, function Py_BuildValue. The description for the format unit "f" is incorrect. It reads "Same as d.", as it should be "Convert a C float to a Python floating point number." since "f" is not the same as "d" when converting double to Python float. This was corrected in the documentation of Python 3, from which the proposed description comes. ---------- assignee: docs at python components: Documentation messages: 145031 nosy: docs at python, felixantoinefortin priority: normal severity: normal status: open title: Py_BuildValue format f incorrect description. versions: Python 2.6, Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Oct 6 22:59:48 2011 From: report at bugs.python.org (M. Zilmer) Date: Thu, 06 Oct 2011 20:59:48 +0000 Subject: [New-bugs-announce] [issue13119] Newline for print() is \n on Windows, and not \r\n as expected Message-ID: <1317934788.08.0.425265217585.issue13119@psf.upfronthosting.co.za> New submission from M. Zilmer : In 3.2.2 the newline for print() is \n on Windows, and not \r\n as expected. In 3.1.4 the newline is \r\n. OS is Win 7, and tried on both 32 and 64 bit. Small example with output is attached. ---------- components: Windows files: newline.py messages: 145039 nosy: M..Z. priority: normal severity: normal status: open title: Newline for print() is \n on Windows, and not \r\n as expected type: behavior versions: Python 3.2 Added file: http://bugs.python.org/file23330/newline.py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Oct 6 23:17:28 2011 From: report at bugs.python.org (Ben Bass) Date: Thu, 06 Oct 2011 21:17:28 +0000 Subject: [New-bugs-announce] [issue13120] Default nosigint optionto pdb.Pdb() prevents use in non-main thread Message-ID: <1317935848.16.0.589862913408.issue13120@psf.upfronthosting.co.za> New submission from Ben Bass : The new SIGINT behaviour of pdb.Pdb prevents use of pdb within a non-main thread without explicitly setting nosigint=True. Specifically the 'continue' command causes a traceback as follows: {{{ ... File "/Library/Frameworks/Python.framework/Versions/3.2/lib/python3.2/pdb.py", line 959, in do_continue signal.signal(signal.SIGINT, self.sigint_handler) ValueError: signal only works in main thread }}} Since the new behaviour seems to be to gain an enhancement rather than anything fundamentally necessary to pdb, wouldn't it be better if the default was reversed, so the same code would work identically on Python 3.1 (and potentially earlier, i.e. Python2) and Python 3.2? At the moment in my codebase (rpcpdb) I'm using inspect.getargspec sniffing for nosigint on pdb.Pdb.__init__ to determine whether to include a nosigint=True parameter, which clearly isn't ideal! ---------- components: Library (Lib) messages: 145040 nosy: bpb priority: normal severity: normal status: open title: Default nosigint optionto pdb.Pdb() prevents use in non-main thread type: behavior versions: Python 3.2 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Oct 7 10:50:34 2011 From: report at bugs.python.org (Lars Buitinck) Date: Fri, 07 Oct 2011 08:50:34 +0000 Subject: [New-bugs-announce] [issue13121] collections.Counter's += copies the entire object Message-ID: <1317977434.46.0.626100406816.issue13121@psf.upfronthosting.co.za> New submission from Lars Buitinck : I've found some counterintuitive behavior in collections.Counter while hacking on the scikit-learn project [1]. I wanted to use a bunch of Counters to do some simple term counting in a set of documents, roughly as follows: count_total = Counter() for doc in documents: count_current = Counter(analyze(doc)) count_total += count_current count_per_doc.append(count_current) Performance was horrible. After some digging, I found out that Counter [2] does not have __iadd__ and += copies the entire left-hand side in __add__. I've attached a patch that fixes the issue (for += only, and I've not patched the testsuite.) [1] https://github.com/scikit-learn/scikit-learn/commit/de6e93094499e4d81b8e3b15fc66b6b9252945af ---------- components: Library (Lib) files: cpython-counter-iadd.diff keywords: patch messages: 145063 nosy: larsmans priority: normal severity: normal status: open title: collections.Counter's += copies the entire object type: behavior versions: Python 3.4 Added file: http://bugs.python.org/file23336/cpython-counter-iadd.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Oct 7 17:02:20 2011 From: report at bugs.python.org (Sven Marnach) Date: Fri, 07 Oct 2011 15:02:20 +0000 Subject: [New-bugs-announce] [issue13122] Out of date links in the sidebar of the documentation index of versions 3.1 and 3.2 Message-ID: <1317999740.46.0.922190010194.issue13122@psf.upfronthosting.co.za> New submission from Sven Marnach : The sidebar on http://docs.python.org/release/3.1.3/ names 3.2 as the development version of Python, while the link points to 3.3. The sidebar on http://docs.python.org/py3k/ links to 3.1 as the "stable version" -- obviously a relict from the time when 3.2 was in development. (This could be fixed in Doc/tools/sphinxext/indexsidebar.html of the respective branches.) ---------- assignee: docs at python components: Documentation messages: 145084 nosy: docs at python, smarnach priority: normal severity: normal status: open title: Out of date links in the sidebar of the documentation index of versions 3.1 and 3.2 versions: Python 3.1, Python 3.2 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Oct 7 17:22:40 2011 From: report at bugs.python.org (Paul Moore) Date: Fri, 07 Oct 2011 15:22:40 +0000 Subject: [New-bugs-announce] [issue13123] bdist_wininst uninstaller does not remove pycache directories Message-ID: <1318000960.21.0.140069466315.issue13123@psf.upfronthosting.co.za> New submission from Paul Moore : When uninstalling a package installed using a bdist_wininst installer, the uninstall reports "XXX files and directories could not be removed". The problem appears to be the __pycache__ directories introduced in Python 3.2, which are not removed properly. ---------- assignee: tarek components: Distutils, Windows messages: 145090 nosy: eric.araujo, pmoore, tarek priority: normal severity: normal status: open title: bdist_wininst uninstaller does not remove pycache directories type: behavior versions: Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Oct 7 20:18:37 2011 From: report at bugs.python.org (Eric Snow) Date: Fri, 07 Oct 2011 18:18:37 +0000 Subject: [New-bugs-announce] [issue13124] Add "Running a Build Slave" page to the devguide Message-ID: <1318011517.56.0.343886781977.issue13124@psf.upfronthosting.co.za> New submission from Eric Snow : Here's a patch to add a page to the devguide on running a build slave. I copied pretty liberally from the wiki (http://wiki.python.org/moin/BuildBot). That page may or may not be up to date (I don't know), so the bulk of this new page may also be out of date... The current devguide buildbots page is oriented toward the use of buildbots in the dev process. In contrast, this new page is all about running one. I figured it is yet another easy way that people can contribute to Python. I didn't stick in the windows-specific buildbot info (http://wiki.python.org/moin/BuildbotOnWindows), but did link to the wiki page. I did include the info, as far as I understood it, from a recent python-dev thread (http://mail.python.org/pipermail/python-dev/2011-October/113935.html). I added a link to the devguide index page, but it may need to be shifted to the right spot (maybe right after "Running & Writing Tests"). I also renamed buildbots.rst to continuous_integration.rst (and updated reference accordingly). I want to be sure attribution is appropriate, regarding the text pulled from the wiki page and from the python-dev thread. Is linking to the thread sufficient? This is a rough stab (especially with the inclusion of the still-ongoing python-dev thread); but hopefully this gets a ball rolling and doesn't take much work to polish. :) ---------- assignee: docs at python components: Devguide, Documentation files: buildslaves.diff keywords: patch messages: 145120 nosy: brett.cannon, docs at python, eric.snow priority: normal severity: normal status: open title: Add "Running a Build Slave" page to the devguide type: feature request versions: Python 3.3 Added file: http://bugs.python.org/file23338/buildslaves.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Oct 7 20:38:13 2011 From: report at bugs.python.org (Barry A. Warsaw) Date: Fri, 07 Oct 2011 18:38:13 +0000 Subject: [New-bugs-announce] [issue13125] test_all_project_files() expected failure Message-ID: <1318012693.65.0.29583104397.issue13125@psf.upfronthosting.co.za> New submission from Barry A. Warsaw : In working on issue 11250, I noticed that lib2to3's test_parser.py tests were not enabled. Fixing that was easy enough, but then test_all_project_files() in TestParserIdempotency began failing. I've shaved enough yaks for the day so I am going to leave test_parser enabled but mark test_all_project_files() with @expectedFailure. Note that there are a number of failures here. There are two ParseErrors, one in main.py and one in pytree_idempotency.py. These both seem to fail on print(..., file=foo). After that, bom.py fails idempotency because the BOM does not show up in the converted file. ---------- components: Tests messages: 145122 nosy: barry, benjamin.peterson priority: normal severity: normal status: open title: test_all_project_files() expected failure versions: Python 3.2, Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Oct 7 21:46:36 2011 From: report at bugs.python.org (Antoine Pitrou) Date: Fri, 07 Oct 2011 19:46:36 +0000 Subject: [New-bugs-announce] [issue13126] find() slower than rfind() Message-ID: <1318016796.03.0.16031959225.issue13126@psf.upfronthosting.co.za> New submission from Antoine Pitrou : With some gcc versions, str.find() is slower than str.rfind(): - 11.22 0.0 s="ABC"*33; ((s+"D")*500+s+"E").find(s+"E") (*100) - 4.56 0.0 s="ABC"*33; ((s+"D")*500+"E"+s).find("E"+s) (*100) - 6.71 0.0 s="ABC"*33; (s+"E") in ((s+"D")*300+s+"E") (*100) - 11.22 0.0 s="ABC"*33; ((s+"D")*500+s+"E").index(s+"E") (*100) - 11.52 0.0 s="ABC"*33; ((s+"D")*500+s+"E").partition(s+"E") (*100) - 8.79 0.0 s="ABC"*33; ("E"+s+("D"+s)*500).rfind("E"+s) (*100) - 3.86 0.0 s="ABC"*33; (s+"E"+("D"+s)*500).rfind(s+"E") (*100) - 8.80 0.0 s="ABC"*33; ("E"+s+("D"+s)*500).rindex("E"+s) (*100) - 9.80 0.0 s="ABC"*33; ("E"+s+("D"+s)*500).rpartition("E"+s) (*100) - 9.83 0.0 s="ABC"*33; ("E"+s+("D"+s)*500).rsplit("E"+s, 1) (*100) - 11.56 0.0 s="ABC"*33; ((s+"D")*500+s+"E").split(s+"E", 1) (*100) Attached patch seems to fix it. ---------- components: Interpreter Core files: findperf.patch keywords: patch messages: 145136 nosy: haypo, pitrou priority: low severity: normal status: open title: find() slower than rfind() type: performance versions: Python 3.3 Added file: http://bugs.python.org/file23339/findperf.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Oct 8 06:18:12 2011 From: report at bugs.python.org (Dillon Amburgey) Date: Sat, 08 Oct 2011 04:18:12 +0000 Subject: [New-bugs-announce] [issue13127] xml.dom.Attr.name is not labeled as read-only Message-ID: <1318047492.07.0.217686953928.issue13127@psf.upfronthosting.co.za> New submission from Dillon Amburgey : http://docs.python.org/library/xml.dom.html#dom-attr-objects does not label the name attribute as read-only (like localName) even though it is. ---------- assignee: docs at python components: Documentation messages: 145155 nosy: dillona, docs at python priority: normal severity: normal status: open title: xml.dom.Attr.name is not labeled as read-only _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Oct 8 07:11:44 2011 From: report at bugs.python.org (Matt Spear) Date: Sat, 08 Oct 2011 05:11:44 +0000 Subject: [New-bugs-announce] [issue13128] httplib debuglevel on CONNECT doesn't print response headers Message-ID: <1318050704.97.0.551622649018.issue13128@psf.upfronthosting.co.za> New submission from Matt Spear : httplib with a debuglevel prints out the response headers, but does not do so with CONNECT requests (when set_tunnel is used). Attached is a small patch to print the reply when the CONNECT request returns something other than 200 OK. I'm not sure if it is worth printing the headers when a 200 OK is given. If it seems useful I can update the patch. Thanks!!! ---------- components: Library (Lib) files: httplib.py.patch keywords: patch messages: 145157 nosy: Matt.Spear priority: normal severity: normal status: open title: httplib debuglevel on CONNECT doesn't print response headers type: feature request versions: Python 2.7 Added file: http://bugs.python.org/file23342/httplib.py.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Oct 8 07:15:48 2011 From: report at bugs.python.org (rmtew) Date: Sat, 08 Oct 2011 05:15:48 +0000 Subject: [New-bugs-announce] [issue13129] bad argument exceptions observed in AST Message-ID: <1318050948.4.0.561383872922.issue13129@psf.upfronthosting.co.za> New submission from rmtew : Platform Windows 7. hg id: a3f2dba93743+ (3.2) I do not know any reproduction steps for this bug outside as a side-effect within an incomplete and problematic Stackless merge. This bug also seems to exist in cpython, and is not in Stackless specific code. It seems to be bad exception handling, but maybe I do not understand all cases where this code is used. 1. ast_error_finish is called. 2. It calls PyErr_Fetch(&type, &value, &tback); 3. It them proceeds to treat 'value' as a tuple which results in PyErr_BadInternalCall being called and then being used in place of the original exception. Reproduction steps: 1. Sync http://hg.python.org/stackless. 2. Update to 3.2-slp branch. 3. Merge in changes from v3.2.1 to v3.2.2. 4. Compile and run regression tests. 5. Several exceptions will happen along the lines of bad argument where ast exceptions have happened and hit the problem above. ---------- files: ast.diff keywords: patch messages: 145158 nosy: rmtew priority: normal severity: normal status: open title: bad argument exceptions observed in AST versions: Python 3.2 Added file: http://bugs.python.org/file23343/ast.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Oct 8 08:54:37 2011 From: report at bugs.python.org (Stefan Krah) Date: Sat, 08 Oct 2011 06:54:37 +0000 Subject: [New-bugs-announce] [issue13130] test_gdb: attempt to dereference a generic pointer Message-ID: <1318056877.65.0.853767349869.issue13130@psf.upfronthosting.co.za> New submission from Stefan Krah : The Fedora bot fails since yesterday: Breakpoint 1, builtin_id (self=, v=Traceback (most recent call last): File "/home/buildbot/buildarea/3.x.krah-fedora/build/python-gdb.py", line 1329, in to_string return pyop.get_truncated_repr(MAX_OUTPUT_LEN) File "/home/buildbot/buildarea/3.x.krah-fedora/build/python-gdb.py", line 213, in get_truncated_repr self.write_repr(out, set()) File "/home/buildbot/buildarea/3.x.krah-fedora/build/python-gdb.py", line 1199, in write_repr proxy = self.proxyval(visited) File "/home/buildbot/buildarea/3.x.krah-fedora/build/python-gdb.py", line 1166, in proxyval Py_UNICODEs = [int(field_str[i]) for i in safe_range(field_length)] RuntimeError: Attempt to dereference a generic pointer. ) at Python/bltinmodule.c:927 927 return PyLong_FromVoidPtr(v); #0 builtin_id (self=, v=Traceback (most recent call last): File "/home/buildbot/buildarea/3.x.krah-fedora/build/python-gdb.py", line 1329, in to_string return pyop.get_truncated_repr(MAX_OUTPUT_LEN) File "/home/buildbot/buildarea/3.x.krah-fedora/build/python-gdb.py", line 213, in get_truncated_repr self.write_repr(out, set()) File "/home/buildbot/buildarea/3.x.krah-fedora/build/python-gdb.py", line 1199, in write_repr proxy = self.proxyval(visited) File "/home/buildbot/buildarea/3.x.krah-fedora/build/python-gdb.py", line 1166, in proxyval Py_UNICODEs = [int(field_str[i]) for i in safe_range(field_length)] RuntimeError: Attempt to dereference a generic pointer. ) at Python/bltinmodule.c:927 #1 0x00000000004b667f in call_function (pp_stack=0x7fffffffd6e8, oparg=1) at Python/ceval.c:3988 #2 0x00000000004b0787 in PyEval_EvalFrameEx (f=Frame 0x7ffff7f409c0, for file , line 1, in (), throwflag=0) at Python/ceval.c:2625 #3 0x00000000004b44ca in PyEval_EvalCodeEx (_co=, globals={'__builtins__': , '__name__': '__main__', '__doc__': None, '__package__': None}, locals={'__builtins__': , '__name__': '__main__', '__doc__': None, '__package__': None}, args=0x0, argcount=0, kws=0x0, kwcount=0, defs=0x0, defcount=0, kwdefs=0x0, closure=0x0) at Python/ceval.c:3375 #4 0x00000000004a4668 in PyEval_EvalCode (co=, globals={'__builtins__': , '__name__': '__main__', '__doc__': None, '__package__': None}, locals={'__builtins__': , '__name__': '__main__', '__doc__': None, '__package__': None}) at Python/ceval.c:770 #5 0x00000000004edc20 in run_mod (mod=0x9b0560, filename=0x619622 "", globals={'__builtins__': , '__name__': '__main__', '__doc__': None, '__package__': None}, locals={'__builtins__': , '__name__': '__main__', '__doc__': None, '__package__': None}, flags=0x7fffffffe3c0, arena=0x92e070) at Python/pythonrun.c:1795 #6 0x00000000004ed91e in PyRun_StringFlags (str=0x7ffff10e1418 "id('\\U0001d121')\n", start=257, globals={'__builtins__': , '__name__': '__main__', '__doc__': None, '__package__': None}, locals={'__builtins__': , '__name__': '__main__', '__doc__': None, '__package__': None}, flags=0x7fffffffe3c0) at Python/pythonrun.c:1729 #7 0x00000000004ebfb6 in PyRun_SimpleStringFlags (command=0x7ffff10e1418 "id('\\U0001d121')\n", flags=0x7fffffffe3c0) at Python/pythonrun.c:1302 #8 0x000000000050b41f in run_command (command=0x8e0500 L"id('\\U0001d121')\n", cf=0x7fffffffe3c0) at Modules/main.c:260 #9 0x000000000050bf70 in Py_Main (argc=4, argv=0x7ffff7faf040) at Modules/main.c:634 #10 0x0000000000416e97 in main (argc=4, argv=0x7fffffffe5a8) at ./Modules/python.c:59 ---------- components: Tests messages: 145161 nosy: haypo, loewis, skrah priority: normal severity: normal stage: needs patch status: open title: test_gdb: attempt to dereference a generic pointer type: behavior versions: Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Oct 8 14:25:53 2011 From: report at bugs.python.org (Valery Khamenya) Date: Sat, 08 Oct 2011 12:25:53 +0000 Subject: [New-bugs-announce] [issue13131] FD leak in urllib2 Message-ID: <1318076753.32.0.0530567720617.issue13131@psf.upfronthosting.co.za> New submission from Valery Khamenya : Explanation from dablitz's comment at https://bugs.pypy.org/issue867 : urllib2 in the stdlib leaks fd's if an exception is raised while opening a connection. The issue occurs due to a socket being opened then an exception being raised before an object with the socket is returned, leaving no way to explicitly close the object. On cpython this would not be an issue as the object would lose all references almost immediately however it lingers around with a proper GC causing FD's to build up if the same condition happens repeatedly (eg a loop/web crawling) The file enclosed is a script to generate the leakage, to run invok it as follows leak.py pypy should start leaking FD's and can be see in /proc//fd Related issues: http://bugs.python.org/issue3066 http://bugs.python.org/issue1208304 http://bugs.python.org/issue1601399 ---------- components: IO, Library (Lib) files: leak.py messages: 145166 nosy: Valery.Khamenya priority: normal severity: normal status: open title: FD leak in urllib2 type: resource usage versions: Python 2.7 Added file: http://bugs.python.org/file23344/leak.py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Oct 8 16:56:28 2011 From: report at bugs.python.org (Mitchell Hashimoto) Date: Sat, 08 Oct 2011 14:56:28 +0000 Subject: [New-bugs-announce] [issue13132] distutils sends non-RFC compliant HTTP request Message-ID: <1318085788.89.0.459164084672.issue13132@psf.upfronthosting.co.za> New submission from Mitchell Hashimoto : In ``Lib/distutils/command/register.py`` as well as ``upload.py``, the following code exists to build the HTTP request body to send to the cheese shop server: body.write('\nContent-Disposition: form-data; name="%s"'%key) body.write("\n\n") RFC2616 page 31 (http://tools.ietf.org/html/rfc2616#page-31) states that headers must be separated by CRLF. Specifically, the above "\n\n" for the header separator is causing issues with some minimal RFC-compliant web servers. ---------- assignee: tarek components: Distutils messages: 145171 nosy: eric.araujo, mitchellh, tarek priority: normal severity: normal status: open title: distutils sends non-RFC compliant HTTP request versions: Python 2.6, Python 2.7, Python 3.1, Python 3.2, Python 3.3, Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Oct 8 20:48:55 2011 From: report at bugs.python.org (Valery Khamenya) Date: Sat, 08 Oct 2011 18:48:55 +0000 Subject: [New-bugs-announce] [issue13133] FD leaks in ZipFile.read(), ZipFile.extract() and also using explicit arc_member.close() Message-ID: <1318099735.4.0.121973105523.issue13133@psf.upfronthosting.co.za> New submission from Valery Khamenya : The attached file reproduces 3 types of FD leaks and leads to the error like: IOError: [Errno 24] Too many open files: '/tmp/1019' For example if executed with pypy. ---------- components: IO, Library (Lib) files: zipfiletest.py messages: 145182 nosy: Valery.Khamenya priority: normal severity: normal status: open title: FD leaks in ZipFile.read(), ZipFile.extract() and also using explicit arc_member.close() type: resource usage versions: Python 2.7 Added file: http://bugs.python.org/file23347/zipfiletest.py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Oct 8 22:29:04 2011 From: report at bugs.python.org (Antoine Pitrou) Date: Sat, 08 Oct 2011 20:29:04 +0000 Subject: [New-bugs-announce] [issue13134] speed up finding of one-character strings Message-ID: <1318105744.0.0.664183527644.issue13134@psf.upfronthosting.co.za> New submission from Antoine Pitrou : In stringlib/fastsearch, instead of using our own loops, we can use memchr() (and, if available, memrchr()) when looking for one-character strings. memchr() is generally quite optimized; on this Linux/glibc machine, I get speedups of 5x-10x: ./python -m timeit -s "large='a'*10000+'b'" "large.find('b')" -> before: 10.5 usec per loop -> after: 0.889 usec per loop ./python -m timeit -s "large='b'+'a'*10000" "large.rfind('b')" -> before: 7.06 usec per loop -> after: 1.94 usec per loop ---------- components: Interpreter Core messages: 145186 nosy: haypo, loewis, pitrou priority: normal severity: normal status: open title: speed up finding of one-character strings type: performance versions: Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Oct 8 23:53:38 2011 From: report at bugs.python.org (Marty Alchin) Date: Sat, 08 Oct 2011 21:53:38 +0000 Subject: [New-bugs-announce] [issue13135] Using type() as a constructor doesn't support new class keyword arguments Message-ID: <1318110818.93.0.631665925826.issue13135@psf.upfronthosting.co.za> New submission from Marty Alchin : PEP 3115 introduced keyword arguments to class definitions and changed metaclasses to use them instead. Unfortunately, `type()` doesn't seem to have been updated to accept those keyword arguments as well. What this amounts to is that using `type()` as a constructor can no longer fully replicate the behavior of a class definition. Therefore, classes that use keyword arguments can't be created dynamically. I would attempt a patch, but I don't have a development environment capable of compiling Python, so I wouldn't have any chance to test it. ---------- messages: 145190 nosy: gulopine priority: normal severity: normal status: open title: Using type() as a constructor doesn't support new class keyword arguments type: feature request _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Oct 9 00:18:31 2011 From: report at bugs.python.org (Antoine Pitrou) Date: Sat, 08 Oct 2011 22:18:31 +0000 Subject: [New-bugs-announce] [issue13136] speed-up conversion between unicode widths Message-ID: <1318112311.49.0.66949742663.issue13136@psf.upfronthosting.co.za> New submission from Antoine Pitrou : This patch speeds up _PyUnicode_CONVERT_BYTES by unrolling its loop. Example micro-benchmark: ./python -m timeit -s "a='x'*10000;b='\u0102'*1000;c='\U00100000'" "a+b+c" -> before: 100000 loops, best of 3: 14.9 usec per loop -> after: 100000 loops, best of 3: 9.19 usec per loop ---------- components: Interpreter Core files: unroll_convert_bytes.patch keywords: patch messages: 145192 nosy: pitrou priority: normal severity: normal stage: patch review status: open title: speed-up conversion between unicode widths type: performance versions: Python 3.3 Added file: http://bugs.python.org/file23351/unroll_convert_bytes.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Oct 9 00:58:37 2011 From: report at bugs.python.org (Blair) Date: Sat, 08 Oct 2011 22:58:37 +0000 Subject: [New-bugs-announce] [issue13137] from __future__ import division breaks ad hoc numeric types Message-ID: <1318114717.45.0.0615506676272.issue13137@psf.upfronthosting.co.za> New submission from Blair : I believe that the use of __future__.division may have unintended consequences with user types that define division. The following fails: from __future__ import division class NumericType(object): def __init__(self,x): self.x = x def __div__(self,rhs): return self.x/rhs print NumericType(3.0) / 2.0 with the error message File "C:\proj_py\learning\future_bug\future.py", line 10, in print NumericType(3.0) / 2.0 TypeError: unsupported operand type(s) for /: 'NumericType' and 'float' Remove the line `from __future__ import division` and everything works fine. I am using Python 2.7.2 ---------- components: None messages: 145195 nosy: gumtree priority: normal severity: normal status: open title: from __future__ import division breaks ad hoc numeric types type: behavior versions: Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Oct 9 02:49:32 2011 From: report at bugs.python.org (=?utf-8?q?Andreas_St=C3=BChrk?=) Date: Sun, 09 Oct 2011 00:49:32 +0000 Subject: [New-bugs-announce] [issue13138] ElementTree's Element.iter() lacks versionadded Message-ID: <1318121372.98.0.459756814836.issue13138@psf.upfronthosting.co.za> New submission from Andreas St?hrk : See http://docs.python.org/whatsnew/2.7.html#updated-module-elementtree-1-3 ---------- assignee: docs at python components: Documentation files: Element_iter_versionadded.patch keywords: patch messages: 145199 nosy: Trundle, docs at python priority: normal severity: normal status: open title: ElementTree's Element.iter() lacks versionadded versions: Python 2.7 Added file: http://bugs.python.org/file23352/Element_iter_versionadded.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Oct 9 04:05:47 2011 From: report at bugs.python.org (Daniel Wagner-Hall) Date: Sun, 09 Oct 2011 02:05:47 +0000 Subject: [New-bugs-announce] [issue13139] multiprocessing.map skips finally blocks Message-ID: <1318125947.15.0.13973515193.issue13139@psf.upfronthosting.co.za> New submission from Daniel Wagner-Hall : import random from multiprocessing import Pool from time import sleep def Process(x): try: print x sleep(random.random()) raise Exception('Exception: ' + x) finally: print 'Finally: ' + x Pool(3).map(Process, ['1','2','3']) Expect all three Finally blocks to be called (or at least, one Finally per x printed by line 8) Actually, only one (occasionally two) are printed. Same behaviour exhibited on dual-core Mac running OSX 10.6 with Python 2.7, and single core Ubuntu running Python 2.6. ---------- components: None messages: 145201 nosy: illicitonion priority: normal severity: normal status: open title: multiprocessing.map skips finally blocks type: behavior versions: Python 2.6, Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Oct 9 22:18:45 2011 From: report at bugs.python.org (Florent Xicluna) Date: Sun, 09 Oct 2011 20:18:45 +0000 Subject: [New-bugs-announce] [issue13140] ThreadingMixIn.daemon_threads is not honored when parent is daemon Message-ID: <1318191525.3.0.322601594247.issue13140@psf.upfronthosting.co.za> New submission from Florent Xicluna : I use the socketserver.ThreadingMixIn to create a TCPServer. I set the server thread as daemon (t.daemon=True). But I want the client threads to run as non-daemon. According to the documentation, the "daemon_threads" class attribute should do the trick. But it fails: if server is daemon, the clients are daemon too, even if daemon_threads=False. Demo attached. ---------- components: Library (Lib) files: test_socketserver.py messages: 145273 nosy: flox priority: normal severity: normal stage: needs patch status: open title: ThreadingMixIn.daemon_threads is not honored when parent is daemon type: behavior versions: Python 2.6, Python 2.7, Python 3.2, Python 3.3 Added file: http://bugs.python.org/file23361/test_socketserver.py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Oct 9 22:37:07 2011 From: report at bugs.python.org (Florent Xicluna) Date: Sun, 09 Oct 2011 20:37:07 +0000 Subject: [New-bugs-announce] [issue13141] get rid of old threading API in the examples Message-ID: <1318192627.46.0.311858462486.issue13141@psf.upfronthosting.co.za> New submission from Florent Xicluna : http://docs.python.org/dev/library/socketserver.html#asynchronous-mixins Still there's getName or setDaemon in some example. ---------- assignee: docs at python components: Documentation messages: 145274 nosy: docs at python, flox priority: low severity: normal stage: needs patch status: open title: get rid of old threading API in the examples type: behavior versions: Python 2.7, Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Oct 10 00:26:17 2011 From: report at bugs.python.org (Patrick Westerhoff) Date: Sun, 09 Oct 2011 22:26:17 +0000 Subject: [New-bugs-announce] [issue13142] Add support for other HTTP methods in urllib.request Message-ID: <1318199177.09.0.985752068879.issue13142@psf.upfronthosting.co.za> New submission from Patrick Westerhoff : Hey, I would like to request the support of other HTTP methods (other than GET and POST) in urllib.request. While it?s actually simple enough to override the Request class to add such a possibility, I think it is far too simple to leave it out of the standard library. I?ve attached a patch that adds the functionality with a simple `method` property. The `get_method` function then simply looks if a custom method was entered, and otherwise falls back to the default behaviour. Thanks a lot! Patrick Westerhoff Btw. Being a Git user, I hope the patch is actually useful ;) ---------- components: Library (Lib) files: urllib.patch keywords: patch messages: 145283 nosy: poke priority: normal severity: normal status: open title: Add support for other HTTP methods in urllib.request type: feature request versions: Python 3.2, Python 3.3, Python 3.4 Added file: http://bugs.python.org/file23362/urllib.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Oct 10 06:35:03 2011 From: report at bugs.python.org (Garen) Date: Mon, 10 Oct 2011 04:35:03 +0000 Subject: [New-bugs-announce] [issue13143] os.path.islink documentation is ambiguous Message-ID: <1318221303.29.0.86938915547.issue13143@psf.upfronthosting.co.za> New submission from Garen : The documentation for os.path.islink says: "Return True if path refers to a directory entry that is a symbolic link. Always False if symbolic links are not supported." But what does "supported" mean? "Supported" by what? Supported by the OS, or supported by the Python runtime? Because clearly there is a difference, which surprised me: PythonWin 2.7.2 (default, Jun 24 2011, 12:21:10) [MSC v.1500 32 bit (Intel)] on win32. Portions Copyright 1994-2008 Mark Hammond - see 'Help/About PythonWin' for further copyright information. >>> import os >>> os.path.islink(r"C:\Users\Garen\dev\pypy.exe") False >>> os.path.islink(r"C:\Users\Garen\dev\abspypy.exe") False Whereas if I use 3.2.x, I get the right answers: ActivePython 3.2.2.3 (ActiveState Software Inc.) based on Python 3.2.2 (default, Sep 8 2011, 10:56:38) [MSC v.1500 32 bit (Intel)] on win32 Type "copyright", "credits" or "license()" for more information. >>> import os >>> os.path.islink(r"C:\Users\Garen\dev\pypy.exe") True >>> os.path.islink(r"C:\Users\Garen\dev\abspypy.exe") True An additional surprise is that in other places of the Python runtime, if functionality is not implemented for Windows, an exception of type NotImplementedError is raised--but not in this case with os.path.islink(). This all makes it a hairy mess to properly detect symlinks--from the client code perspective, now one has to check for specific versions of python, specific versions of Windows, and possibly which file-system is being used (FAT vs NTFS) just to be able to determine if islink() is silently failing or not. After which the client side will want to add clarifying comments to compensate for what's missing from the official docs (as opposed to posting a link to the docs in a comment). As a user from the client side, I would only expect os.path.islink() to return False if the underlying OS/filesystem didn't support symlinks; if the underlying OS/filesystem did suport symlinks but support was missing, I'd expect to see a NoteImplementedError raised. In any case, where behavior for os.path.islink() (and related routines) deviates from the above pattern, I'd expect documentation that indicates what those deviations are--in this case, that False means unsupported by the Python runtime regardless of whether the OS/filesystem provides that functionality. ---------- messages: 145290 nosy: Garen priority: normal severity: normal status: open title: os.path.islink documentation is ambiguous versions: Python 2.7, Python 3.2 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Oct 10 14:16:08 2011 From: report at bugs.python.org (Graeme Glass) Date: Mon, 10 Oct 2011 12:16:08 +0000 Subject: [New-bugs-announce] [issue13144] Global Module Index link in the offline documentation is incorrect Message-ID: <1318248968.6.0.0439422849007.issue13144@psf.upfronthosting.co.za> New submission from Graeme Glass : On my machine (Ubuntu 11.04) the link to "Python Module Index" from the index page is incorrect in the "Indices and tables" section (it links to modindex.html instead of py-modindex.html). It links to the correct place in the navigation bar at the top right of the page. Navigation (Correct):
  • modules |
    • In the body (Incorrect):

    Indices and tables:

    ...

    Global Module Index
    _______________________________________ From report at bugs.python.org Mon Oct 10 15:26:15 2011 From: report at bugs.python.org (Sven Marnach) Date: Mon, 10 Oct 2011 13:26:15 +0000 Subject: [New-bugs-announce] [issue13145] Documentation of PyNumber_ToBase() wrong Message-ID: <1318253175.42.0.981988907278.issue13145@psf.upfronthosting.co.za> New submission from Sven Marnach : The documentation of PyNumber_ToBase() [1] states When base is not 2, 8, 10, or 16, the format is 'x#num' where x is the base. In reality, the function does not accept any bases different from 2, 8, 10, or 16, as can be seen in the source code of _PyLong_Form() [2], which is called from PyNumber_ToBase() to do the actual conversion. The patch fixes the documentation. [1]: http://docs.python.org/c-api/number.html#PyNumber_ToBase [2]: http://hg.python.org/cpython/file/f924e0f62bcb/Objects/longobject.c#l1663 ---------- assignee: docs at python components: Documentation files: pynumber-tobase-doc.patch keywords: patch messages: 145297 nosy: docs at python, smarnach priority: normal severity: normal status: open title: Documentation of PyNumber_ToBase() wrong Added file: http://bugs.python.org/file23367/pynumber-tobase-doc.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Oct 10 21:37:55 2011 From: report at bugs.python.org (Antoine Pitrou) Date: Mon, 10 Oct 2011 19:37:55 +0000 Subject: [New-bugs-announce] [issue13146] Writing a pyc file is not atomic Message-ID: <1318275475.02.0.82335017062.issue13146@psf.upfronthosting.co.za> New submission from Antoine Pitrou : One of the buildbots recently showed the following failure: ====================================================================== ERROR: test_rapid_restart (test.test_multiprocessing.WithProcessesTestManagerRestart) ---------------------------------------------------------------------- Traceback (most recent call last): File "/var/lib/buildslave/3.x.murray-gentoo/build/Lib/test/test_multiprocessing.py", line 1442, in test_rapid_restart queue = manager.get_queue() File "/var/lib/buildslave/3.x.murray-gentoo/build/Lib/multiprocessing/managers.py", line 670, in temp token, exp = self._create(typeid, *args, **kwds) File "/var/lib/buildslave/3.x.murray-gentoo/build/Lib/multiprocessing/managers.py", line 568, in _create conn = self._Client(self._address, authkey=self._authkey) File "/var/lib/buildslave/3.x.murray-gentoo/build/Lib/multiprocessing/connection.py", line 778, in XmlClient import xmlrpc.client as xmlrpclib File "/var/lib/buildslave/3.x.murray-gentoo/build/Lib/xmlrpc/client.py", line 137, in import http.client File "/var/lib/buildslave/3.x.murray-gentoo/build/Lib/http/client.py", line 69, in import email.parser File "/var/lib/buildslave/3.x.murray-gentoo/build/Lib/email/parser.py", line 12, in from email.feedparser import FeedParser File "/var/lib/buildslave/3.x.murray-gentoo/build/Lib/email/feedparser.py", line 28, in from email import policy EOFError: EOF read where not expected (http://www.python.org/dev/buildbot/all/builders/x86%20Gentoo%203.x/builds/942/steps/test/logs/stdio) "EOF read where not expected" comes from reading a pyc file in marshal.c. It is raised when the pyc file is somehow truncated or incomplete. Writing and reading the same pyc file is protected by the import lock when in a single interpreter, but not when running several Python processes at the same time (which test_multiprocessing obviously does). Under POSIX, import.c could do the traditional write-then-rename dance which guarantees that the file contents appear atomically. And so could importlib. ---------- components: Interpreter Core messages: 145313 nosy: brett.cannon, ncoghlan, pitrou, r.david.murray priority: normal severity: normal status: open title: Writing a pyc file is not atomic type: behavior versions: Python 2.7, Python 3.2, Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Oct 11 01:37:50 2011 From: report at bugs.python.org (Jakub Gedeon) Date: Mon, 10 Oct 2011 23:37:50 +0000 Subject: [New-bugs-announce] [issue13147] Multiprocessing Pool.map_async() does not have an error_callback parameter Message-ID: <1318289870.89.0.681252830912.issue13147@psf.upfronthosting.co.za> New submission from Jakub Gedeon : Multiprocessing Pool.map_async() does not have an error_callback paramter as described here http://docs.python.org/library/multiprocessing.html#multiprocessing.pool.multiprocessing.Pool.map_async I assume this is an old configuration that no longer works... I tried to call that parameter by name and I got a Type Error, plus the actual documentation does not mention it at all (and it is missing from similar functions). Recommend it be removed from the documentation, or else better described and implemented. ---------- assignee: docs at python components: Documentation messages: 145316 nosy: Jakub.Gedeon, docs at python priority: normal severity: normal status: open title: Multiprocessing Pool.map_async() does not have an error_callback parameter versions: Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Oct 11 02:45:48 2011 From: report at bugs.python.org (Maxim Yanchenko) Date: Tue, 11 Oct 2011 00:45:48 +0000 Subject: [New-bugs-announce] [issue13148] simple bug in mmap size check Message-ID: <1318293948.21.0.819256952944.issue13148@psf.upfronthosting.co.za> New submission from Maxim Yanchenko : The condition contradicts the exception text: if (offset >= st.st_size) { PyErr_SetString(PyExc_ValueError, "mmap offset is greater than file size"); return NULL; } The condition should be changed to (offset > st.st_size), similar to the later condition which is correct: } else if (offset + (size_t)map_size > st.st_size) { PyErr_SetString(PyExc_ValueError, "mmap length is greater than file size"); return NULL; } The patch is attached. ---------- components: Library (Lib) files: mmap-greater.patch keywords: patch messages: 145319 nosy: jazzer priority: normal severity: normal status: open title: simple bug in mmap size check type: behavior versions: Python 2.7 Added file: http://bugs.python.org/file23372/mmap-greater.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Oct 11 03:17:34 2011 From: report at bugs.python.org (Antoine Pitrou) Date: Tue, 11 Oct 2011 01:17:34 +0000 Subject: [New-bugs-announce] [issue13149] optimization for append-only StringIO Message-ID: <1318295854.61.0.959309073941.issue13149@psf.upfronthosting.co.za> New submission from Antoine Pitrou : io.StringIO is quite slower than ''.append() when used for mass concatenation (around 5x slower). This patch brings it to similar performance by deferring construction of the internal buffer until needed. The problem is that it's very easy to disable the optimization by calling a method other than write() and getvalue(). ---------- components: IO files: stringio.patch keywords: patch messages: 145322 nosy: haypo, pitrou priority: normal severity: normal status: open title: optimization for append-only StringIO type: performance versions: Python 3.3 Added file: http://bugs.python.org/file23373/stringio.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Oct 11 05:02:58 2011 From: report at bugs.python.org (Antoine Pitrou) Date: Tue, 11 Oct 2011 03:02:58 +0000 Subject: [New-bugs-announce] [issue13150] Most of Python's startup time is sysconfig Message-ID: <1318302178.08.0.514256961817.issue13150@psf.upfronthosting.co.za> New submission from Antoine Pitrou : sysconfig is imported and used by site.py. $ time ./python -S -c '' real 0m0.019s user 0m0.013s sys 0m0.005s $ time ./python -S -c 'import sysconfig' real 0m0.047s user 0m0.046s sys 0m0.002s $ time ./python -S -c 'import sysconfig; sysconfig.get_path("purelib")' real 0m0.053s user 0m0.047s sys 0m0.005s $ time ./python -c '' real 0m0.058s user 0m0.054s sys 0m0.003s ---------- messages: 145328 nosy: eric.araujo, ncoghlan, pitrou, tarek, terry.reedy priority: normal severity: normal status: open title: Most of Python's startup time is sysconfig type: performance versions: Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Oct 11 13:12:18 2011 From: report at bugs.python.org (Vinay Sajip) Date: Tue, 11 Oct 2011 11:12:18 +0000 Subject: [New-bugs-announce] [issue13151] pysetup3 run bdist_wininst fails Message-ID: <1318331538.35.0.635641564623.issue13151@psf.upfronthosting.co.za> New submission from Vinay Sajip : When you run pysetup3 run bdist_wininst in a project directory with a valid setup.cfg, it fails with error: Invalid command install after the build, build_py and build_scripts steps. For info, pysetup3 run bdist_dumb runs without error. ---------- assignee: tarek components: Distutils2, Library (Lib) messages: 145339 nosy: alexis, eric.araujo, tarek, vinay.sajip priority: normal severity: normal status: open title: pysetup3 run bdist_wininst fails versions: Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Oct 11 15:05:00 2011 From: report at bugs.python.org (John Feuerstein) Date: Tue, 11 Oct 2011 13:05:00 +0000 Subject: [New-bugs-announce] [issue13152] textwrap: support custom tabsize Message-ID: <1318338300.67.0.514985359705.issue13152@psf.upfronthosting.co.za> New submission from John Feuerstein : The textwrap module calls .expandtabs() to expand tabs to spaces. This patch adds support for a custom tabsize, so that .expandtabs(tabsize) is called instead. Includes test case. ---------- components: Library (Lib) files: textwrap_tabsize.diff keywords: patch messages: 145341 nosy: jfeuerstein priority: normal severity: normal status: open title: textwrap: support custom tabsize type: feature request versions: Python 3.3 Added file: http://bugs.python.org/file23376/textwrap_tabsize.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Oct 11 22:01:32 2011 From: report at bugs.python.org (=?utf-8?q?Jo=C3=A3o_Bernardo?=) Date: Tue, 11 Oct 2011 20:01:32 +0000 Subject: [New-bugs-announce] [issue13153] IDLE crash with unicode bigger than 0xFFFF Message-ID: <1318363292.9.0.682519731008.issue13153@psf.upfronthosting.co.za> New submission from Jo?o Bernardo : I was playing with some unicode chars on Python 3.2 (x64 on Windows 7), but when pasted a char bigger than 0xFFFF, IDLE crashes without any error message. Example (works fine): >>> '\U000104a2' '?' But, if I try to paste the above char, the window will instantly close. The interpreter uses 2-bytes per char (UTF-16) and I don't know if that's causing the problem (as side note, why don't the default Windows build uses 4-bytes char?). I can't check now with my Ubuntu install (UTF-32) if the problem persists. ---------- components: IDLE, Unicode, Windows messages: 145363 nosy: JBernardo priority: normal severity: normal status: open title: IDLE crash with unicode bigger than 0xFFFF versions: Python 3.2 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Oct 11 23:55:08 2011 From: report at bugs.python.org (Antoine Pitrou) Date: Tue, 11 Oct 2011 21:55:08 +0000 Subject: [New-bugs-announce] [issue13154] pep-0000.txt doesn't build anymore Message-ID: <1318370108.79.0.613915208631.issue13154@psf.upfronthosting.co.za> New submission from Antoine Pitrou : $ make make: D?pendance circulaire pep-0000.txt <- pep-0000.txt abandonn?e. python genpepindex.py . Traceback (most recent call last): File "genpepindex.py", line 67, in main(sys.argv) File "genpepindex.py", line 64, in main write_pep0(peps, pep0_file) File "/home/antoine/cpython/peps/pep0/output.py", line 195, in write_pep0 authors_dict = verify_email_addresses(peps) File "/home/antoine/cpython/peps/pep0/output.py", line 104, in verify_email_addresses "listed:\n" + '\n'.join(err_output)) ValueError: some authors have more than one email address listed: Gregory Ewing: [u'greg at cosc.canterbury.ac.nz', u'greg.ewing at canterbury.ac.nz'] make: *** [pep-0000.txt] Erreur 1 ---------- assignee: docs at python components: Documentation messages: 145370 nosy: docs at python, pitrou priority: normal severity: normal status: open title: pep-0000.txt doesn't build anymore type: compile error _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Oct 12 01:14:19 2011 From: report at bugs.python.org (Antoine Pitrou) Date: Tue, 11 Oct 2011 23:14:19 +0000 Subject: [New-bugs-announce] [issue13155] Optimize finding the max character width Message-ID: <1318374859.38.0.809726887697.issue13155@psf.upfronthosting.co.za> New submission from Antoine Pitrou : This patch optimizes scanning for the max character width in an unicode buffer. Micro-benchmarking some worst case situations: $ ./python -m timeit -s "x='?'+'x'*100000" "x[1:]" -> before: 10000 loops, best of 3: 74.9 usec per loop -> after: 100000 loops, best of 3: 15.5 usec per loop $ ./python -m timeit -s "x='\U00010000'+'x'*100000" "x[1:]" -> before: 10000 loops, best of 3: 138 usec per loop -> after: 10000 loops, best of 3: 71.3 usec per loop ---------- components: Interpreter Core files: find_max_char.patch keywords: patch messages: 145372 nosy: pitrou priority: normal severity: normal status: open title: Optimize finding the max character width type: performance versions: Python 3.3 Added file: http://bugs.python.org/file23379/find_max_char.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Oct 12 08:33:47 2011 From: report at bugs.python.org (Graham Dumpleton) Date: Wed, 12 Oct 2011 06:33:47 +0000 Subject: [New-bugs-announce] [issue13156] _PyGILState_Reinit assumes auto thread state will always exist which is not true. Message-ID: <1318401227.21.0.161699609918.issue13156@psf.upfronthosting.co.za> New submission from Graham Dumpleton : This is a followup bug report to fix wrong implementation of _PyGILState_Reinit() introduced by http://bugs.python.org/issue10517. I don't have a standalone test case yet. Problem occurs under mod_wsgi with Python 2.7.2 and thus similarly 3.2 where _PyGILState_Reinit() was also added. The Python code part which triggers the problem is: pid = os.fork() if pid: sys.stderr.write('Fork succeeded (PID=%s)\n' % pid) else: sys.stderr.write('Fork succeeded (child PID=%s)\n' % os.getpid()) time.sleep(60.0) os._exit(0) To trigger the problem requires this code be executed from a thread originally created outside of Python and then calling into a sub interpreter. This thread would have created its own thread state object for the sub interpreter call since auto thread states don't work for sub interpreters. Further, it would never have called into the main interpreter so auto thread state simply doesn't exist for main interpreter. When this thread has a fork() occur and _PyGILState_Reinit() is called, the call of PyGILState_GetThisThreadState() returns NULL because auto thread state for main interpreter was never initialised for this thread. When it then calls into PyThread_set_key_value() it is value of NULL and rather than set it, it thinks internally in find_key() you are doing a get which results in PyThread_set_key_value() returning -1 and so the fatal error. So _PyGILState_Reinit() is broken because it assumes that an auto thread state will always exist for the thread for it to reinit, which will not always be the case. The simple fix may be that if PyGILState_GetThisThreadState() returns NULL then don't do any reinit. Making that change does seem to fix the problem. Code that works then is: void _PyGILState_Reinit(void) { PyThreadState *tstate = PyGILState_GetThisThreadState(); if (tstate) { PyThread_delete_key(autoTLSkey); if ((autoTLSkey = PyThread_create_key()) == -1) Py_FatalError("Could not allocate TLS entry"); /* re-associate the current thread state with the new key */ if (PyThread_set_key_value(autoTLSkey, (void *)tstate) < 0) Py_FatalError("Couldn't create autoTLSkey mapping"); } } Diff file also attached. ---------- components: Extension Modules files: pystate.c.diff keywords: patch messages: 145383 nosy: grahamd, neologix priority: normal severity: normal status: open title: _PyGILState_Reinit assumes auto thread state will always exist which is not true. type: crash versions: Python 2.7, Python 3.2 Added file: http://bugs.python.org/file23385/pystate.c.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Oct 12 14:06:07 2011 From: report at bugs.python.org (STINNER Victor) Date: Wed, 12 Oct 2011 12:06:07 +0000 Subject: [New-bugs-announce] [issue13157] Build Python outside the source directory Message-ID: <1318421167.12.0.301144955548.issue13157@psf.upfronthosting.co.za> New submission from STINNER Victor : It is no more possible to build Python outside its source directory. Try using: cd mkdir release cd release ../configure make Attached patch should fix this issue. ---------- files: build.patch keywords: patch messages: 145392 nosy: haypo, loewis, neologix, pitrou priority: normal severity: normal status: open title: Build Python outside the source directory versions: Python 3.3 Added file: http://bugs.python.org/file23386/build.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Oct 12 14:54:32 2011 From: report at bugs.python.org (Sebastien Binet) Date: Wed, 12 Oct 2011 12:54:32 +0000 Subject: [New-bugs-announce] [issue13158] tarfile.TarFile.getmembers misses some entries Message-ID: <1318424072.71.0.575626132028.issue13158@psf.upfronthosting.co.za> New submission from Sebastien Binet : hi there, it seems tarfile in python 3.2.2 (as installed in archlinux, but I don't see any additional patch applied on top of the vanilla sources: http://projects.archlinux.org/svntogit/packages.git/tree/trunk/PKGBUILD?h=packages/python ) has troubles giving the complete content of a tar ball. see: $ wget http://downloads.sourceforge.net/sourceforge/boost/boost_1_44_0.tar.gz $ md5sum boost_1_44_0.tar.gz 085fce4ff2089375105d72475d730e15 boost_1_44_0.tar.gz $ python --version Python 3.2.2 $ python2 --version Python 2.7.2 $ python ./foo.py >>> 8145 $ python2 ./foo.py >>> 33635 where foo.py is: ## import tarfile o = tarfile.open("boost_1_44_0.tar.gz") print(">>> %s" % len(o.getmembers())) o.close() ## EOF ## is it a known bug ? (this of course prevents TarFile.extractall to be useful w/ python3...) -s ---------- messages: 145393 nosy: bins priority: normal severity: normal status: open title: tarfile.TarFile.getmembers misses some entries type: behavior versions: Python 3.2 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Oct 12 18:02:00 2011 From: report at bugs.python.org (Nadeem Vawda) Date: Wed, 12 Oct 2011 16:02:00 +0000 Subject: [New-bugs-announce] [issue13159] _io.FileIO uses a quadratic-time buffer growth algorithm Message-ID: <1318435320.7.0.151419273993.issue13159@psf.upfronthosting.co.za> New submission from Nadeem Vawda : As mentioned in issue 6715, the buffer growth strategy used by _io.FileIO has quadratic running time if each reallocation is O(n). The code in question is new_buffersize() from Modules/_io/fileio.c: if (currentsize > SMALLCHUNK) { /* Keep doubling until we reach BIGCHUNK; then keep adding BIGCHUNK. */ if (currentsize <= BIGCHUNK) return currentsize + currentsize; else return currentsize + BIGCHUNK; } return currentsize + SMALLCHUNK; Is there a reason for this? One possible improvement would be to instead use the same formula as list.resize() in Objects/listobject.c: new_allocated = (newsize >> 3) + (newsize < 9 ? 3 : 6); which has amortized O(n) running time behaviour. Your thoughts? ---------- components: IO messages: 145403 nosy: benjamin.peterson, nadeem.vawda, pitrou, stutzbach priority: normal severity: normal stage: needs patch status: open title: _io.FileIO uses a quadratic-time buffer growth algorithm type: performance versions: Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Oct 12 18:19:54 2011 From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=) Date: Wed, 12 Oct 2011 16:19:54 +0000 Subject: [New-bugs-announce] [issue13160] Rename install_dist to install Message-ID: <1318436394.33.0.345868937694.issue13160@psf.upfronthosting.co.za> New submission from ?ric Araujo : When we first added actions to pysetup, the install command was renamed to install_dist to avoid a name conflict between the install command and the install action. Later, the run action was introduced and now serves to namespace all commands. Thus, we have no conflict anymore. I would like to restore the original name of the install command, for distutils compat: people used to d1 build/install will get the same name, and the section in config files (which are currently compatible with d1 and d2, except for install_dist) will share the same name again (letting people give options in [install], not [install] and [install_dist]). ---------- assignee: eric.araujo components: Distutils2 messages: 145408 nosy: alexis, eric.araujo priority: normal severity: normal status: open title: Rename install_dist to install versions: 3rd party, Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Oct 12 18:22:23 2011 From: report at bugs.python.org (Eli Bendersky) Date: Wed, 12 Oct 2011 16:22:23 +0000 Subject: [New-bugs-announce] [issue13161] problems with help() documentation of __i*__ operators Message-ID: <1318436543.45.0.46958950416.issue13161@psf.upfronthosting.co.za> New submission from Eli Bendersky : Report from Joao Carneiro in the docs@ maillist: ---------------------------- I would like to report that I found a mistake in the document of "help(set)". In the document all the __i*__ methods are described exactly like the same methods without i before the name. Copied from the document: __ixor__(...) x.__ixor__(y) <==> x^y __xor__(...) x.__xor__(y) <==> x^y I suppose that the __ixor__ would mean x^=y and not x^y like the __xor__ method right? This problem also occurs for: __iand__ __ior__ __isub__ ---------------------------- The report is on Python 3.2, but the problem also exists in 2.7 It appears that the problem's source is in Objects/typeobject.c, where the __i*__ operators are defined with the IBSLOT macro. The documentation string is the operator, passed to IBSLOT - for __ixor__ it's "^", while it should probably be "^=" ---------- assignee: docs at python components: Documentation messages: 145411 nosy: docs at python, eli.bendersky priority: normal severity: normal status: open title: problems with help() documentation of __i*__ operators versions: Python 2.7, Python 3.2, Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Oct 13 00:35:20 2011 From: report at bugs.python.org (Paul Moore) Date: Wed, 12 Oct 2011 22:35:20 +0000 Subject: [New-bugs-announce] [issue13162] Trying to install a binary extension as a resource file causes pysetup to give a traceback Message-ID: <1318458920.54.0.0914338083355.issue13162@psf.upfronthosting.co.za> New submission from Paul Moore : I am trying to create a pysetup package that contains a precompiled binary extension, which can be installed without compiling, by using the resource file feature of setup.cfg. This may be incorrect usage of pysetup, but at a minimum, a proper error message should be given rather than a traceback. With a directory containing an extension hello.pyd plus the following setup.cfg file: [metadata] name = hello version = 0.1 author = Paul Moore author-email = p.f.moore at gmail.com summary = Test C extension [files] resources = hello.pyd = {platlib} I get a traceback when I do pysetup install: PS D:\Data\python-sample\bin> pysetup install Installing from source directory: 'D:\\Data\\python-sample\\bin' running install_dist running build running install_data running install_distinfo creating D:\Data\cpython\Lib\site-packages\hello-0.1.dist-info creating D:\Data\cpython\Lib\site-packages\hello-0.1.dist-info\METADATA creating D:\Data\cpython\Lib\site-packages\hello-0.1.dist-info\INSTALLER creating D:\Data\cpython\Lib\site-packages\hello-0.1.dist-info\REQUESTED creating D:\Data\cpython\Lib\site-packages\hello-0.1.dist-info\RESOURCES Traceback (most recent call last): File "D:\Data\cpython\lib\runpy.py", line 160, in _run_module_as_main "__main__", fname, loader, pkg_name) File "D:\Data\cpython\lib\runpy.py", line 73, in _run_code exec(code, run_globals) File "D:\Data\cpython\lib\packaging\run.py", line 666, in sys.exit(main()) File "D:\Data\cpython\lib\packaging\run.py", line 653, in main return dispatcher() File "D:\Data\cpython\lib\packaging\run.py", line 642, in __call__ return func(self, self.args) File "D:\Data\cpython\lib\packaging\run.py", line 91, in wrapper return f(*args, **kwargs) File "D:\Data\cpython\lib\packaging\run.py", line 164, in _install return not install_local_project(target) File "D:\Data\cpython\lib\packaging\install.py", line 122, in install_local_project return _run_install_from_dir(path) File "D:\Data\cpython\lib\packaging\install.py", line 160, in _run_install_from_dir func(source_dir) File "D:\Data\cpython\lib\packaging\install.py", line 87, in _run_packaging_install dist.run_command('install_dist') File "D:\Data\cpython\lib\packaging\dist.py", line 709, in run_command cmd_obj.run() File "D:\Data\cpython\lib\packaging\command\install_dist.py", line 506, in run self.run_command(cmd_name) File "D:\Data\cpython\lib\packaging\command\cmd.py", line 330, in run_command self.distribution.run_command(command) File "D:\Data\cpython\lib\packaging\dist.py", line 709, in run_command cmd_obj.run() File "D:\Data\cpython\lib\packaging\command\install_distinfo.py", line 112, in run writer.writerow(row) TypeError: 'str' does not support the buffer interface If this configuration is invalid a better error message should be given. However, I would also like to know what (if any) would be the correct way of writing a setup.cfg file to install a compiled extension like this. For background on why I am trying to do things in this (odd) way, see the python-dev thread starting at http://mail.python.org/pipermail/python-dev/2011-October/113956.html ---------- assignee: tarek components: Distutils2, Library (Lib) messages: 145441 nosy: alexis, eric.araujo, pmoore, tarek priority: normal severity: normal status: open title: Trying to install a binary extension as a resource file causes pysetup to give a traceback type: behavior versions: Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Oct 13 00:51:21 2011 From: report at bugs.python.org (Ram Rachum) Date: Wed, 12 Oct 2011 22:51:21 +0000 Subject: [New-bugs-announce] [issue13163] `port` and `host` are confused in `_get_socket Message-ID: <1318459881.81.0.817663809275.issue13163@psf.upfronthosting.co.za> New submission from Ram Rachum : Look here: http://hg.python.org/cpython/file/3313ce92cef7/Lib/smtplib.py#l279 `port` and `host` are confused. I saw this is fixed on 3.2; possibly it should be fixed in the next 2.7 micro release too. ---------- components: Library (Lib) messages: 145442 nosy: cool-RR priority: normal severity: normal status: open title: `port` and `host` are confused in `_get_socket versions: Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Oct 13 14:35:20 2011 From: report at bugs.python.org (Valvanuz) Date: Thu, 13 Oct 2011 12:35:20 +0000 Subject: [New-bugs-announce] [issue13164] importing rlcompleter module writes a control sequence in stdout Message-ID: <1318509320.97.0.686046301557.issue13164@psf.upfronthosting.co.za> New submission from Valvanuz : When you import the module rlcompleter in a python script in Centos 6 (x86_64), the control sequence \033[?1034h is printed in stdout. The problem is that these sequence is not visible by the user and cause a lot of confusion. In my case I compared the output of a python script (the integer 6) in bash and I got: test: 6: integer expression expected How to reproduce: ============================= BASH SCRIPT that calls test.py ============================= id=$(./test.py) echo $id|sed -n l if test ${id} -eq 0;then fi ========= test.py ========= #!/usr/bin/python import rlcompleter a=2 print a ======== OUTPUT ======== [valva at wn009 ~]$ bash p.sh \033[?1034h2$ p.sh: line 3: test: 2: integer expression expected This only has happened to me in Centos 6 (python 2.6.5) I've tested in Centos 5, debian and Ubuntu and it does not happen. ---------- messages: 145452 nosy: valva priority: normal severity: normal status: open title: importing rlcompleter module writes a control sequence in stdout type: behavior versions: Python 2.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Oct 13 17:37:26 2011 From: report at bugs.python.org (Antoine Pitrou) Date: Thu, 13 Oct 2011 15:37:26 +0000 Subject: [New-bugs-announce] [issue13165] Integrate stringbench in the Tools directory Message-ID: <1318520246.46.0.148882944484.issue13165@psf.upfronthosting.co.za> New submission from Antoine Pitrou : The stringbench suite of micro-benchmarks, currently available through SVN at http://svn.python.org/projects/sandbox/trunk/stringbench, would probably be a reasonable addition to the Tools directory. ---------- components: Demos and Tools keywords: easy messages: 145457 nosy: haypo, pitrou priority: normal severity: normal stage: needs patch status: open title: Integrate stringbench in the Tools directory type: feature request versions: Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Oct 13 17:52:11 2011 From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=) Date: Thu, 13 Oct 2011 15:52:11 +0000 Subject: [New-bugs-announce] [issue13166] Implement packaging.database.Distribution.__str__ Message-ID: <1318521131.43.0.0575328734451.issue13166@psf.upfronthosting.co.za> New submission from ?ric Araujo : In code working with instances of packaging.database.Distribution, it?s bothersome to have to use '%r %s' % (dist.name, dist.version) all the time. It is also not good-looking in 2.x, where we get u'name'. I think it would be best to implement a __str__ method on the class and just use %s everywhere, for example in pysetup list and pysetup search. More sophisticated clients that want to display projects in a GUI can still access dist.name, dist.version and other attributes. I?ve insisted on using %r for project names and paths to avoid ambiguities with trailing spaces and such hard-to-catch things. For logging output, we have to pass pure strings, but for direct console printing we could use ANSI escape sequences to display projects? names in bold for example. ---------- assignee: tarek components: Distutils2 messages: 145463 nosy: alexis, eric.araujo, tarek priority: normal severity: normal status: open title: Implement packaging.database.Distribution.__str__ versions: 3rd party, Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Oct 13 18:01:33 2011 From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=) Date: Thu, 13 Oct 2011 16:01:33 +0000 Subject: [New-bugs-announce] [issue13167] Add get_metadata to packaging Message-ID: <1318521693.13.0.517549681601.issue13167@psf.upfronthosting.co.za> New submission from ?ric Araujo : The PEP 376 implementation in packaging.database has been called ugly and opaque. When discussing PEP 396 for example (that?s why I?m adding Barry and Antoine to nosy, for their feedback), get_distribution(name).metadata['Version'] did not seem to agree with everyone. (Note that there are shortcuts for two metadata fields: name and version also exist as get_distribution(name).name / .version.) I?m not sure how we can make it less opaque, unless we force people to read documentation: PEP 376 proposes a database of installed distributions; packaging.database offers get_distribution, which returns an object with some attributes. I can?t have an outside view on this, so maybe you can explain what?s opaque and ugly so that we can try to improve it. I?ve found in distutils-sig archives from two or three years ago that people intended to offer a get_metadata function that would take a distribution name (i.e. pyOpenSSL, Babel, flufl.enum) and return a mapping object with the metadata read from the installed dist-info/METADATA file. Does that look better to you? ---------- assignee: tarek components: Distutils2 files: d2-get_metadata.diff keywords: patch messages: 145465 nosy: alexis, barry, eric.araujo, pitrou, tarek priority: normal severity: normal status: open title: Add get_metadata to packaging versions: 3rd party, Python 3.3 Added file: http://bugs.python.org/file23394/d2-get_metadata.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Oct 13 18:08:54 2011 From: report at bugs.python.org (Randy Galbraith) Date: Thu, 13 Oct 2011 16:08:54 +0000 Subject: [New-bugs-announce] [issue13168] Python 2.6 having trouble finding modules when invoked via a symlink Message-ID: <1318522134.74.0.524944339938.issue13168@psf.upfronthosting.co.za> New submission from Randy Galbraith : Hi Python Developers, Our install of Python 2.6.4 on AIX 5.3 seems to have problems finding modules when invoked via a symlink. A direct path to the binary will work. One symlink will work, but another will not. I created a test harness to demonstrate this issue and collect (hopefully) useful output. Regards, -Randy Galbraith ps. Thanks for making such a great tool available! --test script-- #!/bin/sh ACTUAL_BINARY=/mypath/tool/Python-2.6.4/powerpc-AIX5.3/bin/python FIRST_SYMLINK=/mypath/tool/bin/python SECOND_SYMLINK=/mypath/tool/powerpc-AIX5.3/bin/python set -x echo echo "Actual binary..." ls -ld $ACTUAL_BINARY echo echo "First symlink..." ls -ld $FIRST_SYMLINK echo echo "Second symlink..." ls -ld $SECOND_SYMLINK echo echo "Run with actual binary is good..." $ACTUAL_BINARY -m py_compile test.py echo echo "Run with first symlink is bad..." $FIRST_SYMLINK -m py_compile test.py echo echo "Run with second symlink is good..." $SECOND_SYMLINK -m py_compile test.py set +x echo echo "Analysis..." truss $ACTUAL_BINARY -m py_compile test.py 2>truss_binary.log truss $FIRST_SYMLINK -m py_compile test.py 2>truss_symlink1.log truss $SECOND_SYMLINK -m py_compile test.py 2>truss_symlink2.log echo echo "runpy is found..." grep runpy truss_binary.log echo echo "runpy is not found..." grep runpy truss_symlink1.log echo echo "runpy is found..." grep runpy truss_symlink2.log --end test script-- --terminal output-- $ ./test_script.sh + echo + echo Actual binary... Actual binary... + ls -ld /mypath/tool/Python-2.6.4/powerpc-AIX5.3/bin/python -rwxr-xr-x 2 myuserid mygroup1 9727885 2010-02-25 10:57 /mypath/tool/Python-2.6.4/powerpc-AIX5.3/bin/python + echo + echo First symlink... First symlink... + ls -ld /mypath/tool/bin/python lrwxrwxrwx 1 myuserid mygroup2 44 2010-06-02 17:16 /mypath/tool/bin/python -> ../../Python-2.6.4/powerpc-AIX5.3/bin/python + echo + echo Second symlink... Second symlink... + ls -ld /mypath/tool/powerpc-AIX5.3/bin/python lrwxrwxrwx 1 myuserid mygroup2 44 2010-06-02 17:16 /mypath/tool/powerpc-AIX5.3/bin/python -> ../../Python-2.6.4/powerpc-AIX5.3/bin/python + echo + echo Run with actual binary is good... Run with actual binary is good... + /mypath/tool/Python-2.6.4/powerpc-AIX5.3/bin/python -m py_compile test.py + echo + echo Run with first symlink is bad... Run with first symlink is bad... + /mypath/tool/bin/python -m py_compile test.py Could not import runpy module + echo + echo Run with second symlink is good... Run with second symlink is good... + /mypath/tool/powerpc-AIX5.3/bin/python -m py_compile test.py Analysis... runpy is found... statx("runpy", 0x2FF21168, 76, 0) Err#2 ENOENT open("runpy.so", O_RDONLY) Err#2 ENOENT open("runpymodule.so", O_RDONLY) Err#2 ENOENT open("runpy.py", O_RDONLY) Err#2 ENOENT open("runpy.pyc", O_RDONLY) Err#2 ENOENT statx("/mypath/tool/Python-2.6.4/lib/python2.6/runpy", 0x2FF21168, 76, 0) Err#2 ENOENT open("/mypath/tool/Python-2.6.4/lib/python2.6/runpy.so", O_RDONLY) Err#2 ENOENT open("/mypath/tool/Python-2.6.4/lib/python2.6/runpymodule.so", O_RDONLY) Err#2 ENOENT open("/mypath/tool/Python-2.6.4/lib/python2.6/runpy.py", O_RDONLY) = 3 open("/mypath/tool/Python-2.6.4/lib/python2.6/runpy.pyc", O_RDONLY) = 4 runpy is not found... statx("runpy", 0x2FF21188, 76, 0) Err#2 ENOENT open("runpy.so", O_RDONLY) Err#2 ENOENT open("runpymodule.so", O_RDONLY) Err#2 ENOENT open("runpy.py", O_RDONLY) Err#2 ENOENT open("runpy.pyc", O_RDONLY) Err#2 ENOENT Could not import runpy module runpy is found... statx("runpy", 0x2FF21178, 76, 0) Err#2 ENOENT open("runpy.so", O_RDONLY) Err#2 ENOENT open("runpymodule.so", O_RDONLY) Err#2 ENOENT open("runpy.py", O_RDONLY) Err#2 ENOENT open("runpy.pyc", O_RDONLY) Err#2 ENOENT statx("/mypath/tool/Python-2.6.4/lib/python2.6/runpy", 0x2FF21178, 76, 0) Err#2 ENOENT open("/mypath/tool/Python-2.6.4/lib/python2.6/runpy.so", O_RDONLY) Err#2 ENOENT open("/mypath/tool/Python-2.6.4/lib/python2.6/runpymodule.so", O_RDONLY) Err#2 ENOENT open("/mypath/tool/Python-2.6.4/lib/python2.6/runpy.py", O_RDONLY) = 3 open("/mypath/tool/Python-2.6.4/lib/python2.6/runpy.pyc", O_RDONLY) = 4 --end terminal output-- ---------- components: Interpreter Core messages: 145468 nosy: RandyGalbraith priority: normal severity: normal status: open title: Python 2.6 having trouble finding modules when invoked via a symlink type: compile error versions: Python 2.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Oct 13 18:30:27 2011 From: report at bugs.python.org (Maurice de Rooij) Date: Thu, 13 Oct 2011 16:30:27 +0000 Subject: [New-bugs-announce] [issue13169] Regular expressions with 0 to 65536 repetitions and above makes Python crash Message-ID: <1318523427.81.0.476768111228.issue13169@psf.upfronthosting.co.za> New submission from Maurice de Rooij : Regular expressions with 0 to 65536 repetitions and above makes Python crash with a "OverflowError: regular expression code size limit exceeded" exception. 65535 repetitions do not raise this issue. Tested and confirmed this with versions 2.7.1 and 3.2.2. C:\Python27>python.exe Python 2.7.1 (r271:86832, Nov 27 2010, 18:30:46) [MSC v.1500 32 bit (Intel)] on win32 Type "help", "copyright", "credits" or "license" for more information. >>> import re >>> re.search('(?s)\A.{0,65535}test', 'test') <_sre.SRE_Match object at 0x00B4E4B8> >>> re.search('(?s)\A.{0,65536}test', 'test') Traceback (most recent call last): File "", line 1, in File "C:\Python27\lib\re.py", line 142, in search return _compile(pattern, flags).search(string) File "C:\Python27\lib\re.py", line 243, in _compile p = sre_compile.compile(pattern, flags) File "C:\Python27\lib\sre_compile.py", line 523, in compile groupindex, indexgroup OverflowError: regular expression code size limit exceeded >>> C:\Python32>python.exe Python 3.2.2 (default, Sep 4 2011, 09:51:08) [MSC v.1500 32 bit (Intel)] on win32 Type "help", "copyright", "credits" or "license" for more information. >>> import re >>> re.search('(?s)\A.{0,65535}test', 'test') <_sre.SRE_Match object at 0x00A6F250> >>> re.search('(?s)\A.{0,65536}test', 'test') Traceback (most recent call last): File "C:\Python32\lib\functools.py", line 176, in wrapper result = cache[key] KeyError: (, '(?s)\\A.{0,65536}test', 0) During handling of the above exception, another exception occurred: Traceback (most recent call last): File "", line 1, in File "C:\Python32\lib\re.py", line 158, in search return _compile(pattern, flags).search(string) File "C:\Python32\lib\re.py", line 255, in _compile return _compile_typed(type(pattern), pattern, flags) File "C:\Python32\lib\functools.py", line 180, in wrapper result = user_function(*args, **kwds) File "C:\Python32\lib\re.py", line 267, in _compile_typed return sre_compile.compile(pattern, flags) File "C:\Python32\lib\sre_compile.py", line 514, in compile groupindex, indexgroup OverflowError: regular expression code size limit exceeded >>> ---------- components: Library (Lib) messages: 145469 nosy: techmaurice priority: normal severity: normal status: open title: Regular expressions with 0 to 65536 repetitions and above makes Python crash type: crash versions: Python 2.7, Python 3.2 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Oct 13 18:37:17 2011 From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=) Date: Thu, 13 Oct 2011 16:37:17 +0000 Subject: [New-bugs-announce] [issue13170] distutils2 test failures Message-ID: <1318523837.27.0.295397321545.issue13170@psf.upfronthosting.co.za> New submission from ?ric Araujo : I get three errors/failures on linux3: ERROR: test_simple_run (distutils2.tests.test_command_install_data.InstallDataTestCase) ---------------------------------------------------------------------- Traceback (most recent call last): File "distutils2/tests/test_command_install_data.py", line 76, in test_simple_run cmd.run() File "distutils2/command/install_data.py", line 50, in run out = self.copy_file(_file[0], dir_dest)[0] File "distutils2/command/cmd.py", line 378, in copy_file copyfile(infile, outfile) File "distutils2/_backport/shutil.py", line 83, in copyfile raise Error("`%s` and `%s` are the same file" % (src, dst)) Error: `/tmp/user/1013/tmpEl9F8m/tmp91wrrV/foo/inst/three` and `/tmp/user/1013/tmpEl9F8m/tmp91wrrV/foo/inst/three` are the same file ====================================================================== FAIL: test_config (distutils2.tests.test_config.ConfigTestCase) ---------------------------------------------------------------------- Traceback (most recent call last): File "distutils2/tests/test_config.py", line 291, in test_config self.assertEqual(dist.package_data, {'cheese': 'data/templates/*'}) AssertionError: {u'cheese': [u'data/templates/*']} != {'cheese': 'data/templates/*'} - {u'cheese': [u'data/templates/*']} ? - -- - + {'cheese': 'data/templates/*'} ====================================================================== FAIL: test_parse_extensions_in_config (distutils2.tests.test_config.ConfigTestCase) ---------------------------------------------------------------------- Traceback (most recent call last): File "distutils2/tests/test_config.py", line 341, in test_parse_extensions_in_config self.assertEqual(ext.sources, ['c_src/speed_coconuts.c']) AssertionError: Lists differ: ['c\x00\x00\x00_\x00\x00\x00s\... != ['c_src/speed_coconuts.c'] First differing element 0: c_src/speed_coconuts.c c_src/speed_coconuts.c - ['c\x00\x00\x00_\x00\x00\x00s\x00\x00\x00r\x00\x00\x00c\x00\x00\x00/\x00\x00\x00s\x00\x00\x00p\x00\x00\x00e\x00\x00\x00e\x00\x00\x00d\x00\x00\x00_\x00\x00\x00c\x00\x00\x00o\x00\x00\x00c\x00\x00\x00o\x00\x00\x00n\x00\x00\x00u\x00\x00\x00t\x00\x00\x00s\x00\x00\x00.\x00\x00\x00c\x00\x00\x00'] + ['c_src/speed_coconuts.c'] The last one looks like a codecs issue. ---------- assignee: tarek components: Distutils2 messages: 145470 nosy: alexis, eric.araujo, tarek priority: normal severity: normal status: open title: distutils2 test failures versions: 3rd party _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Oct 13 20:40:10 2011 From: report at bugs.python.org (Alexander Steppke) Date: Thu, 13 Oct 2011 18:40:10 +0000 Subject: [New-bugs-announce] [issue13171] Bug in tempfile module Message-ID: <1318531210.93.0.392401137226.issue13171@psf.upfronthosting.co.za> New submission from Alexander Steppke : The tempfile module shows strange behavior under certain conditions. This might lead to data leaking or other problems. The test session looks as follows: Python 2.7.2 (default, Jun 12 2011, 15:08:59) [MSC v.1500 32 bit (Intel)] on win32 Type "help", "copyright", "credits" or "license" for more information. >>> import tempfile >>> tmp = tempfile.TemporaryFile() >>> tmp.read() '' >>> tmp.write('test') >>> tmp.read() 'P\xf6D\x02\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\ [ommitted]' or similar behavior in text mode: Python 2.7.2 (default, Jun 12 2011, 15:08:59) [MSC v.1500 32 bit (Intel)] on win32 Type "help", "copyright", "credits" or "license" for more information. >>> import tempfile >>> tmp = tempfile.TemporaryFile('w+t') >>> tmp.read() '' >>> tmp.write('test') >>> tmp.read() '\x00\xa5\x8b\x02int or long, hash(a) is used instead.\n i\x10 [ommitted]' >>> tmp.seek(0) >>> tmp.readline() 'test\x00\xa5\x8b\x02int or long, hash(a) is used instead.\n' This bug seems to be triggered by calling tmp.read() before tmp.seek(). I am running Python 2.7.2 on Windows 7 x64, other people have reproduced the problem on Windows XP but not under Linux or Cygwin (see also http://stackoverflow.com/questions/7757663/python-tempfile-broken-or-am-i-doing-it-wrong). Thank you for looking into this. Alexander ---------- components: Library (Lib), Windows messages: 145477 nosy: Alexander.Steppke priority: normal severity: normal status: open title: Bug in tempfile module type: behavior versions: Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Oct 13 20:47:51 2011 From: report at bugs.python.org (Paul Moore) Date: Thu, 13 Oct 2011 18:47:51 +0000 Subject: [New-bugs-announce] [issue13172] pysetup run --list-commands fails with a traceback Message-ID: <1318531671.43.0.795221927422.issue13172@psf.upfronthosting.co.za> New submission from Paul Moore : In a directory with 2 files, setup.cfg and a single C file containing source for an extension module. The same happens with a pure-python module. This is on Windows. PS D:\Data\python-sample> D:\Data\cpython\PCbuild\python.exe -m packaging.run run --list-commands List of available commands: bdist: create a built (binary) distribution bdist_dumb: create a "dumb" built distribution Traceback (most recent call last): File "D:\Data\cpython\lib\packaging\util.py", line 652, in resolve_name ret = getattr(ret, part) AttributeError: 'module' object has no attribute 'bdist_msi' During handling of the above exception, another exception occurred: Traceback (most recent call last): File "D:\Data\cpython\lib\runpy.py", line 160, in _run_module_as_main "__main__", fname, loader, pkg_name) File "D:\Data\cpython\lib\runpy.py", line 73, in _run_code exec(code, run_globals) File "D:\Data\cpython\lib\packaging\run.py", line 666, in sys.exit(main()) File "D:\Data\cpython\lib\packaging\run.py", line 653, in main return dispatcher() File "D:\Data\cpython\lib\packaging\run.py", line 642, in __call__ return func(self, self.args) File "D:\Data\cpython\lib\packaging\run.py", line 91, in wrapper return f(*args, **kwargs) File "D:\Data\cpython\lib\packaging\run.py", line 264, in _run cls = dispatcher.cmdclass.get(cmd) or get_command_class(cmd) File "D:\Data\cpython\lib\packaging\command\__init__.py", line 61, in get_command_class cls = resolve_name(cls) File "D:\Data\cpython\lib\packaging\util.py", line 654, in resolve_name raise ImportError(exc) ImportError: 'module' object has no attribute 'bdist_msi' ---------- assignee: tarek components: Distutils2 messages: 145478 nosy: alexis, eric.araujo, pmoore, tarek priority: normal severity: normal status: open title: pysetup run --list-commands fails with a traceback type: behavior versions: Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Oct 13 23:16:05 2011 From: report at bugs.python.org (Bfontaine) Date: Thu, 13 Oct 2011 21:16:05 +0000 Subject: [New-bugs-announce] [issue13173] Default values for string.Template Message-ID: <1318540565.49.0.753035083637.issue13173@psf.upfronthosting.co.za> New submission from Bfontaine : This patch allows you to define default values for a string.Template, which is useful when you need to use a lot some values, but sometimes other values. for example: >>> from string import Template >>> s = Template("${user} made me a ${flavor} cake.", default={"user":"Dennis"}) >>> s.substitute(flavor="vanilla") 'Dennis made me a vanilla cake.' >>> s.substitute(user="Ken", flavor="chocolate") 'Ken made me chocolate cake.' ---------- components: Library (Lib) files: string_template_default_values.tar messages: 145485 nosy: nitupho priority: normal severity: normal status: open title: Default values for string.Template type: feature request versions: Python 3.2 Added file: http://bugs.python.org/file23398/string_template_default_values.tar _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Oct 13 23:32:47 2011 From: report at bugs.python.org (STINNER Victor) Date: Thu, 13 Oct 2011 21:32:47 +0000 Subject: [New-bugs-announce] [issue13174] test_os failures on Fedora 15: listxattr() returns ['security.selinux'] Message-ID: <1318541567.35.0.652639760355.issue13174@psf.upfronthosting.co.za> New submission from STINNER Victor : ====================================================================== FAIL: test_fds (test.test_os.ExtendedAttributeTests) ---------------------------------------------------------------------- Traceback (most recent call last): File "/home/haypo/prog/python/default/Lib/test/test_os.py", line 1599, in test_fds self._check_xattrs(getxattr, setxattr, removexattr, listxattr) File "/home/haypo/prog/python/default/Lib/test/test_os.py", line 1574, in _check_xattrs self._check_xattrs_str(str, *args) File "/home/haypo/prog/python/default/Lib/test/test_os.py", line 1543, in _check_xattrs_str self.assertEqual(listxattr(fn), []) AssertionError: Lists differ: ['security.selinux'] != [] First list contains 1 additional elements. First extra element 0: security.selinux - ['security.selinux'] + [] ====================================================================== FAIL: test_lpath (test.test_os.ExtendedAttributeTests) ---------------------------------------------------------------------- Traceback (most recent call last): File "/home/haypo/prog/python/default/Lib/test/test_os.py", line 1584, in test_lpath os.llistxattr) File "/home/haypo/prog/python/default/Lib/test/test_os.py", line 1574, in _check_xattrs self._check_xattrs_str(str, *args) File "/home/haypo/prog/python/default/Lib/test/test_os.py", line 1543, in _check_xattrs_str self.assertEqual(listxattr(fn), []) AssertionError: Lists differ: ['security.selinux'] != [] First list contains 1 additional elements. First extra element 0: security.selinux - ['security.selinux'] + [] ====================================================================== FAIL: test_simple (test.test_os.ExtendedAttributeTests) ---------------------------------------------------------------------- Traceback (most recent call last): File "/home/haypo/prog/python/default/Lib/test/test_os.py", line 1580, in test_simple os.listxattr) File "/home/haypo/prog/python/default/Lib/test/test_os.py", line 1574, in _check_xattrs self._check_xattrs_str(str, *args) File "/home/haypo/prog/python/default/Lib/test/test_os.py", line 1543, in _check_xattrs_str self.assertEqual(listxattr(fn), []) AssertionError: Lists differ: ['security.selinux'] != [] First list contains 1 additional elements. First extra element 0: security.selinux - ['security.selinux'] + [] ---------- components: Extension Modules, Library (Lib) messages: 145486 nosy: haypo priority: normal severity: normal status: open title: test_os failures on Fedora 15: listxattr() returns ['security.selinux'] versions: Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Oct 14 00:47:02 2011 From: report at bugs.python.org (Paul Moore) Date: Thu, 13 Oct 2011 22:47:02 +0000 Subject: [New-bugs-announce] [issue13175] packaging uses wrong line endings in RECORD files on Windows Message-ID: <1318546022.2.0.0477576720396.issue13175@psf.upfronthosting.co.za> New submission from Paul Moore : On Windows, packaging seems to create RECORD files with an additional CR at the end of the line. (So the line end is CR CR LF). This does not seem to be consistent, but it is likely to be because a file is being opened in text mode rather than binary. I am trying to develop a reproducible test case, but am having difficulty at the moment. I have opened this bug in any case as a place holder and in case someone else can reproduce the issue. ---------- assignee: tarek components: Distutils2 messages: 145488 nosy: alexis, eric.araujo, pmoore, tarek priority: normal severity: normal status: open title: packaging uses wrong line endings in RECORD files on Windows type: behavior versions: Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Oct 14 10:05:08 2011 From: report at bugs.python.org (Berker Peksag) Date: Fri, 14 Oct 2011 08:05:08 +0000 Subject: [New-bugs-announce] [issue13176] Broken link in bugs.rst Message-ID: <1318579508.22.0.235286137503.issue13176@psf.upfronthosting.co.za> New submission from Berker Peksag : http://www.python.org/dev/workflow/ is missing in 3.2 documentation. See: http://docs.python.org/py3k/bugs.html It works with latest version of the documentation: http://docs.python.org/dev/bugs.html ---------- assignee: docs at python components: Documentation files: broken_link_v1.patch keywords: patch messages: 145499 nosy: berkerpeksag, docs at python priority: normal severity: normal status: open title: Broken link in bugs.rst versions: Python 3.2 Added file: http://bugs.python.org/file23402/broken_link_v1.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Oct 14 14:19:10 2011 From: report at bugs.python.org (Ezio Melotti) Date: Fri, 14 Oct 2011 12:19:10 +0000 Subject: [New-bugs-announce] [issue13177] Avoid chained exceptions in lru_cache Message-ID: <1318594750.97.0.446461208039.issue13177@psf.upfronthosting.co.za> New submission from Ezio Melotti : The attached patch changes lru_cache to use if/else instead of try/except. This has 2 effects: 1) it avoids chained exceptions and makes the error messages clearer; 2) it probably makes lru_cache a bit faster since building and catching exceptions is expensive. It also gets rid of the KeyError=KeyError optimization/hack; For a couple of examples of 1) see #12749 (msg142059, msg142063), or #13169 (msg145469). See also related issue #6210. ---------- assignee: rhettinger files: issue13177.diff keywords: needs review, patch messages: 145511 nosy: ezio.melotti, rhettinger priority: normal severity: normal stage: patch review status: open title: Avoid chained exceptions in lru_cache type: behavior versions: Python 3.2, Python 3.3 Added file: http://bugs.python.org/file23403/issue13177.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Oct 14 17:01:23 2011 From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=) Date: Fri, 14 Oct 2011 15:01:23 +0000 Subject: [New-bugs-announce] [issue13178] Need tests for Unicode handling in install_distinfo and install_data Message-ID: <1318604483.39.0.256027567702.issue13178@psf.upfronthosting.co.za> New submission from ?ric Araujo : Currently, packaging code opens dist-info files (RECORD, RESOURCES) for writing without giving an explicit encoding. We need to add tests and probably to explicitly specify UTF-8 when writing an reading. ---------- assignee: tarek components: Distutils2 keywords: easy messages: 145526 nosy: alexis, eric.araujo, haypo, tarek priority: normal severity: normal stage: needs patch status: open title: Need tests for Unicode handling in install_distinfo and install_data versions: 3rd party, Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Oct 14 17:52:28 2011 From: report at bugs.python.org (Roger Serwy) Date: Fri, 14 Oct 2011 15:52:28 +0000 Subject: [New-bugs-announce] [issue13179] IDLE uses common tkinter variables across all editor windows Message-ID: <1318607548.28.0.391563618977.issue13179@psf.upfronthosting.co.za> New submission from Roger Serwy : IDLE's EditorWindow.py relies on using FileList.py's "vars" dictionary to store Tkinter variables instead of using its own. As a consequence, toggling a checked menu item in one editor window toggles the menu item in ALL editor windows. To reproduce this error, open two editor windows with Code Context initially disabled. Enable Code Context in one window and then click "Options" in the other. You'll see Code Context checked when it shouldn't be. Attached is a patch to fix this problem. It causes EditorWindow to have its own dictionary for handling these Tkinter variables instead of using the flist's "vars". The comment in FileList.py suggests that this design is a relic from an old version of IDLE, since getrawvar is no longer a function. self.vars = {} # For EditorWindow.getrawvar (shared Tcl variables) ---------- components: IDLE files: patch_EditorWindow.diff keywords: patch messages: 145539 nosy: serwy priority: normal severity: normal status: open title: IDLE uses common tkinter variables across all editor windows type: behavior versions: Python 2.6, Python 2.7, Python 3.1, Python 3.2 Added file: http://bugs.python.org/file23406/patch_EditorWindow.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Oct 14 19:47:19 2011 From: report at bugs.python.org (Paul Moore) Date: Fri, 14 Oct 2011 17:47:19 +0000 Subject: [New-bugs-announce] [issue13180] pysetup silently ignores invalid entries in setup.cfg Message-ID: <1318614439.75.0.304667021355.issue13180@psf.upfronthosting.co.za> New submission from Paul Moore : With a simple setup.cfg defining a distribution containing a single Python module, if you misspell the "modules" keyword (say, as "module") then pysetup does nothing without reporting the error. This silent failure is very hard to debug, and even if pysetup is ignoring unknown items by design, it should at a minimum report ignored items and probably try to warn on common misspellings like this one. PS D:\Data\python-sample\python> type .\setup.cfg [metadata] name = hello version = 0.1 author = Paul Moore author-email = p.f.moore at gmail.com summary = Test Python module [files] module = hello PS D:\Data\python-sample\python> pysetup run build running build PS D:\Data\python-sample\python> dir Directory: D:\Data\python-sample\python Mode LastWriteTime Length Name ---- ------------- ------ ---- -a--- 13/10/2011 19:46 42 hello.py -a--- 14/10/2011 18:42 155 setup.cfg (No build directory created!) ---------- assignee: tarek components: Distutils2 messages: 145552 nosy: alexis, eric.araujo, pmoore, tarek priority: normal severity: normal status: open title: pysetup silently ignores invalid entries in setup.cfg type: behavior versions: Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Oct 14 20:11:07 2011 From: report at bugs.python.org (Paul Moore) Date: Fri, 14 Oct 2011 18:11:07 +0000 Subject: [New-bugs-announce] [issue13181] pysetup install creates .pyc files but pysetup remove doesn't delete them Message-ID: <1318615867.17.0.772590919076.issue13181@psf.upfronthosting.co.za> New submission from Paul Moore : The title explains. Here is an example: PS D:\Data\python-sample\python> pysetup install Installing from source directory: 'D:\\Data\\python-sample\\python' running install_dist running build running build_py running install_lib byte-compiling D:\Data\cpython\Lib\site-packages\hello.py to hello.cpython-33.pyc running install_distinfo creating D:\Data\cpython\Lib\site-packages\hello-0.1.dist-info creating D:\Data\cpython\Lib\site-packages\hello-0.1.dist-info\METADATA creating D:\Data\cpython\Lib\site-packages\hello-0.1.dist-info\INSTALLER creating D:\Data\cpython\Lib\site-packages\hello-0.1.dist-info\REQUESTED creating D:\Data\cpython\Lib\site-packages\hello-0.1.dist-info\RECORD PS D:\Data\python-sample\python> pysetup remove hello Removing 'hello': D:\Data\cpython\Lib\site-packages\hello.py D:\Data\cpython\Lib\site-packages\hello-0.1.dist-info\METADATA D:\Data\cpython\Lib\site-packages\hello-0.1.dist-info\INSTALLER D:\Data\cpython\Lib\site-packages\hello-0.1.dist-info\REQUESTED D:\Data\cpython\Lib\site-packages\hello-0.1.dist-info\RECORD Proceed (y/n)? y Success: removed 5 files and 1 dirs PS D:\Data\python-sample> dir D:\Data\cpython\Lib\site-packages\__pycache__ Directory: D:\Data\cpython\Lib\site-packages\__pycache__ Mode LastWriteTime Length Name ---- ------------- ------ ---- -a--- 14/10/2011 18:53 314 hello.cpython-33.pyc The pyc file should have been removed. It's not critical (the pyc file gets ignored, see PEP 3147) but as pysetup created it, pysetup should remove it... ---------- assignee: tarek components: Distutils2 messages: 145554 nosy: alexis, eric.araujo, pmoore, tarek priority: low severity: normal status: open title: pysetup install creates .pyc files but pysetup remove doesn't delete them type: behavior versions: Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Oct 14 20:26:11 2011 From: report at bugs.python.org (Paul Moore) Date: Fri, 14 Oct 2011 18:26:11 +0000 Subject: [New-bugs-announce] [issue13182] pysetup run bdist_wininst does not work (tries to use "install" command) Message-ID: <1318616771.75.0.522951953738.issue13182@psf.upfronthosting.co.za> New submission from Paul Moore : PS D:\Data\python-sample\python> pysetup run bdist_wininst running bdist_wininst running build running build_py Invalid command install Traceback (most recent call last): File "D:\Data\cpython\lib\packaging\command\__init__.py", line 57, in get_command_class cls = _COMMANDS[name] KeyError: 'install' During handling of the above exception, another exception occurred: Traceback (most recent call last): File "D:\Data\cpython\lib\packaging\run.py", line 653, in main return dispatcher() File "D:\Data\cpython\lib\packaging\run.py", line 642, in __call__ return func(self, self.args) File "D:\Data\cpython\lib\packaging\run.py", line 91, in wrapper return f(*args, **kwargs) File "D:\Data\cpython\lib\packaging\run.py", line 288, in _run dist.run_command(cmd, dispatcher.command_options[cmd]) File "D:\Data\cpython\lib\packaging\dist.py", line 709, in run_command cmd_obj.run() File "D:\Data\cpython\lib\packaging\command\bdist_wininst.py", line 119, in run reinit_subcommands=True) File "D:\Data\cpython\lib\packaging\command\cmd.py", line 323, in get_reinitialized_command command, reinit_subcommands) File "D:\Data\cpython\lib\packaging\dist.py", line 660, in get_reinitialized_command command = self.get_command_obj(command_name) File "D:\Data\cpython\lib\packaging\dist.py", line 583, in get_command_obj cls = get_command_class(command) File "D:\Data\cpython\lib\packaging\command\__init__.py", line 59, in get_command_class raise PackagingModuleError("Invalid command %s" % name) packaging.errors.PackagingModuleError: Invalid command install Looking at bdist_wininst.py (line 118) it is indeed trying to use an "install" command, which is not present in command\__init__.py ---------- assignee: tarek components: Distutils2 messages: 145555 nosy: alexis, eric.araujo, pmoore, tarek priority: normal severity: normal status: open title: pysetup run bdist_wininst does not work (tries to use "install" command) type: behavior versions: Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Oct 14 20:56:31 2011 From: report at bugs.python.org (Xavier de Gaye) Date: Fri, 14 Oct 2011 18:56:31 +0000 Subject: [New-bugs-announce] [issue13183] pdb skips frames after hitting a breakpoint and running step Message-ID: <1318618591.85.0.940577569218.issue13183@psf.upfronthosting.co.za> New submission from Xavier de Gaye : Pdb skips frames after hitting a breakpoint and running step commands that walk back the frame stack. Run the following two tests with the two files named foo.py and bar.py: === foo.py ============================================ from bar import bar def foo(): bar() def nope(): pass def foobar(): foo() nope() foobar() === bar.py ============================================ def bar(): print('1') === test_1 ============================================ $ python3 --version Python 3.2 $ python3 -m pdb foo.py > /path/to/foo.py(1)() -> from bar import bar (Pdb) from bar import bar (Pdb) break bar Breakpoint 1 at /path/to/bar.py:1 (Pdb) continue > /path/to/bar.py(2)bar() -> print('1') (Pdb) step 1 --Return-- > /path/to/bar.py(2)bar()->None -> print('1') (Pdb) step --Call-- > /path/to/foo.py(6)nope() -> def nope(): (Pdb) === test_2 ============================================ $ python3 -m pdb foo.py > /path/to/foo.py(1)() -> from bar import bar (Pdb) break nope Breakpoint 1 at /path/to/foo.py:6 (Pdb) from bar import bar (Pdb) break bar Breakpoint 2 at /path/to/bar.py:1 (Pdb) continue > /path/to/bar.py(2)bar() -> print('1') (Pdb) step 1 --Return-- > /path/to/bar.py(2)bar()->None -> print('1') (Pdb) step --Return-- > /path/to/foo.py(4)foo()->None -> bar() (Pdb) =========================================================== Note: stop_here, break_anywhere and dispatch_call are methods of the Bdb class. test_1 fails to stop in foo() after the second 'step' command because the trace function is not set for all the frames being created in the foo module, since stop_here() and break_anywhere() are both False whenever dispatch_call() is invoked in this module. So after the second 'step' command, trace_dispatch is not invoked by the interpreter until a new frame is created, which happens when nope() is called. test_2 succeeds and stops in foo() after the second 'step' command. After setting the dummy breakpoint 1 in the foo module in test_2, break_anywhere() becomes True in the foo module and the trace function is set for all the frames created in this module (with an associated performance penalty). The problem exists in all python versions. The attached patch fixes this problem by restoring the trace function on returning from a frame when the command is 'step'. The patch includes a test case. ---------- components: Library (Lib) files: restore_trace.patch keywords: patch messages: 145557 nosy: xdegaye priority: normal severity: normal status: open title: pdb skips frames after hitting a breakpoint and running step versions: Python 3.2 Added file: http://bugs.python.org/file23410/restore_trace.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Oct 15 07:14:40 2011 From: report at bugs.python.org (Jason Howlett) Date: Sat, 15 Oct 2011 05:14:40 +0000 Subject: [New-bugs-announce] [issue13184] Multi-layered symlinks cause runtime error. sys.path is malformed. Message-ID: <1318655680.83.0.71543236392.issue13184@psf.upfronthosting.co.za> New submission from Jason Howlett : This error is observed in Python 2.7.2. Steps to recreate problem: 1) Create directory ~/pytest. 2) Untar Python 2.7.2 sources into ~/pytest 3) configure, build, and install with --prefix=~/pytest/pyinstall 4) mkdir -p ~/pytest/other/bin 5) cd ~/pytest/other/bin 6) ln -s ../../pyinstall/bin/python 7) cd ~/pytest 8) ln -s other/bin bin 9) bin/python This will result in the following exception: Traceback (most recent call last): File "/home/jason/pytest/bin/../../pyinstall/lib/python2.7/site.py", line 564, in main() File "/home/jason/pytest/bin/../../pyinstall/lib/python2.7/site.py", line 546, in main known_paths = addusersitepackages(known_paths) File "/home/jason/pytest/bin/../../pyinstall/lib/python2.7/site.py", line 279, in addusersitepackages user_site = getusersitepackages() File "/home/jason/pytest/bin/../../pyinstall/lib/python2.7/site.py", line 254, in getusersitepackages user_base = getuserbase() # this will also set USER_BASE File "/home/jason/pytest/bin/../../pyinstall/lib/python2.7/site.py", line 243, in getuserbase from sysconfig import get_config_var ImportError: No module named sysconfig Placing 'print sys.path' on line 242 of site.py prints out something like this: ['/home/jason/pyinstall/lib/python27.zip', '/home/jason/pyinstall/lib/python2.7', '/home/jason/pyinstall/lib/python2.7/plat-linux2', '/home/jason/pyinstall/lib/python2.7/lib-tk', '/home/jason/pyinstall/lib/python2.7/lib-old', '/home/jason/pyinstall/lib/python2.7/lib-dynload'] Notice that the root directory is /home/jason/pyinstall instead of the correct value /home/jason/pytest/pyinstall. Now, on line 65 of site.py, add import sysconfig. For some reason this works at this point in site.py, but not down on line 243. In sysconfig.py, at line 94, add the following: print 'SYSCONFIG:', sys.exec_prefix, _EXEC_PREFIX This will print the following: SYSCONFIG: /home/jason/pytest/bin/../../pyinstall /home/jason/pyinstall Line 93 of sysconfig.py is a call to normpath that collapses the path. The root of this problem is that the value of sys.exec_prefix is not correct. The value it has will work fine if ls'ing it in a shell as it handles the symlink /home/jason/pytest/bin properly. Path calculations internal to python, however, do not end up with the correct results. I believe the fix to this problem is to modify Modules/getpath.c, starting at line 488, and instead of looking only for a symlink in the python executable, also look for a link in any of the path elements leading up to the executable. Detecting and expanding these out should result, in this example, with sys.exec_prefix being /home/jason/pytest/pyinstall and the correct behavior in sysconfig, site, etc. ---------- components: Interpreter Core messages: 145582 nosy: Jason.Howlett priority: normal severity: normal status: open title: Multi-layered symlinks cause runtime error. sys.path is malformed. type: crash versions: Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Oct 15 07:18:25 2011 From: report at bugs.python.org (Phillip Feldman) Date: Sat, 15 Oct 2011 05:18:25 +0000 Subject: [New-bugs-announce] [issue13185] Why does Python interpreter care about curvy quotes in comments? Message-ID: <1318655905.33.0.141769881228.issue13185@psf.upfronthosting.co.za> New submission from Phillip Feldman : When I try to run a Python script that contains curvy quotes inside comments, the interpreter gets upset: SyntaxError: Non-ASCII character '\x92' in file ... on line 20198, but no encoding declared; see http://www.python.org/peps/pep-0263.html for details Given that the quotes are appearing only in comments, why does the interpreter care about them? Why should it be doing anything at all with comments other than stripping them off? ---------- messages: 145583 nosy: Phillip.M.Feldman priority: normal severity: normal status: open title: Why does Python interpreter care about curvy quotes in comments? _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Oct 15 15:30:38 2011 From: report at bugs.python.org (Stefan Behnel) Date: Sat, 15 Oct 2011 13:30:38 +0000 Subject: [New-bugs-announce] [issue13186] instance_ass_item() broken in classobject.c (Py2.7) Message-ID: <1318685438.52.0.865873705408.issue13186@psf.upfronthosting.co.za> New submission from Stefan Behnel : Starting at line 1223 in classobject.c, you can find this code: if (item == NULL) arg = PyInt_FromSsize_t(i); else arg = Py_BuildValue("(nO)", i, item); if (arg == NULL) { Py_DECREF(func); return -1; } res = PyEval_CallObject(func, arg); If item is NULL, arg will be assigned an int object. Otherwise, it will receive a tuple. Only the second case works in the subsequent call to PyEval_CallObject(), i.e. arg must always be assigned an argument tuple. A quick fix would be to call Py_BuildValue("(n)", i) in the first case. The code just did a getattr(), so this is not performance critical anymore. I found this bug because the test_class.py test suite was failing in Cython. ---------- components: Interpreter Core messages: 145590 nosy: scoder priority: normal severity: normal status: open title: instance_ass_item() broken in classobject.c (Py2.7) type: behavior versions: Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Oct 15 22:28:45 2011 From: report at bugs.python.org (Antoine Pitrou) Date: Sat, 15 Oct 2011 20:28:45 +0000 Subject: [New-bugs-announce] [issue13187] relative imports don't work when circular Message-ID: <1318710525.2.0.403840698833.issue13187@psf.upfronthosting.co.za> New submission from Antoine Pitrou : This is, to say the least, annoying. $ mkdir mypackage $ touch mypackage/__init__.py $ echo "from . import b" > mypackage/a.py $ echo "from . import a" > mypackage/b.py $ ./python -c "import mypackage.a" Traceback (most recent call last): File "", line 1, in File "mypackage/a.py", line 1, in from . import b File "mypackage/b.py", line 1, in from . import a ImportError: cannot import name a ---------- components: Interpreter Core messages: 145606 nosy: ncoghlan, pitrou priority: normal severity: normal status: open title: relative imports don't work when circular type: behavior versions: Python 3.2, Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Oct 16 01:34:30 2011 From: report at bugs.python.org (Antoine Pitrou) Date: Sat, 15 Oct 2011 23:34:30 +0000 Subject: [New-bugs-announce] [issue13188] generator.throw() ignores __traceback__ of exception Message-ID: <1318721670.51.0.393760482816.issue13188@psf.upfronthosting.co.za> New submission from Antoine Pitrou : In the following code, the original traceback attached to the exception thrown into the generator is ignored: def gen(): try: yield except: raise g = gen() try: 1/0 except ZeroDivisionError as v: g.throw(v) But if you replace the last line with: g.throw(type(v), v, v.__traceback__) then the original traceback gets appended. g.throw() should have fetched the __traceback__ attribute by itself. ---------- components: Interpreter Core messages: 145609 nosy: ncoghlan, pitrou priority: normal severity: normal status: open title: generator.throw() ignores __traceback__ of exception type: behavior versions: Python 3.2, Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Oct 16 16:29:52 2011 From: report at bugs.python.org (Paul Moore) Date: Sun, 16 Oct 2011 14:29:52 +0000 Subject: [New-bugs-announce] [issue13189] New bdist_simple binary distribution format for packaging Message-ID: <1318775392.19.0.757483007173.issue13189@psf.upfronthosting.co.za> New submission from Paul Moore : The attached patch is a first version of a bdist_simple binary distribution format for packaging. There is a bdist_simple command to build the distribution, and pysetup install has been updated to handle bdist_simple format distributions (only as local files, there is no support for discovering or downloading binary distributions at this point). The patch still needs documentation and tests, but has been manually tested on Windows, for both Python and C distributions. ---------- assignee: tarek components: Distutils2 files: bdist_simple.patch keywords: patch messages: 145621 nosy: alexis, eric.araujo, pmoore, tarek priority: normal severity: normal status: open title: New bdist_simple binary distribution format for packaging type: feature request versions: Python 3.3 Added file: http://bugs.python.org/file23417/bdist_simple.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Oct 16 19:47:52 2011 From: report at bugs.python.org (Noam Eliahu) Date: Sun, 16 Oct 2011 17:47:52 +0000 Subject: [New-bugs-announce] [issue13190] ConfigParser uses wrong newline on Windows Message-ID: <1318787272.4.0.221500033494.issue13190@psf.upfronthosting.co.za> New submission from Noam Eliahu : ConfigParser writes data to the config file using hard-coded newline: '\n'. This newline is not suitable for Windows. Therefore, the config file isn't readable in Notepad.exe. os.linesep should be used instead. ---------- components: None messages: 145632 nosy: noam.el priority: normal severity: normal status: open title: ConfigParser uses wrong newline on Windows type: behavior versions: Python 2.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Oct 16 22:09:04 2011 From: report at bugs.python.org (Mike Hoy) Date: Sun, 16 Oct 2011 20:09:04 +0000 Subject: [New-bugs-announce] [issue13191] Typo in argparse documentation Message-ID: <1318795744.19.0.406202573511.issue13191@psf.upfronthosting.co.za> New submission from Mike Hoy : In the Docs mailing list a typo was pointed out in argparse docs. http://docs.python.org/dev/library/argparse.html#metavar > "So, a single positional argument with dest='bar' will that argument > will be referred to as bar." > "So, a single positional argument with dest='bar' WITH that argument > will be referred to as bar." Eli Bendersky: > I agree the original sentence makes little sense. But I'm not sure > your correction fully fixes it either - "a single positional argument > ... with that argument" doesn't sound right. > Perhaps it should just say: > "So, a single positional argument with dest='bar' will be referred to > as bar" ? Patch says "So,a single positional argument with dest='bar' will be referred to as bar" ---------- assignee: docs at python components: Documentation files: typo-argparse.diff keywords: patch messages: 145636 nosy: docs at python, mikehoy priority: normal severity: normal status: open title: Typo in argparse documentation Added file: http://bugs.python.org/file23420/typo-argparse.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Oct 16 22:25:16 2011 From: report at bugs.python.org (Antoine Pitrou) Date: Sun, 16 Oct 2011 20:25:16 +0000 Subject: [New-bugs-announce] [issue13192] ImportError silences low-level OS errors Message-ID: <1318796716.98.0.562997558521.issue13192@psf.upfronthosting.co.za> New submission from Antoine Pitrou : Not sure this is by design or not, but I wanted to report this issue (it's rather hard to diagnose). Here the file descriptor limit is reached, and "import" raises an ImportError while it would be more helpful to let the original OS error slip through (which, here, is EMFILE): >>> import resource >>> resource.setrlimit(resource.RLIMIT_NOFILE, (2, 100)) >>> import encodings.idna Traceback (most recent call last): File "", line 1, in ImportError: No module named 'idna' >>> resource.setrlimit(resource.RLIMIT_NOFILE, (100, 100)) >>> import encodings.idna >>> ---------- components: Interpreter Core messages: 145639 nosy: brett.cannon, ncoghlan, pitrou priority: normal severity: normal status: open title: ImportError silences low-level OS errors type: behavior versions: Python 3.2, Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Oct 16 23:24:53 2011 From: report at bugs.python.org (Antoine Pitrou) Date: Sun, 16 Oct 2011 21:24:53 +0000 Subject: [New-bugs-announce] [issue13193] test_packaging and test_distutils failures under Windows Message-ID: <1318800293.23.0.0737706148876.issue13193@psf.upfronthosting.co.za> New submission from Antoine Pitrou : http://www.python.org/dev/buildbot/all/builders/x86%20XP-5%203.x/builds/3593/steps/test/logs/stdio ---------- assignee: tarek components: Distutils, Distutils2, Library (Lib), Tests messages: 145643 nosy: alexis, eric.araujo, pitrou, tarek priority: high severity: normal status: open title: test_packaging and test_distutils failures under Windows type: behavior versions: Python 3.2, Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Oct 16 23:29:40 2011 From: report at bugs.python.org (=?utf-8?q?Simon_El=C3=A9n?=) Date: Sun, 16 Oct 2011 21:29:40 +0000 Subject: [New-bugs-announce] [issue13194] zlib (de)compressobj copy() method missing on Windows Message-ID: <1318800580.02.0.678946639591.issue13194@psf.upfronthosting.co.za> New submission from Simon El?n : The zlib (de)compressobj copy() method is missing on Windows. Tested on Python 2.7.2 and 3.2.2 Windows binaries. I have not tried to build from source. (In the source code I can see a check for HAVE_ZLIB_COPY. Does the Windows binaries statically link the included zlib source? If so, it should be new enough to pass that check...) ---------- components: Library (Lib), Windows messages: 145644 nosy: Simon.El?n priority: normal severity: normal status: open title: zlib (de)compressobj copy() method missing on Windows type: behavior versions: Python 2.7, Python 3.2 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Oct 17 13:21:33 2011 From: report at bugs.python.org (anatoly techtonik) Date: Mon, 17 Oct 2011 11:21:33 +0000 Subject: [New-bugs-announce] [issue13195] subprocess: args with shell=True is not documented on Windows Message-ID: <1318850493.84.0.375275631996.issue13195@psf.upfronthosting.co.za> New submission from anatoly techtonik : For UNIX, it is said that if shell=False then you need to pass `args` as a list (if you want to pass any parameters to executable). Is that true for Windows (and perhaps other platforms) as well? Again, for UNIX it is said that with shell=True, and args is a list - every item except the first one is an argument to the shell itself. Is it the same on Windows? It would be better to just give advice in `shell` parameter description to "pass args as a list with shell=False or else you'll lose params in Unix. If shell=True you need to pass args as a string, because list is needed only if you need to pass arguments to shell itself." ---------- assignee: docs at python components: Documentation, Library (Lib) messages: 145662 nosy: docs at python, techtonik priority: normal severity: normal status: open title: subprocess: args with shell=True is not documented on Windows _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Oct 17 13:27:21 2011 From: report at bugs.python.org (anatoly techtonik) Date: Mon, 17 Oct 2011 11:27:21 +0000 Subject: [New-bugs-announce] [issue13196] subprocess: undocumented if shell=True is necessary to find executable in Windows PATH Message-ID: <1318850841.68.0.83326141038.issue13196@psf.upfronthosting.co.za> New submission from anatoly techtonik : The reason I ask is this changeset - http://code.google.com/p/spyderlib/source/detail?spec=svne5d86b685619a470d593aa5f9ee360ba60779bc1&r=323c6c697f045166e384cdc15803d40eebed0a2b - seems like without shell=True, subprocess.Popen is unable to find Mercurial executable in PATH. ---------- assignee: docs at python components: Documentation messages: 145664 nosy: docs at python, techtonik priority: normal severity: normal status: open title: subprocess: undocumented if shell=True is necessary to find executable in Windows PATH _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Oct 17 13:41:11 2011 From: report at bugs.python.org (anatoly techtonik) Date: Mon, 17 Oct 2011 11:41:11 +0000 Subject: [New-bugs-announce] [issue13197] subprocess: move shell arguments to a separate keyword param Message-ID: <1318851671.68.0.276363356463.issue13197@psf.upfronthosting.co.za> New submission from anatoly techtonik : subprocess.Popen(args, shell=shell) is implicitly inconsistent on Unix: 1. when shell=False, the args should be a list or you'll lose program options 2. when shell=True, the args should be a string or your program options will be passed to shell itself I propose to make consistent behaviour - require args to be a list, and pass shell options in a separate shell_args keyword argument. If it not for python4, then perhaps it can be implemented in PopenShell() and PopenSystem() functions. This will also require unification of behaviour across platforms. ---------- components: Library (Lib) messages: 145669 nosy: techtonik priority: normal severity: normal status: open title: subprocess: move shell arguments to a separate keyword param _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Oct 17 15:12:34 2011 From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=) Date: Mon, 17 Oct 2011 13:12:34 +0000 Subject: [New-bugs-announce] [issue13198] Remove duplicate definition of write_record_file Message-ID: <1318857154.54.0.641953188635.issue13198@psf.upfronthosting.co.za> New submission from ?ric Araujo : We have duplicate code to write a PEP 376 RECORD file in packaging.util and packaging.command.install_distinfo. The command should use the function from p7g.util. Tests would also be good: Currently, one function uses LF as end of line (change made by Tarek, so authoritative) but the other uses os.linesep. ---------- assignee: eric.araujo components: Distutils2 keywords: easy messages: 145687 nosy: alexis, eric.araujo priority: normal severity: normal stage: test needed status: open title: Remove duplicate definition of write_record_file versions: 3rd party, Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Oct 17 15:23:45 2011 From: report at bugs.python.org (Sven Marnach) Date: Mon, 17 Oct 2011 13:23:45 +0000 Subject: [New-bugs-announce] [issue13199] slice_richcompare() might leak an object in rare cases Message-ID: <1318857825.17.0.435087325593.issue13199@psf.upfronthosting.co.za> New submission from Sven Marnach : If exactly one of the two tuple allocations in [1] fails, the tuple that is successfully allocated won't be freed. (This probably never happened. Are you interested in this kind of bug report anyway?) [1]: http://hg.python.org/cpython/file/f6b3ad301851/Objects/sliceobject.c#l349 ---------- components: Interpreter Core messages: 145689 nosy: smarnach priority: normal severity: normal status: open title: slice_richcompare() might leak an object in rare cases _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Oct 17 16:29:00 2011 From: report at bugs.python.org (Sven Marnach) Date: Mon, 17 Oct 2011 14:29:00 +0000 Subject: [New-bugs-announce] [issue13200] Add start, stop and step attributes to range objects Message-ID: <1318861740.84.0.628710969686.issue13200@psf.upfronthosting.co.za> New submission from Sven Marnach : As discussed on python-ideas [1], range objects should expose their start, stop and step values as read-only data attributes. I've attached a patch to this end. I'll open a separate issue for range comparison. [1]: http://mail.python.org/pipermail/python-ideas/2011-October/012356.html ---------- components: Interpreter Core files: range-members messages: 145701 nosy: smarnach priority: normal severity: normal status: open title: Add start, stop and step attributes to range objects type: feature request Added file: http://bugs.python.org/file23425/range-members _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Oct 17 16:52:54 2011 From: report at bugs.python.org (Sven Marnach) Date: Mon, 17 Oct 2011 14:52:54 +0000 Subject: [New-bugs-announce] [issue13201] Implement comparison operators for range objects Message-ID: <1318863174.33.0.432669073084.issue13201@psf.upfronthosting.co.za> New submission from Sven Marnach : It seems some sort of consensus on how to compare range objects has emerged from the python-ideas discussion on comparison of range objects [1]. The attached patch defines '==' and '!=' for range object equality based on the sequence of values they represent. The other comparison operators are left NotImplemented. [1]: http://mail.python.org/pipermail/python-ideas/2011-October/012376.html ---------- files: range-compare messages: 145705 nosy: smarnach priority: normal severity: normal status: open title: Implement comparison operators for range objects Added file: http://bugs.python.org/file23426/range-compare _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Oct 17 17:03:16 2011 From: report at bugs.python.org (David W. Lambert) Date: Mon, 17 Oct 2011 15:03:16 +0000 Subject: [New-bugs-announce] [issue13202] subprocess __exit__ attribute missing Message-ID: <1318863796.84.0.712149290856.issue13202@psf.upfronthosting.co.za> New submission from David W. Lambert : There are a number of issues with subprocess and __exit__ , 12494 status fixed among them. Program (which doesn't work as I had hoped, but that's not the issue): 'file p.py' import subprocess as S with S.Popen(('cat','-n',),shell=False,stdin=S.PIPE,stdout=S.PIPE,bufsize=1,universal_newlines=True) as p: p.stdin.write('these\n') print(p.stdout.readline()) Use: $ python3 p.py  Traceback (most recent call last): File "p.py", line 5, in print(p.stdout.readline()) KeyboardInterrupt $ $ python p.py Traceback (most recent call last): File "p.py", line 3, in with S.Popen(('cat','-n',),shell=False,stdin=S.PIPE,stdout=S.PIPE,bufsize=1,universal_newlines=True) as p: AttributeError: __exit__ $ $ python Python 2.7.1+ (r271:86832, Apr 11 2011, 18:13:53) [GCC 4.5.2] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> ---------- components: Interpreter Core, Library (Lib) messages: 145707 nosy: LambertDW priority: normal severity: normal status: open title: subprocess __exit__ attribute missing versions: Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Oct 17 19:50:35 2011 From: report at bugs.python.org (Terry J. Reedy) Date: Mon, 17 Oct 2011 17:50:35 +0000 Subject: [New-bugs-announce] [issue13203] Doc: say id() is only useful for existing objects Message-ID: <1318873835.36.0.466865504792.issue13203@psf.upfronthosting.co.za> New submission from Terry J. Reedy : Newbies too often do something like (3.2.2, ) >>> id(getattr(x, 'pop')) == id(x.pop) True and get confused by the (invalid) result, whereas >>> a,b=getattr(x, 'pop'),x.pop >>> id(a)==id(b) False works properly. I think we should add a sentence or two or three to the id() doc, such as Since a newly created argument object is either destroyed or becomes inaccessible before the function returns, *id(obj)* is only useful and valid if *obj* exists prior to the call and therefore after its return. The value of an expression such as *id(666)== id(667)* is arbitrary and meaningless. The id of the first int object might or might not be reused for the second one. ---------- assignee: docs at python components: Documentation messages: 145743 nosy: docs at python, terry.reedy priority: normal severity: normal status: open title: Doc: say id() is only useful for existing objects versions: Python 2.7, Python 3.2, Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Oct 18 00:14:25 2011 From: report at bugs.python.org (=?utf-8?q?Andreas_St=C3=BChrk?=) Date: Mon, 17 Oct 2011 22:14:25 +0000 Subject: [New-bugs-announce] [issue13204] sys.flags.__new__ crashes Message-ID: <1318889665.83.0.350090316357.issue13204@psf.upfronthosting.co.za> New submission from Andreas St?hrk : It's not possible (by intention) to instantiate a new instance of sys.flags. This is achieved by setting the "tp_new" slot to NULL (in `_PySys_Init()`), after `PyType_Ready()` is called, which means that a slot wrapper is added to the type dict for the "tp_new" slot (because the slot != NULL at that time). The problem is now that if one calls `sys.flags.__new__` directly, a null pointer dereference occurs in `tp_new_wrapper()`. Attached is a patch that fixes the crash and adds a test. ---------- files: sys_flags__new__crash.patch keywords: patch messages: 145763 nosy: Trundle priority: normal severity: normal status: open title: sys.flags.__new__ crashes type: crash versions: Python 2.7, Python 3.2, Python 3.3 Added file: http://bugs.python.org/file23431/sys_flags__new__crash.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Oct 18 03:53:53 2011 From: report at bugs.python.org (David Barnett) Date: Tue, 18 Oct 2011 01:53:53 +0000 Subject: [New-bugs-announce] [issue13205] NameErrors in generated setup.py (codecs, split_multiline) Message-ID: <1318902833.17.0.0898413636747.issue13205@psf.upfronthosting.co.za> New submission from David Barnett : The setup.py file currently generated by "pysetup generate-setup" fails to import the "codecs" module, and also uses a split_multiline function from distutils2/utils.py that's undefined in the setup script. ---------- assignee: tarek components: Distutils2 files: fix_nameerrors.patch keywords: patch messages: 145768 nosy: alexis, eric.araujo, mu_mind, tarek priority: normal severity: normal status: open title: NameErrors in generated setup.py (codecs, split_multiline) type: behavior versions: Python 2.7 Added file: http://bugs.python.org/file23435/fix_nameerrors.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Oct 18 08:31:14 2011 From: report at bugs.python.org (R Blackmore) Date: Tue, 18 Oct 2011 06:31:14 +0000 Subject: [New-bugs-announce] [issue13206] while loop vs for loop test Message-ID: <1318919474.2.0.667717683099.issue13206@psf.upfronthosting.co.za> New submission from R Blackmore : Using Python 3.2.2 on Windows 7 See attached file Was having problem with a program I was doing... couldn't get around issue unless I changed from "while" loop to "for" loop... WTF??? So restarted computer and then Python Shell and IDLE I wrote a very simple loop file... The 1st loop is a while loop that hangs and only prints divisor 1 and divisor 2 (Should also print divisor 5) For loop works as expected printing divisor 1 divisor 2 divisor 3 Unless I'm missing something both loops should return (i.e. print) same! Cheers ---------- components: IO files: LOOP_Test1.py messages: 145775 nosy: JavaJunkie priority: normal severity: normal status: open title: while loop vs for loop test versions: Python 3.2 Added file: http://bugs.python.org/file23436/LOOP_Test1.py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Oct 18 13:34:29 2011 From: report at bugs.python.org (Manuel de la Pena) Date: Tue, 18 Oct 2011 11:34:29 +0000 Subject: [New-bugs-announce] [issue13207] os.path.expanduser brakes when using unicode character in the username Message-ID: <1318937669.16.0.167083698894.issue13207@psf.upfronthosting.co.za> New submission from Manuel de la Pena : During our development we have experience the following: If you have a user in your Windows machine with a name hat uses Japanese characters like ???????? you will have the following in your system: * The Windows Shell will show the path correctly, that is: ?C:\Users\??????? * cmd.exe will show: ?C:\Users\??????? * All the env variables will be wrong, which means they will be similar to the info shown in cmd.exe The above is a problem because the implementation of expanduser in ntpath.py uses the env variables to get expand the path which means that in this case the returned path will be wrong. I have attached a small example of how to get the user profile path (~) on Windows using SHGetFolderPathW or SHGetKnownFolderPathW to fix the issue. PS: I don't know if this issue also occurs on python 3. ---------- components: Windows files: expanduser.py messages: 145798 nosy: mandel priority: normal severity: normal status: open title: os.path.expanduser brakes when using unicode character in the username type: behavior versions: Python 2.7 Added file: http://bugs.python.org/file23442/expanduser.py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Oct 18 13:49:49 2011 From: report at bugs.python.org (Deepak Dodo) Date: Tue, 18 Oct 2011 11:49:49 +0000 Subject: [New-bugs-announce] [issue13208] Problems with urllib on windows Message-ID: <1318938589.99.0.598751159325.issue13208@psf.upfronthosting.co.za> New submission from Deepak Dodo : When I try to read the contents of the webpage: http://www.ai-class.com/course/json/filter/QuizQuestion using urllib.read, it doesn't read the entire content. This behavior is only seen on windows and the same operation works fine on linux machines. ---------- components: Windows messages: 145800 nosy: Deepak.Dodo priority: normal severity: normal status: open title: Problems with urllib on windows type: behavior versions: Python 2.6, Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Oct 18 13:50:11 2011 From: report at bugs.python.org (STINNER Victor) Date: Tue, 18 Oct 2011 11:50:11 +0000 Subject: [New-bugs-announce] [issue13209] Refactor code using unicode_encode_call_errorhandler() in unicodeobject.c Message-ID: <1318938611.14.0.651217726677.issue13209@psf.upfronthosting.co.za> New submission from STINNER Victor : It's difficult to use unicode_encode_call_errorhandler() because the caller has to: - resize the output buffer (and check for integer overflow on the new size) - handle bytes and str for the replacement string: PyUnicode_EncodeDecimal() doesn't support bytes for example - encode replacement str: some encoders uses ASCII, unicode_encode_ucs1() uses Latin1, PyUnicode_EncodeCharmap() uses a recursive call (without check for infinite loop!), ... ; and raise a UnicodeEncodeError if the encoding fails It would be nice to factorize this code. I plan this implement this refactoring, it's just a reminder for me :-) ---------- components: Unicode messages: 145801 nosy: haypo priority: normal severity: normal status: open title: Refactor code using unicode_encode_call_errorhandler() in unicodeobject.c versions: Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Oct 18 14:55:21 2011 From: report at bugs.python.org (=?utf-8?b?U8OpYmFzdGllbiBTYWJsw6k=?=) Date: Tue, 18 Oct 2011 12:55:21 +0000 Subject: [New-bugs-announce] [issue13210] Support Visual Studio 2010 Message-ID: <1318942521.44.0.961979099616.issue13210@psf.upfronthosting.co.za> New submission from S?bastien Sabl? : Python for Windows is currently compiled with Visual Studio 2008. It is not possible to use Visual Studio 2010. It would be great to be able to compile Python with Visual Studio 2010: * some people may only have access to this compiler which is more recent * when embedding Python in an application compiled with Visual Studio 2010, you mix 2 C Runtime Libraries (msvcr90.dll and msvcr100.dll) which will generally result in a crash This is the parent issue. I have various patches to achieve that and I will try to open one issue by patch. I may also run a builtbot using that compiler. ---------- assignee: tarek components: Build, Distutils, Distutils2, Installation, Windows messages: 145803 nosy: alexis, eric.araujo, mhammond, sable, tarek priority: normal severity: normal status: open title: Support Visual Studio 2010 type: feature request versions: Python 2.7, Python 3.2 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Oct 18 15:06:08 2011 From: report at bugs.python.org (Jason R. Coombs) Date: Tue, 18 Oct 2011 13:06:08 +0000 Subject: [New-bugs-announce] [issue13211] urllib2.HTTPError does not have 'reason' attribute. Message-ID: <1318943168.93.0.520705450261.issue13211@psf.upfronthosting.co.za> New submission from Jason R. Coombs : The urllib2 docs indicate that HTTPError is a subclass of URLError and that URLError has an attribute of 'reason', but HTTPError does not have this attribute. The docs should be updated to reflect this deviance. It appears the Python 3.2 docs no longer include documentation for URLError Python 2.7.2 >>> try:urllib2.urlopen('http://api.wordnik.com/v4/word.json/foo/examples') ... except urllib2.HTTPError as exc: ... print(dir(exc)) ... ['_HTTPError__super_init', '__class__', '__delattr__', '__dict__', '__doc__', '__format__', '__getattribute__', '__getitem__', '__getslice__', '__hash__', '__init__', '__iter__', '__module__', '__new__', '__reduce__', '__reduce_ex__', '__repr__', '__setattr__', '__setstate__', '__sizeof__', '__str__', '__subclasshook__', '__unicode__', '__weakref__', 'args', 'close', 'code', 'errno', 'filename', 'fileno', 'fp', 'getcode', 'geturl', 'hdrs', 'headers', 'info', 'message', 'msg', 'next', 'read', 'readline', 'readlines', 'strerror', 'url'] The same issue exists in Python 3.2.2. Here's what I propose: - For Python 3.2 and 3.3, update HTTPError to supply a @property, aliasing .msg (will .msg always be a suitable .reason?). - For Python 2.7, document the deviance, such as by adding the following wording to the HTTPError docs: "Unlike URLError, HTTPError does not supply a reason attribute. The reason can be retrieved through the msg attribute." ---------- assignee: docs at python components: Documentation messages: 145805 nosy: docs at python, jason.coombs priority: normal severity: normal status: open title: urllib2.HTTPError does not have 'reason' attribute. versions: Python 2.7, Python 3.2, Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Oct 18 20:00:32 2011 From: report at bugs.python.org (Tomasz Buchert) Date: Tue, 18 Oct 2011 18:00:32 +0000 Subject: [New-bugs-announce] [issue13212] json library is decoding/encoding when it should not Message-ID: <1318960832.41.0.586770861075.issue13212@psf.upfronthosting.co.za> New submission from Tomasz Buchert : Hi there! According to http://www.ietf.org/rfc/rfc4627.txt . The JSON object is either a list or a dictionary with other elements in it. However Python's implementation took liberty to parse also basic types, like integers, strings, floats, etc. For example: >>> import json >>> json.loads('42') 42 >>> json.dumps(3.141592) '3.141592' It wouldn't be a problem if other implementations would adhere to this behavior, but this is not true. Take Ruby for example: irb(main):007:0> require 'rubygems'; irb(main):008:0* require 'json'; irb(main):009:0* JSON.parse '42' JSON::ParserError: 743: unexpected token at '42' from /var/lib/gems/1.8/gems/json-1.6.1/lib/json/common.rb:148:in `parse' from /var/lib/gems/1.8/gems/json-1.6.1/lib/json/common.rb:148:in `parse' from (irb):9 from :0 irb(main):010:0> JSON.generate(3.141592) JSON::GeneratorError: only generation of JSON objects or arrays allowed from /var/lib/gems/1.8/gems/json-1.6.1/lib/json/common.rb:216:in `generate' from /var/lib/gems/1.8/gems/json-1.6.1/lib/json/common.rb:216:in `generate' from (irb):10 from :0 Also http://jsonlint.com/ considers it an error. I know this is not very important, but I've ran into this today when trying to parse JSON in Ruby which was produced in Python. I've made a patch for that, but I still need to fix tests and there are many of them. I first would like to know if it is going to be fixed, then I will complete the patch. Thanks for Python, anyway! Tomek ---------- components: Library (Lib) messages: 145847 nosy: thinred priority: normal severity: normal status: open title: json library is decoding/encoding when it should not versions: Python 2.6, Python 2.7, Python 3.1, Python 3.2, Python 3.3, Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Oct 18 20:16:43 2011 From: report at bugs.python.org (Petri Lehtinen) Date: Tue, 18 Oct 2011 18:16:43 +0000 Subject: [New-bugs-announce] [issue13213] generator.throw() behavior Message-ID: <1318961803.9.0.966531589594.issue13213@psf.upfronthosting.co.za> New submission from Petri Lehtinen : The documentation of generator.throw() gives this signature: generator.throw(type[, value[, traceback]]) Looking at the code, it accepts the following arguments: g.throw(ExcType) --> raise ExcType() g.throw(ExcType, None) --> raise ExcType() g.throw(ExcType, None, tb) --> raise ExcType().with_traceback(tb) g.throw(ExcType, instace_of_ExcType) --> raise instance_of_ExcType g.throw(ExcType, instace_of_ExcType, tb) --> raise instance_of_ExcType.with_traceback(tb) g.throw(ExcType, other_value) --> raise ExcType(other_value) g.throw(ExcType, other_value, tb) --> raise ExcType(other_value).with_traceback(tb) Up to this point, I think everything is in line with the documentation. But it also accepts the following (now that issue 13188 is fixed): g.throw(exc_instance) --> raise exc_instance (preserving the traceback of exc_instance) g.throw(exc_instance, None) --> raise exc_instance (preserving the traceback of exc_instance) g.throw(exc_instance, None, tb) --> raise exc_instance.with_traceback(tb) It does not accept these, throwing a TypeError: g.throw(exc_instance, some_value_other_than_None) g.throw(exc_instance, some_value_other_than_None, tb) g.throw(exc_instance, tb) The documentation is really unclear on throwing existing exception instances with (exc_instance) or (exc_instance, None), and that calling with (type, value) or (type, value, tb) will create a new exception if not isinstance(value, type). ---------- assignee: docs at python components: Documentation, Interpreter Core messages: 145848 nosy: docs at python, ezio.melotti, ncoghlan, petri.lehtinen, pitrou priority: normal severity: normal status: open title: generator.throw() behavior type: behavior versions: Python 2.7, Python 3.2, Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Oct 18 21:16:06 2011 From: report at bugs.python.org (Garrett Cooper) Date: Tue, 18 Oct 2011 19:16:06 +0000 Subject: [New-bugs-announce] [issue13214] Cmd: list available completions from the cmd.Cmd subclass and filter out EOF handler(s) Message-ID: <1318965366.62.0.48247525728.issue13214@psf.upfronthosting.co.za> New submission from Garrett Cooper : 1. The current code in cmd.get_names does a dir on the derived class for cmd.Cmd object instead, which means that if I do something similar to the following: class CLI(cmd.Cmd): def register_subcommand(self, cmd, cli_class): def call_cli(self): cli = cli_class() cli.cmdloop() setattr(self, 'do_%s' % (cmd, ), call_cli) it won't register the command in the completion list or help list. 2. Registering a do_EOF handler is a bit of a hack to work around the fact that entering in ^D on the command line prints out: (Cmd) *** Unknown syntax: EOF I can't speak to the fact that my desired behavior should be enforced (basically trickle up the EOFError like so): def do_EOF(self, arg): raise EOFError so what I'm proposing instead is that it be filtered out by default. Given that there's some value in allowing developers to build custom filter rules for the completions (example: certain commands can be undocumented, hidden to lower privilege users, etc), I figured it would be wise to create a custom mechanism for filtering out commands. This could be cleaned up to use better python idioms like a generator, cache the data and have a refresh method, etc, but this is a good first start. ---------- components: Library (Lib) files: python-cmd-better-filtering.patch keywords: patch messages: 145856 nosy: yaneurabeya priority: normal severity: normal status: open title: Cmd: list available completions from the cmd.Cmd subclass and filter out EOF handler(s) type: feature request versions: Python 2.7, Python 3.4 Added file: http://bugs.python.org/file23449/python-cmd-better-filtering.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Oct 18 21:16:57 2011 From: report at bugs.python.org (Benjamin Gilbert) Date: Tue, 18 Oct 2011 19:16:57 +0000 Subject: [New-bugs-announce] [issue13215] multiprocessing Manager.connect() aggressively retries refused connections Message-ID: <1318965417.81.0.122561387998.issue13215@psf.upfronthosting.co.za> New submission from Benjamin Gilbert : multiprocessing.managers.BaseManager.connect() takes 20 seconds to return on failure, even if the server refuses the connection. This is because the function that creates the connection, multiprocessing.connection.SocketClient(), handles ECONNREFUSED by retrying the connection attempt every 10 ms for 20 seconds. While a 20 second timeout may make sense for *unresponsive* servers, ECONNREFUSED probably indicates that the server is not listening on this port, so hammering it with 1,999 more connection attempts isn't going to help. In this case, SocketClient() should fail immediately, or -- at most -- retry a small number of times with exponential backoff. ---------- components: Library (Lib) messages: 145857 nosy: bgilbert priority: normal severity: normal status: open title: multiprocessing Manager.connect() aggressively retries refused connections type: behavior versions: Python 2.7, Python 3.2 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Oct 19 00:44:31 2011 From: report at bugs.python.org (STINNER Victor) Date: Tue, 18 Oct 2011 22:44:31 +0000 Subject: [New-bugs-announce] [issue13216] Add cp65001 codec Message-ID: <1318977871.28.0.0371088882056.issue13216@psf.upfronthosting.co.za> New submission from STINNER Victor : Thanks to #12281, it is now trivial to implement any Windows code page in Python. I don't know if existing code pages (e.g. cp932) should use codecs.code_page_encode/.code_page_decode on Windows, or continue to use the (portable) Python code. Users want the code page 65001, even if I consider that it is useless to set the ANSI code page to 65001 in a console (see issue #1602), but that's a different story. Attached patch implements this code page. ---------- components: Unicode files: cp65001.py messages: 145871 nosy: amaury.forgeotdarc, haypo, loewis priority: normal severity: normal status: open title: Add cp65001 codec versions: Python 3.3 Added file: http://bugs.python.org/file23453/cp65001.py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Oct 19 02:14:18 2011 From: report at bugs.python.org (John O'Connor) Date: Wed, 19 Oct 2011 00:14:18 +0000 Subject: [New-bugs-announce] [issue13217] Missing header dependencies in Makefile Message-ID: <1318983258.55.0.960297108265.issue13217@psf.upfronthosting.co.za> New submission from John O'Connor : I think ucs{1,2,4}lib.h, asciilib.h and a few other files should be in the Makefile deps list for unicodeobject.c. Patch included. ---------- components: Build files: makefile.patch keywords: patch messages: 145881 nosy: haypo, jcon, pitrou priority: normal severity: normal status: open title: Missing header dependencies in Makefile type: behavior versions: Python 3.2, Python 3.3 Added file: http://bugs.python.org/file23456/makefile.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Oct 19 14:30:50 2011 From: report at bugs.python.org (Nadeem Vawda) Date: Wed, 19 Oct 2011 12:30:50 +0000 Subject: [New-bugs-announce] [issue13218] test_ssl failures on Ubuntu 11.10 Message-ID: <1319027450.54.0.786023148917.issue13218@psf.upfronthosting.co.za> New submission from Nadeem Vawda : Since upgrading to Ubuntu 11.10, I've been getting the following failures in test_ssl: ====================================================================== FAIL: test_protocol_sslv3 (test.test_ssl.ThreadedTests) Connecting to an SSLv3 server with various client options ---------------------------------------------------------------------- Traceback (most recent call last): File "/home/nadeem/code/src/cpython/def/Lib/test/test_ssl.py", line 1415, in test_protocol_sslv3 try_protocol_combo(ssl.PROTOCOL_SSLv3, ssl.PROTOCOL_SSLv23, False) File "/home/nadeem/code/src/cpython/def/Lib/test/test_ssl.py", line 1232, in try_protocol_combo ssl.get_protocol_name(server_protocol))) AssertionError: Client protocol SSLv23 succeeded with server protocol SSLv3! ====================================================================== FAIL: test_protocol_tlsv1 (test.test_ssl.ThreadedTests) Connecting to a TLSv1 server with various client options ---------------------------------------------------------------------- Traceback (most recent call last): File "/home/nadeem/code/src/cpython/def/Lib/test/test_ssl.py", line 1433, in test_protocol_tlsv1 try_protocol_combo(ssl.PROTOCOL_TLSv1, ssl.PROTOCOL_SSLv23, False) File "/home/nadeem/code/src/cpython/def/Lib/test/test_ssl.py", line 1232, in try_protocol_combo ssl.get_protocol_name(server_protocol))) AssertionError: Client protocol SSLv23 succeeded with server protocol TLSv1! ---------------------------------------------------------------------- and this (presumably related) failure in test_nntplib: ====================================================================== ERROR: setUpClass (test.test_nntplib.NetworkedNNTP_SSLTests) ---------------------------------------------------------------------- Traceback (most recent call last): File "/home/nadeem/code/src/cpython/def/Lib/test/test_nntplib.py", line 291, in setUpClass cls.server = cls.NNTP_CLASS(cls.NNTP_HOST, timeout=TIMEOUT, usenetrc=False) File "/home/nadeem/code/src/cpython/def/Lib/nntplib.py", line 1052, in __init__ readermode=readermode, timeout=timeout) File "/home/nadeem/code/src/cpython/def/Lib/nntplib.py", line 344, in __init__ self.getcapabilities() File "/home/nadeem/code/src/cpython/def/Lib/nntplib.py", line 380, in getcapabilities resp, caps = self.capabilities() File "/home/nadeem/code/src/cpython/def/Lib/nntplib.py", line 546, in capabilities resp, lines = self._longcmdstring("CAPABILITIES") File "/home/nadeem/code/src/cpython/def/Lib/nntplib.py", line 513, in _longcmdstring resp, list = self._getlongresp(file) File "/home/nadeem/code/src/cpython/def/Lib/nntplib.py", line 464, in _getlongresp resp = self._getresp() File "/home/nadeem/code/src/cpython/def/Lib/nntplib.py", line 437, in _getresp resp = self._getline() File "/home/nadeem/code/src/cpython/def/Lib/nntplib.py", line 425, in _getline if not line: raise EOFError EOFError 3.2 gives a different set of failures in test_ssl (with the same failure in test_nntplib): ====================================================================== ERROR: test_constructor (test.test_ssl.ContextTests) ---------------------------------------------------------------------- Traceback (most recent call last): File "/home/nadeem/code/src/cpython/3.2/Lib/test/test_ssl.py", line 82, in f return func(*args, **kwargs) File "/home/nadeem/code/src/cpython/3.2/Lib/test/test_ssl.py", line 345, in test_constructor ctx = ssl.SSLContext(ssl.PROTOCOL_SSLv2) File "/home/nadeem/code/src/cpython/3.2/Lib/ssl.py", line 168, in __new__ return _SSLContext.__new__(cls, protocol) ssl.SSLError: failed to allocate SSL context ====================================================================== ERROR: test_protocol (test.test_ssl.ContextTests) ---------------------------------------------------------------------- Traceback (most recent call last): File "/home/nadeem/code/src/cpython/3.2/Lib/test/test_ssl.py", line 82, in f return func(*args, **kwargs) File "/home/nadeem/code/src/cpython/3.2/Lib/test/test_ssl.py", line 356, in test_protocol ctx = ssl.SSLContext(proto) File "/home/nadeem/code/src/cpython/3.2/Lib/ssl.py", line 168, in __new__ return _SSLContext.__new__(cls, protocol) ssl.SSLError: failed to allocate SSL context ====================================================================== ERROR: test_session_stats (test.test_ssl.ContextTests) ---------------------------------------------------------------------- Traceback (most recent call last): File "/home/nadeem/code/src/cpython/3.2/Lib/test/test_ssl.py", line 82, in f return func(*args, **kwargs) File "/home/nadeem/code/src/cpython/3.2/Lib/test/test_ssl.py", line 453, in test_session_stats ctx = ssl.SSLContext(proto) File "/home/nadeem/code/src/cpython/3.2/Lib/ssl.py", line 168, in __new__ return _SSLContext.__new__(cls, protocol) ssl.SSLError: failed to allocate SSL context ====================================================================== ERROR: test_echo (test.test_ssl.ThreadedTests) Basic test of an SSL client connecting to a server ---------------------------------------------------------------------- Traceback (most recent call last): File "/home/nadeem/code/src/cpython/3.2/Lib/test/test_ssl.py", line 82, in f return func(*args, **kwargs) File "/home/nadeem/code/src/cpython/3.2/Lib/test/test_ssl.py", line 1147, in test_echo context = ssl.SSLContext(protocol) File "/home/nadeem/code/src/cpython/3.2/Lib/ssl.py", line 168, in __new__ return _SSLContext.__new__(cls, protocol) ssl.SSLError: failed to allocate SSL context ====================================================================== ERROR: test_protocol_sslv2 (test.test_ssl.ThreadedTests) Connecting to an SSLv2 server with various client options ---------------------------------------------------------------------- Traceback (most recent call last): File "/home/nadeem/code/src/cpython/3.2/Lib/test/test_ssl.py", line 82, in f return func(*args, **kwargs) File "/home/nadeem/code/src/cpython/3.2/Lib/test/test_ssl.py", line 1256, in test_protocol_sslv2 try_protocol_combo(ssl.PROTOCOL_SSLv2, ssl.PROTOCOL_SSLv2, True) File "/home/nadeem/code/src/cpython/3.2/Lib/test/test_ssl.py", line 1108, in try_protocol_combo client_context = ssl.SSLContext(client_protocol) File "/home/nadeem/code/src/cpython/3.2/Lib/ssl.py", line 168, in __new__ return _SSLContext.__new__(cls, protocol) ssl.SSLError: failed to allocate SSL context ====================================================================== ERROR: test_protocol_sslv3 (test.test_ssl.ThreadedTests) Connecting to an SSLv3 server with various client options ---------------------------------------------------------------------- Traceback (most recent call last): File "/home/nadeem/code/src/cpython/3.2/Lib/test/test_ssl.py", line 82, in f return func(*args, **kwargs) File "/home/nadeem/code/src/cpython/3.2/Lib/test/test_ssl.py", line 1317, in test_protocol_sslv3 try_protocol_combo(ssl.PROTOCOL_SSLv3, ssl.PROTOCOL_SSLv2, False) File "/home/nadeem/code/src/cpython/3.2/Lib/test/test_ssl.py", line 1108, in try_protocol_combo client_context = ssl.SSLContext(client_protocol) File "/home/nadeem/code/src/cpython/3.2/Lib/ssl.py", line 168, in __new__ return _SSLContext.__new__(cls, protocol) ssl.SSLError: failed to allocate SSL context ====================================================================== ERROR: test_protocol_tlsv1 (test.test_ssl.ThreadedTests) Connecting to a TLSv1 server with various client options ---------------------------------------------------------------------- Traceback (most recent call last): File "/home/nadeem/code/src/cpython/3.2/Lib/test/test_ssl.py", line 82, in f return func(*args, **kwargs) File "/home/nadeem/code/src/cpython/3.2/Lib/test/test_ssl.py", line 1334, in test_protocol_tlsv1 try_protocol_combo(ssl.PROTOCOL_TLSv1, ssl.PROTOCOL_SSLv2, False) File "/home/nadeem/code/src/cpython/3.2/Lib/test/test_ssl.py", line 1108, in try_protocol_combo client_context = ssl.SSLContext(client_protocol) File "/home/nadeem/code/src/cpython/3.2/Lib/ssl.py", line 168, in __new__ return _SSLContext.__new__(cls, protocol) ssl.SSLError: failed to allocate SSL context ====================================================================== FAIL: test_options (test.test_ssl.ContextTests) ---------------------------------------------------------------------- Traceback (most recent call last): File "/home/nadeem/code/src/cpython/3.2/Lib/test/test_ssl.py", line 82, in f return func(*args, **kwargs) File "/home/nadeem/code/src/cpython/3.2/Lib/test/test_ssl.py", line 370, in test_options self.assertEqual(ssl.OP_ALL, ctx.options) AssertionError: 4095 != 16781311 ---------------------------------------------------------------------- On 2.7, the failures are again different: ====================================================================== ERROR: test_protocol_sslv2 (test.test_ssl.ThreadedTests) Connecting to an SSLv2 server with various client options ---------------------------------------------------------------------- Traceback (most recent call last): File "/home/nadeem/code/src/cpython/2.7/Lib/test/test_ssl.py", line 75, in f return func(*args, **kwargs) File "/home/nadeem/code/src/cpython/2.7/Lib/test/test_ssl.py", line 986, in test_protocol_sslv2 try_protocol_combo(ssl.PROTOCOL_SSLv2, ssl.PROTOCOL_SSLv2, True) File "/home/nadeem/code/src/cpython/2.7/Lib/test/test_ssl.py", line 856, in try_protocol_combo ciphers="ALL", chatty=False) File "/home/nadeem/code/src/cpython/2.7/Lib/test/test_ssl.py", line 808, in server_params_test s.connect((HOST, server.port)) File "/home/nadeem/code/src/cpython/2.7/Lib/ssl.py", line 322, in connect self._real_connect(addr, False) File "/home/nadeem/code/src/cpython/2.7/Lib/ssl.py", line 305, in _real_connect self.ca_certs, self.ciphers) SSLError: _ssl.c:316: Invalid SSL protocol variant specified. ====================================================================== FAIL: test_protocol_sslv3 (test.test_ssl.ThreadedTests) Connecting to an SSLv3 server with various client options ---------------------------------------------------------------------- Traceback (most recent call last): File "/home/nadeem/code/src/cpython/2.7/Lib/test/test_ssl.py", line 75, in f return func(*args, **kwargs) File "/home/nadeem/code/src/cpython/2.7/Lib/test/test_ssl.py", line 1028, in test_protocol_sslv3 try_protocol_combo(ssl.PROTOCOL_SSLv3, ssl.PROTOCOL_SSLv23, False) File "/home/nadeem/code/src/cpython/2.7/Lib/test/test_ssl.py", line 870, in try_protocol_combo ssl.get_protocol_name(server_protocol))) AssertionError: Client protocol SSLv23 succeeded with server protocol SSLv3! ====================================================================== FAIL: test_protocol_tlsv1 (test.test_ssl.ThreadedTests) Connecting to a TLSv1 server with various client options ---------------------------------------------------------------------- Traceback (most recent call last): File "/home/nadeem/code/src/cpython/2.7/Lib/test/test_ssl.py", line 75, in f return func(*args, **kwargs) File "/home/nadeem/code/src/cpython/2.7/Lib/test/test_ssl.py", line 1042, in test_protocol_tlsv1 try_protocol_combo(ssl.PROTOCOL_TLSv1, ssl.PROTOCOL_SSLv23, False) File "/home/nadeem/code/src/cpython/2.7/Lib/test/test_ssl.py", line 870, in try_protocol_combo ssl.get_protocol_name(server_protocol))) AssertionError: Client protocol SSLv23 succeeded with server protocol TLSv1! ---------------------------------------------------------------------- The failures were probably caused by Ubuntu upgrading from openssl-0.9.8 to openssl-1.0.0 in 11.10 -- I've reproduced the failures on three different Ubuntu 11.10 machines, and none of the buildbots are having this problem. For reference, the list of changes between 0.9.8 and 1.0.0 (look for the section "Changes between 0.9.8n and 1.0.0 [29 Mar 2010]"): http://www.openssl.org/news/changelog.html ---------- components: Extension Modules messages: 145902 nosy: giampaolo.rodola, janssen, nadeem.vawda, pitrou priority: normal severity: normal stage: needs patch status: open title: test_ssl failures on Ubuntu 11.10 versions: Python 2.7, Python 3.2, Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Oct 19 16:14:40 2011 From: report at bugs.python.org (becky lewis) Date: Wed, 19 Oct 2011 14:14:40 +0000 Subject: [New-bugs-announce] [issue13219] re module doc has minor inaccuracy in character sets Message-ID: <1319033680.8.0.92268984905.issue13219@psf.upfronthosting.co.za> New submission from becky lewis : The documentation for the re module (specifically the section for []) states that: "If you want to include a ']' or a '-' inside a set, precede it with a backslash, or place it as the first character." However, after finding a typo in a regex I wrote it turns out to be false. Using the following regex finds a match: >>> regex = re.compile(r'[123ab-f-]+') >>> regex.match('-') <_sre.SRE_Match object at 0x8dd1b10> I am not sure if this is an issue with the documentation or if the re module itself should not allow this behaviour. It would be nice if the documentation warned that hyphens (and other 'special' characters such as [) that are not escaped may still be matched, even though they are not the first character. ---------- assignee: docs at python components: Documentation messages: 145911 nosy: becky.lewis, docs at python priority: normal severity: normal status: open title: re module doc has minor inaccuracy in character sets versions: Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Oct 19 17:28:02 2011 From: report at bugs.python.org (ben) Date: Wed, 19 Oct 2011 15:28:02 +0000 Subject: [New-bugs-announce] [issue13220] print function unable while multiprocessing.Process is being run Message-ID: <1319038082.58.0.169311394229.issue13220@psf.upfronthosting.co.za> New submission from ben : print function unable while multiprocessing.Process is being run Not sure if this really is a bug, but the multiprocessing.Process (or Pool) does not allow to print during multiprocessing tasks. I've copied the example from The Python V3.2.2 documentation, library reference, multiprocessing (3rd example). My systems details are: MS windows xp or Windows 7, IDLE, Python 3.2.2 [MSC v.1500 32 bit (Intel)] on win32 from multiprocessing import Process import os def info(title): print(title) print('module name:', __name__) print('parent process:', os.getppid()) print('process id:', os.getpid()) def f(name): info('function f') print('hello', name) if __name__ == '__main__': info('main line') p = Process(target=f, args=('bob',)) p.start() p.join() #return #main line #module name: __main__ #parent process: 1588 #process id: 3700 #but function f doesn't get printed. ---------- components: Library (Lib) files: mp.py messages: 145913 nosy: Ben.thelen priority: normal severity: normal status: open title: print function unable while multiprocessing.Process is being run type: behavior versions: Python 3.2 Added file: http://bugs.python.org/file23463/mp.py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Oct 19 19:22:45 2011 From: report at bugs.python.org (Matthias Schreiber) Date: Wed, 19 Oct 2011 17:22:45 +0000 Subject: [New-bugs-announce] [issue13221] No "edit with IDLE" in right click context menu Message-ID: <1319044965.54.0.660981699643.issue13221@psf.upfronthosting.co.za> New submission from Matthias Schreiber : I dont have the context menu "edit with IDLE" anymore. I installed Python 3.2 first and then 2.7 I tried to open a .py file that's written with 3.2, but it were opened with the 2.7 IDLE. So I uninstalled 2.7 and tried to open it again. Now the context menu were missed. I tried to open it over "Open with..." with other applications. I re-installed 3.2 and also repaired it, but the "edit with IDLE" is still not there. ---------- components: IDLE messages: 145924 nosy: Matthias.Schreiber priority: normal severity: normal status: open title: No "edit with IDLE" in right click context menu versions: Python 3.2 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Oct 19 20:53:48 2011 From: report at bugs.python.org (Giampaolo Rodola') Date: Wed, 19 Oct 2011 18:53:48 +0000 Subject: [New-bugs-announce] [issue13222] Erroneous unclosed file warning Message-ID: <1319050428.96.0.600308451611.issue13222@psf.upfronthosting.co.za> New submission from Giampaolo Rodola' : /opt/python3.2/lib/python3.2/site-packages/psutil/_pslinux.py:389: ResourceWarning: unclosed file <_io.FileIO name=7 mode='rb'> return [x for x in f.read().split('\x00') if x] I get this while running tests. The method in question is defined as such: @wrap_exceptions def get_process_cmdline(self): f = open("/proc/%s/cmdline" % self.pid) try: # return the args as a list return [x for x in f.read().split('\x00') if x] finally: f.close() ...therefore, I'm closing the file object (in the finally block). ---------- messages: 145936 nosy: giampaolo.rodola, pitrou priority: normal severity: normal status: open title: Erroneous unclosed file warning versions: Python 3.2, Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Oct 19 20:59:42 2011 From: report at bugs.python.org (Cameron Hayne) Date: Wed, 19 Oct 2011 18:59:42 +0000 Subject: [New-bugs-announce] [issue13223] pydoc removes 'self' in HTML for method docstrings with example code Message-ID: <1319050782.47.0.924539258184.issue13223@psf.upfronthosting.co.za> New submission from Cameron Hayne : If the docstring for a method has example code that uses 'self', the 'self' will not appear in the HTML generated by pydoc.writedoc Example: #--------------------------------- def getAnswer(self): """ Return the answer. Example of use: answer = self.getAnswer() """ return 42 #--------------------------------- The generated HTML will have: getAnswer(self) Return the answer. Example of use: answer = getAnswer() where the final "getAnswer" is an HTML link. -------------------------------------------- I believe the problem arises on line 553 of the Python 2.7 version of pydoc.py which is as follows: results.append(self.namelink(name, methods, funcs, classes)) The appended text is the same whether or not the method call in the docstring was prefaced with 'self' or not. The 'self' has been eaten up by the regex and is in the 'selfdot' variable which is ignored by the above line. ---------- components: Library (Lib) messages: 145937 nosy: Cameron.Hayne priority: normal severity: normal status: open title: pydoc removes 'self' in HTML for method docstrings with example code type: behavior versions: Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Oct 19 21:44:55 2011 From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=) Date: Wed, 19 Oct 2011 19:44:55 +0000 Subject: [New-bugs-announce] [issue13224] Change str(class) to return only the class name Message-ID: <1319053495.26.0.624132637793.issue13224@psf.upfronthosting.co.za> New submission from ?ric Araujo : Suggestion by Guido on #868845: Off-topic: I sometimes wish that the str() of a class would return the class name rather than its repr(); that way "print(str)" would print "str" instead of . (Use case: printing an exception and its message: I wish I could print("%s: %s" % (err.__class__, err)) instead of having to use err.__class__.__name__.) One could even claim that the repr() of a class could be the same, since one of the guiding principles for repr() is that it should, if possible, return an expression that (perhaps given a suitable environment) could reconstruct the value exactly (and otherwise it should have the <...> form discussed in this issue). But both of these wishes are debatable, and if anyone cares, they should open a new bug to discuss it. > I sometimes wish that the str() of a class would return the class name > rather than its repr(); that way "print(str)" would print "str" > instead of . (Use case: printing an exception and its > message: I wish I could print("%s: %s" % (err.__class__, err)) instead > of having to use err.__class__.__name__.) I wrote a simple patch for that. I just copied the definition of type_repr to a new type_str function, edited the format strings and updated the member mapping (I checked in another file than casting to reprfunc is okay for a str func). It compiles and runs just fine, but I?m still learning C, so there may be things I?ve missed: I don?t know if I have to declare the new function or something like that. The test suite passes with very few edits. Guido added this: > One could even claim that the repr() of a class could be the same I for one think of repr first as ?string form for debugging?, so I like the angle brackets. My patch leaves __repr__ alone. If this get approved, I?ll update my patch with doc changes. If there is no feedback I?ll go to python-ideas. ---------- assignee: eric.araujo components: Interpreter Core messages: 145945 nosy: eric.araujo priority: normal severity: normal stage: patch review status: open title: Change str(class) to return only the class name type: feature request versions: Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Oct 19 22:05:37 2011 From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=) Date: Wed, 19 Oct 2011 20:05:37 +0000 Subject: [New-bugs-announce] [issue13225] Failing packaging hooks should not stop operation Message-ID: <1319054737.41.0.295237299107.issue13225@psf.upfronthosting.co.za> New submission from ?ric Araujo : As discussed in #11637, failing hooks should not stop operation. I see different issues: a) a hook is not found b) a hook is not callable c) a hook raises an exception Current code will raise a Packaging exception for a) and b), and let the exception propagate in case of c). I have a patch that makes Packaging ignore all three kinds and issue warning or error logging messages. An option (--strict) would be needed to switch from logging messages to exceptions; I wonder if an elegant way to do that would be a custom logging handler. ---------- assignee: eric.araujo components: Distutils2 messages: 145950 nosy: alexis, eric.araujo, tarek, vinay.sajip priority: normal severity: normal status: open title: Failing packaging hooks should not stop operation versions: 3rd party, Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Oct 20 00:05:44 2011 From: report at bugs.python.org (STINNER Victor) Date: Wed, 19 Oct 2011 22:05:44 +0000 Subject: [New-bugs-announce] [issue13226] Expose RTLD_* constants in the posix module Message-ID: <1319061944.29.0.561087845829.issue13226@psf.upfronthosting.co.za> New submission from STINNER Victor : We have a sys.setdlopenflags() function, but required constants are not available on all platforms. The DLFCN is only available on Linux and sunos5 (is plat-sunos5 available for all Solaris and OpenIndiana versions?), but not on OpenBSD, FreBSD, Mac OS X, ... whereas these platforms have the sys.setdlopenflags() function. My patch contains 7 constants: - RTLD_LAZY - RTLD_NOW - RTLD_GLOBAL - RTLD_LOCAL - RTLD_NODELETE - RTLD_NOLOAD - RTLD_DEEPBIND (glibc >= 2.3) The ctypes has two RTDL constants: RTLD_LOCAL and RTLD_GLOBAL. The 2 constants are always available, even if the platform doesn't support them! Extract of _ctypes.c: ---------------------------------------- /* If RTLD_LOCAL is not defined (Windows!), set it to zero. */ #ifndef RTLD_LOCAL #define RTLD_LOCAL 0 #endif /* If RTLD_GLOBAL is not defined (cygwin), set it to the same value as RTLD_LOCAL. */ #ifndef RTLD_GLOBAL #define RTLD_GLOBAL RTLD_LOCAL #endif ---------------------------------------- Lib/plat-sunos5/DLFCN.py contains 25 constants, only 6 are available in my patch. I don't think that we should expose all constants. Using Google Codesearch, I only found one user of RTLD constants (of the DLFCN module). It's PyKDE4 who calls: sys.setdlopenflags(DLFCN.RTLD_NOW|DLFCN.RTLD_GLOBAL) I guess that the 7 constants should be enough for everyone :-) We may add more later on demand. You can add your own constant to your program if you really need a special option on a specific platform. ---------- components: Library (Lib) files: posix_rtld.patch keywords: patch messages: 145975 nosy: haypo priority: normal severity: normal status: open title: Expose RTLD_* constants in the posix module versions: Python 3.3 Added file: http://bugs.python.org/file23472/posix_rtld.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Oct 20 00:06:36 2011 From: report at bugs.python.org (Raymond Hettinger) Date: Wed, 19 Oct 2011 22:06:36 +0000 Subject: [New-bugs-announce] [issue13227] Option to make the lru_cache type specific Message-ID: <1319061996.92.0.980251015091.issue13227@psf.upfronthosting.co.za> New submission from Raymond Hettinger : Based on a comment from Andrew Koenig, it is suggested that the lru_cache() offer an option to become type specific so that equal objects of different typed don't get cached to the same entry. Here's an example: @lru_cache(typed=True) def square(x): print('squaring', x) return x * x for x in [3, 3.0, 3, 3.0]: print(square(x)) Without type specificity, all four calls will return 9 rather than 9. 9.0, 9, 9.0. First-pass patch attached. ---------- assignee: rhettinger components: Library (Lib) files: typed_lru.diff keywords: patch messages: 145976 nosy: rhettinger priority: low severity: normal status: open title: Option to make the lru_cache type specific type: feature request versions: Python 3.3 Added file: http://bugs.python.org/file23473/typed_lru.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Oct 20 01:37:03 2011 From: report at bugs.python.org (Ezio Melotti) Date: Wed, 19 Oct 2011 23:37:03 +0000 Subject: [New-bugs-announce] [issue13228] Add "Quick Start" section to the devguide index Message-ID: <1319067423.48.0.288389971536.issue13228@psf.upfronthosting.co.za> New submission from Ezio Melotti : Attached patch adds to the index page a list of 5 steps necessary to set up Python and make a patch. These informations are currently scattered around a few pages and many contributors are already familiar with Mercurial and the process of creating patches, so they just need to know the address where to clone and the commands to compile Python and run the tests. The list also includes links to the other sections, so users can find more detailed information if they need them (this is also valid for the second point: the "configure" command is specific to Unix, but the link has information about Windows too). All this should make the devguide a bit more usable. (A bit of background: during the sprints at PyCon FI I wrote the steps 1-3 on the whiteboard, and they worked well for everyone. Most of them managed to get something done with no further assistance, even if a few people were not so familiar with Mercurial.) ---------- assignee: ezio.melotti components: Devguide files: quickstart.diff keywords: patch messages: 145993 nosy: eric.araujo, ezio.melotti, terry.reedy priority: normal severity: normal stage: commit review status: open title: Add "Quick Start" section to the devguide index Added file: http://bugs.python.org/file23476/quickstart.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Oct 20 04:05:30 2011 From: report at bugs.python.org (Nick Coghlan) Date: Thu, 20 Oct 2011 02:05:30 +0000 Subject: [New-bugs-announce] [issue13229] Add shutil.filter_walk Message-ID: <1319076330.7.0.757546324527.issue13229@psf.upfronthosting.co.za> New submission from Nick Coghlan : I needed a depth-limited, filtered search of a directory tree recently and came up with the following wrapper around os.walk that brings in a few niceties like glob-style filtering, depth limiting and symlink traversal that is safe from infinite loops. It also emits a named tuple rather than the bare tuple emitted by os.walk: http://code.activestate.com/recipes/577913-selective-directory-walking/ I think this would make a nice addition to 3.3 as shutil.filter_walk, but it need tests, documentation and reformatting as a patch before it can go anywhere. ---------- components: Library (Lib) messages: 145999 nosy: ncoghlan priority: normal severity: normal stage: test needed status: open title: Add shutil.filter_walk type: feature request versions: Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Oct 20 05:56:09 2011 From: report at bugs.python.org (=?utf-8?q?Westley_Mart=C3=ADnez?=) Date: Thu, 20 Oct 2011 03:56:09 +0000 Subject: [New-bugs-announce] [issue13230] test_resources fails Message-ID: <1319082969.57.0.123711393145.issue13230@psf.upfronthosting.co.za> New submission from Westley Mart?nez : After running the uber test on the latest build of python (./python -bb -E -Wd -m test -r -w -uall) I get one error: ====================================================================== ERROR: test_resources (packaging.tests.test_command_install_data.InstallDataTestCase) ---------------------------------------------------------------------- Traceback (most recent call last): File "/home/westley/Projects/cpython/Lib/packaging/tests/test_command_install_data.py", line 134, in test_resources with packaging.database.get_file('Spamlib', 'spamd') as fp: File "/home/westley/Projects/cpython/Lib/packaging/database.py", line 649, in get_file return open(get_file_path(distribution_name, relative_path), File "/home/westley/Projects/cpython/Lib/packaging/database.py", line 644, in get_file_path raise LookupError('no distribution named %r found' % distribution_name) LookupError: no distribution named 'Spamlib' found ---------------------------------------------------------------------- I also pasted the entire test output (verbose) to the testout file ---------- components: Library (Lib) files: testout.txt messages: 146006 nosy: anikom15 priority: normal severity: normal status: open title: test_resources fails type: behavior Added file: http://bugs.python.org/file23478/testout.txt _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Oct 20 09:40:21 2011 From: report at bugs.python.org (anatoly techtonik) Date: Thu, 20 Oct 2011 07:40:21 +0000 Subject: [New-bugs-announce] [issue13231] sys.settrace - document 'some other code blocks' for 'call' event type Message-ID: <1319096421.5.0.420840017987.issue13231@psf.upfronthosting.co.za> New submission from anatoly techtonik : http://docs.python.org/library/sys.html#sys.settrace While writing settrace function you need to know what kind of data is expected and how to get more information about it. Current documentation for sys.settrace doesn't give too much answers. To improve that situation at least with 'call' event: 1. Link 'frame' to the middle of table on inspect module page [1] 2. List all possible 'code blocks' for 'call' event (I know there is module in addition to function) 3. Provide example how to extract popular data for corresponding 'code block' (name for functions, name for modules, name for classes/methods, relative file path, line no, how to detect labmbda function) in a safe manner (inspect page contains some FUD about memory usage) 1. http://docs.python.org/library/inspect#types-and-members ---------- assignee: docs at python components: Documentation messages: 146009 nosy: docs at python, techtonik priority: normal severity: normal status: open title: sys.settrace - document 'some other code blocks' for 'call' event type _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Oct 20 16:43:20 2011 From: report at bugs.python.org (Thomas Guettler) Date: Thu, 20 Oct 2011 14:43:20 +0000 Subject: [New-bugs-announce] [issue13232] Logging: Unicode Error Message-ID: <1319121800.04.0.366773580653.issue13232@psf.upfronthosting.co.za> New submission from Thomas Guettler : In changeset fe6be0426e0d the format() method was changed. Unfortunately it does not catch all unicode decode errors. I think line 482 of logging/__init__.py should be modified: to this (add 'replace'): s = s + record.exc_text.decode(sys.getfilesystemencoding(), 'replace') http://hg.python.org/cpython/file/f35514dfadf8/Lib/logging/__init__.py#l482 Here is the stacktrace we get: {{{ Traceback (most recent call last): File "/usr/lib64/python2.7/logging/__init__.py", line 838, in emit msg = self.format(record) File "/usr/lib64/python2.7/logging/__init__.py", line 715, in format return fmt.format(record) File "/home/modbau_esg_p/djangotools/utils/logutils.py", line 32, in format msg=logging.Formatter.format(self, record) File "/usr/lib64/python2.7/logging/__init__.py", line 482, in format s = s + record.exc_text.decode(sys.getfilesystemencoding()) UnicodeDecodeError: 'ascii' codec can't decode byte 0xc3 in position 662: ordinal not in range(128) Logged from file base.py, line 209 }}} ---------- components: Library (Lib) messages: 146018 nosy: guettli priority: normal severity: normal status: open title: Logging: Unicode Error versions: Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Oct 20 18:20:40 2011 From: report at bugs.python.org (Guilherme Moro) Date: Thu, 20 Oct 2011 16:20:40 +0000 Subject: [New-bugs-announce] [issue13233] os.acces documentation error Message-ID: <1319127640.96.0.83884717457.issue13233@psf.upfronthosting.co.za> New submission from Guilherme Moro : http://docs.python.org/library/os.html#os.access points out that I should use try: fp = open("myfile") except IOError as e: if e.errno == errno.EACCESS: return "some default data" # Not a permission error. raise else: with fp: return fp.read() but theres a typo the correct is errno.EACCES: not errno.EACCESS: ---------- assignee: docs at python components: Documentation messages: 146024 nosy: Guilherme.Moro, docs at python priority: normal severity: normal status: open title: os.acces documentation error versions: Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Oct 20 18:54:46 2011 From: report at bugs.python.org (Manuel de la Pena) Date: Thu, 20 Oct 2011 16:54:46 +0000 Subject: [New-bugs-announce] [issue13234] os.listdir breaks with literal paths Message-ID: <1319129686.22.0.325584161741.issue13234@psf.upfronthosting.co.za> New submission from Manuel de la Pena : During the development of an application that needed to write paths longer than 260 chars we opted to use \\?\ as per http://msdn.microsoft.com/en-us/library/windows/desktop/aa365247(v=vs.85).aspx#maxpath. When working with literal paths the following the os.listdir funtion would return the following trace: >>> import os >>> test = r'\\?\C:\Python27' >>> os.listdir(test) Traceback (most recent call last): File "", line 1, in WindowsError: [Error 123] The filename, directory name, or volume label syntax is incorrect: '\\\\?\\C:\\Python27/*.*' The reason for this is that the implementation of listdir appends '/' at the end of the path if os.path.sep is not present at the end of it which FindFirstFile does not like. This is a inconsistency from the OS but it can be easily fixed (see attached patch). ---------- components: Library (Lib) files: listdir.patch keywords: patch messages: 146031 nosy: mandel priority: normal severity: normal status: open title: os.listdir breaks with literal paths versions: Python 2.7 Added file: http://bugs.python.org/file23482/listdir.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Oct 20 19:48:50 2011 From: report at bugs.python.org (anatoly techtonik) Date: Thu, 20 Oct 2011 17:48:50 +0000 Subject: [New-bugs-announce] [issue13235] logging.warn() is not documented Message-ID: <1319132930.0.0.280764890807.issue13235@psf.upfronthosting.co.za> New submission from anatoly techtonik : No docs for logging.warn() alias. ---------- assignee: docs at python components: Documentation messages: 146039 nosy: docs at python, techtonik priority: normal severity: normal status: open title: logging.warn() is not documented versions: Python 2.7, Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Oct 20 21:02:04 2011 From: report at bugs.python.org (Peter Eisentraut) Date: Thu, 20 Oct 2011 19:02:04 +0000 Subject: [New-bugs-announce] [issue13236] unittest needs more flush calls Message-ID: <1319137324.16.0.266090134048.issue13236@psf.upfronthosting.co.za> New submission from Peter Eisentraut : I'm using the TextTestRunner class in unittest/runner.py with a special file-like object passed in as stream. Doing this loses some output, because the run() method (and some lower-level methods) don't always call flush() on the stream. There is also no obvious cleanup method in the runner class that might do this, so I assume run() should do that itself. Right now, it looks like it assumes that either the stream is effectively unbuffered, like stderr, or that the end of the program might flush things, but that doesn't always apply. It looks like the best fix would be a self.stream.flush() call at the end of run(). Another flush() call at the end of printErrorList() would also help. (In the meantime, I have fixed up my special file-like class to flush its internal buffers when a newline is seen, which kind of works, but a proper cleanup of this matter would still be nice.) ---------- components: Library (Lib) messages: 146043 nosy: petere priority: normal severity: normal status: open title: unittest needs more flush calls type: behavior versions: Python 2.6, Python 2.7, Python 3.1, Python 3.2 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Oct 21 07:25:02 2011 From: report at bugs.python.org (Nick Coghlan) Date: Fri, 21 Oct 2011 05:25:02 +0000 Subject: [New-bugs-announce] [issue13237] subprocess docs should use emphasise convenience functions Message-ID: <1319174702.47.0.36912184976.issue13237@psf.upfronthosting.co.za> New submission from Nick Coghlan : Many typical subprocess use cases can now be handled simply via the convenience functions: subprocess.call() subprocess.check_call() subprocess.check_output() However, readers of the documentation could be forgiven for not realising that, since the docs dive right in with Popen() and will scare most readers away in search of more user friendly APIs (or even other languages). The module documentation should be reordered to introduce the helper function first, then Popen afterwards. The "subprocess replacements" [1] section would ideally help address this, but it hasn't been updated to use the convenience function, instead using confusing direct calls to Popen. [1] http://docs.python.org/library/subprocess.html#subprocess-replacements ---------- assignee: docs at python components: Documentation messages: 146059 nosy: docs at python, ncoghlan priority: normal severity: normal stage: needs patch status: open title: subprocess docs should use emphasise convenience functions versions: Python 2.7, Python 3.2, Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Oct 21 08:00:13 2011 From: report at bugs.python.org (Nick Coghlan) Date: Fri, 21 Oct 2011 06:00:13 +0000 Subject: [New-bugs-announce] [issue13238] Add shell command helpers to shutil module Message-ID: <1319176813.33.0.203455355645.issue13238@psf.upfronthosting.co.za> New submission from Nick Coghlan : I've been doing a few systems administration tasks with Python recently, and shell command invocation directly via the subprocess module is annoyingly clunky (even with the new convenience APIs). Since subprocess needs to avoid the shell by default for security reasons, I suggest we add the following simple helper functions to shutil: def call(cmd, *args, **kwds): if args or kwds: cmd = cmd.format(*args, **kwds) return subprocess.call(cmd, shell=True) def check_call(cmd, *args, **kwds): if args or kwds: cmd = cmd.format(*args, **kwds) return subprocess.check_call(cmd, shell=True) def check_output(cmd, *args, **kwds): if args or kwds: cmd = cmd.format(*args, **kwds) return subprocess.check_output(cmd, shell=True) Initially posted at: http://code.activestate.com/recipes/577891-simple-invocation-of-shell-commands/ Of course, even if others agree in principle, documentation and tests are still needed before this change can go anywhere. ---------- components: Library (Lib) messages: 146061 nosy: ncoghlan priority: normal severity: normal status: open title: Add shell command helpers to shutil module versions: Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Oct 21 11:11:31 2011 From: report at bugs.python.org (Eli Bendersky) Date: Fri, 21 Oct 2011 09:11:31 +0000 Subject: [New-bugs-announce] [issue13239] Remove <> operator from Grammar/Grammar Message-ID: <1319188291.02.0.897231487042.issue13239@psf.upfronthosting.co.za> New submission from Eli Bendersky : Operator <> was removed in Python 3, but still appears in Grammar/Grammar (and hence in Doc/reference/grammar.rst) Reported by Alexander Ivanyuta on the docs mailing list ---------- assignee: docs at python components: Documentation, Interpreter Core messages: 146070 nosy: docs at python, eli.bendersky priority: normal severity: normal status: open title: Remove <> operator from Grammar/Grammar versions: Python 3.2, Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Oct 21 16:41:26 2011 From: report at bugs.python.org (Florent Xicluna) Date: Fri, 21 Oct 2011 14:41:26 +0000 Subject: [New-bugs-announce] [issue13240] computed gotos not enabled? Message-ID: <1319208086.31.0.00990210804778.issue13240@psf.upfronthosting.co.za> New submission from Florent Xicluna : According to issue 9203 the computed gotos should be enabled by default since 3.2. However, it is not visible from the interpreter. Python 3.2.2 (default, Sep 7 2011, 10:55:43) [GCC 4.2.1 (Apple Inc. build 5666) (dot 3)] on darwin >>> from sysconfig import get_config_var >>> get_config_var('HAVE_COMPUTED_GOTOS') 1 >>> get_config_var('USE_COMPUTED_GOTOS') 0 ---------- components: Build messages: 146090 nosy: flox, pitrou priority: normal severity: normal status: open title: computed gotos not enabled? type: performance versions: Python 3.2, Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Oct 21 21:49:20 2011 From: report at bugs.python.org (Oleg Plakhotnyuk) Date: Fri, 21 Oct 2011 19:49:20 +0000 Subject: [New-bugs-announce] [issue13241] Assertion failed in _PyUnicode_CheckConsistency during build of default branch on Mac OS X Message-ID: <1319226560.18.0.474501275115.issue13241@psf.upfronthosting.co.za> New submission from Oleg Plakhotnyuk : Trying to build latest development revision: localhost:repo family$ hg summary parent: 73044:a985d733b3a3 tip #12753: Add support for Unicode name aliases and named sequences. branch: default commit: (clean) update: (current) Constantly getting this error: ./python.exe -SE -m sysconfig --generate-posix-vars Could not find platform dependent libraries Consider setting $PYTHONHOME to [:] Assertion failed: (compact->utf8_length == 0), function _PyUnicode_CheckConsistency, file Objects/unicodeobject.c, line 399. make: *** [sysconfig] Abort trap However, tag v3.2.2 seems to build successfully. OS: Mac OS X 10.6.8 GCC: 4.2.1 If you have troubles reproducing this issue, feel free to ask any information I can provide that can help. Thank you in advance! ---------- messages: 146120 nosy: Oleg.Plakhotnyuk priority: normal severity: normal status: open title: Assertion failed in _PyUnicode_CheckConsistency during build of default branch on Mac OS X type: compile error _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Oct 21 22:57:30 2011 From: report at bugs.python.org (Antoine Pitrou) Date: Fri, 21 Oct 2011 20:57:30 +0000 Subject: [New-bugs-announce] [issue13242] Crash in test_pydoc Message-ID: <1319230650.87.0.570503030256.issue13242@psf.upfronthosting.co.za> New submission from Antoine Pitrou : On 2.7, I get the following crashes in test_pydoc: ====================================================================== FAIL: test_apropos_with_bad_package (test.test_pydoc.PydocImportTest) ---------------------------------------------------------------------- Traceback (most recent call last): File "/home/antoine/cpython/27/Lib/test/test_pydoc.py", line 316, in test_apropos_with_bad_package result = run_pydoc('nothing', '-k', PYTHONPATH=TESTFN) File "/home/antoine/cpython/27/Lib/test/test_pydoc.py", line 185, in run_pydoc rc, out, err = assert_python_ok('-B', pydoc.__file__, *args, **env) File "/home/antoine/cpython/27/Lib/test/script_helper.py", line 49, in assert_python_ok return _assert_python(True, *args, **env_vars) File "/home/antoine/cpython/27/Lib/test/script_helper.py", line 41, in _assert_python "stderr follows:\n%s" % (rc, err.decode('ascii', 'ignore'))) AssertionError: Process return code is -6, stderr follows: python: Objects/object.c:65: _Py_AddToAllObjects: Assertion `(op->_ob_prev == ((void *)0)) == (op->_ob_next == ((void *)0))' failed. ====================================================================== FAIL: test_apropos_with_unreadable_dir (test.test_pydoc.PydocImportTest) ---------------------------------------------------------------------- Traceback (most recent call last): File "/home/antoine/cpython/27/Lib/test/test_pydoc.py", line 326, in test_apropos_with_unreadable_dir result = run_pydoc('nothing', '-k', PYTHONPATH=TESTFN) File "/home/antoine/cpython/27/Lib/test/test_pydoc.py", line 185, in run_pydoc rc, out, err = assert_python_ok('-B', pydoc.__file__, *args, **env) File "/home/antoine/cpython/27/Lib/test/script_helper.py", line 49, in assert_python_ok return _assert_python(True, *args, **env_vars) File "/home/antoine/cpython/27/Lib/test/script_helper.py", line 41, in _assert_python "stderr follows:\n%s" % (rc, err.decode('ascii', 'ignore'))) AssertionError: Process return code is -6, stderr follows: python: Objects/object.c:65: _Py_AddToAllObjects: Assertion `(op->_ob_prev == ((void *)0)) == (op->_ob_next == ((void *)0))' failed. "hg bisect" tells me the first offending revision is 45862f4ab1c5, but that doesn't tell much, since it's just the revision which introduced the tests. ---------- components: Interpreter Core, Tests messages: 146133 nosy: ned.deily, pitrou priority: high severity: normal status: open title: Crash in test_pydoc type: crash versions: Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Oct 22 08:38:20 2011 From: report at bugs.python.org (Eric Snow) Date: Sat, 22 Oct 2011 06:38:20 +0000 Subject: [New-bugs-announce] [issue13243] _Py_identifier should be _Py_IDENTIFER Message-ID: <1319265500.1.0.820067486138.issue13243@psf.upfronthosting.co.za> New submission from Eric Snow : Looks like Parser/asdl_c.py did not get all the way updated when _Py_identifier switched over to _Py_IDENTIFER. I've included a patch that fixes it (though it's relatively trivial). With this fix I did not notice any further problems. ---------- components: Interpreter Core files: asdl.diff keywords: patch messages: 146159 nosy: eric.snow, loewis priority: normal severity: normal status: open title: _Py_identifier should be _Py_IDENTIFER type: compile error versions: Python 3.3 Added file: http://bugs.python.org/file23493/asdl.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Oct 22 13:07:43 2011 From: report at bugs.python.org (Tobias Oberstein) Date: Sat, 22 Oct 2011 11:07:43 +0000 Subject: [New-bugs-announce] [issue13244] WebSocket schemes in urlparse Message-ID: <1319281663.43.0.214740119457.issue13244@psf.upfronthosting.co.za> New submission from Tobias Oberstein : The urlparse module currently does not support the new "ws" and "wss" schemes used for the WebSocket protocol. As a workaround, we currently use the following code (which is a hack of course): import urlparse wsschemes = ["ws", "wss"] urlparse.uses_relative.extend(wsschemes) urlparse.uses_netloc.extend(wsschemes) urlparse.uses_params.extend(wsschemes) urlparse.uses_query.extend(wsschemes) urlparse.uses_fragment.extend(wsschemes) === A WebSocket URL has scheme "ws" or "wss", MUST have a network location and MAY have a resource part with path and query components, but MUST NOT have a fragment component. ---------- components: Library (Lib) messages: 146167 nosy: oberstet priority: normal severity: normal status: open title: WebSocket schemes in urlparse type: feature request versions: Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Oct 22 21:05:54 2011 From: report at bugs.python.org (Chris Clark) Date: Sat, 22 Oct 2011 19:05:54 +0000 Subject: [New-bugs-announce] [issue13245] sched.py kwargs addition and default time functions Message-ID: <1319310354.56.0.392534213439.issue13245@psf.upfronthosting.co.za> New submission from Chris Clark : I ended up implementing my own sched.py equivalent as I needed kwargs support. This is my attempt to improve the stdlib, so I can throw my module way ;-) Added kwargs support, and made "argument" optional. "argument" is still named argument, I would like to rename this args but I'm unclear on the backwards compat rules for stdlib, in theory it should be fine unless someone has code that treats argument as a keyword arg). The scheduler init no long requires timer functions to be provided, it defaults to time.time, time.sleep as a helper to reduce repeated code for callers. This still allows callers to provide custom timer routines. I added a few (non exhaustive) tests for the new additions. It looks like there are a few pep8 improvements could be made to sched.py but I've not done that to reduce diffs and make it easier to see what I changed. Similar doc strings could be made more clear. I snuck in a hack to the test so that the full test suite isn't needed, I do not expect that to be accepted :-) I don't have enough network bandwidth to pull the whole hg repo so I ended up pulling the tip version for 2.7 of sched and its test (as of 2011-10-22 this is 5110d723fbb1) ---------- components: Library (Lib) files: kwargs_def_timer.patch keywords: patch messages: 146180 nosy: clach04 priority: normal severity: normal status: open title: sched.py kwargs addition and default time functions type: feature request versions: Python 2.7 Added file: http://bugs.python.org/file23496/kwargs_def_timer.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Oct 22 22:13:50 2011 From: report at bugs.python.org (Antoine Pitrou) Date: Sat, 22 Oct 2011 20:13:50 +0000 Subject: [New-bugs-announce] [issue13246] Py_UCS4_strlen and friends needn't be public Message-ID: <1319314430.74.0.993573606288.issue13246@psf.upfronthosting.co.za> New submission from Antoine Pitrou : It seems there's no reason to document these functions which operate on null-terminated unicode arrays. ---------- assignee: docs at python components: Documentation messages: 146187 nosy: docs at python, ezio.melotti, georg.brandl, haypo, loewis, pitrou priority: normal severity: normal status: open title: Py_UCS4_strlen and friends needn't be public versions: Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Oct 23 01:45:24 2011 From: report at bugs.python.org (Yuval Greenfield) Date: Sat, 22 Oct 2011 23:45:24 +0000 Subject: [New-bugs-announce] [issue13247] os.path.abspath returns unicode paths as question marks Message-ID: <1319327124.52.0.956024299245.issue13247@psf.upfronthosting.co.za> New submission from Yuval Greenfield : For Python 2: Python 2.7.1 (r271:86832, Nov 27 2010, 18:30:46) [MSC v.1500 32 bit (Intel)] on win32 >>> os.path.abspath('.') 'C:\\Users\\yuv\\Desktop\\YuvDesktop\\??????' >>> os.path.abspath(u'.') u'C:\\Users\\yuv\\Desktop\\YuvDesktop\\\u05d0\u05d1\u05d2\u05d3\u05d4\u05d5' For Python 3: Python 3.2 (r32:88445, Feb 20 2011, 21:29:02) [MSC v.1500 32 bit (Intel)] on win32 >>> os.path.abspath('.') 'C:\\Users\\yuv\\Desktop\\YuvDesktop\\\u05d0\u05d1\u05d2\u05d3\u05d4\u05d5' >>> os.path.abspath(b'.') b'C:\\Users\\yuv\\Desktop\\YuvDesktop\\??????' The returned path with question marks is completely useless. It's better that python throw an error than return the question marks. Another option is to try and get the ascii version of the path, I believe windows has one. ---------- components: Library (Lib) messages: 146204 nosy: ubershmekel priority: normal severity: normal status: open title: os.path.abspath returns unicode paths as question marks type: behavior versions: Python 2.7, Python 3.2, Python 3.3, Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Oct 23 19:49:46 2011 From: report at bugs.python.org (Florent Xicluna) Date: Sun, 23 Oct 2011 17:49:46 +0000 Subject: [New-bugs-announce] [issue13248] deprecated in 3.2, should be removed in 3.3 Message-ID: <1319392186.66.0.823106983991.issue13248@psf.upfronthosting.co.za> New submission from Florent Xicluna : The PEP 387 suggests that deprecated objects or arguments are removed in version (n+1). I've listed these DeprecationWarnings in 3.2, which are still in 3.3. I assume that most of these deprecated objects or arguments could be removed before next release. *_pyio* argument "max_buffer_size" of BufferedWriter and BufferedRWPair *argparse* argument "version" and related methods of ArgumentParser *asyncore* shortcut "dispatcher.*" for "dispatcher.socket.*" attributes *base64* functions "encodestring" and "decodestring" *cgi* functions "parse_qs" and "parse_qsl" *configparser* "ParsingError.filename", "RawConfigParser.readfp", "SafeConfigParser" *decimal* "Context._clamp" *difflib* "SequenceMatcher.isbjunk", "SequenceMatcher.isbpopular" *gzip* "GzipFile.filename" *http.client* argument "strict" of HTTPResponse and HTTPConnection *lib2to3* methods "set_prefix" and "get_prefix" of "pytree.Base" *mailbox* argument of type "StringIO" or "text mode files" *ntpath* function "splitunc" *tarfile* argument "exclude" of "TarFile.add" *trace* old API *unittest* "assert{DictContainsSubset,RaisesRegexp,RegexpMatches}", "fail*" *xml.etree* "Element.getchildren", "XMLParser.doctype" ---------- components: Library (Lib) messages: 146236 nosy: flox priority: normal severity: normal status: open title: deprecated in 3.2, should be removed in 3.3 type: behavior versions: Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Oct 23 20:32:39 2011 From: report at bugs.python.org (Roy Smith) Date: Sun, 23 Oct 2011 18:32:39 +0000 Subject: [New-bugs-announce] [issue13249] argparse.ArgumentParser() lists arguments in the wrong order Message-ID: <1319394759.74.0.692830705102.issue13249@psf.upfronthosting.co.za> New submission from Roy Smith : The docs list the arguments in the order: class argparse.ArgumentParser([description][, epilog][, prog]... but the code (I'm looking at the 2.7.2 source) lists them as: class ArgumentParser(_AttributeHolder, _ActionsContainer): [...] def __init__(self, prog=None, usage=None, description=None, [...] If you create a parser with just: parser = argparse.ArgumentParser("foo") you end up setting the 'prog' argument instead of the expected 'description'. It's unclear if the order in the code should be fixed to match the docs, or the order in the docs fixed to match the code, or just a note added to the docs saying you should not rely on positional argument ordering and always create a parser with named arguments. ---------- components: Library (Lib) messages: 146238 nosy: roysmith priority: normal severity: normal status: open title: argparse.ArgumentParser() lists arguments in the wrong order type: behavior versions: Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Oct 23 20:45:08 2011 From: report at bugs.python.org (Meador Inge) Date: Sun, 23 Oct 2011 18:45:08 +0000 Subject: [New-bugs-announce] [issue13250] ctypes: reference leak in POINTER code Message-ID: <1319395508.92.0.449724155939.issue13250@psf.upfronthosting.co.za> New submission from Meador Inge : While implementing a patch for issue13096 I found a reference leak in 'ctypes'. I couldn't find the cause immediately, but it can be reproduced by applying the attached patch and running: [meadori at motherbrain cpython]$ ./python -m test -R : test_ctypes [1/1] test_ctypes beginning 9 repetitions 123456789 ......... test_ctypes leaked [51, 51, 51, 51] references, sum=204 1 test failed: test_ctypes [174347 refs] ---------- components: ctypes files: ctypes-refleak-repro.patch keywords: patch messages: 146242 nosy: amaury.forgeotdarc, belopolsky, meador.inge priority: normal severity: normal stage: needs patch status: open title: ctypes: reference leak in POINTER code type: resource usage versions: Python 3.3 Added file: http://bugs.python.org/file23504/ctypes-refleak-repro.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Oct 24 00:22:40 2011 From: report at bugs.python.org (Ezio Melotti) Date: Sun, 23 Oct 2011 22:22:40 +0000 Subject: [New-bugs-announce] [issue13251] Update string description in datamodel.rst Message-ID: <1319408560.2.0.695201505258.issue13251@psf.upfronthosting.co.za> New submission from Ezio Melotti : The attached patch updates the definition of "String" after PEP 393. ---------- assignee: ezio.melotti components: Documentation, Unicode files: issue13251.diff keywords: needs review, patch messages: 146262 nosy: eric.araujo, ezio.melotti, haypo, lemburg, loewis priority: normal severity: normal stage: patch review status: open title: Update string description in datamodel.rst versions: Python 3.3 Added file: http://bugs.python.org/file23506/issue13251.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Oct 24 00:32:48 2011 From: report at bugs.python.org (Carlo Verre) Date: Sun, 23 Oct 2011 22:32:48 +0000 Subject: [New-bugs-announce] [issue13252] new decumulate() function in itertools module Message-ID: <1319409168.22.0.462760902888.issue13252@psf.upfronthosting.co.za> New submission from Carlo Verre : After in Python 3.2 the accumulate() function has been added to itertools module, for self-evident reasons of completeness and symmetry we could add in 3.3 the inverse decumulate() function, which, given the iterable argument p, yields p[0], p[1] - p[0], p[2] - p[1]... Its equivalent python form is in the attached file decumulate.py, below. ---------- components: Extension Modules files: decumulate.py messages: 146263 nosy: carlo.verre, rhettinger priority: normal severity: normal status: open title: new decumulate() function in itertools module type: feature request versions: Python 3.3 Added file: http://bugs.python.org/file23507/decumulate.py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Oct 24 08:25:52 2011 From: report at bugs.python.org (Ezio Melotti) Date: Mon, 24 Oct 2011 06:25:52 +0000 Subject: [New-bugs-announce] [issue13253] 2to3 fix_renames renames sys.maxint only in imports Message-ID: <1319437552.82.0.780264952493.issue13253@psf.upfronthosting.co.za> New submission from Ezio Melotti : $ cat deleteme.py from sys import maxint print 'maxint', maxint $ 2to3 deleteme.py RefactoringTool: Skipping implicit fixer: buffer RefactoringTool: Skipping implicit fixer: idioms RefactoringTool: Skipping implicit fixer: set_literal RefactoringTool: Skipping implicit fixer: ws_comma RefactoringTool: Refactored deleteme.py --- deleteme.py (original) +++ deleteme.py (refactored) @@ -1,2 +1,2 @@ -from sys import maxint -print 'maxint', maxint +from sys import maxsize +print('maxint', maxint) RefactoringTool: Files that need to be modified: RefactoringTool: deleteme.py The maxint in the print should be converted too. ---------- components: 2to3 (2.x to 3.0 conversion tool) messages: 146278 nosy: benjamin.peterson, ezio.melotti priority: normal severity: normal stage: needs patch status: open title: 2to3 fix_renames renames sys.maxint only in imports type: behavior versions: Python 2.7, Python 3.2, Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Oct 24 11:14:59 2011 From: report at bugs.python.org (marco ghidinelli) Date: Mon, 24 Oct 2011 09:14:59 +0000 Subject: [New-bugs-announce] [issue13254] maildir.items() broken Message-ID: <1319447699.1.0.36723918452.issue13254@psf.upfronthosting.co.za> New submission from marco ghidinelli : since python 2.7.2 maildir.items() doesn't return anything: >>> from mailbox import Maildir >>> x = Maildir('test') >>> x.items() [] untils something was written on the maildir. >>> x.add('bubu') '1319447613.M259111P6097Q1.deeppurple' >>> x.items() [('1319447013.M913187P6096Q1.deeppurple', ), ('1319447613.M259111P6097Q1.deeppurple', )] ---------- components: Library (Lib) messages: 146283 nosy: marco.ghidinelli priority: normal severity: normal status: open title: maildir.items() broken type: behavior versions: Python 2.7, Python 3.2 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Oct 24 12:48:07 2011 From: report at bugs.python.org (Florent Xicluna) Date: Mon, 24 Oct 2011 10:48:07 +0000 Subject: [New-bugs-announce] [issue13255] wrong docstring for array.fromunicode Message-ID: <1319453287.77.0.97617561601.issue13255@psf.upfronthosting.co.za> New submission from Florent Xicluna : The docstring should say "ustr.encode" instead of "ustr.decode". The documentation page is correct. >>> print(array.array.fromunicode.__doc__) fromunicode(ustr) Extends this array with data from the unicode string ustr. The array must be a unicode type array; otherwise a ValueError is raised. Use array.frombytes(ustr.decode(...)) to append Unicode data to an array of some other type. ---------- assignee: docs at python components: Documentation messages: 146292 nosy: docs at python, flox priority: normal severity: normal stage: needs patch status: open title: wrong docstring for array.fromunicode type: behavior versions: Python 3.2, Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Oct 24 13:46:15 2011 From: report at bugs.python.org (STINNER Victor) Date: Mon, 24 Oct 2011 11:46:15 +0000 Subject: [New-bugs-announce] [issue13256] Document and test new socket options Message-ID: <1319456775.82.0.463656498781.issue13256@psf.upfronthosting.co.za> New submission from STINNER Victor : The commit c64216addd7f for issue #6560 added various socket option, but some of them are not well documented or tested. Authentication: * SO_PASSCRED, SO_PEERCRED, LOCAL_PEERCRED * SCM_RIGHTS, SCM_CREDENTIALS, SCM_CREDS SCTP: * socket.IPPROTO_SCTP is not mentioned in socket.socket() doc (but it's tested) etc. ---------- messages: 146294 nosy: haypo priority: normal severity: normal status: open title: Document and test new socket options _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Oct 24 21:16:51 2011 From: report at bugs.python.org (Brett Cannon) Date: Mon, 24 Oct 2011 19:16:51 +0000 Subject: [New-bugs-announce] [issue13257] Move importlib over to PEP 3151 exceptions Message-ID: <1319483811.65.0.194402902365.issue13257@psf.upfronthosting.co.za> New submission from Brett Cannon : Importlib uses the errno module explicitly for properly checking OSError for EEXIST and IOError for EACCES. Thanks to PEP 3151, however, neither check is needed since those exceptions correspond to FileExistsError and PermissionError, respectively. As long as posix.mkdir() uses the new exceptions, the entire need for errno goes away for the module, eliminating one more module required for bootstrapping. ---------- assignee: brett.cannon components: Library (Lib) keywords: easy messages: 146317 nosy: brett.cannon priority: normal severity: normal stage: needs patch status: open title: Move importlib over to PEP 3151 exceptions type: behavior versions: Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Oct 24 21:46:15 2011 From: report at bugs.python.org (Florent Xicluna) Date: Mon, 24 Oct 2011 19:46:15 +0000 Subject: [New-bugs-announce] [issue13258] replace hasattr(obj, '__call__') with callable(obj) Message-ID: <1319485575.06.0.0356181366596.issue13258@psf.upfronthosting.co.za> New submission from Florent Xicluna : Now that callable() is back in 3.2, we may replace hasattr(obj, '__call__') with callable(obj). The built-in function is easier to read and gives better performance than attribute lookup. $ ./python -m timeit "hasattr(None, '__call__')" 100000 loops, best of 3: 4.09 usec per loop $ ./python -m timeit "hasattr(str, '__call__')" 1000000 loops, best of 3: 1.3 usec per loop $ ./python -m timeit "callable(None)" 1000000 loops, best of 3: 0.299 usec per loop $ ./python -m timeit "callable(str)" 1000000 loops, best of 3: 0.369 usec per loop ---------- components: Library (Lib) messages: 146320 nosy: flox priority: normal severity: normal status: open title: replace hasattr(obj, '__call__') with callable(obj) type: performance versions: Python 3.2, Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Oct 25 00:49:10 2011 From: report at bugs.python.org (Arkadiusz Wahlig) Date: Mon, 24 Oct 2011 22:49:10 +0000 Subject: [New-bugs-announce] [issue13259] __bytes__ not documented Message-ID: <1319496550.21.0.905326658417.issue13259@psf.upfronthosting.co.za> New submission from Arkadiusz Wahlig : It looks like Python 3 supports the __bytes__ magic method (called by bytes(obj)). However, it's not documented anywhere. Also, I could not find any reference to BDFL accepting it but it looks like it got in anyway. Here are some posts back from 2007 where he argues against it: http://mail.python.org/pipermail/python-3000/2007-August/009375.html ---------- assignee: docs at python components: Documentation messages: 146334 nosy: docs at python, yak priority: normal severity: normal status: open title: __bytes__ not documented versions: Python 3.1, Python 3.2, Python 3.3, Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Oct 25 01:41:39 2011 From: report at bugs.python.org (Alexander Myodov) Date: Mon, 24 Oct 2011 23:41:39 +0000 Subject: [New-bugs-announce] [issue13260] distutils and cross-compiling the extensions Message-ID: <1319499699.99.0.666933133396.issue13260@psf.upfronthosting.co.za> New submission from Alexander Myodov : I was recently trying to cross-compile several extensions (host: Linux, target: Win32) using mingw-gcc, and noticed that there is quite a little amount of changes needed to distutils code to at least make proper win32-compabible modules. Some of them require pretty noticeable functionality changes to distutils (like, adding a new option) thus they are unlikely a target for 2.7 anymore (though with some luck, any person who wants to follow my way and do cross-compilation, may just subclass the existing code). But some others are obvious bugs, and their fixes may still be useful for users stuck at 2.7. 1. (This is dubious but still is related to the problem, and was required to build some of the modules). "--include-dirs" and "--library-dirs" options to build_ext command support multiple paths separated by os.pathsep. For some reason (which I may be unaware of) "--libraries" option doesn't. A tiny fix just adds this support. 2. (more obvious issue) get_msvcr() function in distutils/cygwincompiler.py tries to guess the C runtime library which the target extension should link to. To do that, it tests the Python where the setup.py is *running* for what library it was linked to. But when the compilation target is Win32 but the compilation host is Linux, the hosts's Python won't contain such information. In this case, this function will return None. The result then gets assigned to self.dll_libraries (in an instance of CygwinCCompiler or Mingw32CCompiler), and gets used in a context which implies it is always an iterable (libraries.extend(self.dll_libraries)). These changes, together with altering or subclassing Mingw32CCompiler to use a different compiler name (like, "i586-mingw32msvc-gcc" instead of "gcc"), make it possible to cross-compile a number of extensions which were non-compileable before. ---------- assignee: tarek components: Distutils files: distutils.patch keywords: patch messages: 146340 nosy: amyodov, eric.araujo, tarek priority: normal severity: normal status: open title: distutils and cross-compiling the extensions versions: Python 2.7 Added file: http://bugs.python.org/file23514/distutils.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Oct 25 11:37:07 2011 From: report at bugs.python.org (Elijah Merkin) Date: Tue, 25 Oct 2011 09:37:07 +0000 Subject: [New-bugs-announce] [issue13261] time.clock () has very low resolution on Linux Message-ID: <1319535427.57.0.472664899853.issue13261@psf.upfronthosting.co.za> New submission from Elijah Merkin : time.clock () has very poor time resolution on Linux (tested on Ubuntu 11.04). The result of call to clock () changes once per several seconds. On the other side, on Windows it provides very good resolution. Here is a doctest that fails on Linux: """ >>> from time import sleep >>> prev = clock () >>> res = True >>> for i in xrange(10): ... sleep(0.15) ... next = clock () ... res = res and (next - prev) > 0.1 ... prev = next >>> print res True """ Currently on Linux I am using a workaround that is attached to the issue. ---------- components: None files: monotime_unix.py messages: 146347 nosy: ellioh priority: normal severity: normal status: open title: time.clock () has very low resolution on Linux type: behavior versions: Python 2.6, Python 2.7 Added file: http://bugs.python.org/file23515/monotime_unix.py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Oct 25 12:22:14 2011 From: report at bugs.python.org (Aivar Annamaa) Date: Tue, 25 Oct 2011 10:22:14 +0000 Subject: [New-bugs-announce] [issue13262] IDLE opens partially hidden Message-ID: <1319538134.39.0.210129529894.issue13262@psf.upfronthosting.co.za> New submission from Aivar Annamaa : When IDLE opens in Windows 7, its bottom edge will be hidden behind taskbar. It should position itself so that it's fully visible. ---------- components: IDLE messages: 146354 nosy: Aivar.Annamaa priority: normal severity: normal status: open title: IDLE opens partially hidden type: behavior versions: Python 3.2 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Oct 25 14:06:17 2011 From: report at bugs.python.org (Ezio Melotti) Date: Tue, 25 Oct 2011 12:06:17 +0000 Subject: [New-bugs-announce] [issue13263] Group some os functions in submodules Message-ID: <1319544377.25.0.706220454632.issue13263@psf.upfronthosting.co.za> New submission from Ezio Melotti : In Python 3.3 the os module gained a few new functions and constants: Python 3.2.2+ (3.2:58a75eeb5c8e, Sep 29 2011, 02:11:05) >>> import os; len(dir(os)) 232 Python 3.3.0a0 (default:a50f080c22ca+, Oct 25 2011, 09:56:01) >>> import os; len(dir(os)) 332 http://docs.python.org/dev/py3k/whatsnew/3.3.html#os lists some of these additions, and they are already grouped (e.g. the sched_* functions, the "at" functions, ...). Before the os API gets even more bloated, maybe we should group some of these functions in new submodules, like os.sched.*. ---------- components: Extension Modules messages: 146363 nosy: benjamin.peterson, ezio.melotti, georg.brandl, loewis, pitrou, rhettinger priority: normal severity: normal stage: needs patch status: open title: Group some os functions in submodules type: feature request versions: Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Oct 25 14:45:05 2011 From: report at bugs.python.org (Artem Tomilov) Date: Tue, 25 Oct 2011 12:45:05 +0000 Subject: [New-bugs-announce] [issue13264] Monkeypatching using metaclass Message-ID: <1319546705.67.0.958518065524.issue13264@psf.upfronthosting.co.za> New submission from Artem Tomilov : from abc import ABCMeta class Meta(ABCMeta): def __instancecheck__(cls, instance): # monkeypatching class method cls.__subclasscheck__ = super(Meta, cls).__subclasscheck__ return super(Meta, cls).__instancecheck__(instance) def __subclasscheck__(cls, sub): return cls in sub.mro() class A(object): __metaclass__ = Meta class B(object): pass # registering class 'B' as a virtual subclass of 'A' A.register(B) >>> issubclass(B, A) False >>> isinstance(B(), A) # => method __subclasscheck__ is now monkeypatched True >>> issubclass(B, A) # => desire to get 'True' because 'B' is a virtual subclass False ---------- components: None messages: 146366 nosy: Artem.Tomilov priority: normal severity: normal status: open title: Monkeypatching using metaclass type: behavior versions: Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Oct 26 07:48:49 2011 From: report at bugs.python.org (maniram maniram) Date: Wed, 26 Oct 2011 05:48:49 +0000 Subject: [New-bugs-announce] [issue13265] IDLE crashes when printing some unprintable characters. Message-ID: <1319608129.37.0.0558883356195.issue13265@psf.upfronthosting.co.za> New submission from maniram maniram : When you print an unprintable character, IDLE raises an error. >>> print(chr(500304)) # print an unprintable character The error is only visible when you run the code from a commmand-line. When you run python from the command-line and execute the code it shows the unprintable character symbol (looks like []). ---------- components: IDLE messages: 146411 nosy: maniram.maniram priority: normal severity: normal status: open title: IDLE crashes when printing some unprintable characters. type: crash versions: Python 3.2 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Oct 26 08:43:11 2011 From: report at bugs.python.org (Nick Coghlan) Date: Wed, 26 Oct 2011 06:43:11 +0000 Subject: [New-bugs-announce] [issue13266] Support for unwrapping __wrapped__ functions in 'inspect' module Message-ID: <1319611391.89.0.610441716125.issue13266@psf.upfronthosting.co.za> New submission from Nick Coghlan : I just got bitten by the singularly unhelpful results of doing inspect.getsource(generator_context_manager). Now that @functools.wraps adds the __wrapped__ attribute, perhaps inspect.getsource(f) should follow the wrapper chain by default? This would affect other inspect APIs as well, such as getgeneratorstate() and the new getclosurevars() and getgeneratorlocals() that will be available in 3.3 While the source code of the wrapper could still be accessed by doing inspect.getsource(f.__code__), this isn't a reliable alternative in general (e.g. it doesn't work when introspecting closure state, since that needs access to the function object to look things up correctly). Accordingly, there would need to be a way to disable the "follow wrapper chains behaviour". Alternatively (and more simply), we could just add an "inspect.unwrap(f)" function that followed a chain of __wrapped__ attributes and returned the last object in the chain (using an "already seen" set to avoid hit the recursion limit if someone sets up a wrapper loop). Applying this would then be a manual process when the initial output of an inspect function is clearly coming from a wrapper rather than the underlying function definition. ---------- components: Library (Lib) messages: 146420 nosy: ncoghlan priority: normal severity: normal status: open title: Support for unwrapping __wrapped__ functions in 'inspect' module versions: Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Oct 26 09:23:05 2011 From: report at bugs.python.org (Petri Lehtinen) Date: Wed, 26 Oct 2011 07:23:05 +0000 Subject: [New-bugs-announce] [issue13267] Add an option to disable importing orphaned bytecode files Message-ID: <1319613785.83.0.955902072358.issue13267@psf.upfronthosting.co.za> New submission from Petri Lehtinen : This has been discussed in python-ideas approx. two years ago: http://mail.python.org/pipermail/python-ideas/2009-December/006635.html It seems to me that having an opt-in command-line option, environment variable and sys variable to disable loading orphaned bytecode files upon import had most use cases and gained most support. ---------- components: Interpreter Core messages: 146423 nosy: brett.cannon, ncoghlan, petri.lehtinen, pitrou priority: normal severity: normal status: open title: Add an option to disable importing orphaned bytecode files type: feature request versions: Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Oct 26 17:43:57 2011 From: report at bugs.python.org (Alexander Myodov) Date: Wed, 26 Oct 2011 15:43:57 +0000 Subject: [New-bugs-announce] [issue13268] assert Message-ID: <1319643837.13.0.0801682507198.issue13268@psf.upfronthosting.co.za> New submission from Alexander Myodov : The extended version of assert statement has a strange violation of documented behaviour. According to the http://docs.python.org/reference/simple_stmts.html#the-assert-statement, "assert expression1, expression2" should be equivalent to "if __debug__: if not expression1: raise AssertionError(expression2)". Nevertheless, it is not so for the following scenario: class A(object): def __str__(self): return "str" def __unicode__(self): return "unicode" def __repr__(self): return "repr" expression1 = False expression2 = (A(),) That is, when expression2 is a single-item tuple, assert statement prints the str-evaluation of the item itself, rather than of the tuple. This occurs in 2.x branch only, seems fixed in 3.x, and it would be great to have it backported for consistency. ---------- messages: 146434 nosy: amyodov priority: normal severity: normal status: open title: assert type: behavior versions: Python 2.6, Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Oct 26 17:53:22 2011 From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=) Date: Wed, 26 Oct 2011 15:53:22 +0000 Subject: [New-bugs-announce] [issue13269] Document that "Remote hg repo" accepts remote branches Message-ID: <1319644402.17.0.721295098845.issue13269@psf.upfronthosting.co.za> New submission from Jes?s Cea Avi?n : "Remote hg repo" accepts remote branches, but the devguide says that the patch must be in "default" branch. Update the docs. I take care of this. ---------- assignee: jcea keywords: easy messages: 146435 nosy: jcea priority: normal severity: normal status: open title: Document that "Remote hg repo" accepts remote branches _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Oct 26 23:15:50 2011 From: report at bugs.python.org (Florent Xicluna) Date: Wed, 26 Oct 2011 21:15:50 +0000 Subject: [New-bugs-announce] [issue13270] all classes are new style Message-ID: <1319663750.31.0.916391635164.issue13270@psf.upfronthosting.co.za> New submission from Florent Xicluna : these last references to old/new classes should be dropped. See patch. ---------- assignee: docs at python components: Documentation files: all_classes_belong_to_new_style.diff keywords: patch messages: 146455 nosy: docs at python, flox priority: normal severity: normal stage: patch review status: open title: all classes are new style type: behavior versions: Python 3.2, Python 3.3 Added file: http://bugs.python.org/file23530/all_classes_belong_to_new_style.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Oct 26 23:25:52 2011 From: report at bugs.python.org (Joshua Chia) Date: Wed, 26 Oct 2011 21:25:52 +0000 Subject: [New-bugs-announce] [issue13271] When -h is used with argparse, default values that fail should not matter Message-ID: <1319664352.05.0.511704738067.issue13271@psf.upfronthosting.co.za> New submission from Joshua Chia : What steps will reproduce the problem? 1. Make a script containing this code: parser = argparse.ArgumentParser() parser.add_argument('-i', '--input-base-directory', type=argparse.FileType('r'), default='/home') parser.parse_args() 2. Run the script with '-h'. 3. See it complain that '/home' is a directory Detailed explanation: With '-h', we just need to print the help message. We shouldn't fail on a default value that's wrong or else the help message will not get printed and the user will have no idea what the problem is. This is a valid use case as I want to provide a default location, but I can't guarantee that the location works on the user's machine. I end up doing my own checking. ---------- components: Library (Lib) messages: 146458 nosy: Joshua.Chia priority: normal severity: normal status: open title: When -h is used with argparse, default values that fail should not matter type: feature request versions: Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Oct 27 09:27:05 2011 From: report at bugs.python.org (Ezio Melotti) Date: Thu, 27 Oct 2011 07:27:05 +0000 Subject: [New-bugs-announce] [issue13272] 2to3 fix_renames doesn't rename string.lowercase/uppercase/letters Message-ID: <1319700425.9.0.635731429373.issue13272@psf.upfronthosting.co.za> New submission from Ezio Melotti : $ cat deleteme.py from string import lowercase, uppercase, letters print uppercase == 'ABCDEFGHIJKLMNOPQRSTUVWXYZ' print lowercase == 'abcdefghijklmnopqrstuvwxyz' print letters == 'abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ' $ python deleteme.py True True True $ 2to3 -w deleteme.py RefactoringTool: Skipping implicit fixer: buffer RefactoringTool: Skipping implicit fixer: idioms RefactoringTool: Skipping implicit fixer: set_literal RefactoringTool: Skipping implicit fixer: ws_comma RefactoringTool: Refactored deleteme.py --- deleteme.py (original) +++ deleteme.py (refactored) @@ -1,4 +1,4 @@ from string import lowercase, uppercase, letters -print uppercase == 'ABCDEFGHIJKLMNOPQRSTUVWXYZ' -print lowercase == 'abcdefghijklmnopqrstuvwxyz' -print letters == 'abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ' +print(uppercase == 'ABCDEFGHIJKLMNOPQRSTUVWXYZ') +print(lowercase == 'abcdefghijklmnopqrstuvwxyz') +print(letters == 'abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ') RefactoringTool: Files that were modified: RefactoringTool: deleteme.py $ python3 deleteme.py Traceback (most recent call last): File "deleteme.py", line 1, in from string import lowercase, uppercase, letters ImportError: cannot import name lowercase They should be renamed to ascii_*. ---------- components: 2to3 (2.x to 3.0 conversion tool) messages: 146475 nosy: benjamin.peterson, ezio.melotti priority: normal severity: normal stage: test needed status: open title: 2to3 fix_renames doesn't rename string.lowercase/uppercase/letters type: behavior versions: Python 2.7, Python 3.2, Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Oct 27 09:56:02 2011 From: report at bugs.python.org (Christopher Allen-Poole) Date: Thu, 27 Oct 2011 07:56:02 +0000 Subject: [New-bugs-announce] [issue13273] HTMLParser improperly handling open tags when strict is False Message-ID: <1319702162.06.0.209889524007.issue13273@psf.upfronthosting.co.za> New submission from Christopher Allen-Poole : This is is encountered when extending html.parser.HTMLParser and running with strict mode False. Expected behavior: When '''

    The rain
    in Spain
    ''' is passed to the feed method, div, b, a, br, and span should all be passed to the handle_starttag method. Actual behavior The handle_data method receives the values
    ,,,
    , in addition to the regular text. This can be fixed by changing this (inside the parse_starttag method): m = hparse.attrfind_tolerant.search(rawdata, k) to m = hparse.attrfind_tolerant.match(rawdata, k) ---------- components: Library (Lib) messages: 146479 nosy: Christopher.Allen-Poole priority: normal severity: normal status: open title: HTMLParser improperly handling open tags when strict is False type: behavior versions: Python 3.2 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Oct 27 10:50:25 2011 From: report at bugs.python.org (Ronny Pfannschmidt) Date: Thu, 27 Oct 2011 08:50:25 +0000 Subject: [New-bugs-announce] [issue13274] heapq pure python version uses islice without guarding for negative counts Message-ID: <1319705425.2.0.678284473913.issue13274@psf.upfronthosting.co.za> New submission from Ronny Pfannschmidt : the problem manifests when calling with negative counts when the c versions are used, a empty list is returned, however if the pure python version is called islice errors out ---------- components: Library (Lib) messages: 146483 nosy: Ronny.Pfannschmidt priority: normal severity: normal status: open title: heapq pure python version uses islice without guarding for negative counts type: behavior versions: Python 2.6, Python 2.7, Python 3.1, Python 3.2, Python 3.3, Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Oct 27 12:05:59 2011 From: report at bugs.python.org (Alexey Shamrin) Date: Thu, 27 Oct 2011 10:05:59 +0000 Subject: [New-bugs-announce] [issue13275] Recommend xml.etree for XML processing Message-ID: <1319709959.84.0.984784684468.issue13275@psf.upfronthosting.co.za> New submission from Alexey Shamrin : There are many libraries in Python stdlib [1] xml.dom xml.dom.minidom xml.dom.pulldom xml.sax xml.etree Tutorial mentions xml.dom and xml.sax. [2] In my experience xml.etree is the best library to quickly load some xml and mess with it. It would be nice to recommend people xml.etree in the tutorial [2] and in the beginning of section 19, "Structured Markup Processing Tools". [1] [1]: http://docs.python.org/library/markup.html [2]: http://docs.python.org/tutorial/stdlib.html#batteries-included ---------- assignee: docs at python components: Documentation messages: 146484 nosy: ash, docs at python priority: normal severity: normal status: open title: Recommend xml.etree for XML processing _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Oct 27 17:30:55 2011 From: report at bugs.python.org (francisco) Date: Thu, 27 Oct 2011 15:30:55 +0000 Subject: [New-bugs-announce] [issue13276] distutils bdist_wininst created installer does not run the postinstallation script on uninstalling Message-ID: <1319729455.78.0.312367178712.issue13276@psf.upfronthosting.co.za> New submission from francisco : The bug can be reproduced by running the following command to create a Windows installer for the attached module: python setup.py bdist_wininst --install-script pis.py I include also the installer that I have created in the dist folder. The installer installs everything correctly and it runs the pis.py script, which simply creates a file in the USERPROFILE directory with the "Installing" string. However, when uninstalling the program from the Windows Control Panel the script is not called, what can be verified by checking that the "Uninstalling" string is not appended to the file. I am experiencing this problem in Windows 7 64 bits, but it may be present in other platforms. ---------- assignee: tarek components: Distutils files: foo.zip messages: 146492 nosy: eric.araujo, francisco, tarek priority: normal severity: normal status: open title: distutils bdist_wininst created installer does not run the postinstallation script on uninstalling versions: Python 2.7 Added file: http://bugs.python.org/file23536/foo.zip _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Oct 27 18:40:07 2011 From: report at bugs.python.org (Senthil Kumaran) Date: Thu, 27 Oct 2011 16:40:07 +0000 Subject: [New-bugs-announce] [issue13277] tzinfo subclasses information Message-ID: <1319733607.49.0.8093265907.issue13277@psf.upfronthosting.co.za> New submission from Senthil Kumaran : This was in the docs mailing list, not translated to bug report Paul Koning wrote: Section 8.1.6 of the library manual talks about utcoffset(dt)-dst(dt) as the "standard offset" and says that this should not depend on the date or +time but only on the location. This is not true as there cases were certain locations changed the time offsets as per their convenience. It is either a doc fix to remove that sentence if the datetime.astimezone does not depend upon utcoffset(dt)-dst(dt), or if it does, then it is a code fix. ---------- assignee: docs at python messages: 146501 nosy: docs at python, orsenthil priority: normal severity: normal stage: needs patch status: open title: tzinfo subclasses information type: behavior _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Oct 27 18:58:16 2011 From: report at bugs.python.org (Jeffrey Finkelstein) Date: Thu, 27 Oct 2011 16:58:16 +0000 Subject: [New-bugs-announce] [issue13278] Typo in documentation for sched module Message-ID: <1319734696.41.0.842696728904.issue13278@psf.upfronthosting.co.za> New submission from Jeffrey Finkelstein : In the documentation for the sched.scheduler.enter() function, change the phrase "Other then the relative time" to "Other than the relative time" (i.e. change "then" to "than"). ---------- assignee: docs at python components: Documentation messages: 146506 nosy: docs at python, jfinkels priority: normal severity: normal status: open title: Typo in documentation for sched module versions: Python 2.6, Python 2.7, Python 3.1, Python 3.2, Python 3.3, Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Oct 27 19:52:41 2011 From: report at bugs.python.org (Richard Saunders) Date: Thu, 27 Oct 2011 17:52:41 +0000 Subject: [New-bugs-announce] [issue13279] Add memcmp into unicode_compare for optimizing compares Message-ID: <1319737961.76.0.990787408068.issue13279@psf.upfronthosting.co.za> New submission from Richard Saunders : In discussions of memcmp performance, (http://www.picklingtools.com/study.pdf) it was noted how well Python 2.7 can take advantage of faster memcmps (indeed, the rich comparisons are all memcmp calls). There have been some discussion on python-dev at python.org as well. With unicode and Python 3.3 (and anyPython 3.x) there are a few places we could call memcmp to make string comparisons faster, but they are not completely trivial. Basically, if the unicode strings are "1 byte kind", then memcmp can be used almost as is. If the unicode strings are the same kind, they can at least use memcmp to compare for equality or inequality. There is also a minor optimization laying in unicode_compare: if you are comparing two strings for equality/inequality, there is no reason to look at the entire string if the lengths are different. These 3 minor optimizations can make unicode_compare faster. ---------- components: Interpreter Core messages: 146508 nosy: RichIsMyName, asmodai, loewis, pitrou, scoder priority: normal severity: normal status: open title: Add memcmp into unicode_compare for optimizing compares type: performance versions: Python 3.3, Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Oct 27 22:19:11 2011 From: report at bugs.python.org (Patrick Westerhoff) Date: Thu, 27 Oct 2011 20:19:11 +0000 Subject: [New-bugs-announce] [issue13280] argparse should use the new Formatter class Message-ID: <1319746751.8.0.206945992721.issue13280@psf.upfronthosting.co.za> New submission from Patrick Westerhoff : Hey, according to PEP 3101, the new string.Formatter class is supposed to replace the old string formatting with %. At least that is what I was always thinking. Given that argparse is a Python 3.2+ exclusive module, I think it should make use of that new formatting method. Is there any special reason why that is not the case and the old %-formatting is used? It feels a bit weird to have Python 3 code using only string.Formatter and then have a short section where the old formatter is used ? especially when that module was introduced with Python 3.2. ---------- components: Library (Lib) messages: 146516 nosy: poke priority: normal severity: normal status: open title: argparse should use the new Formatter class type: behavior versions: Python 3.2, Python 3.3, Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Oct 27 22:30:44 2011 From: report at bugs.python.org (Brian Bernstein) Date: Thu, 27 Oct 2011 20:30:44 +0000 Subject: [New-bugs-announce] [issue13281] robotparser.RobotFileParser ignores rules preceeded by a blank line Message-ID: <1319747444.2.0.491041533825.issue13281@psf.upfronthosting.co.za> New submission from Brian Bernstein : When attempting to parse a robots.txt file which has a blank line between allow/disallow rules, all rules after the blank line are ignored. If a blank line occurs between the user-agent and its rules, all of the rules for that user-agent are ignored. I am not sure if having a blank line between rules is allowed in the spec, but I am seeing this behavior in a number of sites, for instance: http://www.whitehouse.gov/robots.txt has a blank line between the disallow rules all other lines, including the associated user-agent line, resulting in the python RobotFileParser to ignore all rules. http://www.last.fm/robots.txt appears to separate their rules with arbitrary blank lines between them. The python RobotFileParser only sees the first two rule between the user-agent and the next newline. If the parser is changed to simply ignore all blank lines, would it have any adverse affect on parsing robots.txt files? I am including a simple patch which ignores all blank lines and appears to find all rules from these robots.txt files. ---------- files: robotparser.py.patch keywords: patch messages: 146518 nosy: bernie9998 priority: normal severity: normal status: open title: robotparser.RobotFileParser ignores rules preceeded by a blank line type: behavior versions: Python 2.7 Added file: http://bugs.python.org/file23538/robotparser.py.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Oct 28 12:08:26 2011 From: report at bugs.python.org (wrobell) Date: Fri, 28 Oct 2011 10:08:26 +0000 Subject: [New-bugs-announce] [issue13282] the table of contents in epub file is too long Message-ID: <1319796506.79.0.347343158897.issue13282@psf.upfronthosting.co.za> New submission from wrobell : the table of contents in python documentation epub file is very very long. it takes several long minutes to jump from first page to a part containing language reference toc. imho it would be great if first page of epub file contained pointers to tutorial, lang ref, mod ref without detailed table of contents as it is at docs.python.org. ---------- assignee: docs at python components: Documentation messages: 146548 nosy: docs at python, wrobell priority: normal severity: normal status: open title: the table of contents in epub file is too long versions: Python 2.7, Python 3.2 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Oct 28 12:14:23 2011 From: report at bugs.python.org (=?utf-8?q?Nicolas_=C3=89vrard?=) Date: Fri, 28 Oct 2011 10:14:23 +0000 Subject: [New-bugs-announce] [issue13283] removal of two unused variable in locale.py Message-ID: <1319796863.15.0.791142726242.issue13283@psf.upfronthosting.co.za> New submission from Nicolas ?vrard : While using pyflake on some of my file I noticed in a copied version of _group two unused variables. The attached patch fixed that very little annoyance. ---------- components: Library (Lib) files: locale.diff keywords: patch messages: 146549 nosy: nicoe priority: normal severity: normal status: open title: removal of two unused variable in locale.py type: resource usage versions: Python 2.7 Added file: http://bugs.python.org/file23540/locale.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Oct 28 12:26:04 2011 From: report at bugs.python.org (Burak Arslan) Date: Fri, 28 Oct 2011 10:26:04 +0000 Subject: [New-bugs-announce] [issue13284] email.utils.formatdate function does not handle timezones correctly. Message-ID: <1319797564.66.0.629117270841.issue13284@psf.upfronthosting.co.za> New submission from Burak Arslan : There's an issue with email.utils.formatdate function, illustrated here: https://gist.github.com/1321994 for reference i'm on Europe/Istanbul timezone, which is +03:00 because of DST at the time of this writing. I'm on stable Python 2.7.2 on gentoo linux. When I run the attached script, I get: Fri, 28 Oct 2011 07:56:14 -0000 datetime.datetime(2011, 10, 28, 9, 56, 14, 945831, tzinfo=) when the local time is 12:56. so the second line is correct and first one is not. let me know if you need any more information. thanks for your attention. ---------- components: Library (Lib) files: test_formatdate.py messages: 146551 nosy: burak.arslan priority: normal severity: normal status: open title: email.utils.formatdate function does not handle timezones correctly. versions: Python 2.7 Added file: http://bugs.python.org/file23541/test_formatdate.py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Oct 28 13:27:58 2011 From: report at bugs.python.org (Vilya Harvey) Date: Fri, 28 Oct 2011 11:27:58 +0000 Subject: [New-bugs-announce] [issue13285] signal module in ignores external signal changes Message-ID: <1319801278.56.0.946220269602.issue13285@psf.upfronthosting.co.za> New submission from Vilya Harvey : The signal module is oblivious to any changes to the set of installed signal handlers which occur outside of the module. This can happen when a native module changes a signal handler, or when the python interpreter is embedded in another program which installs its own signal handlers. In this case, saving and restoring a signal handler through python doesn't work correctly. For example, if the SIGINT handler is set externally after the signal module is initialised, the following code will replace the external signal handler with python's default_int_handler: handler = signal.getsignal(signal.SIGINT) signal.signal(signal.SIGINT, handler) So it's impossible to reliably save and restore signal handlers through python when they can also be changed outside the python interpreter. Also, if there's a signal handler installed before the module is initialised, signal.getsignal() will return None for it - making it impossible to restore the correct handler after disabling it. The reason is that the signal module only checks for existing handlers when it's initialised. The results get stored in the Handlers array, which is then used by all subsequent calls to signal.getsignal(). There are no further checks to see whether the native signal handlers have changed. ---------- messages: 146553 nosy: vilya priority: normal severity: normal status: open title: signal module in ignores external signal changes type: behavior versions: Python 2.6, Python 2.7, Python 3.1, Python 3.2 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Oct 28 16:18:50 2011 From: report at bugs.python.org (STINNER Victor) Date: Fri, 28 Oct 2011 14:18:50 +0000 Subject: [New-bugs-announce] [issue13286] PEP 3151 breaks backward compatibility: it should be documented Message-ID: <1319811530.69.0.689775391155.issue13286@psf.upfronthosting.co.za> New submission from STINNER Victor : The following example works on Python 2.7 and 3.2, but fails on Python 3.3: ----------- import errno import os try: os.rmdir("testdir") except: pass os.mkdir("testdir") try: try: os.mkdir("testdir") except IOError as exc: # If can't get proper access, then just forget about writing # the data. if exc.errno == errno.EACCES: pass else: raise except OSError as exc: # Probably another Python process already created the dir. if exc.errno == errno.EEXIST: pass else: raise except Exception: print("PEP 3151 broke backward compatibility on such pattern!") ----------- I noticed the problem while reading the changeset e4d44c2e8e81. ---------- assignee: docs at python components: Documentation messages: 146562 nosy: docs at python, flox, haypo, pitrou priority: normal severity: normal status: open title: PEP 3151 breaks backward compatibility: it should be documented versions: Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Oct 28 17:01:15 2011 From: report at bugs.python.org (Florent Xicluna) Date: Fri, 28 Oct 2011 15:01:15 +0000 Subject: [New-bugs-announce] [issue13287] urllib.request exposes too many names Message-ID: <1319814075.5.0.569025067527.issue13287@psf.upfronthosting.co.za> New submission from Florent Xicluna : >>> len(dir()) 4 >>> import urllib.request import * >>> len(dir()) 88 In this list we find 14 modules: ['base64', 'collections', 'ssl', 'bisect', 'http', 're', 'email', 'socket', 'os', 'posixpath', 'hashlib', 'io', 'time', 'sys'] And many non-documented functions: - ftperrors - getproxies_environment - getproxies_macosx_sysconf - localhost - noheaders - parse_http_list - parse_keqv_list - proxy_bypass - proxy_bypass_environment - proxy_bypass_macosx_sysconf - quote - randombytes - request_host - urlunparse - splitattr - splithost - splitpasswd - splitport - splitquery - splittag - splittype - splituser - splitvalue - thishost - to_bytes - unquote - unwrap - urljoin - urlparse - urlsplit It may be good to define __all__ for this module, and to preprend "_" on some of these names. ---------- components: Library (Lib) messages: 146568 nosy: flox priority: normal severity: normal stage: needs patch status: open title: urllib.request exposes too many names type: behavior versions: Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Oct 28 23:12:22 2011 From: report at bugs.python.org (John Nagle) Date: Fri, 28 Oct 2011 21:12:22 +0000 Subject: [New-bugs-announce] [issue13288] SSL module doesn't allow access to cert issuer information Message-ID: <1319836342.01.0.0498331341848.issue13288@psf.upfronthosting.co.za> New submission from John Nagle : The SSL module still doesn't return much information from the certificate. SSLSocket.getpeercert only returns a few basic items about the certificate subject. You can't retrieve issuer information, and you can't get the extensions needed to check if a cert is an EV cert. With the latest flaps about phony cert issuers, (another CA compromise hit the news today) it's worth having issuer info available. It was available in the old M2Crypto module, but not in the current Python SSL module. John Nagle ---------- components: Library (Lib) messages: 146579 nosy: nagle priority: normal severity: normal status: open title: SSL module doesn't allow access to cert issuer information versions: Python 2.6, Python 2.7, Python 3.1, Python 3.2, Python 3.3, Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Oct 29 05:50:23 2011 From: report at bugs.python.org (args wu) Date: Sat, 29 Oct 2011 03:50:23 +0000 Subject: [New-bugs-announce] =?utf-8?q?=5Bissue13289=5D_a_spell_error_in_s?= =?utf-8?q?tandard_lib_SocketServer=E2=80=98s_comment?= Message-ID: <1319860223.7.0.549256662259.issue13289@psf.upfronthosting.co.za> New submission from args wu : In line 85, the reqd should be read. I also checked in python3.2's lib, the error still be there? ---------- components: Library (Lib) messages: 146597 nosy: args.wu priority: normal severity: normal status: open title: a spell error in standard lib SocketServer?s comment versions: Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Oct 29 09:04:10 2011 From: report at bugs.python.org (=?utf-8?q?Jo=C3=A3o_Bernardo?=) Date: Sat, 29 Oct 2011 07:04:10 +0000 Subject: [New-bugs-announce] [issue13290] get vars for object with __slots__ Message-ID: <1319871850.77.0.869546838833.issue13290@psf.upfronthosting.co.za> New submission from Jo?o Bernardo : I just realized the builtin function `vars` can't handle custom objects without the __dict__ attribute. It would be nice if it worked with objects that have __slots__ to make them look more like normal objects and to make debugging easier. I changed the source of "Python/bltinmodule.c" to accept this new case, but, as I'm fairly new to the C API, it may not be much good. I'm attaching the whole file to this Issue and the `builtin_vars` function was modified (lines 1859 to 1921) to work with: __slots__ = ('a', 'b', 'c') __slots__ = 'single_name' __slots__ = {'some': 'mapping'} The output is a dict (just like in the __dict__ case). #Example >>> class C: __slots__ = ['x', 'y'] >>> c = C() >>> c.x = 123 >>> vars(c) {'x': 123} ---------- components: Interpreter Core files: bltinmodule.c messages: 146598 nosy: JBernardo priority: normal severity: normal status: open title: get vars for object with __slots__ type: feature request versions: Python 3.2, Python 3.3 Added file: http://bugs.python.org/file23546/bltinmodule.c _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Oct 30 00:51:23 2011 From: report at bugs.python.org (Florent Xicluna) Date: Sat, 29 Oct 2011 22:51:23 +0000 Subject: [New-bugs-announce] [issue13291] latent NameError in xmlrpc package Message-ID: <1319928683.07.0.326015714252.issue13291@psf.upfronthosting.co.za> New submission from Florent Xicluna : There's two names which should be fixed in "xmlrpc" package: --- a/Lib/xmlrpc/client.py - elif isinstance(other, (str, unicode)): --- a/Lib/xmlrpc/server.py - response = xmlrpclib.dumps( - xmlrpclib.Fault(1, "%s:%s" % (exc_type, exc_value)), We may extend test coverage too. ---------- components: Library (Lib), XML messages: 146622 nosy: flox priority: normal severity: normal stage: test needed status: open title: latent NameError in xmlrpc package type: behavior versions: Python 3.2, Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Oct 30 12:52:13 2011 From: report at bugs.python.org (Florent Xicluna) Date: Sun, 30 Oct 2011 11:52:13 +0000 Subject: [New-bugs-announce] [issue13292] missing versionadded for bytearray Message-ID: <1319975533.88.0.431386848219.issue13292@psf.upfronthosting.co.za> New submission from Florent Xicluna : versionadded is missing here: http://docs.python.org/library/functions.html#bytearray ---------- assignee: docs at python components: Documentation messages: 146633 nosy: docs at python, flox priority: normal severity: normal stage: needs patch status: open title: missing versionadded for bytearray type: behavior versions: Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Oct 30 13:55:55 2011 From: report at bugs.python.org (luchenue) Date: Sun, 30 Oct 2011 12:55:55 +0000 Subject: [New-bugs-announce] [issue13293] xmlrpc.client encode error Message-ID: <1319979355.49.0.42965800698.issue13293@psf.upfronthosting.co.za> New submission from luchenue : import xmlrpc.client server = xmlrpc.client.Server('XXX') print(server.login(b'bHVjaGVudWU=',b'bHVjaGVudWU=')) => xmlrpc.client def dump_string write(escape(value)) dispatch[bytes] = dump_string => def escape(s): s = s.replace("&", "&") bytes can't replace ---------- messages: 146637 nosy: luchenue priority: normal severity: normal status: open title: xmlrpc.client encode error type: behavior versions: Python 3.2 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Oct 30 15:40:42 2011 From: report at bugs.python.org (karl) Date: Sun, 30 Oct 2011 14:40:42 +0000 Subject: [New-bugs-announce] [issue13294] http.server - HEAD request when no resource is defined. Message-ID: <1319985642.06.0.787750282348.issue13294@psf.upfronthosting.co.za> New submission from karl : A very simple HTTP server #!/usr/bin/python3 import http.server from os import chdir # CONFIG ROOTPATH = '/Your/path/' PORT = 8000 # CODE def run(server_class=http.server.HTTPServer, server_handler=http.server.SimpleHTTPRequestHandler): server_address = ('', PORT) httpd = server_class(server_address, server_handler) httpd.serve_forever() class MyRequestHandler(http.server.SimpleHTTPRequestHandler): def do_GET(self): pass if __name__ == '__main__': chdir(ROOTPATH) print("server started on PORT:?"+str(PORT)) run(server_handler=MyRequestHandler) Let's start the server. % python3 serveur1.py server started on PORT:?8000 And let's do a GET request with curl. % curl -v http://localhost:8000/ * About to connect() to localhost port 8000 (#0) * Trying ::1... Connection refused * Trying 127.0.0.1... connected * Connected to localhost (127.0.0.1) port 8000 (#0) > GET / HTTP/1.1 > User-Agent: curl/7.21.4 (universal-apple-darwin11.0) libcurl/7.21.4 OpenSSL/0.9.8r zlib/1.2.5 > Host: localhost:8000 > Accept: */* > * Empty reply from server * Connection #0 to host localhost left intact curl: (52) Empty reply from server * Closing connection #0 The server sends nothing because GET is not defined and I haven't defined anything in case of errors. So far so good. Now let's do a HEAD request on the same resource. % curl -vsI http://localhost:8000/ * About to connect() to localhost port 8000 (#0) * Trying ::1... Connection refused * Trying 127.0.0.1... connected * Connected to localhost (127.0.0.1) port 8000 (#0) > HEAD / HTTP/1.1 > User-Agent: curl/7.21.4 (universal-apple-darwin11.0) libcurl/7.21.4 OpenSSL/0.9.8r zlib/1.2.5 > Host: localhost:8000 > Accept: */* > * HTTP 1.0, assume close after body < HTTP/1.0 200 OK HTTP/1.0 200 OK < Server: SimpleHTTP/0.6 Python/3.1.2 Server: SimpleHTTP/0.6 Python/3.1.2 < Date: Sun, 30 Oct 2011 14:19:00 GMT Date: Sun, 30 Oct 2011 14:19:00 GMT < Content-type: text/html; charset=utf-8 Content-type: text/html; charset=utf-8 < Content-Length: 346 Content-Length: 346 < * Closing connection #0 The server shows in the log the request localhost - - [30/Oct/2011 10:19:00] "HEAD / HTTP/1.1" 200 - And is answering. I would suggest that the default behavior is to have something similar to the one for the GET aka nothing. Or to modify the library code that for any resources not yet defined. The server answers a code 403 Forbidden. I could submit a patch in the next few days. ---------- components: Library (Lib) messages: 146639 nosy: karlcow, orsenthil priority: normal severity: normal status: open title: http.server - HEAD request when no resource is defined. type: feature request versions: Python 3.1, Python 3.2 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Oct 30 16:07:25 2011 From: report at bugs.python.org (karl) Date: Sun, 30 Oct 2011 15:07:25 +0000 Subject: [New-bugs-announce] [issue13295] html5 template for Lib/http/server.py Message-ID: <1319987245.42.0.28884085529.issue13295@psf.upfronthosting.co.za> New submission from karl : The code has a set of old HTML templates. Here is a patch to change it to very simple html5 templates. ---------- components: Library (Lib) files: server-html5.patch keywords: patch messages: 146641 nosy: karlcow, orsenthil priority: normal severity: normal status: open title: html5 template for Lib/http/server.py type: feature request versions: Python 3.1, Python 3.2 Added file: http://bugs.python.org/file23554/server-html5.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Oct 30 18:24:51 2011 From: report at bugs.python.org (Roger Serwy) Date: Sun, 30 Oct 2011 17:24:51 +0000 Subject: [New-bugs-announce] [issue13296] IDLE: __future__ flags don't clear on shell restart Message-ID: <1319995491.95.0.0388029066665.issue13296@psf.upfronthosting.co.za> New submission from Roger Serwy : The interactive interpreter in IDLE does not reset its compiler __future__ flags when you restart the shell. To verify this, type into the shell: >>> from __future__ import barry_as_FLUFL >>> 1 != 2 You'll get a syntax error. Restart the shell and type >>> 1 != 2 A syntax error still occurs. The ModifiedInterpreter class in PyShell.py ultimately relies on codeop to mimic the interactive prompt. The codeop module was created specifically for remembering __future__ flags for subsequent commands. The provided patch stores the flags of the interpreter when it first initializes, and then restores them in "restart_subprocess". It's a patch against 3.2.2. ---------- components: IDLE files: patch_future.diff keywords: patch messages: 146646 nosy: ezio.melotti, serwy priority: normal severity: normal status: open title: IDLE: __future__ flags don't clear on shell restart type: behavior versions: Python 2.6, Python 2.7, Python 3.1, Python 3.2 Added file: http://bugs.python.org/file23557/patch_future.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Oct 31 00:41:40 2011 From: report at bugs.python.org (Florent Xicluna) Date: Sun, 30 Oct 2011 23:41:40 +0000 Subject: [New-bugs-announce] [issue13297] xmlrpc.client could accept bytes for input and output Message-ID: <1320018100.14.0.184941596185.issue13297@psf.upfronthosting.co.za> New submission from Florent Xicluna : Since Python 3 makes clear the distinction between bytes and string, there is no more reason to use the xmlrpc.client.Binary wrapper for binary objects. The xmlrpc library may deal with bytes and bytearray normally. To support backward compatibility, the ServerProxy will have a keyword argument "use_bytes" similar to the "use_datetime" from issue #1120353. ---------- components: Library (Lib), XML messages: 146666 nosy: flox priority: normal severity: normal status: open title: xmlrpc.client could accept bytes for input and output type: feature request versions: Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Oct 31 01:14:37 2011 From: report at bugs.python.org (Nick Coghlan) Date: Mon, 31 Oct 2011 00:14:37 +0000 Subject: [New-bugs-announce] [issue13298] Result type depends on order of operands for bytes and bytearray Message-ID: <1320020077.78.0.866789839878.issue13298@psf.upfronthosting.co.za> New submission from Nick Coghlan : In a recent python-ideas discussion of the differences between concatenation and augmented assignment on lists, I pointed out the general guiding principle behind Python's binary operation semantics was that the type of a binary operation should not depend on the order of the operands. That is "X op Y" and "Y op X" should either consistently create results of the same type ("1 + 1.1", "1.1 + 1") or else throw an exception ("[] + ()", "() + []"). This principle is why list concatenation normally only works with other lists, but will accept arbitrary iterables for augmented assignment. collections.deque exhibits similar behaviour (i.e. strict on the binary operation, permissive on augmented assignment). However, bytes and bytearray don't follow this principle - they accept anything that implements the buffer interface even in the binary operation, leading to the following asymmetries: >>> b'' + bytearray() b'' >>> b'' + memoryview(b'') b'' >>> bytearray() + b'' bytearray(b'') >>> bytearray() + memoryview(b'') bytearray(b'') >>> memoryview(b'') + b'' Traceback (most recent call last): File "", line 1, in TypeError: unsupported operand type(s) for +: 'memoryview' and 'bytes' >>> memoryview(b'') + bytearray(b'') Traceback (most recent call last): File "", line 1, in TypeError: unsupported operand type(s) for +: 'memoryview' and 'bytearray' Now, the latter two cases are due to a known problem where returning NotImplemented from sq_concat or sq_repeat doesn't work properly (so none of the relevant method implementations in the stdlib even try), but the bytes and bytearray interaction is exactly the kind of type asymmetry the operand order independence guideline is intended to prevent. My question is - do we care enough to try to change this? If we do, then it's necessary to decide on more appropriate semantics: 1. The "list" solution, permitting only the same type in binary operations (high risk of breaking quite a lot of code) 2. Don't allow arbitrary buffers, but do allow bytes/bytearray interoperability 2a. always return bytes from mixed operations 2b. always return bytearray from mixed operations 2c. return the type of the first operand (ala set.__or__) Or just accept that this really is more of a guideline than a rule and adjust the documentation accordingly. ---------- components: Interpreter Core messages: 146669 nosy: ncoghlan priority: normal severity: normal status: open title: Result type depends on order of operands for bytes and bytearray type: behavior versions: Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Oct 31 01:32:25 2011 From: report at bugs.python.org (Nick Coghlan) Date: Mon, 31 Oct 2011 00:32:25 +0000 Subject: [New-bugs-announce] [issue13299] namedtuple row factory for sqlite3 Message-ID: <1320021145.59.0.53370875256.issue13299@psf.upfronthosting.co.za> New submission from Nick Coghlan : Currently, sqlite3 allows rows to be easily returned as ordinary tuples (default) or sqlite3.Row objects (which allow dict-style access). collections.namedtuple provides a much nicer interface than sqlite3.Row for accessing ordered data which uses valid Python identifiers for field names, and can also tolerate field names which are *not* valid identifiers. It would be convenient if sqlite3 provided a row factory along the lines of the one posted here: http://peter-hoffmann.com/2010/python-sqlite-namedtuple-factory.html (except with smarter caching on the named tuples) ---------- messages: 146670 nosy: ncoghlan priority: normal severity: normal stage: needs patch status: open title: namedtuple row factory for sqlite3 type: feature request versions: Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Oct 31 03:06:39 2011 From: report at bugs.python.org (Ned Deily) Date: Mon, 31 Oct 2011 02:06:39 +0000 Subject: [New-bugs-announce] [issue13300] IDLE 3.3 Restart Shell command fails Message-ID: <1320026799.26.0.540984948832.issue13300@psf.upfronthosting.co.za> New submission from Ned Deily : Currently in the default (pre-3.3) branch, IDLE fails if its Restart Shell command is attempted: Exception in Tkinter callback Traceback (most recent call last): File "Lib/tkinter/__init__.py", line 1397, in __call__ return self.func(*args) File "Lib/idlelib/PyShell.py", line 1180, in restart_shell self.interp.restart_subprocess() File "Lib/idlelib/PyShell.py", line 429, in restart_subprocess self.rpcclt.accept() File "Lib/idlelib/rpc.py", line 525, in accept working_sock, address = self.listening_sock.accept() File "Lib/socket.py", line 134, in accept fd, addr = self._accept() OSError: [Errno 9] Bad file descriptor IDLE Subprocess: socket error: Connection refused, retrying.... IDLE Subprocess: socket error: Connection refused, retrying.... Warning (from warnings module): File "Lib/idlelib/run.py", line 127 socket_error = err ResourceWarning: unclosed IDLE Subprocess: socket error: Connection refused, retrying.... The culprit is recent changeset 3a5a0943b201 which attempted to prevent some debug ResourceWarnings during IDLE shutdown. Adding the close override to the RPCClient class causes the listening socket to be closed when the shell is restarted but then a new listening socket is not opened. The listening socket should only be closed when IDLE terminates, not when the subprocess is restarted. ---------- assignee: ned.deily components: IDLE messages: 146672 nosy: amaury.forgeotdarc, ned.deily priority: normal severity: normal stage: needs patch status: open title: IDLE 3.3 Restart Shell command fails type: behavior versions: Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Oct 31 10:18:16 2011 From: report at bugs.python.org (David Jean Louis) Date: Mon, 31 Oct 2011 09:18:16 +0000 Subject: [New-bugs-announce] [issue13301] the script Tools/i18n/msgfmt.py allows arbitrary code execution via po files Message-ID: <1320052696.17.0.926291745102.issue13301@psf.upfronthosting.co.za> New submission from David Jean Louis : Hi, I'm the author of the polib python module, incidentally (after a bug report in polib: https://bitbucket.org/izi/polib/issue/27/polib-doesnt-check-unescaped-quote) I've found that the eval() in Tools/i18n/msgfmt.py allows arbitrary code execution, someone could create a malicious po entry like this: msgid "owned!" msgstr "" or __import__("os").popen("rm -rf /") As this is an "internal tool" used by developers, maybe it is not very important, but given that people may reuse this script for generating mo files, I think this needs to be fixed, I'm adding a patch for this issue. Regards, -- David ---------- components: Demos and Tools files: msgfmt.py.diff keywords: patch messages: 146678 nosy: izi priority: normal severity: normal status: open title: the script Tools/i18n/msgfmt.py allows arbitrary code execution via po files type: security versions: Python 2.6, Python 2.7, Python 3.1, Python 3.2, Python 3.3, Python 3.4 Added file: http://bugs.python.org/file23566/msgfmt.py.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Oct 31 11:42:43 2011 From: report at bugs.python.org (Sandro Tosi) Date: Mon, 31 Oct 2011 10:42:43 +0000 Subject: [New-bugs-announce] [issue13302] Clarification needed in C API arg parsing Message-ID: <1320057763.71.0.58387430149.issue13302@psf.upfronthosting.co.za> New submission from Sandro Tosi : Hello, given I can't fully comprehend the user request (sent on docs@ as of http://mail.python.org/pipermail/docs/2011-September/005791.html), I'm just echoing it : >>> recently I embedded Python into one of my applications, which included some string parsing. In my opinion the doc page about parsing arguments (http://docs.python.org/c-api/arg.html) is missing the information, that you must not free the returned const char *, like e.g. said here (http://docs.python.org/c-api/string.html#PyString_AsString). It was quite confusing for my first, so I would suggest adding this tiny bit of information. <<< ---------- assignee: docs at python components: Documentation messages: 146687 nosy: docs at python, sandro.tosi priority: normal severity: normal stage: needs patch status: open title: Clarification needed in C API arg parsing versions: Python 2.7, Python 3.2, Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Oct 31 12:01:11 2011 From: report at bugs.python.org (STINNER Victor) Date: Mon, 31 Oct 2011 11:01:11 +0000 Subject: [New-bugs-announce] [issue13303] Sporadic importlib failures: FileNotFoundError on os.rename() Message-ID: <1320058871.09.0.581986884521.issue13303@psf.upfronthosting.co.za> New submission from STINNER Victor : Traceback (most recent call last): File "/export/home/buildbot/32bits/3.x.cea-indiana-x86/build/Lib/test/regrtest.py", line 1186, in runtest_inner indirect_test() File "/export/home/buildbot/32bits/3.x.cea-indiana-x86/build/Lib/test/test_ttk_textonly.py", line 11, in test_main *runtktests.get_tests(gui=False, packages=['test_ttk'])) File "/export/home/buildbot/32bits/3.x.cea-indiana-x86/build/Lib/tkinter/test/runtktests.py", line 65, in get_tests for module in get_tests_modules(gui=gui, packages=packages): File "/export/home/buildbot/32bits/3.x.cea-indiana-x86/build/Lib/tkinter/test/runtktests.py", line 50, in get_tests_modules "tkinter.test") File "/export/home/buildbot/32bits/3.x.cea-indiana-x86/build/Lib/importlib/__init__.py", line 123, in import_module return _bootstrap._gcd_import(name[level:], package, level) File "/export/home/buildbot/32bits/3.x.cea-indiana-x86/build/Lib/importlib/_bootstrap.py", line 834, in _gcd_import loader.load_module(name) File "/export/home/buildbot/32bits/3.x.cea-indiana-x86/build/Lib/importlib/_bootstrap.py", line 460, in load_module return self._load_module(fullname) File "/export/home/buildbot/32bits/3.x.cea-indiana-x86/build/Lib/importlib/_bootstrap.py", line 164, in decorated return fxn(self, module, *args, **kwargs) File "/export/home/buildbot/32bits/3.x.cea-indiana-x86/build/Lib/importlib/_bootstrap.py", line 365, in _load_module exec(code_object, module.__dict__) File "/export/home/buildbot/32bits/3.x.cea-indiana-x86/build/Lib/tkinter/test/test_ttk/test_style.py", line 6, in import tkinter.test.support as support File "/export/home/buildbot/32bits/3.x.cea-indiana-x86/build/Lib/importlib/_bootstrap.py", line 460, in load_module return self._load_module(fullname) File "/export/home/buildbot/32bits/3.x.cea-indiana-x86/build/Lib/importlib/_bootstrap.py", line 164, in decorated return fxn(self, module, *args, **kwargs) File "/export/home/buildbot/32bits/3.x.cea-indiana-x86/build/Lib/importlib/_bootstrap.py", line 353, in _load_module code_object = self.get_code(name) File "/export/home/buildbot/32bits/3.x.cea-indiana-x86/build/Lib/importlib/_bootstrap.py", line 447, in get_code self.set_data(bytecode_path, data) File "/export/home/buildbot/32bits/3.x.cea-indiana-x86/build/Lib/importlib/_bootstrap.py", line 514, in set_data _write_atomic(path, data) File "/export/home/buildbot/32bits/3.x.cea-indiana-x86/build/Lib/importlib/_bootstrap.py", line 94, in _write_atomic _os.rename(path_tmp, path) FileNotFoundError: [Errno 2] No such file or directory ---------- components: Library (Lib) messages: 146691 nosy: brett.cannon, haypo, pitrou priority: normal severity: normal status: open title: Sporadic importlib failures: FileNotFoundError on os.rename() versions: Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Oct 31 19:31:08 2011 From: report at bugs.python.org (Carl Meyer) Date: Mon, 31 Oct 2011 18:31:08 +0000 Subject: [New-bugs-announce] [issue13304] test_site assumes that site.ENABLE_USER_SITE is True Message-ID: <1320085868.02.0.130211137087.issue13304@psf.upfronthosting.co.za> New submission from Carl Meyer : If the test suite is run with PYTHONNOUSERSITE=true, the test_s_option test in test_site fails, because it implicitly assumes that site.ENABLE_USER_SITE is True and that site.USER_SITE should unconditionally be in sys.path. This is a practical problem in the reference implementation for PEP 404, as the tests should pass when run from within a virtual environment, but a system-isolated virtual environment disables user-site (i.e. has the same effect as PYTHONNOUSERSITE). I think the correct fix here is to conditionally skip that test if site.ENABLE_USER_SITE is not True. I also think the module-level conditional check at the top of the file, which, if site.USER_SITE does not exist, creates site.USER_SITE and calls site.addsitedir() on it, should only run if site.ENABLE_USER_SITE is True. ---------- components: Tests messages: 146722 nosy: carljm priority: normal severity: normal status: open title: test_site assumes that site.ENABLE_USER_SITE is True _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Oct 31 21:12:37 2011 From: report at bugs.python.org (Florent Xicluna) Date: Mon, 31 Oct 2011 20:12:37 +0000 Subject: [New-bugs-announce] [issue13305] datetime.strftime("%Y") not consistent for years < 1000 Message-ID: <1320091957.61.0.759691422668.issue13305@psf.upfronthosting.co.za> New submission from Florent Xicluna : See msg146725 on issue 13291. on linux >>> datetime(1, 2, 10, 11, 41, 23).strftime("%Y") '1' on osx >>> datetime(1, 2, 10, 11, 41, 23).strftime("%Y") '0001' >>> datetime.strptime('0001', '%Y') datetime.datetime(1, 1, 1, 0, 0) >>> datetime.strptime('1', '%Y') ValueError: time data '1' does not match format '%Y' ---------- components: Library (Lib) messages: 146740 nosy: flox priority: normal severity: normal stage: test needed status: open title: datetime.strftime("%Y") not consistent for years < 1000 type: behavior versions: Python 2.7, Python 3.2, Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Oct 31 23:07:00 2011 From: report at bugs.python.org (Nick Coghlan) Date: Mon, 31 Oct 2011 22:07:00 +0000 Subject: [New-bugs-announce] [issue13306] Add diagnostic tools to importlib? Message-ID: <1320098820.25.0.925823454462.issue13306@psf.upfronthosting.co.za> New submission from Nick Coghlan : In discussing the module aliasing PEP on python-ideas, it occurred to me that we could potentially add some useful "sanity check" utilities to an "importlib.diagnostics" subpackage. For example: - scan sys.path looking for entries that are inside packages - scan sys.modules looking for entries with duplicate __file__ attributes - scan for shadowed modules (i.e. like find module, but don't stop when we get a hit, and report *all* modules found) Thoughts? ---------- messages: 146746 nosy: brett.cannon, ncoghlan priority: normal severity: normal stage: needs patch status: open title: Add diagnostic tools to importlib? type: feature request _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Oct 31 23:38:37 2011 From: report at bugs.python.org (Stefan Krah) Date: Mon, 31 Oct 2011 22:38:37 +0000 Subject: [New-bugs-announce] [issue13307] test_bdist_rpm: INSTALLED_FILES does not use __pycache__ Message-ID: <1320100717.66.0.765161985418.issue13307@psf.upfronthosting.co.za> New submission from Stefan Krah : The failures seen on the Fedora buildbot are caused by the fact that INSTALLED_FILES does not use __pycache__: [stefan at fedora-14-i386 foo]$ cat build/bdist.linux-i686/rpm/BUILD/foo-0.1/INSTALLED_FILES /usr/local/lib/python3.3/site-packages/foo.py /usr/local/lib/python3.3/site-packages/foo.pyc /usr/local/lib/python3.3/site-packages/foo.pyo /usr/local/lib/python3.3/site-packages/foo-0.1-py3.3.egg-info I'm not familiar with rpm, so I've no clue at which point this file is generated. ---------- components: Tests messages: 146748 nosy: eric.araujo, skrah priority: normal severity: normal status: open title: test_bdist_rpm: INSTALLED_FILES does not use __pycache__ type: behavior versions: Python 3.3 _______________________________________ Python tracker _______________________________________