From report at bugs.python.org Sat Oct 1 02:27:48 2016 From: report at bugs.python.org (John Leitch) Date: Sat, 01 Oct 2016 06:27:48 +0000 Subject: [New-bugs-announce] [issue28322] chain.__setstate__ Type Confusion Message-ID: <1475303268.33.0.0947529181772.issue28322@psf.upfronthosting.co.za> New submission from John Leitch: Python 3.5.2 suffers from a type confusion vulnerability in the chain.__setstate__ method of the itertools module. The issue exists due to lack of argument validation in the chain_setstate() function: static PyObject * chain_setstate(chainobject *lz, PyObject *state) { PyObject *source, *active=NULL; if (! PyArg_ParseTuple(state, "O|O", &source, &active)) return NULL; Py_INCREF(source); Py_XSETREF(lz->source, source); Py_XINCREF(active); Py_XSETREF(lz->active, active); Py_RETURN_NONE; } After parsing the argument tuple, source and active are set without validating that they are iterator objects. This causes issues elsewhere, where the values are passed PyIter_Next: static PyObject * chain_next(chainobject *lz) { PyObject *item; if (lz->source == NULL) return NULL; /* already stopped */ if (lz->active == NULL) { PyObject *iterable = PyIter_Next(lz->source); if (iterable == NULL) { Py_CLEAR(lz->source); return NULL; /* no more input sources */ } lz->active = PyObject_GetIter(iterable); Py_DECREF(iterable); if (lz->active == NULL) { Py_CLEAR(lz->source); return NULL; /* input not iterable */ } } item = PyIter_Next(lz->active); if (item != NULL) return item; if (PyErr_Occurred()) { if (PyErr_ExceptionMatches(PyExc_StopIteration)) PyErr_Clear(); else return NULL; /* input raised an exception */ } Py_CLEAR(lz->active); return chain_next(lz); /* recurse and use next active */ } In some cases, this can lead to a DEP access violation. It might be possible to exploit this to achieve code execution. (4074.198c): Access violation - code c0000005 (first chance) First chance exceptions are reported before any exception handling. This exception may be expected and handled. eax=00000000 ebx=0132fa10 ecx=5b547028 edx=00000002 esi=0132fa10 edi=5b37b3e0 eip=00000000 esp=009ef940 ebp=009ef94c iopl=0 nv up ei pl zr na pe nc cs=0023 ss=002b ds=002b es=002b fs=0053 gs=002b efl=00010246 00000000 ?? ??? 0:000> k6 ChildEBP RetAddr WARNING: Frame IP not in any known module. Following frames may be wrong. 009ef93c 5b329ac0 0x0 009ef94c 5b2cb321 python35!PyIter_Next+0x10 [c:\build\cpython\objects\abstract.c @ 2778] 009ef960 5b37b42e python35!chain_next+0x21 [c:\build\cpython\modules\itertoolsmodule.c @ 1846] 009ef970 5b33fedd python35!wrap_next+0x4e [c:\build\cpython\objects\typeobject.c @ 5470] 009ef990 5b328b9d python35!wrapper_call+0x7d [c:\build\cpython\objects\descrobject.c @ 1195] 009ef9ac 5b3c463c python35!PyObject_Call+0x6d [c:\build\cpython\objects\abstract.c @ 2167] To fix this issue, it is recommended that chain_setstate() be updated to validate its arguments. A proposed patch has been attached. static PyObject * chain_setstate(chainobject *lz, PyObject *state) { PyObject *source, *active=NULL; if (! PyArg_ParseTuple(state, "O|O", &source, &active)) return NULL; if (!PyIter_Check(source) || (active != NULL && !PyIter_Check(active))) { PyErr_SetString(PyExc_ValueError, "Arguments must be iterators."); return NULL; } Py_INCREF(source); Py_XSETREF(lz->source, source); Py_XINCREF(active); Py_XSETREF(lz->active, active); Py_RETURN_NONE; } ---------- components: Library (Lib) files: itertools.patch keywords: patch messages: 277799 nosy: JohnLeitch priority: normal severity: normal status: open title: chain.__setstate__ Type Confusion type: security versions: Python 3.5 Added file: http://bugs.python.org/file44899/itertools.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Oct 1 05:47:07 2016 From: report at bugs.python.org (Chi Hsuan Yen) Date: Sat, 01 Oct 2016 09:47:07 +0000 Subject: [New-bugs-announce] [issue28323] Remove MacOS 9-specific codes from exit() and quit() Message-ID: <1475315227.15.0.994565473323.issue28323@psf.upfronthosting.co.za> New submission from Chi Hsuan Yen: As per PEP 11, MacOS 9 support is removed in Python 2.4. There are some leftovers in CPython code base, among which site.setquit is an example. I propose to remove it for cleaner codes. Added Mac experts as well as Guido, the author of this code in the 18-years-ago changeset 813f527f3bec ---------- components: Library (Lib), Macintosh files: quit-macos9.patch keywords: patch messages: 277802 nosy: Chi Hsuan Yen, gvanrossum, ned.deily, ronaldoussoren priority: normal severity: normal status: open title: Remove MacOS 9-specific codes from exit() and quit() type: enhancement versions: Python 3.6, Python 3.7 Added file: http://bugs.python.org/file44903/quit-macos9.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Oct 1 05:56:14 2016 From: report at bugs.python.org (Chi Hsuan Yen) Date: Sat, 01 Oct 2016 09:56:14 +0000 Subject: [New-bugs-announce] [issue28324] Clean up MacOS 9-specific description in the docstring of os.py Message-ID: <1475315774.15.0.00184796665768.issue28324@psf.upfronthosting.co.za> New submission from Chi Hsuan Yen: As per PEP 11, MacOS 9 support is removed in Python 2.4. There are some leftovers in CPython code base, among which comments about os.py are examples. I propose to clean them up for cleaner codes. Added Mac experts as well as Guido, the author of these comments in some 24-year-ago changesets 3169d38f6774, d945cf33a64f and 259923e4d7b1. ---------- components: Library (Lib), Macintosh files: os-macos9.patch keywords: patch messages: 277803 nosy: Chi Hsuan Yen, gvanrossum, ned.deily, ronaldoussoren priority: normal severity: normal status: open title: Clean up MacOS 9-specific description in the docstring of os.py type: enhancement versions: Python 3.6, Python 3.7 Added file: http://bugs.python.org/file44904/os-macos9.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Oct 1 06:15:54 2016 From: report at bugs.python.org (Chi Hsuan Yen) Date: Sat, 01 Oct 2016 10:15:54 +0000 Subject: [New-bugs-announce] [issue28325] Remove MacOS 9-specific module macurl2path.py Message-ID: <1475316954.78.0.654297187037.issue28325@psf.upfronthosting.co.za> New submission from Chi Hsuan Yen: As per PEP 11, MacOS 9 support is removed in Python 2.4. There are some leftovers in CPython code base, among which the macurl2path module is an example. I propose to remove it for cleaner codes. In f6785bce54b5 (issue7908), reference to macurl2path was removed from Lib/urllib.py, and macurl2path.py says: Do not import directly; use urllib instead. So, unlike the concern in issue9850, I bet there are no third party codes importing this module. It can be removed from CPython safely. Added some Mac experts. ---------- components: Library (Lib), Macintosh messages: 277805 nosy: Chi Hsuan Yen, ned.deily, ronaldoussoren priority: normal severity: normal status: open title: Remove MacOS 9-specific module macurl2path.py type: enhancement versions: Python 3.6, Python 3.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Oct 1 07:45:34 2016 From: report at bugs.python.org (ProgVal) Date: Sat, 01 Oct 2016 11:45:34 +0000 Subject: [New-bugs-announce] [issue28326] multiprocessing.Process depends on sys.stdout being open Message-ID: <1475322334.82.0.360171618996.issue28326@psf.upfronthosting.co.za> New submission from ProgVal: Hello, The following code: import sys import multiprocessing sys.stdout.close() def foo(): pass p = multiprocessing.Process(target=foo) p.start() Crashes with: Traceback (most recent call last): File "foo.py", line 10, in p.start() File "/usr/lib/python3.5/multiprocessing/process.py", line 105, in start self._popen = self._Popen(self) File "/usr/lib/python3.5/multiprocessing/context.py", line 212, in _Popen return _default_context.get_context().Process._Popen(process_obj) File "/usr/lib/python3.5/multiprocessing/context.py", line 267, in _Popen return Popen(process_obj) File "/usr/lib/python3.5/multiprocessing/popen_fork.py", line 17, in __init__ sys.stdout.flush() ValueError: I/O operation on closed file. This bug has been reported to me on a daemonized program (written prior to PEP 3143). ---------- components: Library (Lib) messages: 277807 nosy: Valentin.Lorentz priority: normal severity: normal status: open title: multiprocessing.Process depends on sys.stdout being open versions: Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Oct 1 08:18:35 2016 From: report at bugs.python.org (Mark Dickinson) Date: Sat, 01 Oct 2016 12:18:35 +0000 Subject: [New-bugs-announce] [issue28327] statistics.geometric_mean gives incorrect results for mixed int/float inputs Message-ID: <1475324315.92.0.282609876939.issue28327@psf.upfronthosting.co.za> New submission from Mark Dickinson: The following calculations should all be giving the same result: >>> import statistics >>> statistics.geometric_mean([2, 3, 5, 7]) 3.80675409583932 >>> statistics.geometric_mean([2, 3, 5, 7.0]) 1.6265765616977859 >>> statistics.geometric_mean([2, 3, 5.0, 7.0]) 2.4322992790977875 >>> statistics.geometric_mean([2, 3.0, 5.0, 7.0]) 3.201085872943679 >>> statistics.geometric_mean([2.0, 3.0, 5.0, 7.0]) 3.80675409583932 (Correct result is 3.80675409583932.) The culprit is this line in statistics._product: mant, scale = 1, 0 #math.frexp(prod) # FIXME ... and indeed, we should be starting from `prod` rather than 1 here. But simply using math.frexp has potential for failure if the accumulated integer product overflows a float. ---------- assignee: steven.daprano messages: 277808 nosy: mark.dickinson, steven.daprano priority: normal severity: normal status: open title: statistics.geometric_mean gives incorrect results for mixed int/float inputs type: behavior versions: Python 3.6, Python 3.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Oct 1 08:33:54 2016 From: report at bugs.python.org (Mark Dickinson) Date: Sat, 01 Oct 2016 12:33:54 +0000 Subject: [New-bugs-announce] [issue28328] statistics.geometric_mean has no tests. Defer to 3.7? Message-ID: <1475325234.65.0.257375698668.issue28328@psf.upfronthosting.co.za> New submission from Mark Dickinson: The newly-added statistics.geometric_mean function appears to have no tests at all, with the exception of a single doctest: >>> geometric_mean([1.10, 0.95, 1.12]) 1.0538483123382172 Steve, Ned: what do you think about taking geometric_mean out of Python 3.6, leaving us time to get it into shape for 3.7? The implementation of geometric_mean is complicated, with many edge cases. The original code was committed without review in #27181, and it currently suffers from some serious bugs: see #27761, #28111, #28327 (the first of these affects only the tests for nroot; the second and third are behaviour bugs in geometric_mean). With the lack of tests, and Python 3.6 b2 looming, I think the best thing to do might be to defer the inclusion of geometric_mean to Python 3.7. I'll mark this as a release blocker until we decide what to do. ---------- assignee: steven.daprano messages: 277811 nosy: mark.dickinson, ned.deily, steven.daprano priority: release blocker severity: normal stage: test needed status: open title: statistics.geometric_mean has no tests. Defer to 3.7? type: behavior versions: Python 3.6, Python 3.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Oct 1 09:05:23 2016 From: report at bugs.python.org (Satoru Logic) Date: Sat, 01 Oct 2016 13:05:23 +0000 Subject: [New-bugs-announce] [issue28329] Add support for customizing scheduler's timefunc and delayfunc using subclassing Message-ID: <1475327123.48.0.0947614494483.issue28329@psf.upfronthosting.co.za> Changes by Satoru Logic : ---------- components: Library (Lib) files: overridable_time_delay.patch keywords: patch nosy: Satoru Logic priority: normal severity: normal status: open title: Add support for customizing scheduler's timefunc and delayfunc using subclassing type: enhancement versions: Python 3.7 Added file: http://bugs.python.org/file44907/overridable_time_delay.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Oct 1 09:26:42 2016 From: report at bugs.python.org (Satoru Logic) Date: Sat, 01 Oct 2016 13:26:42 +0000 Subject: [New-bugs-announce] [issue28330] Use simpler and faster sched.Event definition Message-ID: <1475328402.1.0.435562335061.issue28330@psf.upfronthosting.co.za> New submission from Satoru Logic: By removing the rich comparison dunder methods, the sorting of events will use the faster default implementation. ---------- components: Library (Lib) files: simple_def.patch keywords: patch messages: 277816 nosy: Satoru Logic priority: normal severity: normal status: open title: Use simpler and faster sched.Event definition versions: Python 3.7 Added file: http://bugs.python.org/file44909/simple_def.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Oct 1 09:29:12 2016 From: report at bugs.python.org (INADA Naoki) Date: Sat, 01 Oct 2016 13:29:12 +0000 Subject: [New-bugs-announce] [issue28331] "CPython implementation detail:" is removed when contents is translated Message-ID: <1475328552.4.0.631332821236.issue28331@psf.upfronthosting.co.za> New submission from INADA Naoki: "CPython implementation detail:" label is removed when contents of impl-detail directive is translated. This is very bad for people reading translated documents. Attached patch fixes this, with enabling translating the label, like versionchanged directive. ---------- assignee: docs at python components: Documentation files: impl-detail.patch keywords: patch messages: 277817 nosy: docs at python, inada.naoki priority: normal severity: normal stage: patch review status: open title: "CPython implementation detail:" is removed when contents is translated type: enhancement versions: Python 2.7, Python 3.5, Python 3.6, Python 3.7 Added file: http://bugs.python.org/file44910/impl-detail.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Oct 1 11:06:10 2016 From: report at bugs.python.org (Oren Milman) Date: Sat, 01 Oct 2016 15:06:10 +0000 Subject: [New-bugs-announce] [issue28332] silent truncations in socket.htons and socket.ntohs Message-ID: <1475334370.1.0.257280912764.issue28332@psf.upfronthosting.co.za> New submission from Oren Milman: ------------ current state ------------ Due to the implementation of socket_htons (in Modules/socketmodule.c), in case the received integer does not fit in 16-bit unsigned integer, but does fit in a positive C int, it is silently truncated to 16-bit unsigned integer (before converting to network byte order): >>> import socket >>> hex(socket.htons(0x1234)) '0x3412' >>> hex(socket.htons(0x81234)) '0x3412' >>> hex(socket.htons(0x881234)) '0x3412' >>> hex(socket.htons(0x8881234)) '0x3412' >>> hex(socket.htons(0x88881234)) Traceback (most recent call last): File "", line 1, in OverflowError: Python int too large to convert to C long >>> Likewise, socket.ntohs has the same silent truncation feature, due to the implementation of socket_ntohs. ISTM this silent truncation feature has the potential to conceal nasty bugs, and I guess it is rarely used in purpose. With regard to relevant changes made in the past: * The silent truncation was there since the two functions were first added, in changeset 3673 (https://hg.python.org/cpython/rev/f6ace61c3dfe). * A check whether the received integer is negative was added (to each of the two functions) in changeset 40632 (https://hg.python.org/cpython/rev/6efe3a4b10ac), as part of #1635058. Note the lack of discussion in #1635058 and #1619659 about backward compatibility. It might suggest that Guido didn't hesitate to make the change, even though at the time, the four conversion functions (socket.htons, socket.ntohs, socket.htonl and socket.ntohl) were already in the wild for 10 years. ------------ proposed changes ------------ 1. In Modules/socketmodule.c, raise a DeprecationWarning before silently truncating the received integer. In Python 3.8, replace the DeprecationWarning with an OverflowError. 2. In Lib/test/test_socket.py, add tests to verify a DeprecationWarning is raised as expected. 3. In Doc/library/socket.rst, add a description of the silent truncation feature, and declare it is deprecated. ------------ diff ------------ The proposed patches diff file is attached. (I wasn't sure you would approve deprecating a feature that was in the wild for so long, but I implemented it anyway, as it was quite simple.) ------------ tests ------------ I ran 'python_d.exe -m test -j3' (on my 64-bit Windows 10) with and without the patches, and got quite the same output. (That also means my new tests in test_socket passed.) The outputs of both runs are attached. ---------- components: Library (Lib) files: CPythonTestOutput.txt messages: 277820 nosy: Oren Milman priority: normal severity: normal status: open title: silent truncations in socket.htons and socket.ntohs type: behavior versions: Python 3.7 Added file: http://bugs.python.org/file44911/CPythonTestOutput.txt _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Oct 1 11:20:25 2016 From: report at bugs.python.org (=?utf-8?q?Adam_Barto=C5=A1?=) Date: Sat, 01 Oct 2016 15:20:25 +0000 Subject: [New-bugs-announce] [issue28333] input() with Unicode prompt produces mojibake on Windows Message-ID: <1475335225.65.0.631429009191.issue28333@psf.upfronthosting.co.za> New submission from Adam Barto?: In my setting (Python 3.6b1 on Windows), trying to prompt a non-ASCII character via input() results in mojibake. This is related to the recent fix of #1602 and so is Windows-specific. >>> input("?") ?? The result corresponds to print("?".encode("utf-8").decode("cp852")). That cp852 the default terminal encoding in my locale. ---------- components: Unicode, Windows messages: 277821 nosy: Drekin, ezio.melotti, haypo, paul.moore, steve.dower, tim.golden, zach.ware priority: normal severity: normal status: open title: input() with Unicode prompt produces mojibake on Windows type: behavior versions: Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Oct 1 11:35:54 2016 From: report at bugs.python.org (Dimitri Merejkowsky) Date: Sat, 01 Oct 2016 15:35:54 +0000 Subject: [New-bugs-announce] [issue28334] netrc does not work if $HOME is not set Message-ID: <1475336154.44.0.44449733804.issue28334@psf.upfronthosting.co.za> New submission from Dimitri Merejkowsky: If $HOME is not set, netrc will raise an exception. Attached patch fixes the problem by using `os.path.expanduser` instead ---------- components: Library (Lib) files: netrc-use-expanduser.patch keywords: patch messages: 277824 nosy: Dimitri Merejkowsky priority: normal severity: normal status: open title: netrc does not work if $HOME is not set type: behavior versions: Python 2.7, Python 3.3, Python 3.4, Python 3.5, Python 3.6, Python 3.7 Added file: http://bugs.python.org/file44914/netrc-use-expanduser.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Oct 1 14:20:17 2016 From: report at bugs.python.org (Ram Rachum) Date: Sat, 01 Oct 2016 18:20:17 +0000 Subject: [New-bugs-announce] [issue28335] Exception reporting in `logging.config` Message-ID: <1475346017.58.0.463787476643.issue28335@psf.upfronthosting.co.za> New submission from Ram Rachum: In `logging.config.DictConfigurator.configure`, there are exceptions that are caught and then replaced with `ValueError` exceptions. I think you should use the `raise x from y` syntax so that the original tracebacks will be preserved. (I'm debugging such an exception now and it's quite frustrating that I'm not seeing the full traceback of the original exception.) ---------- components: Library (Lib) messages: 277826 nosy: cool-RR, vinay.sajip priority: normal severity: normal status: open title: Exception reporting in `logging.config` type: enhancement versions: Python 3.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Oct 1 14:57:29 2016 From: report at bugs.python.org (Juan Carlos Pujol Mainegra) Date: Sat, 01 Oct 2016 18:57:29 +0000 Subject: [New-bugs-announce] [issue28336] Slicing (operation) is not symmetrical with respect to suffixes and prefixes Message-ID: <1475348249.16.0.807469092149.issue28336@psf.upfronthosting.co.za> New submission from Juan Carlos Pujol Mainegra: Let s be a string or other array-like object, a, b > 0 integers, s[0:b] returns a b-long prefix to s, the same as s[:b], but s[-a:0] returns empty (for len(s) > 0 and a > 1), while it should return the same as s[-a:], an a-long suffix (a > 0). A syntax asymmetry like this shall not be imposed to those using non-literal slicing indexes, as it would be necessarily to introduce a control condition to test whether the upper bound index is a non-negative quantity, assuming the lower bound index is negative. Furthermore, it breaks the whole negative slicing idea, being that (I consider) index i always be treated as i mod len(s), so that constructions like s[-a:b] (for a, b > 0 or a, b < 0) could return s[-a:] + s[:b]. ---------- components: Interpreter Core messages: 277829 nosy: jksware priority: normal severity: normal status: open title: Slicing (operation) is not symmetrical with respect to suffixes and prefixes type: enhancement versions: Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Oct 2 05:17:09 2016 From: report at bugs.python.org (Masayuki Yamamoto) Date: Sun, 02 Oct 2016 09:17:09 +0000 Subject: [New-bugs-announce] [issue28337] Segfault in _struct.unpack_iterator Message-ID: <1475399829.48.0.464642269918.issue28337@psf.upfronthosting.co.za> New submission from Masayuki Yamamoto: After #21224 was applied into default branch, the _struct.unpack_iterator has crashed by segfault. reproduce segfault: $ uname -a Linux masayuki-P35-DS3 4.4.0-38-generic #57-Ubuntu SMP Tue Sep 6 15:41:41 UTC 2016 i686 i686 i686 GNU/Linux $ hg update -C -r "branch(default)" $ ./configure --prefix=/opt/py35 --without-threads --with-system-ffi --with-system-expat $ make (build succeed) $ ./python Python 3.7.0a0 (default:6f299f7d6643, Oct 2 2016, 17:50:08) [GCC 5.4.0 20160609] on linux Type "help", "copyright", "credits" or "license" for more information. >>> import struct >>> it = struct.iter_unpack('b', b'123') >>> type(it) (segfault happens) ---------- components: Extension Modules messages: 277867 nosy: mark.dickinson, masamoto, meador.inge, zach.ware priority: normal severity: normal status: open title: Segfault in _struct.unpack_iterator type: crash versions: Python 3.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Oct 2 05:20:17 2016 From: report at bugs.python.org (Xavier de Gaye) Date: Sun, 02 Oct 2016 09:20:17 +0000 Subject: [New-bugs-announce] [issue28338] test_pdb doctests have been removed from its test suite Message-ID: <1475400017.05.0.963185548302.issue28338@psf.upfronthosting.co.za> New submission from Xavier de Gaye: Changeset ee0bbfd972de in issue 18401 has removed the doctests from the pdb test suite as can be seen by running test_pdb in verbose mode. See also msg277864 that triggered the creation of this issue. Nosying members of the issue 18401 nosy list. ---------- assignee: xdegaye components: Tests messages: 277868 nosy: lukasz.langa, ncoghlan, numerodix, python-dev, r.david.murray, ronaldoussoren, sam.kimbrel, sptonkin, terry.reedy, xdegaye priority: normal severity: normal status: open title: test_pdb doctests have been removed from its test suite type: behavior versions: Python 3.6, Python 3.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Oct 2 11:21:33 2016 From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis) Date: Sun, 02 Oct 2016 15:21:33 +0000 Subject: [New-bugs-announce] [issue28339] "TypeError: Parameterized generics cannot be used with class or instance checks" in test_functools after importing typing module Message-ID: <1475421693.5.0.638809019729.issue28339@psf.upfronthosting.co.za> New submission from Arfrever Frehtes Taifersar Arahesis: Commits 09cc43df4509 (3.5), 81f27d3ab214 (3.6), 8f0df4db2b06 (3.7) cause "TypeError: Parameterized generics cannot be used with class or instance checks" errors in 4 tests in Lib/test/test_functools.py file in situation when typing module is already imported. Examples of steps to reproduce: $ LD_LIBRARY_PATH="$(pwd)" ./python -m test -v test_typing test_functools $ LD_LIBRARY_PATH="$(pwd)" ./python -m test -v test___all__ test_functools $ LD_LIBRARY_PATH="$(pwd)" ./python -c 'import runpy, typing; runpy.run_module("test")' -v test_functools Errors in test_functools: ====================================================================== ERROR: test_cache_invalidation (test.test_functools.TestSingleDispatch) ---------------------------------------------------------------------- Traceback (most recent call last): File "/tmp/cpython/Lib/functools.py", line 776, in dispatch impl = dispatch_cache[cls] File "/tmp/cpython/Lib/test/test_functools.py", line 1896, in __getitem__ result = self.data[key] KeyError: During handling of the above exception, another exception occurred: Traceback (most recent call last): File "/tmp/cpython/Lib/functools.py", line 779, in dispatch impl = registry[cls] KeyError: During handling of the above exception, another exception occurred: Traceback (most recent call last): File "/tmp/cpython/Lib/test/test_functools.py", line 1955, in test_cache_invalidation self.assertEqual(g(d), "sized") File "/tmp/cpython/Lib/functools.py", line 801, in wrapper return dispatch(args[0].__class__)(*args, **kw) File "/tmp/cpython/Lib/functools.py", line 781, in dispatch impl = _find_impl(cls, registry) File "/tmp/cpython/Lib/functools.py", line 732, in _find_impl mro = _compose_mro(cls, registry.keys()) File "/tmp/cpython/Lib/functools.py", line 709, in _compose_mro if sub not in bases and issubclass(cls, sub): File "/tmp/cpython/Lib/typing.py", line 1043, in __subclasscheck__ raise TypeError("Parameterized generics cannot be used with class " TypeError: Parameterized generics cannot be used with class or instance checks ====================================================================== ERROR: test_compose_mro (test.test_functools.TestSingleDispatch) ---------------------------------------------------------------------- Traceback (most recent call last): File "/tmp/cpython/Lib/test/test_functools.py", line 1594, in test_compose_mro m = mro(c.defaultdict, [c.Sized, c.Container, str]) File "/tmp/cpython/Lib/functools.py", line 709, in _compose_mro if sub not in bases and issubclass(cls, sub): File "/tmp/cpython/Lib/typing.py", line 1043, in __subclasscheck__ raise TypeError("Parameterized generics cannot be used with class " TypeError: Parameterized generics cannot be used with class or instance checks ====================================================================== ERROR: test_mro_conflicts (test.test_functools.TestSingleDispatch) ---------------------------------------------------------------------- Traceback (most recent call last): File "/tmp/cpython/Lib/functools.py", line 776, in dispatch impl = dispatch_cache[cls] File "/tmp/cpython/Lib/test/test_functools.py", line 1896, in __getitem__ result = self.data[key] KeyError: During handling of the above exception, another exception occurred: Traceback (most recent call last): File "/tmp/cpython/Lib/functools.py", line 779, in dispatch impl = registry[cls] KeyError: During handling of the above exception, another exception occurred: Traceback (most recent call last): File "/tmp/cpython/Lib/test/test_functools.py", line 1822, in test_mro_conflicts h(c.defaultdict(lambda: 0)) File "/tmp/cpython/Lib/functools.py", line 801, in wrapper return dispatch(args[0].__class__)(*args, **kw) File "/tmp/cpython/Lib/functools.py", line 781, in dispatch impl = _find_impl(cls, registry) File "/tmp/cpython/Lib/functools.py", line 732, in _find_impl mro = _compose_mro(cls, registry.keys()) File "/tmp/cpython/Lib/functools.py", line 709, in _compose_mro if sub not in bases and issubclass(cls, sub): File "/tmp/cpython/Lib/typing.py", line 1043, in __subclasscheck__ raise TypeError("Parameterized generics cannot be used with class " TypeError: Parameterized generics cannot be used with class or instance checks ====================================================================== ERROR: test_register_abc (test.test_functools.TestSingleDispatch) ---------------------------------------------------------------------- Traceback (most recent call last): File "/tmp/cpython/Lib/functools.py", line 776, in dispatch impl = dispatch_cache[cls] File "/tmp/cpython/Lib/test/test_functools.py", line 1896, in __getitem__ result = self.data[key] KeyError: During handling of the above exception, another exception occurred: Traceback (most recent call last): File "/tmp/cpython/Lib/functools.py", line 779, in dispatch impl = registry[cls] KeyError: During handling of the above exception, another exception occurred: Traceback (most recent call last): File "/tmp/cpython/Lib/test/test_functools.py", line 1641, in test_register_abc self.assertEqual(g(d), "sized") File "/tmp/cpython/Lib/functools.py", line 801, in wrapper return dispatch(args[0].__class__)(*args, **kw) File "/tmp/cpython/Lib/functools.py", line 781, in dispatch impl = _find_impl(cls, registry) File "/tmp/cpython/Lib/functools.py", line 732, in _find_impl mro = _compose_mro(cls, registry.keys()) File "/tmp/cpython/Lib/functools.py", line 709, in _compose_mro if sub not in bases and issubclass(cls, sub): File "/tmp/cpython/Lib/typing.py", line 1043, in __subclasscheck__ raise TypeError("Parameterized generics cannot be used with class " TypeError: Parameterized generics cannot be used with class or instance checks ---------------------------------------------------------------------- Ran 186 tests in 0.431s FAILED (errors=4) ---------- components: Library (Lib), Tests messages: 277896 nosy: Arfrever, gvanrossum, ncoghlan, rhettinger priority: normal severity: normal status: open title: "TypeError: Parameterized generics cannot be used with class or instance checks" in test_functools after importing typing module versions: Python 3.5, Python 3.6, Python 3.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Oct 2 11:51:27 2016 From: report at bugs.python.org (Rob Malouf) Date: Sun, 02 Oct 2016 15:51:27 +0000 Subject: [New-bugs-announce] [issue28340] TextIOWrapper.tell extremely slow Message-ID: <1475423487.6.0.338998508065.issue28340@psf.upfronthosting.co.za> New submission from Rob Malouf: io.TextIOWrapper.tell() is unusably slow in Python 2.7. This same problem was introduced in Python 3 and fixed in Python 3.3 (see Issue # 11114). Any chance of getting the fix backported into the Python 2.7 library? It would make it much easier to modernize Unicode handling in libraries that have to support both 2 and 3 using the same codebase. ---------- components: IO messages: 277898 nosy: rmalouf priority: normal severity: normal status: open title: TextIOWrapper.tell extremely slow type: performance versions: Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Oct 2 18:59:33 2016 From: report at bugs.python.org (Skip Montanaro) Date: Sun, 02 Oct 2016 22:59:33 +0000 Subject: [New-bugs-announce] [issue28341] cpython tip fails to build on Mac OS X Message-ID: <1475449173.08.0.90782279022.issue28341@psf.upfronthosting.co.za> New submission from Skip Montanaro: Just trying an infrequent update of tip (last time seems to have been early July), I get a link error on my Mac: % make ./Programs/_freeze_importlib \ ./Lib/importlib/_bootstrap.py Python/importlib.h dyld: lazy symbol binding failed: Symbol not found: _getentropy Referenced from: /Users/skip/src/hgpython/cpython/./Programs/_freeze_importlib Expected in: /usr/lib/libSystem.B.dylib dyld: Symbol not found: _getentropy Referenced from: /Users/skip/src/hgpython/cpython/./Programs/_freeze_importlib Expected in: /usr/lib/libSystem.B.dylib make: *** [Python/importlib.h] Trace/BPT trap: 5 I'm running Mac OS X 10.11.6, and upgraded to XCode 8.0 a few days ago. Searching for the error, I saw some suggestions elsewhere on the web that this might be a known problem, though I saw nothing here (just searched for _getentropy). ---------- components: Build messages: 277914 nosy: skip.montanaro priority: normal severity: normal status: open title: cpython tip fails to build on Mac OS X type: compile error versions: Python 3.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Oct 2 19:48:54 2016 From: report at bugs.python.org (Alexander Mohr) Date: Sun, 02 Oct 2016 23:48:54 +0000 Subject: [New-bugs-announce] [issue28342] OSX 10.12 crash in urllib.request getproxies_macosx_sysconf and proxy_bypass_macosx_sysconf Message-ID: <1475452134.75.0.942961822081.issue28342@psf.upfronthosting.co.za> New submission from Alexander Mohr: I have a unittest which spawns several processes repeatedly. One of these subprocesses uses botocore, which itself uses the above two methods through the calls proxy_bypass and getproxies. It seems after re-spawning the methods a few times the titled calls eventually repeatedly cause python to crash on 10.12. I have a core file if that would help, zip'd it's ~242MB. I've attached a file that shows the lldb callstack and python callstack. ---------- components: Library (Lib) files: python_urllib_crash.txt messages: 277917 nosy: thehesiod priority: normal severity: normal status: open title: OSX 10.12 crash in urllib.request getproxies_macosx_sysconf and proxy_bypass_macosx_sysconf versions: Python 3.5 Added file: http://bugs.python.org/file44940/python_urllib_crash.txt _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Oct 2 23:11:31 2016 From: report at bugs.python.org (Mingye Wang (Arthur2e5)) Date: Mon, 03 Oct 2016 03:11:31 +0000 Subject: [New-bugs-announce] [issue28343] Bad encoding alias cp936 -> gbk: euro sign Message-ID: <1475464291.36.0.0934021228231.issue28343@psf.upfronthosting.co.za> New submission from Mingye Wang (Arthur2e5): Microsoft's cp936 defines a euro sign at 0x80, but Python would kick the bucket when asked to do something like `u'\u20ac'.encode('cp936')`. This may break things for zh-hans-cn windows users who wants to put a euro sign in their file name (if they insist on using a non-unicode str for open() in py2, well.) By looking at the codecs documentation, 'cp936' appears to be an alias for the GBK encoder, which by itself has been a very ambiguous name and subject to confusion -- The name "GBK" might refer to any of the four commonly-known members of the family of EUC-CN (gb2312) extensions that has full coverage of Unicode 1.1 CJK Unified Ideographs block: 1) The original GBK. Rust-Encoding says that it's in a normative annex of GB13000.1-1993, but the closest thing I can find in my archive.org copy of that standard is an annex on an EUC (GB/T 2311) UCS. 2) IANA GBK, or Microsoft cp936. This is the one with the euro sign I am looking for. 3) GBK 1.0, a recommendation from the official standardization committees based on cp936. It's roughly cp936 without the euro sign but with some additional 95 PUA code points. 4) W3C TR GBK. This GBK is basically gb18030-2005 without four-byte UTF, and with the euro sign. Roughly a union of 2) and 3) with some PUA code points moved into the right place. Looking at Modules/cjkcodecs/_codecs_cn.c @ 104259:36b052adf5a7, Python seems to be doing either 1) or 3). For a quick fix you can just make an additional cp936 encoding around the gbk encoding that handles U+20AC; for some excitement (of potentially breaking stuff) you can join the web people and use either 2) or 4). ---------- components: Unicode messages: 277925 nosy: Mingye Wang (Arthur2e5), ezio.melotti, haypo priority: normal severity: normal status: open title: Bad encoding alias cp936 -> gbk: euro sign type: behavior versions: Python 2.7, Python 3.3, Python 3.4, Python 3.5, Python 3.6, Python 3.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Oct 3 02:14:44 2016 From: report at bugs.python.org (spooja) Date: Mon, 03 Oct 2016 06:14:44 +0000 Subject: [New-bugs-announce] [issue28344] Python 3.5.2 hangs when running in session 0 Message-ID: <1475475284.89.0.546394834548.issue28344@psf.upfronthosting.co.za> New submission from spooja: Started the python 3.5.2 exe in session 0 using the task scheduler, 2 instances of python are running in task manager and the process gets hanged, killing the process did not create any logs in %temp% folder. ---------- messages: 277930 nosy: spooja priority: normal severity: normal status: open title: Python 3.5.2 hangs when running in session 0 type: behavior versions: Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Oct 3 02:20:30 2016 From: report at bugs.python.org (Jonas Wegelius) Date: Mon, 03 Oct 2016 06:20:30 +0000 Subject: [New-bugs-announce] [issue28345] 8/3 is calculated incorrectly Message-ID: <1475475630.46.0.74903307256.issue28345@psf.upfronthosting.co.za> New submission from Jonas Wegelius: When you type 8/3, the interpreter return incorrect value: 2.6666666666666665 it should be 2.6666666666666667 ---------- components: Interpreter Core messages: 277931 nosy: Jonas Wegelius priority: normal severity: normal status: open title: 8/3 is calculated incorrectly type: behavior versions: Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Oct 3 04:37:07 2016 From: report at bugs.python.org (lurker10) Date: Mon, 03 Oct 2016 08:37:07 +0000 Subject: [New-bugs-announce] [issue28346] 3.6 source doesn't build on centos 6 Message-ID: <1475483827.37.0.674411154506.issue28346@psf.upfronthosting.co.za> New submission from lurker10: Centos 6.7 Python 2.6.6 (default in Centos 6, no other python installed) GCC 4.4.7 # ./configure ... (no errors) # make python ./Tools/scripts/generate_opcode_h.py ./Lib/opcode.py ./Include/opcode.h /bin/mkdir -p Include python ./Parser/asdl_c.py -h Include ./Parser/Python.asdl Traceback (most recent call last): File "./Parser/asdl_c.py", line 6, in import asdl File "/root/cpython/Parser/asdl.py", line 36 builtin_types = {'identifier', 'string', 'bytes', 'int', 'object', 'singleton', ^ SyntaxError: invalid syntax make: *** [Include/Python-ast.h] Error 1 ---------- components: Build messages: 277937 nosy: lurker10 priority: normal severity: normal status: open title: 3.6 source doesn't build on centos 6 type: compile error _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Oct 3 11:59:10 2016 From: report at bugs.python.org (Poren Chiang) Date: Mon, 03 Oct 2016 15:59:10 +0000 Subject: [New-bugs-announce] [issue28348] Doc typo in asyncio.Task Message-ID: <1475510350.17.0.416323283403.issue28348@psf.upfronthosting.co.za> New submission from Poren Chiang: Version: Latest (v3.5.2) Affected module: asyncio (section 18.5) Problem: Under section 18.5.3.5. "Task", The word "completion" is misspelled "completition". > A task is responsible for executing a coroutine object in an event loop. If the wrapped coroutine yields from a future, the task suspends the execution of the wrapped coroutine and waits for the **completition** of the future. When the future is done, the execution of the wrapped coroutine restarts with the result or the exception of the future. Possible fixes: Replace "completition" with "completion". Reference: [1] https://docs.python.org/3/library/asyncio-task.html#task ---------- assignee: docs at python components: Documentation messages: 277962 nosy: RSChiang, docs at python priority: normal severity: normal status: open title: Doc typo in asyncio.Task versions: Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Oct 3 14:07:59 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Mon, 03 Oct 2016 18:07:59 +0000 Subject: [New-bugs-announce] [issue28349] Issues with PyMemberDef flags Message-ID: <1475518079.81.0.844864411163.issue28349@psf.upfronthosting.co.za> New submission from Serhiy Storchaka: As documented in Doc/extending/newtypes.rst, the flags field of PyMemberDef must be bitwise-or-ed combination of flag constants READONLY, READ_RESTRICTED, WRITE_RESTRICTED and RESTRICTED. There are problems with this: 1. Actually WRITE_RESTRICTED was renamed to PY_WRITE_RESTRICTED in 2.6 (a8dd8874ff2d). I didn't find mention of this backward incompatible change in Misc/NEWS and whatsnew files. 2. Since the support of restricted mode was removed in 3.x, only READONLY flag has effect. Other flags are still documented and used in CPython sources. I think we should get rid of using these flags and undocument them or document as outdated. 3. As noted by Skip Montanaro on the Python-Dev mailing list, these flags (as well as T_* type tags in Include/structmember.h) should have the PY_ prefix. ---------- assignee: docs at python components: Documentation messages: 277972 nosy: christian.heimes, docs at python, serhiy.storchaka, skip.montanaro priority: normal severity: normal status: open title: Issues with PyMemberDef flags versions: Python 2.7, Python 3.5, Python 3.6, Python 3.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Oct 3 15:23:36 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Mon, 03 Oct 2016 19:23:36 +0000 Subject: [New-bugs-announce] [issue28350] Interning string constants with null character Message-ID: <1475522616.74.0.369918481264.issue28350@psf.upfronthosting.co.za> New submission from Serhiy Storchaka: Currently string constants are interned if they consist of ASCII word characters ([0-9A-Za-z_]). But strings are tested only to the first null character. This is not problem for names, since they can't include null characters, but string constants that contains ASCII non-word characters after the null character passes this test. Proposed simple patch fixes the testing function all_name_chars(). Other question: shouldn't PyUnicode_IsIdentifier() be used in 3.x? ---------- components: Interpreter Core files: all_name_chars.patch keywords: patch messages: 277994 nosy: benjamin.peterson, brett.cannon, georg.brandl, ncoghlan, rhettinger, serhiy.storchaka, yselivanov priority: normal severity: normal stage: patch review status: open title: Interning string constants with null character type: behavior versions: Python 2.7, Python 3.5, Python 3.6, Python 3.7 Added file: http://bugs.python.org/file44945/all_name_chars.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Oct 3 15:33:07 2016 From: report at bugs.python.org (Mark Dickinson) Date: Mon, 03 Oct 2016 19:33:07 +0000 Subject: [New-bugs-announce] [issue28351] statistics.geometric_mean enters infinite loop for Decimal inputs Message-ID: <1475523187.92.0.24883134157.issue28351@psf.upfronthosting.co.za> New submission from Mark Dickinson: On my machine, the following code enters an infinite loop: Python 3.7.0a0 (default:14c52bb996be, Oct 3 2016, 20:20:58) [GCC 4.2.1 Compatible Apple LLVM 7.0.2 (clang-700.1.81)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> from statistics import geometric_mean >>> from decimal import Decimal >>> x = [0.5636536271446626, 0.7185039116960741, 0.5265438727361142] >>> geometric_mean(map(Decimal, x)) The nth_root implementation for Decimals does a repeated Newton iteration until convergence, with convergence being defined as the current iteration value being exactly equal to the last one. It's very easy for the iteration to end up alternating between two (or more) nearby values, and that's what happens above. This isn't a rare corner case: if you generate triples of random floats, convert to Decimal and apply geometric mean, you'll hit something like the above within just a few trials. I don't think there's any need for an iteration here: I'd suggest simply computing the nth root directly after increasing the Decimal context precision by a suitable amount. If we do use Newton iteration, it should likely restrict itself to doing a single polishing step, as in the issue #28111 fix and #27181 discussion. ---------- messages: 277995 nosy: mark.dickinson priority: normal severity: normal status: open title: statistics.geometric_mean enters infinite loop for Decimal inputs type: behavior versions: Python 3.6, Python 3.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Oct 3 22:03:51 2016 From: report at bugs.python.org (Tyler Sweeden) Date: Tue, 04 Oct 2016 02:03:51 +0000 Subject: [New-bugs-announce] [issue28352] winfo_pathname(..) | window id "xyz" doesn't exist in this application. | Python 3.4.4 Message-ID: <1475546631.28.0.75775044978.issue28352@psf.upfronthosting.co.za> New submission from Tyler Sweeden: This issue presents itself in 3.4.4.. Reverted back to 3.4.1 and the issue was gone. ---------- components: Tkinter messages: 278004 nosy: Tyler Sweeden priority: normal severity: normal status: open title: winfo_pathname(..) | window id "xyz" doesn't exist in this application. | Python 3.4.4 versions: Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Oct 4 03:06:56 2016 From: report at bugs.python.org (Samson Lee) Date: Tue, 04 Oct 2016 07:06:56 +0000 Subject: [New-bugs-announce] [issue28353] os.fwalk() unhandled exception when error occurs accessing symbolic link target Message-ID: <1475564816.03.0.238756399525.issue28353@psf.upfronthosting.co.za> New submission from Samson Lee: The bug is os.fwalk() crashes with unhandled exception when there is an error accessing symbolic link targets. To reproduce the bug, create a symbolic link that targets a file that you do not have permission to access: $ touch handsoff $ sudo chown root:root handsoff $ sudo chmod 700 handsoff $ ln -s handsoff blah Now, os.fwalk() fails: >>> for root, dirs, files, fd in os.fwalk('.'): ... print(root, dirs, files) ... Traceback (most recent call last): File "test_fwalk_permission_error.py", line 3, in for root, dirs, files, fd in os.fwalk('.'): File "/usr/lib64/python3.5/os.py", line 520, in fwalk yield from _fwalk(topfd, top, topdown, onerror, follow_symlinks) File "/usr/lib64/python3.5/os.py", line 537, in _fwalk if st.S_ISDIR(stat(name, dir_fd=topfd).st_mode): PermissionError: [Errno 13] Permission denied: 'blah' The cause of the problem is in this part of os.py: for name in names: try: # Here, we don't use AT_SYMLINK_NOFOLLOW to be consistent with # walk() which reports symlinks to directories as directories. # We do however check for symlinks before recursing into # a subdirectory. if st.S_ISDIR(stat(name, dir_fd=topfd).st_mode): dirs.append(name) else: nondirs.append(name) except FileNotFoundError: try: # Add dangling symlinks, ignore disappeared files if st.S_ISLNK(stat(name, dir_fd=topfd, follow_symlinks=False) .st_mode): nondirs.append(name) except FileNotFoundError: continue To fix it, simply replace FileNotFoundError with more general OSError. Cheers ---------- components: Library (Lib) messages: 278016 nosy: Samson Lee priority: normal severity: normal status: open title: os.fwalk() unhandled exception when error occurs accessing symbolic link target versions: Python 3.5, Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Oct 4 05:00:39 2016 From: report at bugs.python.org (Sergey B Kirpichev) Date: Tue, 04 Oct 2016 09:00:39 +0000 Subject: [New-bugs-announce] [issue28354] DeprecationWarning not reported for invalid escape sequences Message-ID: <1475571639.5.0.779232953767.issue28354@psf.upfronthosting.co.za> New submission from Sergey B Kirpichev: We know from release notes, that "A backslash-character pair that is not a valid escape sequence now generates a DeprecationWarning". Sometimes it's true: $ python -W error Python 3.6.0b1+ (default, Oct 4 2016, 08:47:51) [GCC 4.9.2] on linux Type "help", "copyright", "credits" or "license" for more information. >>> "xxx" != "hello \world" DeprecationWarning: invalid escape sequence '\w' But shouldn't DeprecationWarning be in the following case as well? $ cat a.py def f(s): return s != "hello \world" $ cat b.py import a print(a.f("xxx")) $ python b.py True $ python -W error b.py True ---------- components: Interpreter Core messages: 278020 nosy: Sergey.Kirpichev priority: normal severity: normal status: open title: DeprecationWarning not reported for invalid escape sequences versions: Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Oct 4 07:57:43 2016 From: report at bugs.python.org (Tobias Dammers) Date: Tue, 04 Oct 2016 11:57:43 +0000 Subject: [New-bugs-announce] [issue28355] wsgiref simple_server PATH_INFO treats slashes and %2F the same Message-ID: <1475582263.54.0.955385942496.issue28355@psf.upfronthosting.co.za> New submission from Tobias Dammers: The WSGI reference implementation does not provide any means for application code to distinguish between the following request lines: GET /foo/bar HTTP/1.1 GET /foo%2Fbar HTTP/1.1 Now, the relevant RFC-1945 (https://tools.ietf.org/html/rfc1945#section-3.2) does not explicitly state how these should be handled by application code, but it does clearly distinguish encoded from unencoded forward-slashes in the BNF, which suggests that percent-encoded slashes should be considered part of a path segment, while unencoded slashes should be considere segment separators, and thus that the first URL is supposed to be interpreted as ['foo', 'bar'], but the second one as ['foo/bar']. However, the 'PATH_INFO' WSGI environ variable contains the same string, '/foo/bar', in both cases, making it impossible for application code to handle the difference. I believe the underlying issue is that percent-decoding (and decoding URLs into UTF-8) happens before interpreting the 'PATH_INFO', which is unavoidable because of the design decision to present PATH_INFO as a unicode string - if it were kept as a bytestring, then interpreting it would remain the sole responsibility of the application code; if it were a fully parsed list of unicode path segments, then the splitting could be implemented correctly. Unfortunately, I cannot see a pleasant way of fixing this without breaking a whole lot of stuff, but maybe someone else does. It's also very possible that I interpret the RFC incorrectly, in which case please enlighten me. ---------- messages: 278032 nosy: tdammers priority: normal severity: normal status: open title: wsgiref simple_server PATH_INFO treats slashes and %2F the same type: behavior versions: Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Oct 4 09:42:32 2016 From: report at bugs.python.org (stephan) Date: Tue, 04 Oct 2016 13:42:32 +0000 Subject: [New-bugs-announce] [issue28356] os.rename different in python 2.7.12 and python 3.5.2 Message-ID: <1475588552.47.0.916118565333.issue28356@psf.upfronthosting.co.za> New submission from stephan: Hi, I am just migrating my code from python 2.7.12 to 3.5.2 on Windows and stumbled on the following difference: In python 2.7.12: os.rename(filepath1, filepath2) works even if filepath1 and filepath2 are on different drives (or one on a local drive, the other on a network share). In python 3.5.2 I get for the same operation: "OSError: [WinError 17] The system cannot move the file to a different disk drive" My question: - is this a bug? - if not, where is this difference mentioned in the docs? I did find nothing, but I think it should be mentioned, otherwise I assume it's a bug. ---------- messages: 278035 nosy: stephan priority: normal severity: normal status: open title: os.rename different in python 2.7.12 and python 3.5.2 type: behavior versions: Python 2.7, Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Oct 4 12:05:06 2016 From: report at bugs.python.org (grovarsunil) Date: Tue, 04 Oct 2016 16:05:06 +0000 Subject: [New-bugs-announce] [issue28357] *1-800-790-9186* Dell printer helpdesk phone number usa. Dell printer issue support remotely by third party Message-ID: <1475597106.86.0.519962343897.issue28357@psf.upfronthosting.co.za> New submission from grovarsunil: Are you looking online technical support for printer problems. Is your printer unable to print or scan. call us 1-800-790-9186 and get instant technical support remotely for Dell printer issues. DISCLAIMER: - WE are an independent organization working as online third party technical support company for business and personal computer software,antivirus,printers and email support. Call +1800 790 9186 Dell Printer customer support number Dell Printer phone number +1800 790 9186 Dell Printer +1-800-790-9186 tech support phone number Dell Printer help +1800 790 9186 USA technical support phone number +1800 790 9186 Dell Printer customer Support Telephone Number, Dell PRINTER technical support phone number Dell printer +1800-790-9186 Customer Support Number, Dell printer Technical Helpline Number USA, Dell printer support phone number united states +1800-790-9186 Dell printer +1800-790-9186 Customer Support , Dell printer technical Support phone number USA, Dell printer support phone number united states +1800-790-9186 Dell printer +1800-790-9186 Customer Support Number Dell printer technical Support phone number USA, Dell printer support phone number united states +1800-790-9186 +1800-790-9186@@@ Dell printer tech support number , .Dell printer technical support phone number Dell printer Toll Free - 1800-790-9186 Dell printer Technical Support Number, Dell printer help desk phone number Just Call, +1800-790-9186 for all type help related Dell printer Issue support telephone number,Dell printer support phone number,Dell printer support phone number,Dell printer help phone number, Dell printer technical support number.Dell printer support number, Dell printer phone number, Dell printer tech support number, Dell printer customer support number, Dell printer customer support phone number, Dell printer customer service phone number, Dell printer customer service phone number, Dell printer support phone number Dell printer help number-Dell printer Helpline Number; Dell printer help phone number-Dell printer Helpline Number, Dell printer Tech Support Toll free Number, Dell printer Support Telephone Number, Dell printer Tech Support Telephone number, Dell printer Tech Support contact number, Dell printer support contact number, Dell printer technical support contact number, Dell printer help desk phone number.Dell printer support phone number. Dial +1800 790 9186 Dell Printer contact number, Dell Printer antivirus tech support phone number, Dell Printer Dial +1800 790 9186 Dell Printer contact number, Dell Printer antivirus tech support phone number, Dell Printer Dial +1800 790 9186 Dell Printer contact number, Dell Printer antivirus tech support phone number, Dell Printer Now call +1800 790 9186 Dell Printer contact number, Dell Printerantivirus tech support phone number, Dell Printer Dial +1800 790 9186 Dell Printer contact number, Dell Printerantivirus tech support phone number, Dell Printer Now call +1800 790 9186 Dell Printer contact number, Dell Printer antivirus tech support phone number, Dell Printer Now call Dell Printer contact number, Dell Printerantivirus tech support phone number, Dell Printer Now call +1800 790 9186 Dell Printer contact number, Dell Printerantivirus tech support phone number, Dell Printer +1800 790 9186 Dell Printer technical support number Dell PRINTER technical support phone number usa +1800 790 9186 Dell Printer technical support number Dell PRINTER technical support phone number usa +1800 790 9186 Dell PRINTER technical support Dell PRINTER technical support number Dell Printer technical support number Dell PRINTER technical support phone number +1800 790 9186 Dell PRINTER technical support Dell PRINTER technical support number Dell PRINTER antivirus technical support number Dell PRINTER technical support phone number +1800 790 9186 Dell PRINTER technical support Dell PRINTER technical support number Dell Printer technical support number Dell PRINTER technical support phone number Dell PRINTER technical support phone number usa Dell PRINTER antivirus technical support phone number NOW**/FIRST Tech CALL. Dell Printer customer support phone numberDial +1800 790 9186 Dial +1800 790 9186 Dell Printer customer support phone number. Dell Printer phone number .Dell Printer support phone numbers FIRST Dial +1800 790 9186 Dell Printer customer support phone number. Dell Printer phone number .Dell Printer support phone numbers FIRST Dial +1800 790 9186 Dell Printer customer support phone number. Dell Printer phone number .Dell Printer support phone number Dial +1800 790 9186 Dell Printer customer support phone number. Dell Printer phone number .Dell Printer support phone number +1800 790 9186 Dell Printer support phone number, Dell Printer phone number .Dell Printer support phone number Dell Printer tech support number here. FREE Dell Printer Tech Support | Dell PRINTER HelpLine Number Describe 1- +1800 790 9186 FREE Dell Printer Tech Support | Dell PRINTER HelpLine Number here. Dell Printer customer support number usa 1- +1800 790 9186 FREE usa Dell Printer customer support number, Dell PRINTER antivirus support phone number, Dell PRINTER tech support phone number, F- SECURE customer support phone number, Dell PRINTER helpline number, Dell PRINTER customer number, Dell Printer customer support number, Dell PRINTER contact telephone number, contact number for Dell PRINTER , Dell PRINTER software contact number, Dell PRINTER toll free number, Dell PRINTER telephone number , Dell PRINTER number, Dell PRINTER toll free number usa, Dell PRINTER customer support, Dell PRINTER software customer support support, Dell Printer support phone number, Dell PRINTER support phone########### Dell PRINTER tech support, Dell PRINTER customer support, Dell PRINTER phone support, Dell PRINTER support number Dell PRINTER technical support, Dell PRINTER antivirus customer support phone numberDial +1800 790 9186 Dell PRINTER antivirus tech support phone number, contact Dell PRINTER support, Dell PRINTER antivirus technical support phone number Dell PRINTER phone number tech support, Dell PRINTER support ticket, Dell PRINTER customer support number, F- SECURE tech support number Dell PRINTER technical support number, Dell PRINTER support center, Dell PRINTER telephone support, call Dell PRINTER support Dell PRINTER antivirus customer support number, Dell Printer tech support number, support for Dell PRINTER Dell PRINTER phone number, Dell PRINTER customer support phone number, Dell PRINTER contact phone number, Dell Printer phone number, F- Dial +1800 790 9186 Dell Printer contact number, Dell Printer antivirus tech support phone number, Dell Printer Dial +1800 790 9186 Dell Printer contact number, Dell Printer antivirus tech support phone number, Dell Printer Dial +1800 790 9186 Dell Printer contact number, Dell Printer antivirus tech support phone number, Dell Printer Now call +1800 790 9186 Dell Printer contact number, Dell Printerantivirus tech support phone number, Dell Printer Dial +1800 790 9186 Dell Printer contact number, Dell Printerantivirus tech support phone number, Dell Printer Now call +1800 790 9186 Dell Printer contact number, Dell Printer antivirus tech support phone number, Dell Printer Now call Dell Printer contact number, Dell Printerantivirus tech support phone number, Dell Printer Now call +1800 790 9186 Dell Printer contact number, Dell Printerantivirus tech support phone number, Dell Printer +1800 790 9186 Dell Printer technical support number Dell PRINTER technical support phone number usa +1800 790 9186 Dell Printer technical support number Dell PRINTER technical support phone number usa +1800 790 9186 Dell PRINTER technical support Dell PRINTER technical support number Dell Printer technical support number Dell PRINTER technical support phone number +1800 790 9186 Dell PRINTER technical support Dell PRINTER technical support number Dell PRINTER antivirus technical support number Dell PRINTER technical support phone number +1800 790 9186 Dell PRINTER technical support Dell PRINTER technical support number Dell Printer technical support number Dell PRINTER technical support phone number Dell PRINTER technical support phone number usa Dell PRINTER antivirus technical support phone number NOW**/FIRST Tech CALL. Dell Printer customer support phone number Dial +1800 790 9186 Dial +1800 790 9186 Dell Printer customer support phone number. Dell Printer phone number .Dell Printer support phone numbers FIRST Dial +1800 790 9186 Dell Printer customer support phone number. Dell Printer phone number .Dell Printer support phone numbers FIRST Dial +1800 790 9186 Dell Printer customer support phone number. Dell Printer phone number .Dell Printer support phone number Dial +1800 790 9186 Dell Printer customer support phone number. Dell Printer phone number .Dell Printer support phone number +1800 790 9186 Dell Printer support phone number, Dell Printer phone number .Dell Printer support phone number Describe Dell Printer tech support number here. FREE Dell Printer Tech Support | Dell PRINTER HelpLine Number Describe 1- +1800 790 9186 FREE Dell Printer Tech Support | Dell PRINTER HelpLine Number here. Dell Printer customer support number usa 1- +1800 790 9186 FREE usa Dell Printer customer support number, Dell PRINTER antivirus support phone number, Dell PRINTER tech support phone number, F- SECURE customer support phone number, Dell PRINTER helpline number, Dell PRINTER customer number, Dell Printer customer support number, Dell PRINTER contact telephone number, contact number for Dell PRINTER , Dell PRINTER software contact number, Dell PRINTER toll free number, Dell PRINTER telephone number , Dell PRINTER number, Dell PRINTER toll free number usa, Dell PRINTER customer support, Dell PRINTER software customer support support, Dell Printer support phone number, Dell PRINTER support phone Dell PRINTER tech support, Dell PRINTER customer support, Dell PRINTER phone support, Dell PRINTER support number Dell PRINTER technical support, Dell PRINTER antivirus customer support phone number Dial +1800 790 9186 Dell PRINTER support antivirus tech support phone number, contact Dell PRINTER support, Dell PRINTER antivirus technical support phone number Dell PRINTER phone number tech support, Dell PRINTER support ticket, Dell PRINTER customer support number,- SECURE tech support number Dell PRINTER technical support number, Dell PRINTER support center, Dell PRINTER telephone support, call Dell PRINTER support Dell PRINTER antivirus customer support number, Dell Printer tech support number, support for Dell PRINTER Dell PRINTER phone number, Dell PRINTER customer support phone number, Dell PRINTER contact phone number, Dell Printer phone number, Dial +1800 790 9186 Dell Printer contact number, Dell Printer antivirus tech support phone number, Dell Printer Dial +1800 790 9186 Dell Printer contact number, Dell Printer antivirus tech support phone number, Dell Printer Dial +1800 790 9186 Dell Printer contact number, Dell Printer antivirus tech support phone number, Dell Printer Now call +1800 790 9186 Dell Printer contact number, Dell Printerantivirus tech support phone number, Dell Printer Dial +1800 790 9186 Dell Printer contact number, Dell Printerantivirus tech support phone number, Dell Printer Now call +1800 790 9186 Dell Printer contact number, Dell Printer antivirus tech support phone number, Dell Printer Now call Dell Printer contact number, Dell Printerantivirus tech support phone number, Dell Printer Now call +1800 790 9186 Dell Printer contact number, Dell Printerantivirus tech support phone number, Dell Printer +1800 790 9186 Dell Printer technical support number Dell PRINTER technical support phone number usa +1800 790 9186 Dell Printer technical support number Dell PRINTER technical support phone number usa +1800 790 9186 Dell PRINTER technical help ---------- components: Build messages: 278055 nosy: grovarsunil priority: normal severity: normal status: open title: *1-800-790-9186* Dell printer helpdesk phone number usa. Dell printer issue support remotely by third party versions: Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Oct 4 13:11:48 2016 From: report at bugs.python.org (goon) Date: Tue, 04 Oct 2016 17:11:48 +0000 Subject: [New-bugs-announce] [issue28358] cakekup073@gmail.com Message-ID: <1475601108.21.0.157184134464.issue28358@psf.upfronthosting.co.za> New submission from goon: calli norton support 1-888-879-0163 phone number norton antivirus support customer dot support phone number usa calli norton support 1-888-879-0163 phone number norton antivirus support customer dot support phone number usa calli norton support 1-888-879-0163 phone number norton antivirus support customer dot support phone number usa Techsc 1-888-879-0163 norton Antivirus Technical Support Number customer service phone number customer support phone number customer care number1 8888790163 toll free number telephone number contact number norton antivirus Tech Support Number1-888-879-0163norton 360 technical support phone number usa 1.888.879.0163 norton 360 technical support phone number norton free call norton helpline phone number norton antivirus Tech Support Number1-888-879-0163norton 360 technical support phone number usa 1.888.879.0163 norton 360 technical support phone number norton free call norton helpline phone number@~@~1-888-879-0163++ norton Support Number norton antivirus customer service phone number norton helpline phone number@~@~1-888-879-0163++ norton Support Number norton antivirus customer service phone number norton helpline phone number@~@~1-888-879-0163++ norton Support Number norton antivirus customer service phone number norton Support Phone Number!!@~1-888-879-0163++ norton Tech Support Number usa norton Support Phone Number!!@~1-888-879-0163++ norton support phone number norton Support Phone Number!!@~1-888-879-0163++ norton support phone number norton helpline phone number@~@~1-888-879-0163++ norton Support Number norton antivirus customer service phone number norton Security contact Number +1 888.879.0163**norton antivirus support phone numberusa1 888.879.0163) Technical support number CANADA+@~1-888-879-0163++ norton Antivirus Technical Support USA-1 888.879.0163contact norton antivirus customer service phone number AUS-1 888.879.0163 phone number for norton customer service UK-@~1-888-879-0163++ phone number for norton antivirus technical support 1-888-879-0163 phone number for norton antivirus customer service phone number for norton antivirus technical support phone number for norton security norton customer service telephone number norton customer support norton grentry non payment norton helpline support number norton internet security customer service norton internet security technical support norton oem customer service norton pc cillin technical support norton phone support norton removal tool download norton subscription renewal norton support contact norton support hotline norton support phone number norton tech support phone number norton technical support norton technical support chat norton technical support phone number norton technical support phone number usa norton telephone number norton titanium antivirus norton titanium internet security norton titanium maximum norton titanium maximum security norton titanium problems norton Support Phone Number!!@~1-888-879-0163++ norton support phone number norton Support Phone Number!!@~1-888-879-0163++ norton support phone number norton helpline phone number@~@~1-888-879-0163++ norton tech Support Number norton antivirus customer service phone number norton Security contact Number +1888-8790163**norton antivirus support phone number usa+1-888-879-0163) Technical support number CANADA+@~1-888-879-0163++ norton Antivirus Technical Support USA-1888-879-1879contact norton antivirus customer service phone number AUS-1-888-879-0163 phone number for norton customer service UK-@~1-888-879-0163++ phone number for norton antivirus technical support 1-888-879-0163 phone number for norton antivirus customer service norton titanium removal tool norton titanium reviews norton titanium support norton virus removal service uninstall norton smart surfing for mac usa customer care number for norton antivirus norton phone number customer service norton phone numbers customer support norton phone support number norton security contact phone number norton security phone number customer service norton security support phone number norton support contact number norton support email address norton support phone number norton support telephone number norton support telephone number usa norton support telephone number norton tech support number norton Support Phone Number!!@~1-888-879-0163++ norton support phone number norton Support Phone Number!!@~1-888-879-0163++ norton support phone number norton helpline phone number@~@~1-888-879-0163++ norton tech Support Number norton antivirus customer service phone number norton Security contact Number +1888-8790163**norton antivirus support phone number usa+1-888-879-0163) Technical support number CANADA+@~1-888-879-0163++ norton Antivirus Technical Support USA-1888-879-1879contact norton antivirus customer service phone number AUS-1-888-879-0163 phone number for norton customer service UK-@~1-888-879-0163++ phone number for norton antivirus technical support 1-888-879-0163 phone number for norton antivirus customer servicenorton antivirus customer care phone number norton antivirus customer service billing norton antivirus customer service email address norton antivirus customer service live chat norton antivirus customer service telephone number norton antivirus customer support usa phone number norton antivirus help desk support phone number free in usa norton antivirus phone number customer service us norton antivirus phone number support norton antivirus support phone number norton antivirus tech support phone number free in usa norton antivirus tech support phone number norton antivirus technical support customer service norton antivirus technical support number norton antivirus telephone number norton antivirus toll free customer care number norton antivirus toll free number in usa norton antivirus contact phone number in usa norton antivirus customer service number norton antivirus customer service phone number norton antivirus customer service telephone number norton antivirus customer support number norton antivirus customer support phone number norton Support Phone Number!!@~1-888-879-0163++ norton support phone number norton Support Phone Number!!@~1-888-879-0163++ norton support phone number norton helpline phone number@~@~1-888-879-0163++ norton tech Support Number norton antivirus customer service phone number norton Security contact Number +1888-8790163**norton antivirus support phone number usa+1-888-879-0163) Technical support number CANADA+@~1-888-879-0163++ norton Antivirus Technical Support USA-1888-879-1879contact norton antivirus customer service phone number AUS-1-888-879-0163 phone number for norton customer service UK-@~1-888-879-0163++ phone number for norton antivirus technical support 1-888-879-0163 phone number for norton antivirus customer service norton antivirus customer support phone number norton antivirus help desk phone number in usa norton antivirus phone number norton tech support phone number norton tech support phone number free norton technical support phone number norton technical support cutomer phone number norton technical support phone number norton technical support number free in usa norton technical support number toll free number norton technical support phone number norton technologies phone number norton telephone support number norton antivirus customer support phone number norton antivirus customer service phone number norton customer support phone number norton phone number customer service norton technical support telephone number contact norton antivirus customer service phone number customer service number for norton antivirus phone number for norton antivirus phone number for norton antivirus customer service phone number for norton antivirus support phone number for norton customer service phone number for norton customer service phone number for norton customer support norton Support Phone Number!!@~1-888-879-0163++ norton support phone number norton Support Phone Number!!@~1-888-879-0163++ norton support phone number norton helpline phone number@~@~1-888-879-0163++ norton tech Support Number norton antivirus customer service phone number norton Security contact Number +1888-8790163**norton antivirus support phone number usa+1-888-879-0163) Technical support number CANADA+@~1-888-879-0163++ norton Antivirus Technical Support USA-1888-879-1879contact norton antivirus customer service phone number AUS-1-888-879-0163 phone number for norton customer service UK-@~1-888-879-0163++ phone number for norton antivirus technical support 1-888-879-0163 phone number for norton antivirus customer service phone number for norton tech support phone number norton antivirus customer service norton antivirus customer service number norton antivirus customer service phone norton antivirus customer service phone number norton antivirus customer service phone number us norton antivirus customer service telephone number norton antivirus customer support norton antivirus customer support number norton antivirus phone number customer service us norton antivirus phone number support norton antivirus phone support norton antivirus phone support number norton antivirus support phone number norton antivirus tech support phone number norton antivirus technical support norton antivirus technical support number norton antivirus technical support phone number norton customer service phone number norton customer support phone number norton helpline phone number norton internet security customer service norton internet security customer service phone number norton internet security help phone number norton internet security phone number customer service norton phone number customer service norton phone number customer support norton security customer service phone number K*Y*norton helpline phone number@~1-888-879-0163++ norton antivirus Support Number phone norton antivirus customer care phone number~K*Y*norton helpline phone number@~1-888-879-0163++ norton antivirus Support Number phone norton antivirus customer care phone number~K*Y*norton helpline phone number@~1-888-879-0163++ norton antivirus Support Number phone norton antivirus customer care phone number~K*Y*norton helpline phone number@~1-888-879-0163++ norton antivirus Support Number phone norton antivirus customer care phone number~K*Y*norton helpline phone number@~1-888-879-0163++ norton antivirus Support Number phone norton antivirus customer care phone number~K*Y*norton helpline phone number@~1-888-879-0163++ norton antivirus Support Number phone norton antivirus customer care phone number~K*Y*norton helpline phone number@~1-888-879-0163++ norton antivirus Support Number phone norton antivirus customer care phone number~K*Y*norton helpline phone number@~1-888-879-0163++ norton antivirus Support Number phone norton antivirus customer care phone number~K*Y*norton helpline phone number@~1-888-879-0163++ norton antivirus Support Number phone norton antivirus customer care phone number~K*Y*norton helpline phone number@~1-888-879-0163++ norton antivirus Support Number phone norton antivirus customer care phone number ~K*Y*norton helpline phone number@~1-888-879-0163++ norton antivirus Support Number phone norton antivirus customer care phone number norton helpline phone number@~1888-879-0163 norton tech Support Number norton antivirus customer service phone number norton Security contact Number +1888-8790163**norton antivirus support phone number usa+1-888-879-0163) Technical support number CANADA+1888-879-0163 norton Antivirus Technical Support USA-1888-879-1879contact norton antivirus customer service phone numberusa1 888.879.0163) Technical support number CANADA+@~1-888-879-0163++ norton Antivirus Technical Support USA-1 888.879.0163contact norton antivirus customer service phone number AUS-1 888.879.0163 phone number for norton customer service UK-@~1-888-879-0163++ phone number for norton antivirus technical support 1-888-879-0163 phone number for norton antivirus customer service phone number for norton antivirus technical support phone number for norton security norton customer service telephone number norton customer support norton grentry non payment norton helpline support number norton internet security customer service norton internet security technical support norton oem customer service norton pc cillin technical support norton phone support norton removal tool download norton subscription renewal norton support contact norton support hotline norton support phone number norton tech support phone number norton technical support norton technical support chat norton technical support phone number norton technical support phone number usa norton telephone number norton titanium antivirus norton titanium internet security norton titanium maximum norton titanium maximum security norton titanium problems norton Support Phone Number!!@~1-888-879-0163++ norton support phone number norton Support Phone Number!!@~1-888-879-0163++ norton support phone number norton helpline phone number@~@~1-888-879-0163++ norton tech Support Number norton antivirus customer service phone number norton Security contact Number +1888-8790163**norton antivirus support phone number usa+1-888-879-0163) Technical support number CANADA+@~1-888-879-0163++ norton Antivirus Technical Support USA-1888-879-1879contact norton antivirus customer service phone number AUS-1-888-879-0163 phone number for norton customer service UK-@~1-888-879-0163++ phone number for norton antivirus technical support 1-888-879-0163 phone number for norton antivirus customer service norton titanium removal tool norton titanium reviews norton titanium support norton virus removal service uninstall norton smart surfing for mac usa customer care number for norton antivirus norton phone number customer service norton phone numbers customer support norton phone support number norton security contact phone number norton security phone number customer service norton security support phone number norton support contact number norton support email address norton support phone number norton support telephone number norton support telephone number usa norton support telephone number norton tech support number norton Support Phone Number!!@~1-888-879-0163++ norton support phone number norton Support Phone Number!!@~1-888-879-0163++ norton support phone number norton helpline phone number@~@~1-888-879-0163++ norton tech Support Number norton antivirus customer service phone number norton Security contact Number +1888-8790163**norton antivirus support phone number usa+1-888-879-0163) Technical support number CANADA+@~1-888-879-0163++ norton Antivirus Technical Support USA-1888-879-1879contact norton antivirus customer service phone number AUS-1-888-879-0163 phone number for norton customer service UK-@~1-888-879-0163++ phone number for norton antivirus technical support 1-888-879-0163 phone number for norton antivirus customer servicenorton antivirus customer care phone number norton antivirus customer service billing norton antivirus customer service email address norton antivirus customer service live chat norton antivirus customer service telephone number norton antivirus customer support usa phone number norton antivirus help desk support phone number free in usa norton antivirus phone number customer service us norton antivirus phone number support norton antivirus support phone number norton antivirus tech support phone number free in usa norton antivirus tech support phone number norton antivirus technical support customer service norton antivirus technical support number norton antivirus telephone number norton antivirus toll free customer care number norton antivirus toll free number in usa norton antivirus contact phone number in usa norton antivirus customer service number norton antivirus customer service phone number norton antivirus customer service telephone number norton antivirus customer support number norton antivirus customer support phone number norton Support Phone Number!!@~1-888-879-0163++ norton support phone number norton Support Phone Number!!@~1-888-879-0163++ norton support phone number norton helpline phone number@~@~1-888-879-0163++ norton tech Support Number norton antivirus customer service phone number norton Security contact Number +1888-8790163**norton antivirus support phone number usa+1-888-879-0163) Technical support number CANADA+@~1-888-879-0163++ norton Antivirus Technical Support USA-1888-879-1879contact norton antivirus customer service phone number AUS-1-888-879-0163 phone number for norton customer service UK-@~1-888-879-0163++ phone number for norton antivirus technical support 1-888-879-0163 phone number for norton antivirus customer service norton antivirus customer support phone number norton antivirus help desk phone number in usa norton antivirus phone number norton tech support phone number norton tech support phone number free norton technical support phone number norton technical support cutomer phone number norton technical support phone number norton technical support number free in usa norton technical support number toll free number norton technical support phone number norton technologies phone number norton telephone support number norton antivirus customer support phone number norton antivirus customer service phone number norton customer support phone number norton phone number customer service norton technical support telephone number contact norton antivirus customer service phone number customer service number for norton antivirus phone number for norton antivirus phone number for norton antivirus customer service phone number for norton antivirus support phone number for norton customer service phone number for norton customer service phone number for norton customer support norton Support Phone Number!!@~1-888-879-0163++ norton support phone number norton Support Phone Number!!@~1-888-879-0163++ norton support phone number norton helpline phone number@~@~1-888-879-0163++ norton tech Support Number norton antivirus customer service phone number norton Security contact Number +1888-8790163**norton antivirus support phone number usa+1-888-879-0163) Technical support number CANADA+@~1-888-879-0163++ norton Antivirus Technical Support USA-1888-879-1879contact norton antivirus customer service phone number AUS-1-888-879-0163 phone number for norton customer service UK-@~1-888-879-0163++ phone number for norton antivirus technical support 1-888-879-0163 phone number for norton antivirus customer service phone number for norton tech support phone number norton antivirus customer service norton antivirus customer service number norton antivirus customer service phone norton antivirus customer service phone number norton antivirus customer service phone number us norton antivirus customer service telephone number norton antivirus customer support norton antivirus customer support number norton antivirus phone number customer service us norton antivirus phone number support norton antivirus phone support norton antivirus phone support number norton antivirus support phone number norton antivirus tech support phone number norton antivirus technical support norton antivirus technical support number norton antivirus technical support phone number norton customer service phone number norton customer support phone number norton helpline phone number norton internet security customer service norton internet security customer service phone number norton internet security help phone number norton internet security phone number customer service norton phone number customer service norton phone number customer support norton security customer service phone number K*Y*norton helpline phone number@~1-888-879-0163++ norton antivirus Support Number phone norton antivirus customer care phone number~K*Y*norton helpline phone number@~1-888-879-0163++ norton antivirus Support Number phone norton antivirus customer care phone number~K*Y*norton helpline phone number@~1-888-879-0163++ norton antivirus Support Number phone norton antivirus customer care phone number~K*Y*norton helpline phone number@~1-888-879-0163++ norton antivirus Support Number phone norton antivirus customer care phone number~K*Y*norton helpline phone number@~1-888-879-0163++ norton antivirus Support Number phone norton antivirus customer care phone number~K*Y*norton helpline phone number@~1-888-879-0163++ norton antivirus Support Number phone norton antivirus customer care phone number~K*Y*norton helpline phone number@~1-888-879-0163++ norton antivirus Support Number phone norton antivirus customer care phone number~K*Y*norton helpline phone number@~1-888-879-0163++ norton antivirus Support Number phone norton antivirus customer care phone number~K*Y*norton helpline phone number@~1-888-879-0163++ norton antivirus Support Number phone norton antivirus customer care phone number~K*Y*norton helpline phone number@~1-888-879-0163++ norton antivirus Support Number phone norton antivirus customer care phone number ~K*Y*norton helpline phone number@~1-888-879-0163++ norton antivirus Support Number phone norton antivirus customer care phone number norton helpline phone number@~1888-879-0163 norton tech Support Number norton antivirus customer service phone number norton Security contact Number +1888-8790163**norton antivirus support phone number usa+1-888-879-0163) Technical support number CANADA+1888-879-0163 norton Antivirus Technical Support USA-1888-879-1879contact norton antivirus customer service phone number Page URL: ---------- components: Argument Clinic messages: 278063 nosy: goon369, larry priority: normal severity: normal status: open title: cakekup073 at gmail.com type: behavior versions: Python 3.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Oct 4 13:14:10 2016 From: report at bugs.python.org (goon) Date: Tue, 04 Oct 2016 17:14:10 +0000 Subject: [New-bugs-announce] [issue28359] Norton.Helpline +1-888-879-.0163 Norton Technical Support telePhone number Norton phone Number Message-ID: <1475601250.88.0.732728688895.issue28359@psf.upfronthosting.co.za> New submission from goon: - USAA-1-888-879-0163++ Norton 360 support phone number Norton tech support phone number Norton 360 Tech Support Number Norton antivirus~:((++1888879.01.63+))@Norton antivirus Phone at number@Norton antivirus at Dell@brother at Norton antivirus at Norton antivirus@@technical at support@number at USA !!Help W:::norton:::::::::::norton:::::::::::::::::@1888 879 0163::::::::::::SUPPORT:::::::::::::::::::::~~! norton Antivirus tech support phone number;;;;;; -!@!~~chilluu@@pLumber+18888790163 norton antivirus internet security tech support phone number 8888790163@@@@##### https://answers.launchpad.net norton internet security tech support phone number - USAi-1-888-879-0163++ Norton 360 support phone number Norton tech support phone number Norton 360 Tech Support Number calli norton support 1-888-879-0163 phone number norton antivirus support customer dot support phone number usa Techsc 1-888-879-0163 norton Antivirus Technical Support Number customer service phone number customer support phone number customer care number1 8888790163 toll free number telephone number contact number norton antivirus Tech Support Number1-888-879-0163norton 360 technical support phone number usa 1.888.879.0163 norton 360 technical support phone number norton free call norton helpline phone number norton antivirus Tech Support Number1-888-879-0163norton 360 technical support phone number usa 1.888.879.0163 norton 360 technical support phone number norton free call norton helpline phone number@~@~1-888-879-0163++ norton Support Number norton antivirus customer service phone number norton helpline phone number@~@~1-888-879-0163++ norton Support Number norton antivirus customer service phone number norton helpline phone number@~@~1-888-879-0163++ norton Support Number norton antivirus customer service phone number norton Support Phone Number!!@~1-888-879-0163++ norton Tech Support Number usa norton Support Phone Number!!@~1-888-879-0163++ norton support phone number norton Support Phone Number!!@~1-888-879-0163++ norton support phone number norton helpline phone number@~@~1-888-879-0163++ norton Support Number norton antivirus customer service phone number norton Security contact Number +1 888.879.0163**norton antivirus support phone numberusa1 888.879.0163) Technical support number CANADA+@~1-888-879-0163++ norton Antivirus Technical Support USA-1 888.879.0163contact norton antivirus customer service phone number AUS-1 888.879.0163 phone number for norton customer service UK-@~1-888-879-0163++ phone number for norton antivirus technical support 1-888-879-0163 phone number for norton antivirus customer service phone number for norton antivirus technical support phone number for norton security norton customer service telephone number norton customer support norton grentry non payment norton helpline support number norton internet security customer service norton internet security technical support norton oem customer service norton pc cillin technical support norton phone support norton removal tool download norton subscription renewal norton support contact norton support hotline norton support phone number norton tech support phone number norton technical support norton technical support chat norton technical support phone number norton technical support phone number usa norton telephone number norton titanium antivirus norton titanium internet security norton titanium maximum norton titanium maximum security norton titanium problems norton Support Phone Number!!@~1-888-879-0163++ norton support phone number norton Support Phone Number!!@~1-888-879-0163++ norton support phone number norton helpline phone number@~@~1-888-879-0163++ norton tech Support Number norton antivirus customer service phone number norton Security contact Number +1888-8790163**norton antivirus support phone number usa+1-888-879-0163) Technical support number CANADA+@~1-888-879-0163++ norton Antivirus Technical Support USA-1888-879-0163contact norton antivirus customer service phone number AUS-1-888-879-0163 phone number for norton customer service UK-@~1-888-879-0163++ phone number for norton antivirus technical support 1-888-879-0163 phone number for norton antivirus customer service norton titanium removal tool norton titanium reviews norton titanium support norton virus removal service uninstall norton smart surfing for mac usa customer care number for norton antivirus norton phone number customer service norton phone numbers customer support norton phone support number norton security contact phone number norton security phone number customer service norton security support phone number norton support contact number norton support email address norton support phone number norton support telephone number norton support telephone number usa norton support telephone number norton tech support number norton Support Phone Number!!@~1-888-879-0163++ norton support phone number norton Support Phone Number!!@~1-888-879-0163++ norton support phone number norton helpline phone number@~@~1-888-879-0163++ norton tech Support Number norton antivirus customer service phone number norton Security contact Number +1888-8790163**norton antivirus support phone number usa+1-888-879-0163) Technical support number CANADA+@~1-888-879-0163++ norton Antivirus Technical Support USA-1888-879-0163contact norton antivirus customer service phone number AUS-1-888-879-0163 phone number for norton customer service UK-@~1-888-879-0163++ phone number for norton antivirus technical support 1-888-879-0163 phone number for norton antivirus customer servicenorton antivirus customer care phone number norton antivirus customer service billing norton antivirus customer service email address norton antivirus customer service live chat norton antivirus customer service telephone number norton antivirus customer support usa phone number norton antivirus help desk support phone number free in usa norton antivirus phone number customer service us norton antivirus phone number support norton antivirus support phone number norton antivirus tech support phone number free in usa norton antivirus tech support phone number norton antivirus technical support customer service norton antivirus technical support number norton antivirus telephone number norton antivirus toll free customer care number norton antivirus toll free number in usa norton antivirus contact phone number in usa norton antivirus customer service number norton antivirus customer service phone number norton antivirus customer service telephone number norton antivirus customer support number norton antivirus customer support phone number norton Support Phone Number!!@~1-888-879-0163++ norton support phone number norton Support Phone Number!!@~1-888-879-0163++ norton support phone number norton helpline phone number@~@~1-888-879-0163++ norton tech Support Number norton antivirus customer service phone number norton Security contact Number +1888-8790163**norton antivirus support phone number usa+1-888-879-0163) Technical support number CANADA+@~1-888-879-0163++ norton Antivirus Technical Support USA-1888-879-0163contact norton antivirus customer service phone number AUS-1-888-879-0163 phone number for norton customer service UK-@~1-888-879-0163++ phone number for norton antivirus technical support 1-888-879-0163 phone number for norton antivirus customer service norton antivirus customer support phone number norton antivirus help desk phone number in usa norton antivirus phone number norton tech support phone number norton tech support phone number free norton technical support phone number norton technical support cutomer phone number norton technical support phone number norton technical support number free in usa norton technical support number toll free number norton technical support phone number norton technologies phone number norton telephone support number norton antivirus customer support phone number norton antivirus customer service phone number norton customer support phone number norton phone number customer service norton technical support telephone number contact norton antivirus customer service phone number customer service number for norton antivirus phone number for norton antivirus phone number for norton antivirus customer service phone number for norton antivirus support phone number for norton customer service phone number for norton customer service phone number for norton customer support norton Support Phone Number!!@~1-888-879-0163++ norton support phone number norton Support Phone Number!!@~1-888-879-0163++ norton support phone number norton helpline phone number@~@~1-888-879-0163++ norton tech Support Number norton antivirus customer service phone number norton Security contact Number +1888-8790163**norton antivirus support phone number usa+1-888-879-0163) Technical support number CANADA+@~1-888-879-0163++ norton Antivirus Technical Support USA-1888-879-0163contact norton antivirus customer service phone number AUS-1-888-879-0163 phone number for norton customer service UK-@~1-888-879-0163++ phone number for norton antivirus technical support 1-888-879-0163 phone number for norton antivirus customer service phone number for norton tech support phone number norton antivirus customer service norton antivirus customer service number norton antivirus customer service phone norton antivirus customer service phone number norton antivirus customer service phone number us norton antivirus customer service telephone number norton antivirus customer support norton antivirus customer support number norton antivirus phone number customer service us norton antivirus phone number support norton antivirus phone support norton antivirus phone support number norton antivirus support phone number norton antivirus tech support phone number norton antivirus technical support norton antivirus technical support number norton antivirus technical support phone number norton customer service phone number norton customer support phone number norton helpline phone number norton internet security customer service norton internet security customer service phone number norton internet security help phone number norton internet security phone number customer service norton phone number customer service norton phone number customer support norton security customer service phone number K*Y*norton helpline phone number@~1-888-879-0163++ norton antivirus Support Number phone norton antivirus customer care phone number~K*Y*norton helpline phone number@~1-888-879-0163++ norton antivirus Support Number phone norton antivirus customer care phone number~K*Y*norton helpline phone number@~1-888-879-0163++ norton antivirus Support Number phone norton antivirus customer care phone number~K*Y*norton helpline phone number@~1-888-879-0163++ norton antivirus Support Number phone norton antivirus customer care phone number~K*Y*norton helpline phone number@~1-888-879-0163++ norton antivirus Support Number phone norton antivirus customer care phone number~K*Y*norton helpline phone number@~1-888-879-0163++ norton antivirus Support Number phone norton antivirus customer care phone number~K*Y*norton helpline phone number@~1-888-879-0163++ norton antivirus Support Number phone norton antivirus customer care phone number~K*Y*norton helpline phone number@~1-888-879-0163++ norton antivirus Support Number phone norton antivirus customer care phone number~K*Y*norton helpline phone number@~1-888-879-0163++ norton antivirus Support Number phone norton antivirus customer care phone number~K*Y*norton helpline phone number@~1-888-879-0163++ norton antivirus Support Number phone norton antivirus customer care phone number ~K*Y*norton helpline phone number@~1-888-879-0163++ norton antivirus Support Number phone norton antivirus customer care phone number norton helpline phone number@~1888-879-0163 norton tech Support Number norton antivirus customer service phone number norton Security contact Number +1888-8790163**norton antivirus support phone number usa+1-888-879-0163) Technical support number CANADA+1888-879-0163 norton Antivirus Technical Support USA-1888-879-0163contact norton antivirus customer service phone numberusa1 888.879.0163) Technical support number CANADA+@~1-888-879-0163++ norton Antivirus Technical Support USA-1 888.879.0163contact norton antivirus customer service phone number AUS-1 888.879.0163 phone number for norton customer service UK-@~1-888-879-0163++ phone number for norton antivirus technical support 1-888-879-0163 phone number for norton antivirus customer service phone number for norton antivirus technical support phone number for norton security norton customer service telephone number norton customer support norton grentry non payment norton helpline support number norton internet security customer service norton internet security technical support norton oem customer service norton pc cillin technical support norton phone support norton removal tool download norton subscription renewal norton support contact norton support hotline norton support phone number norton tech support phone number norton technical support norton technical support chat norton technical support phone number norton technical support phone number usa norton telephone number norton titanium antivirus norton titanium internet security norton titanium maximum norton titanium maximum security norton titanium problems norton Support Phone Number!!@~1-888-879-0163++ norton support phone number norton Support Phone Number!!@~1-888-879-0163++ norton support phone number norton helpline phone number@~@~1-888-879-0163++ norton tech Support Number norton antivirus customer service phone number norton Security contact Number +1888-8790163**norton antivirus support phone number usa+1-888-879-0163) Technical support number CANADA+@~1-888-879-0163++ norton Antivirus Technical Support USA-1888-879-0163contact norton antivirus customer service phone number AUS-1-888-879-0163 phone number for norton customer service UK-@~1-888-879-0163++ phone number for norton antivirus technical support 1-888-879-0163 phone number for norton antivirus customer service norton titanium removal tool norton titanium reviews norton titanium support norton virus removal service uninstall norton smart surfing for mac usa customer care number for norton antivirus norton phone number customer service norton phone numbers customer support norton phone support number norton security contact phone number norton security phone number customer service norton security support phone number norton support contact number norton support email address norton support phone number norton support telephone number norton support telephone number usa norton support telephone number norton tech support number norton Support Phone Number!!@~1-888-879-0163++ norton support phone number norton Support Phone Number!!@~1-888-879-0163++ norton support phone number norton helpline phone number@~@~1-888-879-0163++ norton tech Support Number norton antivirus customer service phone number norton Security contact Number +1888-8790163**norton antivirus support phone number usa+1-888-879-0163) Technical support number CANADA+@~1-888-879-0163++ norton Antivirus Technical Support USA-1888-879-0163contact norton antivirus customer service phone number AUS-1-888-879-0163 phone number for norton customer service UK-@~1-888-879-0163++ phone number for norton antivirus technical support 1-888-879-0163 phone number for norton antivirus customer servicenorton antivirus customer care phone number norton antivirus customer service billing norton antivirus customer service email address norton antivirus customer service live chat norton antivirus customer service telephone number norton antivirus customer support usa phone number norton antivirus help desk support phone number free in usa norton antivirus phone number customer service us norton antivirus phone number support norton antivirus support phone number norton antivirus tech support phone number free in usa norton antivirus tech support phone number norton antivirus technical support customer service norton antivirus technical support number norton antivirus telephone number norton antivirus toll free customer care number norton antivirus toll free number in usa norton antivirus contact phone number in usa norton antivirus customer service number norton antivirus customer service phone number norton antivirus customer service telephone number norton antivirus customer support number norton antivirus customer support phone number norton Support Phone Number!!@~1-888-879-0163++ norton support phone number norton Support Phone Number!!@~1-888-879-0163++ norton support phone number norton helpline phone number@~@~1-888-879-0163++ norton tech Support Number norton antivirus customer service phone number norton Security contact Number +1888-8790163**norton antivirus support phone number usa+1-888-879-0163) Technical support number CANADA+@~1-888-879-0163++ norton Antivirus Technical Support USA-1888-879-0163contact norton antivirus customer service phone number AUS-1-888-879-0163 phone number for norton customer service UK-@~1-888-879-0163++ phone number for norton antivirus technical support 1-888-879-0163 phone number for norton antivirus customer service norton antivirus customer support phone number norton antivirus help desk phone number in usa norton antivirus phone number norton tech support phone number norton tech support phone number free norton technical support phone number norton technical support cutomer phone number norton technical support phone number norton technical support number free in usa norton technical support number toll free number norton technical support phone number norton technologies phone number norton telephone support number norton antivirus customer support phone number norton antivirus customer service phone number norton customer support phone number norton phone number customer service norton technical support telephone number contact norton antivirus customer service phone number customer service number for norton antivirus phone number for norton antivirus phone number for norton antivirus customer service phone number for norton antivirus support phone number for norton customer service phone number for norton customer service phone number for norton customer support norton Support Phone Number!!@~1-888-879-0163++ norton support phone number norton Support Phone Number!!@~1-888-879-0163++ norton support phone number norton helpline phone number@~@~1-888-879-0163++ norton tech Support Number norton antivirus customer service phone number norton Security contact Number +1888-8790163**norton antivirus support phone number usa+1-888-879-0163) Technical support number CANADA+@~1-888-879-0163++ norton Antivirus Technical Support USA-1888-879-0163contact norton antivirus customer service phone number AUS-1-888-879-0163 phone number for norton customer service UK-@~1-888-879-0163++ phone number for norton antivirus technical support 1-888-879-0163 phone number for norton antivirus customer service phone number for norton tech support phone number norton antivirus customer service norton antivirus customer service number norton antivirus customer service phone norton antivirus customer service phone number norton antivirus customer service phone number us norton antivirus customer service telephone number norton antivirus customer support norton antivirus customer support number norton antivirus phone number customer service us norton antivirus phone number support norton antivirus phone support norton antivirus phone support number norton antivirus support phone number norton antivirus tech support phone number norton antivirus technical support norton antivirus technical support number norton antivirus technical support phone number norton customer service phone number norton customer support phone number norton helpline phone number norton internet security customer service norton internet security customer service phone number norton internet security help phone number norton internet security phone number customer service norton phone number customer service norton phone number customer support norton security customer service phone number K*Y*norton helpline phone number@~1-888-879-0163++ norton antivirus Support Number phone norton antivirus customer care phone number~K*Y*norton helpline phone number@~1-888-879-0163++ norton antivirus Support Number phone norton antivirus customer care phone number~K*Y*norton helpline phone number@~1-888-879-0163++ norton antivirus Support Number phone norton antivirus customer care phone number~K*Y*norton helpline phone number@~1-888-879-0163++ norton antivirus Support Number phone norton antivirus customer care phone number~K*Y*norton helpline phone number@~1-888-879-0163++ norton antivirus Support Number phone norton antivirus customer care phone number~K*Y*norton helpline phone number@~1-888-879-0163++ norton antivirus Support Number phone norton antivirus customer care phone number~K*Y*norton helpline phone number@~1-888-879-0163++ norton antivirus Support Number phone norton antivirus customer care phone number~K*Y*norton helpline phone number@~1-888-879-0163++ norton antivirus Support Number phone norton antivirus customer care phone number~K*Y*norton helpline phone number@~1-888-879-0163++ norton antivirus Support Number phone norton antivirus customer care phone number~K*Y*norton helpline phone number@~1-888-879-0163++ norton antivirus Support Number phone norton antivirus customer care phone number ~K*Y*norton helpline phone number@~1-888-879-0163++ norton antivirus Support Number phone norton antivirus customer care phone number norton helpline phone number@~1888-879-0163 norton tech Support Number norton antivirus customer service phone number norton Security contact Number +1888-8790163**norton antivirus support phone number usa+1-888-879-0163) Technical support number CANADA+1888-879-0163 norton Antivirus Technical Support USA-1888-879-0163contact norton antivirus customer service phone number ---------- components: asyncio messages: 278064 nosy: goon369, gvanrossum, yselivanov priority: normal severity: normal status: open title: Norton.Helpline +1-888-879-.0163 Norton Technical Support telePhone number Norton phone Number type: crash versions: Python 3.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Oct 4 13:18:48 2016 From: report at bugs.python.org (goon) Date: Tue, 04 Oct 2016 17:18:48 +0000 Subject: [New-bugs-announce] [issue28360] **<<<<<<<1^888`879~O163>>>>>>>> Norton antivirus customer support phone number Message-ID: <1475601528.59.0.803082698155.issue28360@psf.upfronthosting.co.za> New submission from goon: USA..1 888-879-0163++ Norton 360 support phone number om Norton tech support phone number Norton 360 Tech Support Number USA..1 888-879-0163++ Norton 360 support phone number om Norton tech support phone number Norton 360 Tech Support Number USAtralia>>>> USA-1 888-879-0163++ Norton 360 support phone number Norton tech support phone number Norton 360 Tech Support Number USA >>>> USA-1 888-879-0163++ Norton 360 support phone number USA-1 888-879-0163USA/canada Norton 360 Tech Support Number @@!1-888-879-0163;!!Norton 360 Support Number Norton Live Support and Help? 18(88-879-0163 @@ Norton tech support phone number Norton Live Support and Help? 18(88-879-0163 @@ Norton tech support phone number Norton Live Support and Help? 18(88-879-0163 Norton 360 support phone number USA USA Canada>>>> USA-1 888-879-0163++ Norton 360 support phone number USA-1 888-879-0163USA/canada Norton 360 Tech Support Number @@!1-888-879-0163;!!Norton 360 Support Number WikiGenes- @+++1888-879-0163++880Norton 360 support phone number18888790163USA/canada Norton antivirus technical support phone number 1.888-879-0163 hdfc toll free customer care number(((!1.888-879-0163)) Norton 360 Tech Support Number @@!1-888-879-0163!! Norton 360 Support Number Norton toll free customer care number 1.888-879-0163 Norton toll free customer care number 1.888-879-0163 Norton toll free customer care number 1.888-879-0163 Norton toll free customer care number 1.888-879-0163>>>>> Norton technical support phone number ((1.888-879-0163)) Norton technical support number 1.888-879-0163 Norton technical support number 1.888-879-0163 symantec technical support number 1.888-879-0163 Norton antivirus technical support number 1.888-879-0163 Norton support phone number 1.888-879-0163 Norton locations Norton 360 Tech Support Number @@!1-888-879-0163!! Norton 360 Support Number Norton 360 Tech Support Number @@!1-888-879-0163!! Norton 360 Support Number Norton customer service Norton antivirus customer care__Norton Support phone number 1.888-879-0163 Norton customer support phone number 1.888-879-0163 Norton customer support phone number 1.888-879-0163 Norton antivirus customer support phone number 1.888-879-0163Norton antivirus customer service phone number 1.888-879-0163 Norton antivirus technical support phone number 1.888-879-0163 Norton antivirus tech support phone number 1.888-879-0163 Norton antivirus phone number 1.888-879-0163 Norton 360 Tech Support Number @@!1-888-879-0163!! Norton 360 Support Number Norton security center phone number 1.888-879-0163 Norton support telephone number 1.888-879-0163 Norton 360 technical support phone number 1.888-879-0163 symantec technical support phone number 1.888-879-0163 Norton tech support phone number 1.888-879-0163 Norton 360 Tech Support Number @@!1-888-879-0163!! Norton 360 Support Number apple technical support phone number 1.888-879-0163 USA microsoft technical support phone number 1.888-879-0163 USA gmail technical support phone number 1.888-879-0163 USA kaspersky technical support phone number 1.888-879-0163 USA lenovo technical support phone number 1.888-879-0163 USA epson technical support phone number 1.888-879-0163 USA Norton technical support phone number 1.888-879-0163 Norton 360 Tech Support Number @@!1-888-879-0163!! Norton 360 Support Number Norton AntiVirus Customer Service Phone Number #1: 888-879-0163 Norton Phone number 1-888-879-0163 Norton 360 phone number Norton 360 support phone number Free~* C at ll 1.888-879-0163 Norton 360 technical support phone number USA 1.888-879-0163 Norton 360 technical support phone number Norton free call ~* C at ll 1.888-879-0163 Norton 360 technical support phone number USA 1.888-879-0163 Norton 360 technical support phone number Norton free call Norton 360 Tech Support Number @@!1-888-879-0163!! Norton 360 Support Number PHONE support USA @1.888-879-0163 Norton antivirus technical support phone number Norton locations Norton online support Norton Support phone number 1.888-879-0163 Norton customer care Norton tech support phone number 1.888-879-0163 Norton tech support phone number 1.888-879-0163 Norton antivirus tech support phone number 1.888-879-0163 Norton locations Norton 360 Tech Support Number @@!1-888-879-0163!! Norton 360 Support Number Norton Support phone number 1.888-879-0163 service Norton com Norton login Norton technical support phone number 1.888-879-0163 Norton customer service Norton Support phone number 1.888-879-0163 Norton support telephone number 1.888-879-0163 Norton support phone number 1.888-879-0163 Norton antivirus support phone number 1.888-879-0163 Norton 360 Tech Support Number @@!1-888-879-0163!! Norton 360 Support Number Norton antivirus tech support phone number 1.888-879-0163 Norton antivirus customer service phone number 1.888-879-0163 Norton 360 technical support phone number 1.888-879-0163 symantec technical support phone number 1.888-879-0163 Norton technical support phone number 1.888-879-0163 Norton customer service telephone number 1.888-879-0163 Norton antivirus phone number 1.888-879-0163 Norton antivirus customer service phone number 1.888-879-0163 Norton antivirus customer service Support Norton 360 Tech Support Number @@!1-888-879-0163!! Norton 360 Support Number Norton antivirus phone number 1.888-879-0163 Norton phone number 1.888-879-0163 cancel subscription Norton technical support phone number 1.888-879-0163 Norton 888 phone number 1.888-879-0163 snapdeal toll free customer care number 1.888-879-0163 sbi toll free customer care number 1.888-879-0163 airtel toll free customer care number 1.888-879-0163 Norton customer service number 1.888-879-0163 Norton call center Norton 360 Tech Support Number @@!1-888-879-0163!! Norton 360 Support Number Norton customer service email address Norton customer care no Norton 360 Tech Support Number @@!1-888-879-0163!! Norton 360 Support Number call Norton support chat with Norton support Norton customer support Norton antivirus customer service number 1.888-879-0163 Norton Norton 360 Tech Support Number @@!1-888-879-0163!! Norton 360 Support Number Norton call center Norton hq Norton office locations Norton support site Norton telephone number 1.888-879-0163 for customer support Norton customer service contact number 1.888-879-0163 Norton customer care Norton toll free number 1.888-879-0163 Norton security contact number 1.888-879-0163 contact Vipre Norton headquarters Norton 360 Tech Support Number @@!1-888-879-0163!! Norton 360 Support Number Norton customer service chat Norton customer service telephone number 1.888-879-0163 Norton Support phone number 1.888-879-0163 Norton customer support Norton customer service refund Norton login Norton locations Norton customer service number 1.888-879-0163 USA Norton locations Norton customer service email address Norton support site Norton 360 Tech Support Number @@!1-888-879-0163!! Norton 360 Support Number Norton technical support phone number 1.888-879-0163 Norton technical support live chat Norton technical support email address Norton technical support number 1.888-879-0163 Norton technical support number 1.888-879-0163 Norton 360 Tech Support Number @@!1-888-879-0163!! Norton 360 Support Number symantec technical support number 1.888-879-0163 Norton antivirus technical support number 1.888-879-0163 Norton customer support phone number 1.888-879-0163 Norton customer support number 1.888-879-0163 Norton customer support number 1.888-879-0163 Norton 360 Tech Support Number @@!1-888-879-0163!! Norton 360 Support Number Norton antivirus customer support number 1.888-879-0163 Norton locations Norton 360 Tech Support Number @@!1-888-879-0163!! Norton 360 Support Number Norton Support phone number 1.888-879-0163 Norton corporate phone number 1.888-879-0163 Norton 360 Tech Support Number @@!1-888-879-0163!! Norton 360 Support Number Norton customer service Support Norton technical support phone number 1.888-879-0163 Norton tech support phone number 1.888-879-0163 Norton tech support number 1.888-879-0163 Norton tech support number 1.888-879-0163 FREE ---------- components: Argument Clinic messages: 278065 nosy: goon369, larry priority: normal severity: normal status: open title: **<<<<<<<1^888`879~O163>>>>>>>> Norton antivirus customer support phone number versions: Python 3.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Oct 4 14:46:02 2016 From: report at bugs.python.org (Michael Felt) Date: Tue, 04 Oct 2016 18:46:02 +0000 Subject: [New-bugs-announce] [issue28361] BETA report: Python3.6 names pip pip3.6 (and why is the other name pip3) Message-ID: <1475606762.49.0.568305298556.issue28361@psf.upfronthosting.co.za> New submission from Michael Felt: a) pip is embedded in Python for some time. b) pip is called pip3.5 (with link to pip3) c) in Python3.6 pip is now called pip3.6 and linked to pip3 pip is pip - not pip3* because python is now called python3* pip is pip - currently version 8.1.2 - what does that have to do with pip3? IMHO - the name should just be pip p.s. in Python2.7 - pip is embedded, but not installed automatically. However, when you run the embedded install - pip is pip ---------- messages: 278075 nosy: Michael.Felt priority: normal severity: normal status: open title: BETA report: Python3.6 names pip pip3.6 (and why is the other name pip3) type: enhancement versions: Python 3.4, Python 3.5, Python 3.6, Python 3.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Oct 5 01:56:10 2016 From: report at bugs.python.org (Mariatta Wijaya) Date: Wed, 05 Oct 2016 05:56:10 +0000 Subject: [New-bugs-announce] [issue28362] Deprecation warning doesn't stand out enough Message-ID: <1475646970.65.0.933224265007.issue28362@psf.upfronthosting.co.za> New submission from Mariatta Wijaya: In documentation for python 3.3, the deprecation warning is rendered in a red box which is more eye-catching. eg https://docs.python.org/3.3/library/imp.html?highlight=imp#module-imp But since python 3.4 onwards, seems like the red box disappears and the deprecation warning message no longer stands out. for example https://docs.python.org/3.4/library/imp.html?highlight=imp#module-imp I kinda prefer like the older style (with the red box). ---------- assignee: docs at python components: Documentation messages: 278103 nosy: Mariatta, docs at python priority: normal severity: normal status: open title: Deprecation warning doesn't stand out enough versions: Python 3.4, Python 3.5, Python 3.6, Python 3.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Oct 5 09:19:07 2016 From: report at bugs.python.org (Michael Felt) Date: Wed, 05 Oct 2016 13:19:07 +0000 Subject: [New-bugs-announce] [issue28363] -D_LARGE_FILES not exported to modules (for AIX) Message-ID: <1475673547.47.0.62626707078.issue28363@psf.upfronthosting.co.za> New submission from Michael Felt: I was asked to assist with some problems with a "pip install numpy" and - maybe I am barking up the wrong tree. However, in the thread https://github.com/numpy/numpy/issues/8118 in short, if "python" is responsible for providing the -D flags "extensions" receive during the pip build process - the -D_LARGE_FILES also needs to be provided for AIX. DETAILS... you can see the complete command "pip build|install" reports as creating an error at the URL above - here is the critical part. xlc_r -I/opt/include -O2 -qmaxmem=-1 -qarch=pwr5 -q64 -I/opt/buildaix/includes -DNDEBUG -DHAVE_NPY_CONFIG_H=1 -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE=1 -D_LARGEFILE64_SOURCE=1 ... The key error is several of this form: "/usr/include/unistd.h", line 921.25: 1506-343 (S) Redeclaration of fclear64 differs from previous declaration on line 918 of "/usr/include/unistd.h". "/usr/include/unistd.h", line 921.25: 1506-050 (I) Return type "long long" in redeclaration is not compatible with the previous return type "long". "/usr/include/unistd.h", line 921.25: 1506-377 (I) The type "long long" of parameter 2 differs from the previous type "long". "/usr/include/unistd.h", line 922.25: 1506-343 (S) Redeclaration of fsync_range64 differs from previous declaration on line 919 of "/usr/include/unistd.h". "/usr/include/unistd.h", line 922.25: 1506-377 (I) The type "long long" of parameter 3 differs from the previous type "long". with the include file: Excerpt: +914 #ifdef _LARGE_FILES +915 #define fclear fclear64 +916 #define fsync_range fsync_range64 +917 #endif +918 extern off_t fclear(int, off_t); +919 extern int fsync_range(int, int, off_t, off_t); +920 #ifdef _LARGE_FILE_API +921 extern off64_t fclear64(int, off64_t); +922 extern int fsync_range64(int, int, off64_t, off64_t); +923 #endif After adding # export CFLAGS="-D_LARGE_FILES" pip install completes without any error messages (the command becomes): xlc_r -I/opt/include -O2 -qmaxmem=-1 -qarch=pwr5 -q64 -I/opt/buildaix/includes -DNDEBUG -DHAVE_NPY_CONFIG_H=1 -D_FILE_OFFSET_BITS=64 -D_LARGE_FILES -D_LARGEFILE_SOURCE=1 -D_LARGEFILE64_SOURCE=1 ... ---------- components: Extension Modules messages: 278124 nosy: Michael.Felt priority: normal severity: normal status: open title: -D_LARGE_FILES not exported to modules (for AIX) type: behavior versions: Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Oct 5 10:53:26 2016 From: report at bugs.python.org (Mateusz Klatt) Date: Wed, 05 Oct 2016 14:53:26 +0000 Subject: [New-bugs-announce] [issue28364] Windows - Popen (subprocess.py) does not call _handle.Close() at all Message-ID: <1475679206.56.0.813487481998.issue28364@psf.upfronthosting.co.za> New submission from Mateusz Klatt: _subprocess.TerminateProcess(self._handle, 1) is not enough, on windows need to call self._handle.Close() after that self._handle.Close() should be also called in __del__ - for the process es that ware not killed bu user, but terminated by themselves. To reproduce... run popen in loop and observe file descriptors usage (SysInternals... handle -s -p ) ---------- components: Library (Lib) messages: 278129 nosy: Mateusz Klatt priority: normal severity: normal status: open title: Windows - Popen (subprocess.py) does not call _handle.Close() at all versions: Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Oct 5 11:35:57 2016 From: report at bugs.python.org (A.J.) Date: Wed, 05 Oct 2016 15:35:57 +0000 Subject: [New-bugs-announce] [issue28365] 3.5.2 syntax issue Message-ID: <1475681757.64.0.722295974246.issue28365@psf.upfronthosting.co.za> New submission from A.J.: whenever I go to run a program no matter what I do it always says syntax error and highlights the 5 in the 3.5.2 version banner ---------- components: Windows messages: 278132 nosy: paul.moore, radialbeast, steve.dower, tim.golden, zach.ware priority: normal severity: normal status: open title: 3.5.2 syntax issue versions: Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Oct 5 11:56:10 2016 From: report at bugs.python.org (A.J.) Date: Wed, 05 Oct 2016 15:56:10 +0000 Subject: [New-bugs-announce] [issue28366] Syntax issue Message-ID: <1475682970.9.0.497885423929.issue28366@psf.upfronthosting.co.za> Changes by A.J. : ---------- files: image1.jpeg, image2.jpeg, unnamed, unnamed nosy: radialbeast priority: normal severity: normal status: open title: Syntax issue Added file: http://bugs.python.org/file44972/image1.jpeg Added file: http://bugs.python.org/file44973/unnamed Added file: http://bugs.python.org/file44974/image2.jpeg Added file: http://bugs.python.org/file44975/unnamed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Oct 5 15:22:47 2016 From: report at bugs.python.org (Andrey Smirnov) Date: Wed, 05 Oct 2016 19:22:47 +0000 Subject: [New-bugs-announce] [issue28367] Add more standard baud rate constants to "termios" Message-ID: <1475695367.16.0.283640170005.issue28367@psf.upfronthosting.co.za> New submission from Andrey Smirnov: Termios magic constants for the following baud rates: - B500000 - B576000 - B921600 - B1000000 - B1152000 - B1500000 - B2000000 - B2500000 - B3000000 - B3500000 - B4000000 in Linux are different between various architectures (i. e. PowerPC and Alpha are different from the rest of them). And because they are defined as per-processor symbols the only way to access them is if they are built-in as a part of CPython during its compilation. Attached is the patch implementing that ---------- components: Library (Lib) files: add-more-termios-baudrates.patch keywords: patch messages: 278145 nosy: Andrey Smirnov, twouters priority: normal severity: normal status: open title: Add more standard baud rate constants to "termios" type: enhancement Added file: http://bugs.python.org/file44977/add-more-termios-baudrates.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Oct 5 16:53:35 2016 From: report at bugs.python.org (Yury Selivanov) Date: Wed, 05 Oct 2016 20:53:35 +0000 Subject: [New-bugs-announce] [issue28368] Refuse monitoring processes if the child watcher has no loop attached Message-ID: <1475700815.84.0.114441761384.issue28368@psf.upfronthosting.co.za> New submission from Yury Selivanov: Proxy issue for https://github.com/python/asyncio/pull/391 ---------- assignee: yselivanov components: asyncio messages: 278148 nosy: gvanrossum, yselivanov priority: normal severity: normal stage: resolved status: open title: Refuse monitoring processes if the child watcher has no loop attached type: enhancement versions: Python 3.5, Python 3.6, Python 3.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Oct 5 17:47:34 2016 From: report at bugs.python.org (Yury Selivanov) Date: Wed, 05 Oct 2016 21:47:34 +0000 Subject: [New-bugs-announce] [issue28369] Raise RuntimeError when transport's FD is used with add_reader etc Message-ID: <1475704054.39.0.284138754743.issue28369@psf.upfronthosting.co.za> New submission from Yury Selivanov: Proxy issue for https://github.com/python/asyncio/pull/420 ---------- assignee: yselivanov components: asyncio messages: 278152 nosy: gvanrossum, yselivanov priority: normal severity: normal stage: resolved status: open title: Raise RuntimeError when transport's FD is used with add_reader etc type: enhancement versions: Python 3.5, Python 3.6, Python 3.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Oct 5 17:59:50 2016 From: report at bugs.python.org (Yury Selivanov) Date: Wed, 05 Oct 2016 21:59:50 +0000 Subject: [New-bugs-announce] [issue28370] Speedup asyncio.StreamReader.readexactly Message-ID: <1475704790.2.0.121613727751.issue28370@psf.upfronthosting.co.za> New submission from Yury Selivanov: Proxy for https://github.com/python/asyncio/pull/395 ---------- assignee: yselivanov components: asyncio messages: 278154 nosy: gvanrossum, yselivanov priority: normal severity: normal stage: resolved status: open title: Speedup asyncio.StreamReader.readexactly type: performance versions: Python 3.5, Python 3.6, Python 3.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Oct 5 18:26:04 2016 From: report at bugs.python.org (Yury Selivanov) Date: Wed, 05 Oct 2016 22:26:04 +0000 Subject: [New-bugs-announce] [issue28371] Deprecate passing asyncio.Handles to run_in_executor Message-ID: <1475706364.89.0.846891709474.issue28371@psf.upfronthosting.co.za> New submission from Yury Selivanov: Proxy issue for https://github.com/python/asyncio/issues/334 ---------- assignee: yselivanov components: asyncio messages: 278156 nosy: gvanrossum, yselivanov priority: normal severity: normal stage: resolved status: open title: Deprecate passing asyncio.Handles to run_in_executor type: enhancement versions: Python 3.5, Python 3.6, Python 3.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Oct 5 19:31:28 2016 From: report at bugs.python.org (Yury Selivanov) Date: Wed, 05 Oct 2016 23:31:28 +0000 Subject: [New-bugs-announce] [issue28372] Fix asyncio to support formatting of non-python coroutines Message-ID: <1475710288.73.0.330973256467.issue28372@psf.upfronthosting.co.za> New submission from Yury Selivanov: Like the ones that were compiled with Cython. ---------- assignee: yselivanov components: asyncio messages: 278159 nosy: gvanrossum, yselivanov priority: normal severity: normal stage: resolved status: open title: Fix asyncio to support formatting of non-python coroutines type: enhancement versions: Python 3.5, Python 3.6, Python 3.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Oct 6 05:13:03 2016 From: report at bugs.python.org (Arnon Yaari) Date: Thu, 06 Oct 2016 09:13:03 +0000 Subject: [New-bugs-announce] [issue28373] input() prints to original stdout even if sys.stdout is wrapped Message-ID: <1475745183.18.0.209614419228.issue28373@psf.upfronthosting.co.za> New submission from Arnon Yaari: When I wrap sys.stdout with a custom object that overrides the 'write' method, regular prints use the custom write method, but the input() function prints the prompt to the original stdout. This is broken on Python 3.5. Earlier versions work correctly. In the following example 'write' does nothing, so I expect no output, but the input() function outputs to stdout anyway: import sys class StreamWrapper(object): def __init__(self, wrapped): self.__wrapped = wrapped def __getattr__(self, name): # 'write' is overridden but for every other function, like 'flush', use the original wrapped stream return getattr(self.__wrapped, name) def write(self, text): pass orig_stdout = sys.stdout sys.stdout = StreamWrapper(orig_stdout) print('a') # this prints nothing input('b') # this should print nothing, but prints 'b' (in Python 3.5 and up only) Looks like this was broken in http://bugs.python.org/issue24402 . Adding the 'fileno' function from this issue fixes the problem, but it's just a workaround. This affects the colorama package: https://github.com/tartley/colorama/issues/103 ---------- messages: 278179 nosy: wiggin15 priority: normal severity: normal status: open title: input() prints to original stdout even if sys.stdout is wrapped versions: Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Oct 6 06:13:23 2016 From: report at bugs.python.org (Jan Welker) Date: Thu, 06 Oct 2016 10:13:23 +0000 Subject: [New-bugs-announce] [issue28374] SyntaxError: invalid token in python2.7/test/test_grammar.py Message-ID: <1475748803.26.0.293864566162.issue28374@psf.upfronthosting.co.za> New submission from Jan Welker: I compiled Python 2.7.12 from source and ran the tests unsuccessful. Compiling /usr/lib/python2.7/test/test_grammar.py ... File "/usr/lib/python2.7/test/test_grammar.py", line 80 self.assertEqual(1 if 1else 0, 1) ^ SyntaxError: invalid token It looks like a space (" ") is missing before the else. The same bug can be found in the next line 81. ---------- components: Tests messages: 278180 nosy: welker priority: normal severity: normal status: open title: SyntaxError: invalid token in python2.7/test/test_grammar.py versions: Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Oct 6 08:00:23 2016 From: report at bugs.python.org (Sebastian Rittau) Date: Thu, 06 Oct 2016 12:00:23 +0000 Subject: [New-bugs-announce] [issue28375] cgi.py spam in Apache server logs Message-ID: <1475755223.43.0.818852294498.issue28375@psf.upfronthosting.co.za> New submission from Sebastian Rittau: I am using cgi.py in WSGI applications, using Apache and mod_wsgi. Unfortunately cgi.py keeps spamming the error log with messages like the following: Exception ignored in: Traceback (most recent call last): File "/usr/lib/python3.5/cgi.py", line 566, in __del__ NameError: name 'AttributeError' is not defined This is mostly likely due to the warning about __del__ in , i.e. AttributeError will already have been cleaned at the time FieldStorage is collected. One workaround that seems to work for me is to cache AttributeError in the constructor of FieldStorage in self and use that attribute during __del__. ---------- messages: 278186 nosy: srittau priority: normal severity: normal status: open title: cgi.py spam in Apache server logs versions: Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Oct 6 08:00:27 2016 From: report at bugs.python.org (Oren Milman) Date: Thu, 06 Oct 2016 12:00:27 +0000 Subject: [New-bugs-announce] [issue28376] assertion failure in rangeobject.c Message-ID: <1475755227.93.0.551363347905.issue28376@psf.upfronthosting.co.za> New submission from Oren Milman: ------------ current state ------------ An assertion in Objects/rangeobject.c might fail: >>> type(iter(range(0))) >>> type(iter(range(0)))(1, 1, 0) Assertion failed: step != 0, file ..\Objects\rangeobject.c, line 895 This is caused by the lack of a check whether 'step' is zero, during the creation of a range_iterator object, in rangeiter_new. Note that during the creation of a range object, the function range_new does check that, by calling validate_step, which leads to the following behavior: >>> range(1, 1, 0) Traceback (most recent call last): File "", line 1, in ValueError: range() arg 3 must not be zero >>> ------------ proposed changes ------------ 1. In Objects/rangeobject.c in rangeiter_new: - in case 'step' is zero, raise a ValueError - in error messages, replace 'rangeiter' with 'range_iterator', as the latter is the name of the type in Python code 2. In Lib/test/test_range.py, add tests for calling the range_iterator type (i.e. creating a range_iterator object) ------------ diff ------------ The proposed patches diff file is attached. ------------ tests ------------ I ran 'python_d.exe -m test -j3' (on my 64-bit Windows 10) with and without the patches, and got quite the same output. (That also means my new tests in test_range passed.) The outputs of both runs are attached. ---------- components: Interpreter Core files: CPythonTestOutput.txt messages: 278187 nosy: Oren Milman priority: normal severity: normal status: open title: assertion failure in rangeobject.c type: crash versions: Python 3.7 Added file: http://bugs.python.org/file44984/CPythonTestOutput.txt _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Oct 6 09:14:23 2016 From: report at bugs.python.org (Weihong Guan) Date: Thu, 06 Oct 2016 13:14:23 +0000 Subject: [New-bugs-announce] [issue28377] struct.unpack of Bool Message-ID: <1475759663.29.0.378814371853.issue28377@psf.upfronthosting.co.za> New submission from Weihong Guan: According to the doc: For the '?' format character, the return value is either True or False. When packing, the truth value of the argument object is used. Either 0 or 1 in the native or standard bool representation will be packed, and any non-zero value will be True when unpacking. But it behaves more like & 1 operation. so False for even value, and True for odd value. unpack fmt '?H' should reqiure buff of length 3, same as 'H?', not 4. ---------- components: ctypes files: Screen Shot 2016-10-06 at 20.59.43.png messages: 278192 nosy: Weihong Guan priority: normal severity: normal status: open title: struct.unpack of Bool type: behavior versions: Python 2.7 Added file: http://bugs.python.org/file44987/Screen Shot 2016-10-06 at 20.59.43.png _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Oct 6 11:01:13 2016 From: report at bugs.python.org (Grzegorz Sikorski) Date: Thu, 06 Oct 2016 15:01:13 +0000 Subject: [New-bugs-announce] [issue28378] urllib2 does not handle cookies with `, ` Message-ID: <1475766073.34.0.905667468742.issue28378@psf.upfronthosting.co.za> New submission from Grzegorz Sikorski: I have a usecase when the server sends two cookies in separate `Set-Cookie` headers. One of the cookie includes a `,` (comma). It seems this is not handled properly, as the library always try to fold multiple headers with the same name into a single comma-separated string. While this is valid for other header fields, `Set-Cookie` should never be folded, as RFC 6265 says: ``` Origin servers SHOULD NOT fold multiple Set-Cookie header fields into a single header field. The usual mechanism for folding HTTP headers fields (i.e., as defined in [RFC2616]) might change the semantics of the Set-Cookie header field because the %x2C (",") character is used by Set-Cookie in a way that conflicts with such folding. ``` ---------- components: Library (Lib) messages: 278196 nosy: Grzegorz Sikorski priority: normal severity: normal status: open title: urllib2 does not handle cookies with `,` type: behavior _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Oct 6 14:15:04 2016 From: report at bugs.python.org (Xiang Zhang) Date: Thu, 06 Oct 2016 18:15:04 +0000 Subject: [New-bugs-announce] [issue28379] PyUnicode_CopyCharacters could lead to undefined behaviour Message-ID: <1475777704.53.0.510656129922.issue28379@psf.upfronthosting.co.za> New submission from Xiang Zhang: Currently PyUnicode_CopyCharacters doesn't check arguments thoroughly. This could lead to undefined behaviour or crash in debug mode. For example, from_start > len(from), how_many < 0. Another case is that when how_many > len(from), it will choose len(from) but this can still fail since from_start can > 0. The doc of it is also not perfect, it does not necessarily return 0 on success. ---------- components: Interpreter Core files: PyUnicode_CopyCharacters.patch keywords: patch messages: 278202 nosy: haypo, serhiy.storchaka, xiang.zhang priority: normal severity: normal stage: patch review status: open title: PyUnicode_CopyCharacters could lead to undefined behaviour type: behavior versions: Python 3.5, Python 3.6, Python 3.7 Added file: http://bugs.python.org/file44989/PyUnicode_CopyCharacters.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Oct 6 16:13:19 2016 From: report at bugs.python.org (Yannick Brehon) Date: Thu, 06 Oct 2016 20:13:19 +0000 Subject: [New-bugs-announce] [issue28380] Mock functions with autospec don't support assert_called_once, assert_called, assert_not_called Message-ID: <1475784799.56.0.716869368954.issue28380@psf.upfronthosting.co.za> New submission from Yannick Brehon: If one defines a mock for a function, using autospec=True, then the mock will correctly support assert_called_once_with(), among others, but not assert_called_once, assert_called, and assert_not_called. The attached file contains a fix for the issue. ---------- components: Library (Lib) files: fix_autospecced_mock_functions.patch keywords: patch messages: 278208 nosy: Yannick Brehon priority: normal severity: normal status: open title: Mock functions with autospec don't support assert_called_once, assert_called, assert_not_called type: behavior versions: Python 3.3, Python 3.4, Python 3.5, Python 3.6, Python 3.7 Added file: http://bugs.python.org/file44991/fix_autospecced_mock_functions.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Oct 6 17:18:28 2016 From: report at bugs.python.org (Josh Rosenberg) Date: Thu, 06 Oct 2016 21:18:28 +0000 Subject: [New-bugs-announce] [issue28381] Add a "starcaller" function Message-ID: <1475788708.75.0.957253302294.issue28381@psf.upfronthosting.co.za> New submission from Josh Rosenberg: Not sure if this is the right venue to propose this, but I'd like to propose adding a starcaller method to the standard library, either functools or operator (not sure if the proposal is more like partial or more like methodcaller). Basically, right now, when you want to take an existing function and call it repeatedly with preconstructed tuples using functional tools (e.g. sorted or groupby's key argument, multiprocessing.Pool's various map-like methods), you need to either have a special starmethod (e.g. Pool.map vs. Pool.starmap), or if Python doesn't provide one, you need use Python-defined functions (and for stuff like Pool, you can't even use lambda due to pickling issues, so you need to define the utility somewhere else). This means that you can't reuse builtins for stuff like the old "find runs of consecutive numbers" example from the itertools docs ( https://docs.python.org/2.6/library/itertools.html#examples ). In terms of behavior: starfunc = starcaller(func) would be behave roughly the same as the following (less efficient) Python 2 code: starfunc = functools.partial(apply, func) (and perhaps starcaller(func, kwonly=True) would behave like functools.partial(apply, func, ()) to extend it to dicts). This would make it possible to write the old consecutive numbers example: for k, g in groupby(enumerate(data), lambda (i,x):i-x): (which is no longer legal since Py3 banned sequence unpacking in arguments like that) as: for k, g in groupby(enumerate(data), starcaller(operator.sub)): It would also mean that instead of constantly needing to write new "star methods", you can just reuse existing functions with new batteries. For example, multiprocessing.Pool has a map and starmap function, but imap and imap_unordered have no starimap or starimap_unordered equivalents, which means using them at all requires you to def a function at trivial wrapper at global scope (possibly a long way away from the point of use) just to use an existing function ( def whydidineedthis(args): return existingfunction(*args) ). With starcaller, there is no need to add starimap and friends, because the same result is easily achieved with: with multiprocessing.Pool() as pool: for res in pool.imap(starcaller(existingfunction), ...): Is this a reasonable proposal? I could get an implementation ready fairly quickly, I'd just need to feedback on the name, which module it should be put in (functools or operator seem equally plausible) and whether the idea of using a keyword argument to the constructor makes more sense (kwonly=True) vs. expecting users to do functools.partial(starcaller(existingfunc), ()), vs. a separate class like doublestarcaller. ---------- components: Library (Lib) messages: 278212 nosy: josh.r priority: normal severity: normal status: open title: Add a "starcaller" function versions: Python 3.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Oct 6 19:20:37 2016 From: report at bugs.python.org (Alexis) Date: Thu, 06 Oct 2016 23:20:37 +0000 Subject: [New-bugs-announce] [issue28382] Possible deadlock after many multiprocessing.Process are launch Message-ID: <1475796037.28.0.0216232278478.issue28382@psf.upfronthosting.co.za> New submission from Alexis: I am launching a process inside a pool worker, using the multiprocessing module. After a while, a deadlock append when I am trying to join the process. Here is a simple version of the code: import sys, time, multiprocessing from multiprocessing.pool import ThreadPool def main(): # Launch 8 workers pool = ThreadPool(8) it = pool.imap(run, range(500)) while True: try: it.next() except StopIteration: break def run(value): # Each worker launch its own Process process = multiprocessing.Process(target=run_and_might_segfault, args=(value,)) process.start() while process.is_alive(): sys.stdout.write('.') sys.stdout.flush() time.sleep(0.1) # Will never join after a while, because of a mystery deadlock process.join() def run_and_might_segfault(value): print(value) if __name__ == '__main__': main() And here is a possible output: ~ python m.py ..0 1 ........8 .9 .......10 ......11 ........12 13 ........14 ........16 ........................................................................................ As you can see, process.is_alive() is alway true after few iterations, the process will never join. If I CTRL-C the script a get this stacktrace: Traceback (most recent call last): File "/usr/local/Cellar/python3/3.5.1/Frameworks/Python.framework/Versions/3.5/lib/python3.5/multiprocessing/pool.py", line 680, in next item = self._items.popleft() IndexError: pop from an empty deque During handling of the above exception, another exception occurred: Traceback (most recent call last): File "m.py", line 30, in main() File "m.py", line 9, in main it.next() File "/usr/local/Cellar/python3/3.5.1/Frameworks/Python.framework/Versions/3.5 /lib/python3.5/multiprocessing/pool.py", line 684, in next self._cond.wait(timeout) File "/usr/local/Cellar/python3/3.5.1/Frameworks/Python.framework/Versions/3.5 /lib/python3.5/threading.py", line 293, in wait waiter.acquire() KeyboardInterrupt Error in atexit._run_exitfuncs: Traceback (most recent call last): File "/usr/local/Cellar/python3/3.5.1/Frameworks/Python.framework/Versions/3.5 /lib/python3.5/multiprocessing/popen_fork.py", line 29, in poll pid, sts = os.waitpid(self.pid, flag) KeyboardInterrupt Using python 3.5.1 on macos, also tried with 3.5.2 with same issue. Same result on Debian. I tried using python 2.7, and it is working well. May be a python 3.5 issue only? Here is the link of the stackoverflow question: http://stackoverflow.com/questions/39884898/large-amount-of-multiprocessing-process-causing-deadlock ---------- components: Library (Lib) messages: 278221 nosy: Hadhoke priority: normal severity: normal status: open title: Possible deadlock after many multiprocessing.Process are launch type: behavior versions: Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Oct 7 00:37:23 2016 From: report at bugs.python.org (Kevin Norris) Date: Fri, 07 Oct 2016 04:37:23 +0000 Subject: [New-bugs-announce] [issue28383] __hash__ documentation recommends naive XOR to combine but this is suboptimal Message-ID: <1475815043.27.0.00299962010674.issue28383@psf.upfronthosting.co.za> New submission from Kevin Norris: The documentation for __hash__ contains this text: "The only required property is that objects which compare equal have the same hash value; it is advised to somehow mix together (e.g. using exclusive or) the hash values for the components of the object that also play a part in comparison of objects." The recommendation of "using exclusive or" is likely to result in programmers naively doing this: def __hash__(self): return hash(self.thing1) ^ hash(self.thing2) ^ hash(self.thing3) In the event that (say) self.thing1 and self.thing2 have almost or exactly the same hash (with "almost" referring to bitwise differences rather than integral distance), this wipes out most or all of the entropy from both values and greatly increases the likelihood of hash collisions. Indeed, Python's own tuple type does not do this (while it does use XOR, it also does some other math to ensure the bits are as mixed up as is practical).[1] Because the correct algorithm is both nontrivial to implement and already exists in the tuple type's __hash__, I propose that the documentation be updated to recommend something like the following: def __hash__(self): return hash((self.thing1, self.thing2, self.thing3)) One possible wording: "The only required property is that objects which compare equal have the same hash value; it is advised to mix together the hash values of the components of the object that also play a part in comparison of objects by packing them into a tuple and hashing the tuple: [code example]" [1]: https://hg.python.org/cpython/file/fca5c4a63251/Objects/tupleobject.c#l348 ---------- assignee: docs at python components: Documentation messages: 278229 nosy: Kevin.Norris, docs at python priority: normal severity: normal status: open title: __hash__ documentation recommends naive XOR to combine but this is suboptimal type: performance versions: Python 2.7, Python 3.3, Python 3.4, Python 3.5, Python 3.6, Python 3.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Oct 7 07:50:44 2016 From: report at bugs.python.org (Min RK) Date: Fri, 07 Oct 2016 11:50:44 +0000 Subject: [New-bugs-announce] [issue28384] hmac cannot be used with shake algorithms Message-ID: <1475841044.31.0.0614510494585.issue28384@psf.upfronthosting.co.za> New submission from Min RK: HMAC digest methods call inner.digest() with no arguments, but new-in-3.6 shake algorithms require a length argument. possible solutions: 1. add optional length argument to HMAC.[hex]digest, and pass through to inner hash object 2. set hmac.digest_size, and use that to pass through to inner hash object if inner hash object has digest_size == 0 3. give shake hashers a default value for `length` in digest methods (logically 32 for shake_256, 16 for shake_128, I think) test: import hmac, hashlib h = hmac.HMAC(b'secret', digestmod=hashlib.shake_256) h.hexdigest() # raises on self.inner.digest() requires length argument ---------- messages: 278235 nosy: minrk priority: normal severity: normal status: open title: hmac cannot be used with shake algorithms versions: Python 3.6, Python 3.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Oct 7 10:28:40 2016 From: report at bugs.python.org (=?utf-8?b?0JzQsNGA0Log0JrQvtGA0LXQvdCx0LXRgNCz?=) Date: Fri, 07 Oct 2016 14:28:40 +0000 Subject: [New-bugs-announce] [issue28385] Non-informative exception while formatting strings. Message-ID: <1475850520.09.0.230705784029.issue28385@psf.upfronthosting.co.za> New submission from ???? ?????????: $ python3 -c "'{0:s}'.format(b'qwe')" Traceback (most recent call last): File "", line 1, in TypeError: non-empty format string passed to object.__format__ Spent many hours to detect bug in my code. ---------- components: Library (Lib) messages: 278244 nosy: mmarkk priority: normal severity: normal status: open title: Non-informative exception while formatting strings. versions: Python 3.5, Python 3.6, Python 3.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Oct 7 12:50:32 2016 From: report at bugs.python.org (Daniel Moisset) Date: Fri, 07 Oct 2016 16:50:32 +0000 Subject: [New-bugs-announce] [issue28386] Improve documentation about tzinfo.dst(None) Message-ID: <1475859032.48.0.21993169144.issue28386@psf.upfronthosting.co.za> New submission from Daniel Moisset: The datetime module documentation[1] describes the tzinfo.dst method with a single "dt" argument without being too explicit about possible values for it. The implication is that dt should be a datetime object, but the implementation of time.dst() [2] actually calls tz.dst(None) (where tz is an instance of some tzinfo subclass), so this should clarify that None is an allowed value. Also, some of the examples given below in the same document (like LocalTimezone, GMT1, GMT2) actually have a related bug (it doesn't handle a None value correctly). So running >>> ... # copy the example from the documentation >>> t = time(tzinfo=LocalTimeZone()) >>> t.dst() crashes with an AttributeError: 'NoneType' object has no attribute 'year'. This kind of bugs have propagated to some other projects already [2]. Some of the other examples (like USTimeZone) seem to be OK What I think would be desirable here is: * A clarification on https://docs.python.org/3.5/library/datetime.html#datetime.tzinfo.dst indicating that dt is either a datetime or a None, in which situations it can be None, and what is the method supposed to return in this case. * Fixes in the code examples that reflect this I would offer a patch, but I'm not quite sure of what the desired behaviour is so I wouldn't know what to document :) [1] https://docs.python.org/3.5/library/datetime.html [2] https://github.com/python/cpython/blob/master/Modules/_datetimemodule.c#L3623 [3] https://github.com/django/django/blob/1.10.2/django/utils/timezone.py#L111 ---------- assignee: docs at python components: Documentation messages: 278256 nosy: Daniel Moisset, docs at python priority: normal severity: normal status: open title: Improve documentation about tzinfo.dst(None) _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Oct 7 15:32:57 2016 From: report at bugs.python.org (Sebastian Cufre) Date: Fri, 07 Oct 2016 19:32:57 +0000 Subject: [New-bugs-announce] [issue28387] double free in io.TextIOWrapper Message-ID: <1475868777.61.0.59647562301.issue28387@psf.upfronthosting.co.za> New submission from Sebastian Cufre: We have found that you can produce a crash when an instance of _io.TextIOWrapper is being deallocated while there's another thread invoking the garbage collector. I've attached a simple script that should reproduce the issue (textiowrapper_crash.py) Looking at the code of the _io module, we found that on the dealloc method of the TextIOWrapper class, it first tries to invoke the close method, then releases its internal members, after that removes itself from the garbage collector tracking and finally frees deallocates the remaining stuff. What happens, is that while releasing it's internal members, it might end up calling code that releases the interpreter lock (because its doing an operating system call), letting other threads execute. If for example the thread that comes in, invokes the garbage collector, on debug will raise an assert on gcmodule.c on line 351, where I understand it is complaining that it is tracking an object with refcount 0. In a release build, I suppose this goes on and will end up releasing the object (given it has a refcount of 0), and when the interrupted dealloc thread continues will end up freeing again itself which at some point produces a crash. Attached is a proposed fix for the issue in textio.c.patch, where the it the call to _PyObject_GC_UNTRACK is now done right after the call to the close method and before release its internal members. As a reference we have been able to reproduce this with Python 2.7.12 on Windows (i386) ---------- components: Extension Modules files: textiowrapper_crash.py messages: 278263 nosy: scufre priority: normal severity: normal status: open title: double free in io.TextIOWrapper type: crash versions: Python 2.7 Added file: http://bugs.python.org/file45004/textiowrapper_crash.py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Oct 7 19:56:50 2016 From: report at bugs.python.org (Ivan Levkivskyi) Date: Fri, 07 Oct 2016 23:56:50 +0000 Subject: [New-bugs-announce] [issue28388] Update documentation for typing module Message-ID: <1475884610.88.0.342172022706.issue28388@psf.upfronthosting.co.za> New submission from Ivan Levkivskyi: Here is the patch with updates according to recent changes in typing module and PEP 484: - most things are not classes now - outcome of parameterizing generics is cached - Union does not unify everything with Any - few minor fixes This patch also fixes http://bugs.python.org/issue27588 The attached patch is generated for 3.5 ---------- assignee: docs at python components: Documentation files: doc-typing-patch.diff keywords: patch messages: 278283 nosy: docs at python, gvanrossum, levkivskyi priority: normal severity: normal status: open title: Update documentation for typing module versions: Python 3.5, Python 3.6 Added file: http://bugs.python.org/file45007/doc-typing-patch.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Oct 8 07:53:34 2016 From: report at bugs.python.org (Attila Vangel) Date: Sat, 08 Oct 2016 11:53:34 +0000 Subject: [New-bugs-announce] [issue28389] xmlrpc.client HTTP proxy example code does not work Message-ID: <1475927614.18.0.277920882449.issue28389@psf.upfronthosting.co.za> New submission from Attila Vangel: Go to https://docs.python.org/3/library/xmlrpc.client.html Under '21.26.8. Example of Client Usage' -> 'To access an XML-RPC server through a HTTP proxy, you need to define a custom transport. The following example shows how:' copy the example code to a .py file (for me it is easier than REPL), e.g. xmlrpc_client_http_proxy_test.py This is the example code: import xmlrpc.client, http.client class ProxiedTransport(xmlrpc.client.Transport): def set_proxy(self, proxy): self.proxy = proxy def make_connection(self, host): self.realhost = host h = http.client.HTTPConnection(self.proxy) return h def send_request(self, connection, handler, request_body, debug): connection.putrequest("POST", 'http://%s%s' % (self.realhost, handler)) def send_host(self, connection, host): connection.putheader('Host', self.realhost) p = ProxiedTransport() p.set_proxy('proxy-server:8080') server = xmlrpc.client.ServerProxy('http://time.xmlrpc.com/RPC2', transport=p) print(server.currentTime.getCurrentTime()) I changed the 'proxy-server:8080' to '10.144.1.11:8080' which is a valid HTTP/HTTPS proxy in company I work for. Try to run this code: $ python3 xmlrpc_client_http_proxy_test.py Traceback (most recent call last): File "xmlrpc_client_http_proxy_test.py", line 21, in print(server.currentTime.getCurrentTime()) File "/usr/lib/python3.5/xmlrpc/client.py", line 1092, in __call__ return self.__send(self.__name, args) File "/usr/lib/python3.5/xmlrpc/client.py", line 1432, in __request verbose=self.__verbose File "/usr/lib/python3.5/xmlrpc/client.py", line 1134, in request return self.single_request(host, handler, request_body, verbose) File "/usr/lib/python3.5/xmlrpc/client.py", line 1146, in single_request http_conn = self.send_request(host, handler, request_body, verbose) File "xmlrpc_client_http_proxy_test.py", line 13, in send_request connection.putrequest("POST", 'http://%s%s' % (self.realhost, handler)) AttributeError: 'str' object has no attribute 'putrequest' Personally I don't like the idea of putting this amount of code to documentation: - as it seems, without automated tests running it, the code seems to rot, and gets outdated - I need to paste this boilerplate code to my application if I want this functionality. IMHO it would be much better to move this ProxiedTransport example code (after fixing it) to e.g. xmlrpc.client.HttpProxyTransport (or similar name) class. Details about python3: $ python3 Python 3.5.2 (default, Sep 10 2016, 08:21:44) [GCC 5.4.0 20160609] on linux Type "help", "copyright", "credits" or "license" for more information. >>> ---------- assignee: docs at python components: Documentation files: xmlrpc_client_http_proxy_test.py messages: 278291 nosy: avangel, docs at python priority: normal severity: normal status: open title: xmlrpc.client HTTP proxy example code does not work type: crash versions: Python 3.5 Added file: http://bugs.python.org/file45010/xmlrpc_client_http_proxy_test.py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Oct 8 08:59:14 2016 From: report at bugs.python.org (SilentGhost) Date: Sat, 08 Oct 2016 12:59:14 +0000 Subject: [New-bugs-announce] [issue28390] Wrong heading levels in whatsnew/3.6 Message-ID: <1475931554.95.0.299802036089.issue28390@psf.upfronthosting.co.za> New submission from SilentGhost: Couple of headings in whatsnew/3.6.rst have wrong level. The patch fixes this. ---------- assignee: docs at python components: Documentation files: headings.diff keywords: patch messages: 278296 nosy: SilentGhost, docs at python priority: normal severity: normal stage: patch review status: open title: Wrong heading levels in whatsnew/3.6 type: behavior versions: Python 3.6, Python 3.7 Added file: http://bugs.python.org/file45013/headings.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Oct 8 21:34:18 2016 From: report at bugs.python.org (Arno-Can Uestuensoez) Date: Sun, 09 Oct 2016 01:34:18 +0000 Subject: [New-bugs-announce] [issue28391] Multiple occurances of: Closing quotes separate words Message-ID: <1475976858.38.0.622085422041.issue28391@psf.upfronthosting.co.za> New submission from Arno-Can Uestuensoez: I am currently writing an extended options scanner including shlex-compatibility mode. So including numerous extended unittests for compatibility verification. I am not sure whether the following behaviour of shlex.split() is correct: Quote from manual: Parsing Rules: Closing quotes separate words ("Do"Separate is parsed as "Do" and Separate); Case-0: Works sopts = """-a "Do"Separate """ resx = ["-a", '"Do"', 'Separate', ] shlex.split(sopts,posix=False) assert res == resx Case-1: Fails - should work? sopts = """-a "Do"Separate"this" """ resx = ["-a", '"Do"', 'Separate', '"this"', ] shlex.split(sopts,posix=False) assert res == resx Case-2: Works - should fail? sopts = """-a "Do"Separate"this" """ #@UnusedVariable resx = ["-a", '"Do"', 'Separate"this"', ] shlex.split(sopts,posix=False) assert res == resx The Case-0 is as defined in the manuals. Is Case-1 or Case-2 the correct behaviour? Which of Case-1, Case-2 is an error? REMARK: I haven't found an eralier issue, so filing this here. ---------- components: Library (Lib) messages: 278329 nosy: Andrey.Kislyuk, acue, cvrebert, eric.araujo, eric.smith, ezio.melotti, python-dev, r.david.murray, robodan, vinay.sajip priority: normal severity: normal status: open title: Multiple occurances of: Closing quotes separate words type: behavior versions: Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Oct 9 04:02:45 2016 From: report at bugs.python.org (Arno-Can Uestuensoez) Date: Sun, 09 Oct 2016 08:02:45 +0000 Subject: [New-bugs-announce] [issue28392] shlex - non-posix-mode: error in Multiple occurances of quotes substrings/words Message-ID: <1476000165.64.0.597524292198.issue28392@psf.upfronthosting.co.za> New submission from Arno-Can Uestuensoez: See also 28391: Multiple occurances of: Closing quotes separate words The issue 28391 is accepted, as it is defined: Quotes *within* words are ignored, only a leading quoted string will result in a separate word. (That's recursive: try '"Do""This""Separate). So I implement for compatibility mode your proposal. But the example does not seem to work as expected, so seems to hint to a bug. Thus openning a seperate issue: snip--> import shlex sopts = """-a "Do""This""Separate" """ resx = ["-a", '"Do"', 'ThisSeparate', ] res=shlex.split(sopts,posix=False) print "sopts ="+str(sopts) print "resx ="+str(resx) print "res ="+str(res) assert res == resx """ Results in: sopts =-a "Do""This""Separate" resx =['-a', '"Do"', 'ThisSeparate'] res =['-a', '"Do"', '"This"', '"Separate"'] Traceback (most recent call last): File "shlex_demo.py", line 52, in assert res == resx AssertionError """ <--snip I also checked the variant with a trailing quoted word for completeness, which is not enclosed. Does not split at all: sopts =-a Do"SeparateThis" resx =['-a', 'Do', '"SeparateThis"'] res =['-a', 'Do"SeparateThis"'] ---------- components: Library (Lib) messages: 278351 nosy: Andrey.Kislyuk, acue, cvrebert, eric.araujo, eric.smith, ezio.melotti, python-dev, r.david.murray, robodan, vinay.sajip priority: normal severity: normal status: open title: shlex - non-posix-mode: error in Multiple occurances of quotes substrings/words type: behavior versions: Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Oct 9 07:39:09 2016 From: report at bugs.python.org (=?utf-8?q?Ville_Skytt=C3=A4?=) Date: Sun, 09 Oct 2016 11:39:09 +0000 Subject: [New-bugs-announce] [issue28393] Update encoding lookup docs wrt #27938 Message-ID: <1476013149.31.0.17921258936.issue28393@psf.upfronthosting.co.za> New submission from Ville Skytt?: The attached patch brings codecs docs up to date with respect to changes in #27938. ---------- assignee: docs at python components: Documentation files: codecs-doc.patch keywords: patch messages: 278354 nosy: docs at python, haypo, scop priority: normal severity: normal status: open title: Update encoding lookup docs wrt #27938 type: enhancement Added file: http://bugs.python.org/file45030/codecs-doc.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Oct 9 07:46:33 2016 From: report at bugs.python.org (=?utf-8?q?Ville_Skytt=C3=A4?=) Date: Sun, 09 Oct 2016 11:46:33 +0000 Subject: [New-bugs-announce] [issue28394] Spelling fixes Message-ID: <1476013593.44.0.181122480978.issue28394@psf.upfronthosting.co.za> Changes by Ville Skytt? : ---------- assignee: docs at python components: Documentation files: spelling.patch keywords: patch nosy: docs at python, scop priority: normal severity: normal status: open title: Spelling fixes type: enhancement Added file: http://bugs.python.org/file45031/spelling.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Oct 9 07:49:02 2016 From: report at bugs.python.org (=?utf-8?q?Ville_Skytt=C3=A4?=) Date: Sun, 09 Oct 2016 11:49:02 +0000 Subject: [New-bugs-announce] [issue28395] Remove unnecessary semicolons Message-ID: <1476013742.58.0.0976253320339.issue28395@psf.upfronthosting.co.za> Changes by Ville Skytt? : ---------- components: Tests files: semicolons.patch keywords: patch nosy: scop priority: normal severity: normal status: open title: Remove unnecessary semicolons type: enhancement Added file: http://bugs.python.org/file45032/semicolons.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Oct 9 07:50:43 2016 From: report at bugs.python.org (=?utf-8?q?Ville_Skytt=C3=A4?=) Date: Sun, 09 Oct 2016 11:50:43 +0000 Subject: [New-bugs-announce] [issue28396] Remove *.pyo references from man page Message-ID: <1476013843.61.0.385970802582.issue28396@psf.upfronthosting.co.za> Changes by Ville Skytt? : ---------- assignee: docs at python components: Documentation files: man-pyo.patch keywords: patch nosy: docs at python, scop priority: normal severity: normal status: open title: Remove *.pyo references from man page type: enhancement Added file: http://bugs.python.org/file45033/man-pyo.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Oct 9 08:32:05 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Sun, 09 Oct 2016 12:32:05 +0000 Subject: [New-bugs-announce] [issue28397] Faster index range checks Message-ID: <1476016325.64.0.828735989384.issue28397@psf.upfronthosting.co.za> New submission from Serhiy Storchaka: The expression for testing that some index is in half-open range from 0 to limit can be written as index >= 0 && index < limit or as (size_t)index < (size_t)limit The latter form generates simpler machine code. This is idiomatic code, it is used in many C and C++ libraries (including C++ stdlib implementations). It already is used in CPython (in deque implementation). Proposed patch rewrites index range checks in more efficient way. The patch was generated automatically by coccinelle script, and then manually cleaned up. ---------- components: Extension Modules, Interpreter Core files: check_index.patch keywords: patch messages: 278355 nosy: serhiy.storchaka priority: normal severity: normal stage: patch review status: open title: Faster index range checks type: performance versions: Python 3.7 Added file: http://bugs.python.org/file45034/check_index.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Oct 9 11:49:06 2016 From: report at bugs.python.org (Xiang Zhang) Date: Sun, 09 Oct 2016 15:49:06 +0000 Subject: [New-bugs-announce] [issue28398] Return singleton empty string in _PyUnicode_FromASCII Message-ID: <1476028146.3.0.529072270103.issue28398@psf.upfronthosting.co.za> New submission from Xiang Zhang: Right now in _PyUnicode_FromASCII, it only optimises for size 1 not size 0. All other places getting the same situation in unicodeobject.c do both. ---------- files: _PyUnicode_FromASCII.patch keywords: patch messages: 278364 nosy: haypo, serhiy.storchaka, xiang.zhang priority: normal severity: normal stage: patch review status: open title: Return singleton empty string in _PyUnicode_FromASCII type: enhancement versions: Python 3.7 Added file: http://bugs.python.org/file45038/_PyUnicode_FromASCII.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Oct 9 12:13:45 2016 From: report at bugs.python.org (Yury Selivanov) Date: Sun, 09 Oct 2016 16:13:45 +0000 Subject: [New-bugs-announce] [issue28399] Remove UNIX socket from FS before binding Message-ID: <1476029625.22.0.715081570912.issue28399@psf.upfronthosting.co.za> New submission from Yury Selivanov: Proxy for https://github.com/python/asyncio/pull/441 ---------- assignee: yselivanov components: asyncio messages: 278367 nosy: gvanrossum, yselivanov priority: normal severity: normal stage: resolved status: open title: Remove UNIX socket from FS before binding type: enhancement versions: Python 3.5, Python 3.6, Python 3.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Oct 9 13:21:42 2016 From: report at bugs.python.org (Xiang Zhang) Date: Sun, 09 Oct 2016 17:21:42 +0000 Subject: [New-bugs-announce] [issue28400] Remove uncessary checks in unicode_char and resize_copy Message-ID: <1476033702.7.0.657105257763.issue28400@psf.upfronthosting.co.za> New submission from Xiang Zhang: In resize_copy we don't need to PyUnicode_READY(unicode) since when it's not PyUnicode_WCHAR_KIND it should be ready. In unicode_char, PyUnicode_1BYTE_KIND is handled by get_latin1_char. ---------- components: Interpreter Core files: unicode_char_and_resize_copy.patch keywords: patch messages: 278379 nosy: haypo, serhiy.storchaka, xiang.zhang priority: normal severity: normal stage: patch review status: open title: Remove uncessary checks in unicode_char and resize_copy type: enhancement versions: Python 3.7 Added file: http://bugs.python.org/file45039/unicode_char_and_resize_copy.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Oct 9 13:31:32 2016 From: report at bugs.python.org (Stefano Rivera) Date: Sun, 09 Oct 2016 17:31:32 +0000 Subject: [New-bugs-announce] [issue28401] Don't support the PEP384 stable ABI in pydebug builds Message-ID: <1476034292.17.0.316209799179.issue28401@psf.upfronthosting.co.za> New submission from Stefano Rivera: setup.py build for a library using py_limited_api will always generate a stable ABI tagged shared library, even under the pydebug interpreter. This means that extensions that are built for a pydebug interpreter may be accidentally (and brokenly) imported in a non-dbg interpreter and vice-versa. e.g. in python-librtmp, with cffi 1.8.3: $ python3-dbg setup.py build ... x86_64-linux-gnu-gcc -pthread -shared -Wl,-O1 -Wl,-Bsymbolic-functions -Wl,-z,relro -Wl,-z,relro -g -Og -fdebug-prefix-map=/build/python3.5-H9Fri6/python3.5-3.5.2=. -fstack-protector-strong -Wformat -Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2 build/temp.linux-x86_64-3.5-pydebug/build/temp.linux-x86_64-3.5-pydebug/librtmp._librtmp.o -lrtmp -o build/lib.linux-x86_64-3.5-pydebug/librtmp/_librtmp.abi3.so Then: $ cd build/lib.linux-x86_64-3.5-pydebug $ python3 -c 'import librtmp' Traceback (most recent call last): File "", line 1, in File "/tmp/python-librtmp-0.3.0/build/lib.linux-x86_64-3.5-pydebug/librtmp/__init__.py", line 8, in from ._librtmp import ffi, lib as librtmp ImportError: /tmp/python-librtmp-0.3.0/build/lib.linux-x86_64-3.5-pydebug/librtmp/_librtmp.abi3.so: undefined symbol: _Py_RefTotal setuptools decides whether to use the stable ABI, by looking at imp.get_suffixes(). And obviously, the importer is looking at that too. So, the stable ABI tag should simply not be in there. PEP3149 agrees with this. It has this quote from Martin v. L?wis: --with-pydebug would not be supported by the stable ABI because this changes the layout of PyObject , which is an exposed structure. So, here's a patch, to disable support for the stable ABI under pydebug builds. ---------- components: Library (Lib) files: pep384-pydbg.patch keywords: patch messages: 278381 nosy: stefanor priority: normal severity: normal status: open title: Don't support the PEP384 stable ABI in pydebug builds type: behavior versions: Python 3.3, Python 3.4, Python 3.5, Python 3.6, Python 3.7 Added file: http://bugs.python.org/file45040/pep384-pydbg.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Oct 9 23:17:50 2016 From: report at bugs.python.org (Steve Dower) Date: Mon, 10 Oct 2016 03:17:50 +0000 Subject: [New-bugs-announce] [issue28402] Add signed catalog files for stdlib on Windows Message-ID: <1476069470.02.0.829638678389.issue28402@psf.upfronthosting.co.za> New submission from Steve Dower: On Windows, we sign all binaries with the PSF code signing certificate. We can also sign all the standard library and tools .py files using a catalog, which will put the hashes of the original files into a signed bundle. This can then be validated by users (e.g. using "signtool.exe verify") at any point after installation. Worth noting that the OS does not automatically verify signatures in a catalog file. It's only worthwhile doing this for files that may end up on a production machine - essentially, those files included in lib.msi and tools.msi (not test.msi, dev.msi or tcltk.msi). ---------- assignee: steve.dower components: Windows messages: 278400 nosy: paul.moore, steve.dower, tim.golden, zach.ware priority: normal severity: normal status: open title: Add signed catalog files for stdlib on Windows type: enhancement versions: Python 3.6, Python 3.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Oct 9 23:52:12 2016 From: report at bugs.python.org (Nick Coghlan) Date: Mon, 10 Oct 2016 03:52:12 +0000 Subject: [New-bugs-announce] [issue28403] Migration RFE: optional warning for implicit unicode conversions Message-ID: <1476071532.35.0.73217429855.issue28403@psf.upfronthosting.co.za> New submission from Nick Coghlan: Some of the hardest compatibility issues to track down in Python 3 migrations are those where existing code is depending on an implicit str->unicode promotion something in the depths of a support library (or sometimes even the standard library - the context where this came up relates to some apparent misbehaviour in the standard library). In other cases, just being able to rule implicit conversions out as a possible contributing factor can be helpful in finding the real problem. It's technically already possible to hook implicit conversions by adjusting (or shadowing) the site.py module and replacing the default "ascii" encoding with one that emits a warning whenever you rely on it: http://washort.twistedmatrix.com/2010/11/unicode-in-python-and-how-to-prevent-it.html However, actually setting that up is a bit tricky, since we deliberately drop "sys.setdefaultencoding" from the sys module in the default site module. That means requesting warnings for implicit conversions requires doing the following: 1. Finding the "ascii_with_warnings" codec above (or writing your own) 2. Learning one of the following 3 tricks for overriding the default encoding: 2a. Run with "-S" and call sys.setdefaultencoding post-startup 2b. Edit the actual system site.py in a container or other test environment 2c. Shadow site.py with your own modified copy 3. Run your tests or application with the modified default encoding If we wanted to make that easier for folks migrating, the first step would be to provide the "ascii_with_warnings" codec by default in Python 2.7 (perhaps as "_ascii_with_warnings", since it isn't intended for general use, it's just a migration helper) The second would be to provide a way to turn it on that doesn't require fiddling with the site module. The simplest option there would be to always enable it under `-3`. The argument against the simple option is that I'm not sure how noisy it would be by default - there are some standard library modules (e.g. URL processing) where we still rely on implicit encoding and decoding in Python 2, but have separate code paths in Python 3. Since we don't have -X options in Python 2, the second simplest alternative would be to leave `sys.setdefaultencoding` available when running under `-3`: that way folks could more easily opt in to enabling the "ascii_with_warnings" codec selectively (e.g. via a context manager), rather than always having it enabled. ---------- messages: 278402 nosy: ncoghlan priority: normal severity: normal status: open title: Migration RFE: optional warning for implicit unicode conversions type: enhancement versions: Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Oct 10 08:14:22 2016 From: report at bugs.python.org (=?utf-8?q?Jos=C3=A9_Manuel?=) Date: Mon, 10 Oct 2016 12:14:22 +0000 Subject: [New-bugs-announce] [issue28404] Logging SyslogHandler not appending '\n' to the end Message-ID: <1476101662.48.0.994997122347.issue28404@psf.upfronthosting.co.za> New submission from Jos? Manuel: I'm using SyslogHandler from logging.handlers to send syslog messages to a Fluentd input (https://github.com/fluent/fluentd/blob/master/lib/fluent/plugin/in_syslog.rb), both in TCP and UDP. UDP works fine, but TCP does not work. The "problem" is that the handler is not ending messages with a new line '\n' character (I realized that using tcpdump). I've temporarily added this to line 855 of handlers.py: msg = prio + msg + '\n' And now is working. Now I'm confused because maybe this is not an issue but a problem of Fluentd. For the time, I will create a new class extending SyslogHandler and override the emit function. Thank you for your time. ---------- components: Library (Lib) messages: 278412 nosy: elelement priority: normal severity: normal status: open title: Logging SyslogHandler not appending '\n' to the end type: behavior versions: Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Oct 10 10:46:48 2016 From: report at bugs.python.org (Masayuki Yamamoto) Date: Mon, 10 Oct 2016 14:46:48 +0000 Subject: [New-bugs-announce] [issue28405] Compile error on Modules/_futuresmodule.c Message-ID: <1476110808.48.0.333996496956.issue28405@psf.upfronthosting.co.za> New submission from Masayuki Yamamoto: I tried to build cpython on cygwin (vista x86). Core interpretor has built to success, but '_futures' extension module has failed (compile error on Modules/_futuresmodule.c:946 ). It has occured since f8815001a390 part of build log: $ uname -a CYGWIN_NT-6.0 masayuki-PC 2.6.0(0.304/5/3) 2016-08-31 14:27 i686 Cygwin $ ./configure --without-threads --prefix=/opt/py37 $ LANG=C make (snip) building '_futures' extension gcc -Wno-unused-result -Wsign-compare -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes -std=c99 -Wextra -Wno-unused-result -Wno-unused-parameter -Wno-missing-field-initializers -I./Include -I/opt/py37/include -I. -I/usr/local/include -I/home/masayuki/var/repos/py37-work01/Include -I/home/masayuki/var/repos/py37-work01 -c /home/masayuki/var/repos/py37-work01/Modules/_futuresmodule.c -o build/temp.cygwin-2.6.0-i686-3.7/home/masayuki/var/repos/py37-work01/Modules/_futuresmodule.o gcc -shared -Wl,--enable-auto-image-base build/temp.cygwin-2.6.0-i686-3.7/home/masayuki/var/repos/py37-work01/Modules/_futuresmodule.o -L. -L/opt/py37/lib -L/usr/local/lib -L. -lpython3.7m -o build/lib.cygwin-2.6.0-i686-3.7/_futures.dll build/temp.cygwin-2.6.0-i686-3.7/home/masayuki/var/repos/py37-work01/Modules/_futuresmodule.o: In function `new_future_iter': /home/masayuki/var/repos/py37-work01/Modules/_futuresmodule.c:946: undefined reference to `_PyGC_generation0' /home/masayuki/var/repos/py37-work01/Modules/_futuresmodule.c:946: undefined reference to `_PyGC_generation0' /home/masayuki/var/repos/py37-work01/Modules/_futuresmodule.c:946: undefined reference to `_PyGC_generation0' collect2: error: ld returned 1 exit status (snip) ---------- components: Build, Extension Modules messages: 278418 nosy: bquinlan, masamoto priority: normal severity: normal status: open title: Compile error on Modules/_futuresmodule.c type: compile error versions: Python 3.6, Python 3.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Oct 10 11:41:22 2016 From: report at bugs.python.org (Larry Hastings) Date: Mon, 10 Oct 2016 15:41:22 +0000 Subject: [New-bugs-announce] [issue28406] Possible PyUnicode_InternInPlace() edge-case bug Message-ID: <1476114082.63.0.695607000765.issue28406@psf.upfronthosting.co.za> New submission from Larry Hastings: A visual inspection of PyUnicode_InternInPlace() suggests there might be a rare edge-case bug lurking there. Specifically, the bug has to do with "interned mortal" strings. Interned mortal strings are stored in the static "interned" dictionary, with their key and value set to the same string. (If "x" is interned, then in the interned dictionary "x" is set to "x".) Under normal circumstances, these two references would keep the string alive forever. However, in order for the string to be *mortal*, the unicode object then DECREFs the string twice so the references in the "interned" dict no longer "count". When the refcnt reaches 0, and the string is being destroyed, unicode_dealloc() temporarily resurrects the object, bumping its reference count up to 3. It then removes the string from the interned dict and destroys it as normal. The actual intern substitution happens in a function called PyUnicode_InternInPlace(). This function looks the string up in the "interned" dictionary, and if the string is there it substitutes in the interned version from the dictionary. There's a curious comment in that function: /* It might be that the GetItem call fails even though the key is present in the dictionary, namely when this happens during a stack overflow. */ Py_ALLOW_RECURSION t = PyDict_GetItem(interned, s); Py_END_ALLOW_RECURSION If t is NULL, then PyUnicode_InternInPlace() goes on to set t in the interned dictionary, reduces the refcnt by 2, etc etc. The problem: if t is in the dictionary, but PyDict_GetItem() fails (during a stack overflow?), then the subsequent PyDict_SetItem() will *overwrite* the existing interned string. Which means the "interned" dict will drop its two references, which means two REFCNTs. If there were only 1 or 2 extant references to this string, it means the string will be immediately dealloc'd, *even though the string was still in use*. I suppose this is already such a speculative condition that it's probably not worrying over. If PyDict_GetItem fails due to stack overflow, perhaps the Python process is doomed to fail soon anyway. Perhaps PyDict_SetItem has no chance of working. But it *seems* like this code is intended to function correctly even when PyDict_GetItem fails due to stack overflow, and I suspect it won't. ---------- components: Interpreter Core messages: 278421 nosy: larry priority: low severity: normal stage: test needed status: open title: Possible PyUnicode_InternInPlace() edge-case bug type: behavior versions: Python 3.5, Python 3.6, Python 3.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Oct 10 13:06:00 2016 From: report at bugs.python.org (Dillon Brock) Date: Mon, 10 Oct 2016 17:06:00 +0000 Subject: [New-bugs-announce] [issue28407] Improve coverage of email.utils.make_msgid() Message-ID: <1476119160.34.0.206786092221.issue28407@psf.upfronthosting.co.za> New submission from Dillon Brock: There were 2 lines of email.utils.make_msgid() that were not covered (lines 202 and 204 of Lib/email/utils.py), so I wrote a quick patch to cover them. ---------- components: Tests, email files: make_msgid_coverage.patch keywords: patch messages: 278430 nosy: barry, dillon.brock, r.david.murray priority: normal severity: normal status: open title: Improve coverage of email.utils.make_msgid() type: enhancement versions: Python 3.7 Added file: http://bugs.python.org/file45047/make_msgid_coverage.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Oct 10 13:13:36 2016 From: report at bugs.python.org (Xiang Zhang) Date: Mon, 10 Oct 2016 17:13:36 +0000 Subject: [New-bugs-announce] [issue28408] Fix redundant code and memory leak in _PyUnicodeWriter_Finish Message-ID: <1476119616.69.0.933399987937.issue28408@psf.upfronthosting.co.za> New submission from Xiang Zhang: _PyUnicodeWriter_Finish gets 2 problems now: 1. It has two same branches handling empty strings which is redundant. 2. It may leak the inner buffer object when resize_compact fails. When resize_compact fails, the buffer object is left untouched. Then the writer itself is freed and the buffer is leaked. ---------- components: Interpreter Core files: _PyUnicodeWriter_Finish.patch keywords: patch messages: 278434 nosy: haypo, serhiy.storchaka, xiang.zhang priority: normal severity: normal stage: patch review status: open title: Fix redundant code and memory leak in _PyUnicodeWriter_Finish type: behavior versions: Python 3.5, Python 3.6, Python 3.7 Added file: http://bugs.python.org/file45048/_PyUnicodeWriter_Finish.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Oct 10 13:37:52 2016 From: report at bugs.python.org (Charalampos Stratakis) Date: Mon, 10 Oct 2016 17:37:52 +0000 Subject: [New-bugs-announce] [issue28409] test.regrtest does not support multiple -x flags Message-ID: <1476121072.74.0.870952515909.issue28409@psf.upfronthosting.co.za> New submission from Charalampos Stratakis: Until python3.6.0a04 it was possible to pass multiple times the -x option at regrtest. However since the 3.6.0b1 when trying the same thing I get an error. Test names are random. python3 -m test.regrtest -x test_venv -x test_gdb usage: python -m test [options] [test_name1 [test_name2 ...]] python path/to/Lib/test/regrtest.py [options] [test_name1 [test_name2 ...]] regrtest.py: error: unrecognized arguments: test_gdb If however I omit the second -x, the tests run fine and correctly exclude the specific tests. Was the change intentional or a side effect from something else? ---------- components: Tests messages: 278435 nosy: cstratak priority: normal severity: normal status: open title: test.regrtest does not support multiple -x flags versions: Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Oct 10 15:50:27 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Mon, 10 Oct 2016 19:50:27 +0000 Subject: [New-bugs-announce] [issue28410] Add convenient C API for "raise ... from ..." Message-ID: <1476129027.52.0.516927582831.issue28410@psf.upfronthosting.co.za> New submission from Serhiy Storchaka: Sometimes after catching an exception we need to raise new exception of specific type, but save the information about current exception. In Python the syntax "raise ... from ..." serves this purpose (PEP 3134). But in C the code that implements this is too cumbersome. Proposed patch adds private convenient function that raises an exception and sets previously raised exception as its __context__ and __cause__ attributes. This is a generalized version of gen_chain_runtime_error() from Objects/genobject.c. It could be reused in three other places: Objects/abstract.c, Objects/unicodeobject.c, and Modules/zipimport.c (currently only __context__ is set, but setting __cause__ looks preferable), and in new code for issue28214. Maybe there are other opportunities. ---------- components: Interpreter Core files: _PyErr_FormatFromCause.patch keywords: patch messages: 278441 nosy: haypo, serhiy.storchaka, yselivanov priority: normal severity: normal stage: patch review status: open title: Add convenient C API for "raise ... from ..." type: enhancement versions: Python 3.5, Python 3.6, Python 3.7 Added file: http://bugs.python.org/file45050/_PyErr_FormatFromCause.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Oct 10 18:33:03 2016 From: report at bugs.python.org (Eric Snow) Date: Mon, 10 Oct 2016 22:33:03 +0000 Subject: [New-bugs-announce] [issue28411] Eliminate PyInterpreterState.modules. Message-ID: <1476138783.81.0.661524291989.issue28411@psf.upfronthosting.co.za> New submission from Eric Snow: tl;dr PyInterpreterState does not need a "modules" field. Attached is a patch that removes it. During interpreter startup [1] the sys module is imported using the same C API [2] as any other builtin module. That API only requires one bit of import state, sys.modules. Obviously, while the sys module is being imported, sys.modules does not exist yet. To accommodate this situation, PyInterpreterState has a "modules" field. The problem is that PyInterpreterState.modules remains significant in the C-API long after it is actually needed during startup. This creates the potential for sys.modules and PyInterpreterState.modules to be out of sync. Currently I'm working on an encapsulation of the import state. PyInterpreterState.modules complicates the scene enough that I'd like to see it go away. The attached patch does so by adding private C-API functions that take a modules arg, rather than getting it from the interpreter state. These are used during interpreter startup, rendering PyInterpreterState.modules unnecessary and allowing sys.modules to become the single source of truth. If this patch lands, we can close issue12633. [1] see _Py_InitializeEx_Private() and Py_NewInterpreter() in Python/pylifecycle.c [2] see PyModule_Create2() and _PyImport_FindBuiltin() in Python/import.c ---------- components: Interpreter Core files: drop-interp-modules.diff keywords: patch messages: 278445 nosy: brett.cannon, eric.snow, ncoghlan priority: normal severity: normal stage: patch review status: open title: Eliminate PyInterpreterState.modules. versions: Python 3.7 Added file: http://bugs.python.org/file45052/drop-interp-modules.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Oct 10 18:57:46 2016 From: report at bugs.python.org (Michael Partridge) Date: Mon, 10 Oct 2016 22:57:46 +0000 Subject: [New-bugs-announce] [issue28412] os.path.splitdrive documentation out of date Message-ID: <1476140266.77.0.441294579348.issue28412@psf.upfronthosting.co.za> New submission from Michael Partridge: ntpath.splitdrive was updated in patch 26ec6248ee8b. (I think this was released in 2.7.8.) This changes the behaviour of splitdrive for UNC style paths. Previously: >>> ntpath.splitdrive(r'\\nancy\foo\bar') ('', '\\\\nancy\\foo\\bar') >>> Now: >>> ntpath.splitdrive(r'\\nancy\foo\bar') ('\\\\nancy\\foo', '\\bar') >>> The documentation should be updated to say the same. ---------- assignee: docs at python components: Documentation messages: 278446 nosy: docs at python, snooter priority: normal severity: normal status: open title: os.path.splitdrive documentation out of date type: behavior versions: Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Oct 11 02:02:34 2016 From: report at bugs.python.org (Matthias Klose) Date: Tue, 11 Oct 2016 06:02:34 +0000 Subject: [New-bugs-announce] [issue28413] unprefixed global symbol freegrammar Message-ID: <1476165754.08.0.234164363206.issue28413@psf.upfronthosting.co.za> New submission from Matthias Klose: changeset 103932 introduced an unprefixed global symbol freegrammar. Please make it local, or prefix it with _Py_. ---------- messages: 278463 nosy: benjamin.peterson, doko priority: normal severity: normal stage: needs patch status: open title: unprefixed global symbol freegrammar versions: Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Oct 11 04:02:36 2016 From: report at bugs.python.org (Anton Sychugov) Date: Tue, 11 Oct 2016 08:02:36 +0000 Subject: [New-bugs-announce] [issue28414] SSL match_hostname fails for internationalized domain names Message-ID: <1476172956.13.0.85556243538.issue28414@psf.upfronthosting.co.za> New submission from Anton Sychugov: In accordance with http://tools.ietf.org/html/rfc6125#section-6.4.2: "If the DNS domain name portion of a reference identifier is an internationalized domain name, then an implementation MUST convert any U-labels [IDNA-DEFS] in the domain name to A-labels before checking the domain name." The question is: Where in python stdlib should it to convert domain name from U-label to A-label? Should it be in ssl._dnsname_match, e.g.: ... hostname = hostname.encode('idna').decode('utf-8') ... Or should it be at ssl._dnsname_match caller level? I found that error appears after using ssl.SSLContext.wrap_bio, which in turn uses internal newPySSLSocket, which in turn always decode server_hostname through: PySSLSocket *self; ... PyObject *hostname = PyUnicode_Decode(server_hostname, strlen(server_hostname), "idna", "strict"); ... self->server_hostname = hostname; In this way, SSLSocket always contains U-label in its server_hostname field, and ssl._dnsname_match falis with "ssl.CertificateError: hostname ... doesn't match either of ..." And i don't understand where is a bug, or is it a bug. ---------- components: asyncio messages: 278466 nosy: abracadaber, gvanrossum, yselivanov priority: normal severity: normal status: open title: SSL match_hostname fails for internationalized domain names versions: Python 3.4, Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Oct 11 04:56:20 2016 From: report at bugs.python.org (Xiang Zhang) Date: Tue, 11 Oct 2016 08:56:20 +0000 Subject: [New-bugs-announce] [issue28415] PyUnicode_FromFromat interger format handling different from printf about zeropad Message-ID: <1476176180.11.0.398413685253.issue28415@psf.upfronthosting.co.za> New submission from Xiang Zhang: Although declared *exactly equivalent* to printf in the doc, PyUnicode_FromFormat could generate different result from printf with the same format. For example: from ctypes import pythonapi, py_object, c_int f = getattr(pythonapi, 'PyUnicode_FromFormat') f.restype = py_object f(b'%010.5d', c_int(100)) '0000000100' while printf outputs: printf("%010.5d\n", 100); 00100 I use both gcc and clang to compile and get the same result. gcc gives me a warning: warning: '0' flag ignored with precision and ?%d? gnu_printf format I am not sure this should be fixed. It seems the change could break backwards compatibility. ---------- components: Interpreter Core messages: 278467 nosy: haypo, serhiy.storchaka, xiang.zhang priority: normal severity: normal status: open title: PyUnicode_FromFromat interger format handling different from printf about zeropad type: behavior versions: Python 3.5, Python 3.6, Python 3.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Oct 11 12:14:11 2016 From: report at bugs.python.org (Carl Witty) Date: Tue, 11 Oct 2016 16:14:11 +0000 Subject: [New-bugs-announce] [issue28416] defining persistent_id in _pickle.Pickler subclass causes reference cycle Message-ID: <1476202451.78.0.408768500752.issue28416@psf.upfronthosting.co.za> New submission from Carl Witty: On creation, _pickle.Pickler caches any .persistent_id() method defined by a subclass (in the pers_func field of PicklerObject). This causes a reference cycle (pickler -> bound method of pickler -> pickler), so the pickler is held in memory until the next cycle collection. (Then, because of the pickler's memo table, any objects that this pickler has pickled are also held until the next cycle collection.) Looking at the source code, it looks like the same thing would happen with _pickle.Unpickler and .persistent_load(), but I haven't tested it. Any fix should be applied to both classes. I've attached a test file; when I run it with "python3 pickle_reference_cycle.py", all 3 print statements are executed. I would prefer it if "Oops, still here" was not printed. (I'm using Debian's python3.5 package, version 3.5.2-4 for amd64, but I believe the problem occurs across many versions of python3, looking at the history of _pickle.c.) I don't see how to fix the problem with no performance impact. (Setting pers_func at the beginning of dump() and clearing it at the end would have approximately the same performance in the common case that only one object was dumped per pickler, but would be slower when dumping multiple objects.) If you decide not to fix the problem, could you at least describe the problem and a workaround in the documentation? ---------- components: Extension Modules files: pickle_reference_cycle.py messages: 278495 nosy: cwitty priority: normal severity: normal status: open title: defining persistent_id in _pickle.Pickler subclass causes reference cycle type: behavior versions: Python 3.5 Added file: http://bugs.python.org/file45058/pickle_reference_cycle.py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Oct 11 12:19:38 2016 From: report at bugs.python.org (Xiang Zhang) Date: Tue, 11 Oct 2016 16:19:38 +0000 Subject: [New-bugs-announce] [issue28417] va_end twice in PyUnicode_FromFormatV Message-ID: <1476202778.52.0.223163614953.issue28417@psf.upfronthosting.co.za> New submission from Xiang Zhang: vargs2 could be va_end()ed twice in PyUnicode_FromFormatV when format contains non-ascii characters. Once va_end()ed, vargs2 is undefined. So this could lead to undefined behaviour. ---------- components: Interpreter Core files: PyUnicode_FromFormatV.patch keywords: patch messages: 278496 nosy: christian.heimes, haypo, serhiy.storchaka, xiang.zhang priority: normal severity: normal stage: patch review status: open title: va_end twice in PyUnicode_FromFormatV type: behavior versions: Python 3.6, Python 3.7 Added file: http://bugs.python.org/file45059/PyUnicode_FromFormatV.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Oct 11 15:04:57 2016 From: report at bugs.python.org (Matthias Bussonnier) Date: Tue, 11 Oct 2016 19:04:57 +0000 Subject: [New-bugs-announce] [issue28418] Raise Deprecation warning for tokenize.generate_tokens Message-ID: <1476212697.92.0.408666384378.issue28418@psf.upfronthosting.co.za> New submission from Matthias Bussonnier: the Tokenize module has the following code: # An undocumented, backwards compatible, API for all the places in the standard # library that expect to be able to use tokenize with strings def generate_tokens(readline): return _tokenize(readline, None) So I'm going to assume it is Deprecated... (since 3.0 AFAICT). If it is expected from Python developers to not use it, may I suggest: 1) Marking it as deprecated in the docstring/ 2) Raise a deprecation warning. Indeed not everyone code by looking at the documentation and it is relatively easy to have your IDE/editor/REPL to complete it. Even tools that grab the source (IPython double question mark for example) will not show the comment above which make it kinda pointless. ---------- assignee: docs at python components: Documentation messages: 278500 nosy: docs at python, mbussonn priority: normal severity: normal status: open title: Raise Deprecation warning for tokenize.generate_tokens versions: Python 3.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Oct 11 17:38:57 2016 From: report at bugs.python.org (David Eyk) Date: Tue, 11 Oct 2016 21:38:57 +0000 Subject: [New-bugs-announce] [issue28419] List comprehension in class scope does not have access to class scope Message-ID: <1476221937.84.0.647969996739.issue28419@psf.upfronthosting.co.za> New submission from David Eyk: I've discovered what appears to be a scoping bug in Python 3.5.1, where the class scope is not available inside a list comprehension defined in the class scope. Attached is a simple example script, also available at the following gist: https://gist.github.com/eykd/c63a7cf760a538ee8bc3828362ed12e3 As demonstrated, the script runs fine in Python 2.7.11, but fails in 3.5.1. I can't think of any good reason why the class scope wouldn't be available to the comprehension scope, but if there is a reason, I'm keen to know what it is! ---------- components: Interpreter Core files: comp_scope.py messages: 278505 nosy: David Eyk priority: normal severity: normal status: open title: List comprehension in class scope does not have access to class scope versions: Python 3.5 Added file: http://bugs.python.org/file45062/comp_scope.py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Oct 11 20:11:27 2016 From: report at bugs.python.org (Vagner Clementino) Date: Wed, 12 Oct 2016 00:11:27 +0000 Subject: [New-bugs-announce] [issue28420] is ok Message-ID: <1476231087.75.0.88301007171.issue28420@psf.upfronthosting.co.za> Changes by Vagner Clementino : ---------- nosy: Vagner Clementino priority: normal severity: normal status: open title: is ok _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Oct 12 03:36:42 2016 From: report at bugs.python.org (Takashi Matsuzawa) Date: Wed, 12 Oct 2016 07:36:42 +0000 Subject: [New-bugs-announce] [issue28421] lib/distutils/sysconfig.py fails to pick up Py_ENABLE_SHARED value Message-ID: <1476257802.16.0.0608575453753.issue28421@psf.upfronthosting.co.za> New submission from Takashi Matsuzawa: I have been debugging for a couple of days to now why my extension module build fails with my Yocto 2.0 cross-build environment. (python version is 2.7, host is x86_64 and target is qemux86). The symptom is that LD flags -L and -lpython27 are not being passed cross gcc and linker fails. The direct cause of this is that lib/distutils/sysconfig.py not picking up Py_ENABLE_SHARED value (it should be 1 since I am linking against shared libpython2.7). In lib/distutils/sysconfig.py:parse_config_h(), the code is reading the file pointer line by line, and only doing string match against #define and #under. No other type of lines are meaningful to this code. However, the pyconfig.h I have is like this: (sysroots/qemux86/user/include/python2.7/pyconfig.h) >>>> /* * Copyright (C) 2005-2011 by Wind River Systems, Inc. * .... #ifdef _MIPS_SIM ... #else /* _MIPS_SIM is not defined */ #include #endif ... <<<< So, parse_config_h() fails to get anything from there. In particular, it fails to get the following in pyconfig-32.h and I fail to build extension module using this configuration of python. #define Py_ENABLE_SHARED 1 I have looked into the master branch, but the parse_config_h() code is the same as what I have on my PC. I am not sure which of the below is true 1) pyconfig.h should be flat, no #ifdef's, so that parse_config_h() does its job sucessfully. 2) parse_config_h() should be flexible to allow ordinal header file syntax including #ifdef's and #includes (or pyconfig.h should be preprocessed before it is read by parse_config_h()). ---------- components: Cross-Build messages: 278518 nosy: Alex.Willmer, tmatsuzawa priority: normal severity: normal status: open title: lib/distutils/sysconfig.py fails to pick up Py_ENABLE_SHARED value type: compile error versions: Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Oct 12 09:03:47 2016 From: report at bugs.python.org (Vilnis Termanis) Date: Wed, 12 Oct 2016 13:03:47 +0000 Subject: [New-bugs-announce] [issue28422] multiprocessing Manager mutable type member access failure Message-ID: <1476277427.94.0.954125704246.issue28422@psf.upfronthosting.co.za> New submission from Vilnis Termanis: Accessing some Manager types (e.g. Lock) through a list, dict or Namespace proxy is not possible if both the mutable container (e.g. list) and contained type instance (e.g. Lock) have been created in the same process. Symptoms: In accessing process: multiprocessing.managers.RemoteError on access, e.g.: Unserializable message: ('#RETURN', ) .. and in underlying manager: _pickle.PicklingError: Can't pickle : attribute lookup lock on _thread failed The provided test script performs: 0) Initialise SyncManager (via multiprocessing.Manager()) 1) Create list proxy through manager 2) Insert another proxied type into the list (e.g. Lock) 3) Try to access type instance from (2) via container created in (1) Note: When step (2) is run in a child process, everything work as expected. When all steps execute in the same process, one gets the aforementioned exception. See also: https://mail.python.org/pipermail/python-list/2009-September/552988.html ---------- components: Library (Lib) files: manager_pickling.py messages: 278529 nosy: vilnis.termanis priority: normal severity: normal status: open title: multiprocessing Manager mutable type member access failure versions: Python 2.7, Python 3.5 Added file: http://bugs.python.org/file45066/manager_pickling.py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Oct 12 17:46:33 2016 From: report at bugs.python.org (stephen) Date: Wed, 12 Oct 2016 21:46:33 +0000 Subject: [New-bugs-announce] [issue28423] list.insert(-1,value) is wrong! Message-ID: <1476308793.35.0.934703472079.issue28423@psf.upfronthosting.co.za> New submission from stephen: python3.4.3 on linux mint 17.3 interactive mode on terminal >>> fred=[0,1,2,3,4] >>> fred.insert(-1,9) >>> fred [0, 1, 2, 3, 9, 4] We should get [0,1,2,3,4,9]. Embarrassing error! ---------- messages: 278541 nosy: unklestephen priority: normal severity: normal status: open title: list.insert(-1,value) is wrong! type: behavior versions: Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Oct 12 19:36:00 2016 From: report at bugs.python.org (Douglas Greiman) Date: Wed, 12 Oct 2016 23:36:00 +0000 Subject: [New-bugs-announce] [issue28424] pkgutil.get_data() doesn't work with namespace packages Message-ID: <1476315360.41.0.557766587306.issue28424@psf.upfronthosting.co.za> New submission from Douglas Greiman: pkg_util.get_data('mypackage', 'resourcename') returns None if 'mypackage' is a namespace package, because the package object has no __file__ attribute. A shell script is attached to reproduce this. This is either a bug to be fixed (my preference) or behavior to be documented. If there is equivalent, working functionality in the new importlib, that would also be a good to document. ---------- components: Library (Lib) files: namespace_package_get_data.sh messages: 278543 nosy: dgreiman priority: normal severity: normal status: open title: pkgutil.get_data() doesn't work with namespace packages type: behavior versions: Python 3.4, Python 3.5 Added file: http://bugs.python.org/file45068/namespace_package_get_data.sh _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Oct 12 20:18:52 2016 From: report at bugs.python.org (Douglas Greiman) Date: Thu, 13 Oct 2016 00:18:52 +0000 Subject: [New-bugs-announce] [issue28425] Python3 ignores __init__.py that are links to /dev/null Message-ID: <1476317932.87.0.807629965942.issue28425@psf.upfronthosting.co.za> New submission from Douglas Greiman: This manifests in the following way: A package directory containing an __init__.py that is a symlink to /dev/null is treated as a namespace package instead of a regular package. The Bazel build tool creates many __init__.py files in this way, which is how I even ran into this. Symlinks to regular files seem fine. ---------- components: Interpreter Core files: namespace_package_dev_null.sh messages: 278544 nosy: dgreiman priority: normal severity: normal status: open title: Python3 ignores __init__.py that are links to /dev/null type: behavior versions: Python 3.4, Python 3.5 Added file: http://bugs.python.org/file45069/namespace_package_dev_null.sh _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Oct 13 00:30:06 2016 From: report at bugs.python.org (Xiang Zhang) Date: Thu, 13 Oct 2016 04:30:06 +0000 Subject: [New-bugs-announce] [issue28426] PyUnicode_AsDecodedObject can only return unicode now Message-ID: <1476333006.27.0.165344919585.issue28426@psf.upfronthosting.co.za> New submission from Xiang Zhang: PyUnicode_AsDecodedObject was added in f46d49e2e0f0 and became an API in 2284fa89ab08. It seems its intention is to return a Python object. But during evolution, with commits 5f11621a6f51 and 123f2dc08b3e, it can only return unicode now, becoming another version of PyUnicode_AsDecodedUnicode. Is this the wanted behaviour? ---------- components: Interpreter Core messages: 278545 nosy: haypo, lemburg, xiang.zhang priority: normal severity: normal status: open title: PyUnicode_AsDecodedObject can only return unicode now type: behavior versions: Python 3.5, Python 3.6, Python 3.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Oct 13 06:36:29 2016 From: report at bugs.python.org (Armin Rigo) Date: Thu, 13 Oct 2016 10:36:29 +0000 Subject: [New-bugs-announce] [issue28427] WeakValueDictionary next bug (with multithreading) Message-ID: <1476354989.22.0.575160455599.issue28427@psf.upfronthosting.co.za> New submission from Armin Rigo: Follow-up on http://bugs.python.org/issue19542. Another crash of using WeakValueDictionary() in a thread-local fashion inside a multi-threaded program. I must admit I'm not exactly sure why this occurs, but it is definitely showing an issue: two threads independently create their own WeakValueDictionary() and try to set one item in it. The problem I get is that the "assert 42 in d" sometimes fails, even though 42 was set in that WeakValueDictionary on the previous line and the value is still alive. This only occurs if there is a cycle of references involving the value. See attached file. Reproduced on Python 2.7, 3.3, 3.5, 3.6-debug. ---------- files: test.py messages: 278555 nosy: arigo priority: normal severity: normal status: open title: WeakValueDictionary next bug (with multithreading) type: behavior versions: Python 2.7, Python 3.3, Python 3.5, Python 3.6 Added file: http://bugs.python.org/file45072/test.py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Oct 13 07:20:36 2016 From: report at bugs.python.org (INADA Naoki) Date: Thu, 13 Oct 2016 11:20:36 +0000 Subject: [New-bugs-announce] [issue28428] Rename _futures module to _asyncio Message-ID: <1476357636.44.0.0358682428138.issue28428@psf.upfronthosting.co.za> New submission from INADA Naoki: Before adding more speedup functions for asyncio, I want to rename the module. Attached patch is tested on Mac 10.11. I'll test it on Windows later. ---------- files: asyncio-speedups.patch keywords: patch messages: 278558 nosy: inada.naoki, yselivanov priority: normal severity: normal stage: patch review status: open title: Rename _futures module to _asyncio type: enhancement versions: Python 3.6, Python 3.7 Added file: http://bugs.python.org/file45074/asyncio-speedups.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Oct 13 08:12:18 2016 From: report at bugs.python.org (Glandos) Date: Thu, 13 Oct 2016 12:12:18 +0000 Subject: [New-bugs-announce] [issue28429] ctypes fails to import with grsecurity's TPE Message-ID: <1476360738.57.0.800770600157.issue28429@psf.upfronthosting.co.za> New submission from Glandos: When using a grsecurity kernel with TPE enabled, the following happens with an untrusted user: Python 3.5.2+ (default, Sep 22 2016, 12:18:14) [GCC 6.2.0 20160914] on linux Type "help", "copyright", "credits" or "license" for more information. >>> from ctypes import CDLL Traceback (most recent call last): File "", line 1, in File "/usr/lib/python3.5/ctypes/__init__.py", line 537, in _reset_cache() File "/usr/lib/python3.5/ctypes/__init__.py", line 276, in _reset_cache CFUNCTYPE(c_int)(lambda: None) MemoryError And grsecurity complains: oct. 13 13:52:27 belette64 kernel: grsec: From XX.XX.XX.XX: denied untrusted exec (due to not being in trusted group and file in world-writable directory) of /tmp/#38928416 by /usr/bin/python3.5[python3:19125] uid/euid:1000/1000 gid/egid:1000/1000, parent /usr/bin/fish[fish:17716] uid/euid:1000/1000 gid/egid:1000/1000 oct. 13 13:52:27 belette64 kernel: grsec: From XX.XX.XX.XX: denied untrusted exec (due to not being in trusted group and file in world-writable directory) of /var/tmp/#15073678 by /usr/bin/python3.5[python3:19125] uid/euid:1000/1000 gid/egid:1000/1000, parent /usr/bin/fish[fish:17716] uid/euid:1000/1000 gid/egid:1000/1000 oct. 13 13:52:27 belette64 kernel: grsec: From XX.XX.XX.XX: denied untrusted exec (due to not being in trusted group and file in world-writable directory) of /dev/shm/#4422450 by /usr/bin/python3.5[python3:19125] uid/euid:1000/1000 gid/egid:1000/1000, parent /usr/bin/fish[fish:17716] uid/euid:1000/1000 gid/egid:1000/1000 oct. 13 13:52:27 belette64 kernel: grsec: From XX.XX.XX.XX: denied untrusted exec (due to not being in trusted group and file in world-writable directory) of /dev/shm/#4422452 by /usr/bin/python3.5[python3:19125] uid/euid:1000/1000 gid/egid:1000/1000, parent /usr/bin/fish[fish:17716] uid/euid:1000/1000 gid/egid:1000/1000 oct. 13 13:52:29 belette64 kernel: grsec: From XX.XX.XX.XX: denied untrusted exec (due to not being in trusted group and file in world-writable directory) of /dev/shm/#4425509 by /usr/bin/python3.5[python3:19125] uid/euid:1000/1000 gid/egid:1000/1000, parent /usr/bin/fish[fish:17716] uid/euid:1000/1000 gid/egid:1000/1000 However, even if the solution should be to put the user in the trusted group, it seems that the involved call is just a workaround for Win64 platforms. The program I used is using ctypes through the xattr package, which never used CFUNCTYPE. Is it possible to wrap this "fake call" into a try block? ---------- components: ctypes messages: 278567 nosy: Glandos priority: normal severity: normal status: open title: ctypes fails to import with grsecurity's TPE type: behavior versions: Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Oct 13 08:43:15 2016 From: report at bugs.python.org (INADA Naoki) Date: Thu, 13 Oct 2016 12:43:15 +0000 Subject: [New-bugs-announce] [issue28430] asyncio: C implemeted Future cause Tornado test fail Message-ID: <1476362595.2.0.424739151536.issue28430@psf.upfronthosting.co.za> New submission from INADA Naoki: https://travis-ci.org/tornadoweb/tornado/jobs/167252979 ---------- assignee: inada.naoki components: asyncio messages: 278569 nosy: gvanrossum, inada.naoki, yselivanov priority: high severity: normal status: open title: asyncio: C implemeted Future cause Tornado test fail type: behavior versions: Python 3.6, Python 3.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Oct 13 11:12:28 2016 From: report at bugs.python.org (Nick Carboni) Date: Thu, 13 Oct 2016 15:12:28 +0000 Subject: [New-bugs-announce] [issue28431] socket gethostbyaddr returns IPv6 names for 127.0.0.1 Message-ID: <1476371548.7.0.723704893045.issue28431@psf.upfronthosting.co.za> New submission from Nick Carboni: socket.gethostbyaddr seems to be equating loopback addresses regardless of IP protocol version. In both versions tested (2.7.5 and 3.4.3) the ordering of the entries in my /etc/hosts file determines the result I get, rather than what address I'm querying for. For example: /etc/hosts: ::1 localhost localhost.localdomain localhost6 localhost6.localdomain6 127.0.0.1 localhost localhost.localdomain localhost4 localhost4.localdomain4 result: >>> import socket >>> socket.gethostbyaddr("127.0.0.1") ('localhost', ['localhost.localdomain', 'localhost6', 'localhost6.localdomain6'], ['127.0.0.1']) Then if I change the ordering of the entries in /etc/hosts as follows: 127.0.0.1 localhost localhost.localdomain localhost4 localhost4.localdomain4 ::1 localhost localhost.localdomain localhost6 localhost6.localdomain6 result: >>> import socket >>> socket.gethostbyaddr("127.0.0.1") ('localhost', ['localhost.localdomain', 'localhost4', 'localhost4.localdomain4'], ['127.0.0.1']) I would expect gethostbyaddr to return only the hostnames associated with the given address regardless of the ordering of the entries in /etc/hosts. ---------- messages: 278580 nosy: carbonin priority: normal severity: normal status: open title: socket gethostbyaddr returns IPv6 names for 127.0.0.1 type: behavior versions: Python 2.7, Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Oct 13 13:03:17 2016 From: report at bugs.python.org (Xiang Zhang) Date: Thu, 13 Oct 2016 17:03:17 +0000 Subject: [New-bugs-announce] [issue28432] Fix doc of PyUnicode_EncodeLocale Message-ID: <1476378197.99.0.847074605857.issue28432@psf.upfronthosting.co.za> New submission from Xiang Zhang: The doc of PyUnicode_EncodeLocale conflicts between signature and content. In content, it should be *unicode* not *str*. ---------- assignee: docs at python components: Documentation files: PyUnicode_EncodeLocale_doc.patch keywords: patch messages: 278583 nosy: docs at python, xiang.zhang priority: normal severity: normal stage: patch review status: open title: Fix doc of PyUnicode_EncodeLocale versions: Python 3.5, Python 3.6, Python 3.7 Added file: http://bugs.python.org/file45081/PyUnicode_EncodeLocale_doc.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Oct 13 14:21:37 2016 From: report at bugs.python.org (=?utf-8?b?0JzQsNGA0Log0JrQvtGA0LXQvdCx0LXRgNCz?=) Date: Thu, 13 Oct 2016 18:21:37 +0000 Subject: [New-bugs-announce] [issue28433] Add sorted (ordered) containers Message-ID: <1476382897.32.0.459857278334.issue28433@psf.upfronthosting.co.za> New submission from ???? ?????????: I mean mutable containers that are always sorted when iterating over them. i.e. * SortedSet (sorted unique elements, implemented using (rb?)tree instead of hash) * SortedList (sorted elements, the same as SortedSet, but without uniquiness constraint) - actually a (rb?)tree, not a list (i.e. not an array) * SortedDict (sorted by key when interating) - like C++'s ordered_map There are many implementations in the net, like: https://bitbucket.org/bcsaller/rbtree/ http://newcenturycomputers.net/projects/rbtree.html https://sourceforge.net/projects/pyavl/ http://www.grantjenks.com/docs/sortedcontainers/ and also in pip: pip3 search sorted | grep -Ei '[^a-z]sorted' I think it should be one standardized implementation of such containers in CPython. For example, C++ has both ordered_map and unorderd_map. P.S. Did not found if such issue was raised earlier. ---------- components: Library (Lib) messages: 278586 nosy: mmarkk priority: normal severity: normal status: open title: Add sorted (ordered) containers type: enhancement versions: Python 3.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Oct 13 15:47:14 2016 From: report at bugs.python.org (Mark Shoulson) Date: Thu, 13 Oct 2016 19:47:14 +0000 Subject: [New-bugs-announce] [issue28434] U+1F441 EYE Missing in unicodedata Message-ID: <1476388034.81.0.0881168624488.issue28434@psf.upfronthosting.co.za> New submission from Mark Shoulson: Python3.4 does not appear to know about the Unicode character U+1F441 EYE, although it does know about nearby characters which were added to Unicode at the same time: >>> "\N{EYES}" # This is character U+1F440 '?' >>> "\N{NOSE}" # This is U+1F442 '?' >>> "\N{EYE}" File "", line 1 SyntaxError: (unicode error) 'unicodeescape' codec can't decode bytes in position 0-6: unknown Unicode character name >>> import unicodedata >>> unicodedata.lookup("EYES") '?' >>> unicodedata.lookup("EYE") Traceback (most recent call last): File "", line 1, in KeyError: "undefined character name 'EYE'" >>> unicodedata.name('?') 'EYES' >>> unicodedata.name('?') Traceback (most recent call last): File "", line 1, in ValueError: no such name >>> ---------- components: Unicode messages: 278594 nosy: Mark Shoulson, ezio.melotti, haypo priority: normal severity: normal status: open title: U+1F441 EYE Missing in unicodedata type: behavior versions: Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Oct 13 16:07:06 2016 From: report at bugs.python.org (Stefan Prawda) Date: Thu, 13 Oct 2016 20:07:06 +0000 Subject: [New-bugs-announce] [issue28435] test_urllib2_localnet.ProxyAuthTests fails with no_proxy and NO_PROXY env Message-ID: <1476389226.43.0.0474537923373.issue28435@psf.upfronthosting.co.za> New submission from Stefan Prawda: test_urllib2_localnet.ProxyAuthTests fails with no_proxy and NO_PROXY env set: NO_PROXY=localhost,127.0.0.0/8,::1 no_proxy=localhost,127.0.0.0/8,::1 Patch attached. Run: ./python -m unittest test.test_urllib2_localnet.ProxyAuthTests -v test_proxy_qop_auth_int_works_or_throws_urlerror (test.test_urllib2_localnet.ProxyAuthTests) ... ok test_proxy_qop_auth_works (test.test_urllib2_localnet.ProxyAuthTests) ... ERROR test_proxy_with_bad_password_raises_httperror (test.test_urllib2_localnet.ProxyAuthTests) ... ERROR test_proxy_with_no_password_raises_httperror (test.test_urllib2_localnet.ProxyAuthTests) ... ERROR ====================================================================== ERROR: test_proxy_qop_auth_works (test.test_urllib2_localnet.ProxyAuthTests) ---------------------------------------------------------------------- Traceback (most recent call last): File "/home/d0han/cpython/cpython/Lib/urllib/request.py", line 1318, in do_open encode_chunked=req.has_header('Transfer-encoding')) File "/home/d0han/cpython/cpython/Lib/http/client.py", line 1239, in request self._send_request(method, url, body, headers, encode_chunked) File "/home/d0han/cpython/cpython/Lib/http/client.py", line 1285, in _send_request self.endheaders(body, encode_chunked=encode_chunked) File "/home/d0han/cpython/cpython/Lib/http/client.py", line 1234, in endheaders self._send_output(message_body, encode_chunked=encode_chunked) File "/home/d0han/cpython/cpython/Lib/http/client.py", line 1026, in _send_output self.send(msg) File "/home/d0han/cpython/cpython/Lib/http/client.py", line 964, in send self.connect() File "/home/d0han/cpython/cpython/Lib/http/client.py", line 936, in connect (self.host,self.port), self.timeout, self.source_address) File "/home/d0han/cpython/cpython/Lib/socket.py", line 722, in create_connection raise err File "/home/d0han/cpython/cpython/Lib/socket.py", line 713, in create_connection sock.connect(sa) ConnectionRefusedError: [Errno 111] Connection refused During handling of the above exception, another exception occurred: Traceback (most recent call last): File "/home/d0han/cpython/cpython/Lib/test/test_urllib2_localnet.py", line 372, in test_proxy_qop_auth_works result = self.opener.open(self.URL) File "/home/d0han/cpython/cpython/Lib/urllib/request.py", line 526, in open response = self._open(req, data) File "/home/d0han/cpython/cpython/Lib/urllib/request.py", line 544, in _open '_open', req) File "/home/d0han/cpython/cpython/Lib/urllib/request.py", line 504, in _call_chain result = func(*args) File "/home/d0han/cpython/cpython/Lib/urllib/request.py", line 1346, in http_open return self.do_open(http.client.HTTPConnection, req) File "/home/d0han/cpython/cpython/Lib/urllib/request.py", line 1320, in do_open raise URLError(err) urllib.error.URLError: ====================================================================== ERROR: test_proxy_with_bad_password_raises_httperror (test.test_urllib2_localnet.ProxyAuthTests) ---------------------------------------------------------------------- Traceback (most recent call last): File "/home/d0han/cpython/cpython/Lib/urllib/request.py", line 1318, in do_open encode_chunked=req.has_header('Transfer-encoding')) File "/home/d0han/cpython/cpython/Lib/http/client.py", line 1239, in request self._send_request(method, url, body, headers, encode_chunked) File "/home/d0han/cpython/cpython/Lib/http/client.py", line 1285, in _send_request self.endheaders(body, encode_chunked=encode_chunked) File "/home/d0han/cpython/cpython/Lib/http/client.py", line 1234, in endheaders self._send_output(message_body, encode_chunked=encode_chunked) File "/home/d0han/cpython/cpython/Lib/http/client.py", line 1026, in _send_output self.send(msg) File "/home/d0han/cpython/cpython/Lib/http/client.py", line 964, in send self.connect() File "/home/d0han/cpython/cpython/Lib/http/client.py", line 936, in connect (self.host,self.port), self.timeout, self.source_address) File "/home/d0han/cpython/cpython/Lib/socket.py", line 722, in create_connection raise err File "/home/d0han/cpython/cpython/Lib/socket.py", line 713, in create_connection sock.connect(sa) ConnectionRefusedError: [Errno 111] Connection refused During handling of the above exception, another exception occurred: Traceback (most recent call last): File "/home/d0han/cpython/cpython/Lib/test/test_urllib2_localnet.py", line 360, in test_proxy_with_bad_password_raises_httperror self.URL) File "/home/d0han/cpython/cpython/Lib/unittest/case.py", line 728, in assertRaises return context.handle('assertRaises', args, kwargs) File "/home/d0han/cpython/cpython/Lib/unittest/case.py", line 177, in handle callable_obj(*args, **kwargs) File "/home/d0han/cpython/cpython/Lib/urllib/request.py", line 526, in open response = self._open(req, data) File "/home/d0han/cpython/cpython/Lib/urllib/request.py", line 544, in _open '_open', req) File "/home/d0han/cpython/cpython/Lib/urllib/request.py", line 504, in _call_chain result = func(*args) File "/home/d0han/cpython/cpython/Lib/urllib/request.py", line 1346, in http_open return self.do_open(http.client.HTTPConnection, req) File "/home/d0han/cpython/cpython/Lib/urllib/request.py", line 1320, in do_open raise URLError(err) urllib.error.URLError: ====================================================================== ERROR: test_proxy_with_no_password_raises_httperror (test.test_urllib2_localnet.ProxyAuthTests) ---------------------------------------------------------------------- Traceback (most recent call last): File "/home/d0han/cpython/cpython/Lib/urllib/request.py", line 1318, in do_open encode_chunked=req.has_header('Transfer-encoding')) File "/home/d0han/cpython/cpython/Lib/http/client.py", line 1239, in request self._send_request(method, url, body, headers, encode_chunked) File "/home/d0han/cpython/cpython/Lib/http/client.py", line 1285, in _send_request self.endheaders(body, encode_chunked=encode_chunked) File "/home/d0han/cpython/cpython/Lib/http/client.py", line 1234, in endheaders self._send_output(message_body, encode_chunked=encode_chunked) File "/home/d0han/cpython/cpython/Lib/http/client.py", line 1026, in _send_output self.send(msg) File "/home/d0han/cpython/cpython/Lib/http/client.py", line 964, in send self.connect() File "/home/d0han/cpython/cpython/Lib/http/client.py", line 936, in connect (self.host,self.port), self.timeout, self.source_address) File "/home/d0han/cpython/cpython/Lib/socket.py", line 722, in create_connection raise err File "/home/d0han/cpython/cpython/Lib/socket.py", line 713, in create_connection sock.connect(sa) ConnectionRefusedError: [Errno 111] Connection refused During handling of the above exception, another exception occurred: Traceback (most recent call last): File "/home/d0han/cpython/cpython/Lib/test/test_urllib2_localnet.py", line 366, in test_proxy_with_no_password_raises_httperror self.URL) File "/home/d0han/cpython/cpython/Lib/unittest/case.py", line 728, in assertRaises return context.handle('assertRaises', args, kwargs) File "/home/d0han/cpython/cpython/Lib/unittest/case.py", line 177, in handle callable_obj(*args, **kwargs) File "/home/d0han/cpython/cpython/Lib/urllib/request.py", line 526, in open response = self._open(req, data) File "/home/d0han/cpython/cpython/Lib/urllib/request.py", line 544, in _open '_open', req) File "/home/d0han/cpython/cpython/Lib/urllib/request.py", line 504, in _call_chain result = func(*args) File "/home/d0han/cpython/cpython/Lib/urllib/request.py", line 1346, in http_open return self.do_open(http.client.HTTPConnection, req) File "/home/d0han/cpython/cpython/Lib/urllib/request.py", line 1320, in do_open raise URLError(err) urllib.error.URLError: ---------------------------------------------------------------------- Ran 4 tests in 3.024s FAILED (errors=3) ---------- components: Tests files: cpython.diff keywords: patch messages: 278600 nosy: Stefan Prawda priority: normal severity: normal status: open title: test_urllib2_localnet.ProxyAuthTests fails with no_proxy and NO_PROXY env type: enhancement versions: Python 3.7 Added file: http://bugs.python.org/file45084/cpython.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Oct 13 16:29:24 2016 From: report at bugs.python.org (Evgeny Kapun) Date: Thu, 13 Oct 2016 20:29:24 +0000 Subject: [New-bugs-announce] [issue28436] GzipFile doesn't properly handle short reads and writes on the underlying stream Message-ID: <1476390564.38.0.787956404388.issue28436@psf.upfronthosting.co.za> New submission from Evgeny Kapun: GzipFile's underlying stream can be a raw stream (such as FileIO), and such streams can return short reads and writes at any time (e.g. due to signals). The correct behavior in case of short read or write is to retry the call to read or write the remaining data. GzipFile doesn't do this. This program demonstrates the problem with reading: import io, gzip class MyFileIO(io.FileIO): def read(self, n): # Emulate short read return super().read(1) raw = MyFileIO('test.gz', 'rb') gzf = gzip.open(raw, 'rb') gzf.read() Output: $ gzip -c /dev/null > test.gz $ python3 test.py Traceback (most recent call last): File "test.py", line 10, in gzf.read() File "/usr/lib/python3.5/gzip.py", line 274, in read return self._buffer.read(size) File "/usr/lib/python3.5/gzip.py", line 461, in read if not self._read_gzip_header(): File "/usr/lib/python3.5/gzip.py", line 409, in _read_gzip_header raise OSError('Not a gzipped file (%r)' % magic) OSError: Not a gzipped file (b'\x1f') And this shows the problem with writing: import io, gzip class MyIO(io.RawIOBase): def write(self, data): print(data) # Emulate short write return 1 raw = MyIO() gzf = gzip.open(raw, 'wb') gzf.close() Output: $ python3 test.py b'\x1f\x8b' b'\x08' b'\x00' b'\xb9\xea\xffW' b'\x02' b'\xff' b'\x03\x00' b'\x00\x00\x00\x00' b'\x00\x00\x00\x00' It can be seen that there is no attempt to write all the data. Indeed, the return value of write() method is completely ignored. I think that either gzip module should be changed to handle short reads and writes properly, or its documentation should reflect the fact that it cannot be used with raw streams. ---------- components: Library (Lib) messages: 278606 nosy: abacabadabacaba priority: normal severity: normal status: open title: GzipFile doesn't properly handle short reads and writes on the underlying stream type: behavior versions: Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Oct 13 19:50:59 2016 From: report at bugs.python.org (Neil Girdhar) Date: Thu, 13 Oct 2016 23:50:59 +0000 Subject: [New-bugs-announce] [issue28437] Class definition is not consistent with types.new_class Message-ID: <1476402659.83.0.311331660228.issue28437@psf.upfronthosting.co.za> New submission from Neil Girdhar: Minimum working example: class MyMetaclass(type): pass class OtherMetaclass(type): pass def metaclass_callable(name, bases, namespace): return OtherMetaclass(name, bases, namespace) class MyClass(metaclass=MyMetaclass): pass try: class MyDerived(MyClass, metaclass=metaclass_callable): pass except: print("Gotcha!") from types import new_class MyDerived = new_class("MyDerived", (), dict(metaclass=metaclass_callable)) print(type(MyDerived)) This is because something happened along the way and Objects/typeobject.c:type_new no longer coincides with Lib/types.py:new_class. The Python version conditionally calls _calculate_meta whereas the C version calls it unconditionally. I consider the C implementation to be the "correct" version. I suggest that * the Python version be made to coincide with the C version. * the documentation be made to coincide with the C version. Specifically, section 3.3.3.2 should read: "The metaclass of a class definition is selected from the explicitly specified metaclass (if any) and the metaclasses (i.e. type(cls)) of all specified base classes. The selected metaclass is the one which is a subtype of all of these candidate metaclasses. If none of the candidate metaclasses meets that criterion, then the class definition will fail with TypeError. If provided, the explicit metaclass must be a callable accepting the positional arguments (name, bases, _dict) as in the three argument form of the built-in type function." ---------- assignee: docs at python components: Documentation, Library (Lib) messages: 278625 nosy: docs at python, neil.g priority: normal severity: normal status: open title: Class definition is not consistent with types.new_class type: behavior versions: Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Oct 14 00:14:26 2016 From: report at bugs.python.org (Xiang Zhang) Date: Fri, 14 Oct 2016 04:14:26 +0000 Subject: [New-bugs-announce] [issue28438] Wrong link in pkgutil.get_data doc Message-ID: <1476418466.2.0.122595119446.issue28438@psf.upfronthosting.co.za> New submission from Xiang Zhang: The get_data link in pkgutil.get_data doc refers to itself which does not help reading. I think it's better for it to refer to importlib.abc.ResourceLoader.get_data. ---------- assignee: docs at python components: Documentation files: pkgutil.get_data_doc.patch keywords: patch messages: 278631 nosy: docs at python, xiang.zhang priority: normal severity: normal stage: patch review status: open title: Wrong link in pkgutil.get_data doc versions: Python 3.5, Python 3.6, Python 3.7 Added file: http://bugs.python.org/file45087/pkgutil.get_data_doc.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Oct 14 05:28:48 2016 From: report at bugs.python.org (Xiang Zhang) Date: Fri, 14 Oct 2016 09:28:48 +0000 Subject: [New-bugs-announce] [issue28439] Remove redundant checks in PyUnicode_EncodeLocale Message-ID: <1476437328.02.0.48418447078.issue28439@psf.upfronthosting.co.za> Changes by Xiang Zhang : ---------- components: Interpreter Core files: PyUnicode_EncodeLocale.patch keywords: patch nosy: haypo, serhiy.storchaka, xiang.zhang priority: normal severity: normal stage: patch review status: open title: Remove redundant checks in PyUnicode_EncodeLocale type: enhancement versions: Python 3.7 Added file: http://bugs.python.org/file45089/PyUnicode_EncodeLocale.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Oct 14 09:09:00 2016 From: report at bugs.python.org (Marc Culler) Date: Fri, 14 Oct 2016 13:09:00 +0000 Subject: [New-bugs-announce] [issue28440] pip failures on macOS Sierra Message-ID: <1476450540.6.0.486887198503.issue28440@psf.upfronthosting.co.za> New submission from Marc Culler: Changes made to /Library/Python on macOSX Sierra cause the --with-ensurepip compiler flag to fail, and lead to failures of pip after installing Python. The new file that causes the problem on Sierra is: /Library/Python/2.7/site-packages/Extras.pth The current version of site.py reads that .pth file, which results in sys.path containing the path: /System/Library/Frameworks/Python.framework/Versions/2.7/Extras/lib/python The latter directory (which is protected by SIP) contains many Python 2.7 packages, including easy_install, setuptools, six, py2app, numpy, pylab and pyOpenSSL. The effect of including this SIP-protected path in sys.path is this: installing or upgrade a package in /Library/Frameworks/Python.framework which is also installed as an "Extra" in the /System/Frameworks/Python.framework will cause pip to attempt to delete the "old" package from its SIP-protected directory, leading to a "Permission Denied" exception and a failed install. Given that Apple has now tied /Library/Python to the system Python in this way, thereby making a separate Python framework in /Library/Frameworks unusable, the natural solution to this problem would be to stop including any /Library/Python paths in sys.path. I am attaching a patch that removes the block of code in site.py which adds these paths. ---------- files: pipfails.patch keywords: patch messages: 278649 nosy: Marc.Culler priority: normal severity: normal status: open title: pip failures on macOS Sierra type: compile error Added file: http://bugs.python.org/file45090/pipfails.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Oct 14 09:34:45 2016 From: report at bugs.python.org (Erik Bray) Date: Fri, 14 Oct 2016 13:34:45 +0000 Subject: [New-bugs-announce] [issue28441] sys.executable is ambiguous on Cygwin without .exe suffix Message-ID: <1476452085.73.0.180033377767.issue28441@psf.upfronthosting.co.za> New submission from Erik Bray: This actually came up previously in #1543469 in the context of test_subprocess, but it's a more general issue that I thought was worth addressing somehow. The issue here is that as Cygwin tries to provide a "UNIX-like" experience, any system interfaces that take the path to an executable as an argument allow the .exe extension to be left off. This is particularly convenient for the shell experience, so that one can run, for example "python" or "ls" without typing "python.exe" or "ls.exe" (this is of course true of the Windows cmd shell as well). In the case of ambiguity however--such as when there is both a "python" and a "python.exe" in the same path, one must explicitly add the ".exe", otherwise the path without the exe is assumed. This is made even worse when you factor in case-insensitivity. Thus, this becomes a real annoyance when developing Python on Cygwin because you get both a "python.exe" and the "Python" directory in your source tree. This isn't so much of a problem, except that sys.executable leaves off the ".exe" (in UNIX-y fashion), so any test that calls Popen([sys.executable]) errors out because it thinks you're trying to execute a directory (Python/). I think the only reasonable fix is to take the patch suggested at #1543469, and ensure that the ".exe" suffix is appended to sys.executable on Cygwin. I think that sys.executable should be as unambiguous as possible, and that's the only way to make it reasonably unambiguous on Cygwin. I've attached a patch adapted from the one in #1543469 which solves the issue for me. ---------- files: cygwin-sys-executable.patch keywords: needs review, patch messages: 278651 nosy: erik.bray, masamoto, zach.ware priority: normal severity: normal status: open title: sys.executable is ambiguous on Cygwin without .exe suffix type: behavior versions: Python 3.7 Added file: http://bugs.python.org/file45091/cygwin-sys-executable.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Oct 14 11:01:36 2016 From: report at bugs.python.org (Siming Yuan) Date: Fri, 14 Oct 2016 15:01:36 +0000 Subject: [New-bugs-announce] [issue28442] tuple(a list subclass) does not iterate through the list Message-ID: <1476457296.79.0.655261011887.issue28442@psf.upfronthosting.co.za> New submission from Siming Yuan: if you subclass a list, and cast it to tuple, the casting does not iterate through the list. (casing to list does) for example, i needed a WeakList where the list only internally contains WeakReferences that gets deleted as soon as the object ref count goes to zero.. so: import weakref class WeakList(list): def __init__(self, items = ()): super(WeakList, self).__init__([weakref.ref(i, self.remove) for i in items]) def __contains__(self, item): return super(WeakList, self).__contains__(weakref.ref(item)) def __getitem__(self, index): if isinstance(index, slice): return [i() for i in super(WeakList, self).__getitem__(index)] else: return super(WeakList, self).__getitem__(index)() def __setitem__(self, index, item): if isinstance(index, slice): item = [weakref.ref(i, self.remove) for i in item] else: item = weakref.ref(item, self.remove) return super(WeakList, self).__setitem__(index, item) def __iter__(self): for i in list(super(WeakList, self).__iter__()): yield i() def remove(self, item): if isinstance(item, weakref.ReferenceType): super(WeakList, self).remove(item) else: super(WeakList, self).remove(weakref.ref(item)) def append(self, item): return super(WeakList, self).append(weakref.ref(item, self.remove)) # write some test code: class Dummy(): pass a = Dummy() b = Dummy() l = WeakList() l.append(a) l.append(b) print(a) <__main__.Dummy instance at 0x7f29993f4ab8> print(b) <__main__.Dummy instance at 0x7f29993f4b00> print(l) [, ] print([i for i in l]) [<__main__.Dummy instance at 0x7f29993f4ab8>, <__main__.Dummy instance at 0x7f29993f4b00>] print(list(l)) [<__main__.Dummy instance at 0x7f29993f4ab8>, <__main__.Dummy instance at 0x7f29993f4b00>] print(tuple(l)) (, ) ^ notice how you are getting weak references back instead of tuples. ---------- messages: 278652 nosy: siming85 priority: normal severity: normal status: open title: tuple(a list subclass) does not iterate through the list type: behavior versions: Python 2.7, Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Oct 14 11:09:14 2016 From: report at bugs.python.org (Jordan Brennan) Date: Fri, 14 Oct 2016 15:09:14 +0000 Subject: [New-bugs-announce] [issue28443] Logger methods never use kwargs Message-ID: <1476457754.13.0.399529764318.issue28443@psf.upfronthosting.co.za> New submission from Jordan Brennan: The methods on the Logger class e.g. logger.debug all accept **kwargs, these are passed to the _log method but they are never used. If _log attached them as an attribute to the LogRecord object, it would allow for creation of more powerful Filter objects to be created. You would then be able to filter log lines based on arbitrary keyword arguments. I've attached a patch along with tests that I think would be a sensible addition and I think that this shouldn't impact existing users of the module. ---------- components: Argument Clinic files: loggingkwargs.patch keywords: patch messages: 278653 nosy: jb098, larry priority: normal severity: normal status: open title: Logger methods never use kwargs type: enhancement versions: Python 3.7 Added file: http://bugs.python.org/file45092/loggingkwargs.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Oct 14 11:34:43 2016 From: report at bugs.python.org (Benny K J) Date: Fri, 14 Oct 2016 15:34:43 +0000 Subject: [New-bugs-announce] [issue28444] Missing extensions modules when cross compiling python 3.5.2 for arm on Linux Message-ID: <1476459283.66.0.870064519048.issue28444@psf.upfronthosting.co.za> New submission from Benny K J: When cross compiling Python for ARM many of the extension modules are not build However when compiling for the native platform the extension modules are properly build. Cross Compilation Steps ======================= CONFIG_SITE=config.site CC=arm-linux-gnueabihf-gcc CXX=arm-linux-gnueabihf-g++ AR=arm-linux-gnueabihf-ar RANLIB=arm-linux-gnueabihf-ranlib READELF=arm-linux-gnueabihf-readelf ./configure --enable-shared --host=arm-linux --build=x86_64-linux-gnu --disable-ipv6 --prefix=/opt/python3 make sudo PATH=/home/benny/workspace/projects/webshield/src/dntl_ws/sw/toolchain/gcc-linaro-4.9-2016.02-x86_64_arm-linux-gnueabihf/bin:$PATH make install Extension Modules Built when cross compiled =========================================== building '_ctypes_test' extension building 'cmath' extension building '_json' extension building '_testcapi' extension building '_testbuffer' extension building '_testimportmultiple' extension building '_testmultiphase' extension building '_lsprof' extension building '_opcode' extension building 'parser' extension building 'mmap' extension building 'audioop' extension building '_crypt' extension building '_csv' extension building 'termios' extension building 'resource' extension building 'nis' extension building '_multibytecodec' extension building '_codecs_kr' extension building '_codecs_jp' extension building '_codecs_cn' extension building '_codecs_tw' extension building '_codecs_hk' extension building '_codecs_iso2022' extension building '_decimal' extension building '_multiprocessing' extension building 'ossaudiodev' extension building 'xxlimited' extension building '_ctypes' extension Compilation Steps on x86 Machine ================================ CONFIG_SITE=config.site ./configure --enable-shared --disable-ipv6 --prefix=/opt/python3 make sudo make install Extension Modules Built when natively compiled =========================================== building '_struct' extension building '_ctypes_test' extension building 'array' extension building 'cmath' extension building 'math' extension building '_datetime' extension building '_random' extension building '_bisect' extension building '_heapq' extension building '_pickle' extension building '_json' extension building '_testcapi' extension building '_testbuffer' extension building '_testimportmultiple' extension building '_testmultiphase' extension building '_lsprof' extension building 'unicodedata' extension building '_opcode' extension building 'fcntl' extension building 'grp' extension building 'spwd' extension building 'select' extension building 'parser' extension building 'mmap' extension building 'syslog' extension building 'audioop' extension building 'readline' extension building '_crypt' extension building '_csv' extension building '_posixsubprocess' extension building '_socket' extension building '_sha256' extension building '_sha512' extension building '_md5' extension building '_sha1' extension building 'termios' extension building 'resource' extension building 'nis' extension building 'binascii' extension building 'pyexpat' extension building '_elementtree' extension building '_multibytecodec' extension building '_codecs_kr' extension building '_codecs_jp' extension building '_codecs_cn' extension building '_codecs_tw' extension building '_codecs_hk' extension building '_codecs_iso2022' extension building '_decimal' extension building '_multiprocessing' extension building 'ossaudiodev' extension building 'xxlimited' extension building '_ctypes' extension I've further tried building for ARM natively on ARM machine and the extensions was build successfully. Tool chain used for cross compilation ======================================= Using built-in specs. COLLECT_GCC=arm-linux-gnueabihf-gcc COLLECT_LTO_WRAPPER=/home/benny/workspace/projects/webshield/src/dntl_ws/sw/toolchain/gcc-linaro-4.9-2016.02-x86_64_arm-linux-gnueabihf/bin/../libexec/gcc/arm-linux-gnueabihf/4.9.4/lto-wrapper Target: arm-linux-gnueabihf Configured with: /home/tcwg-buildslave/workspace/tcwg-make-release/label/tcwg-x86_64-ex40/target/arm-linux-gnueabihf/snapshots/gcc-linaro-4.9-2016.02/configure SHELL=/bin/bash --with-bugurl=https://bugs.linaro.org --with-mpc=/home/tcwg-buildslave/workspace/tcwg-make-release/label/tcwg-x86_64-ex40/target/arm-linux-gnueabihf/_build/builds/destdir/x86_64-unknown-linux-gnu --with-mpfr=/home/tcwg-buildslave/workspace/tcwg-make-release/label/tcwg-x86_64-ex40/target/arm-linux-gnueabihf/_build/builds/destdir/x86_64-unknown-linux-gnu --with-gmp=/home/tcwg-buildslave/workspace/tcwg-make-release/label/tcwg-x86_64-ex40/target/arm-linux-gnueabihf/_build/builds/destdir/x86_64-unknown-linux-gnu --with-gnu-as --with-gnu-ld --disable-libstdcxx-pch --disable-libmudflap --with-cloog=no --with-ppl=no --with-isl=no --disable-nls --enable-c99 --with-tune=cortex-a9 --with-arch=armv7-a --with-fpu=vfpv3-d16 --with-float=hard --with-mode=thumb --disable-multilib --enable-multiarch --with-build-sysroot=/home/tcwg-buildslave/workspace/tcwg-make-release/label/tcwg-x86_64-ex40/target/arm-linux-gnueabihf/_build/sysroots/arm-linux-gnueabihf --enable-lto --enable-linker-build-id --enable-long-long --enable-shared --with-sysroot=/home/tcwg-buildslave/workspace/tcwg-make-release/label/tcwg-x86_64-ex40/target/arm-linux-gnueabihf/_build/builds/destdir/x86_64-unknown-linux-gnu/arm-linux-gnueabihf/libc --enable-languages=c,c++,fortran,lto --enable-checking=release --disable-bootstrap --with-bugurl=https://bugs.linaro.org --build=x86_64-unknown-linux-gnu --host=x86_64-unknown-linux-gnu --target=arm-linux-gnueabihf --prefix=/home/tcwg-buildslave/workspace/tcwg-make-release/label/tcwg-x86_64-ex40/target/arm-linux-gnueabihf/_build/builds/destdir/x86_64-unknown-linux-gnu Thread model: posix gcc version 4.9.4 20151028 (prerelease) (Linaro GCC 4.9-2016.02) Host Machine ============= Ubuntu 16.04.1 LTS Linux whachamacallit 4.4.0-42-generic #62-Ubuntu SMP Fri Oct 7 23:11:45 UTC 2016 x86_64 x86_64 x86_64 GNU/Linux ---------- components: Cross-Build, Extension Modules files: python_x86_host_arm_target_config.log messages: 278654 nosy: Alex.Willmer, bennykj priority: normal severity: normal status: open title: Missing extensions modules when cross compiling python 3.5.2 for arm on Linux versions: Python 3.5 Added file: http://bugs.python.org/file45093/python_x86_host_arm_target_config.log _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Oct 14 12:53:42 2016 From: report at bugs.python.org (Evgeny Kapun) Date: Fri, 14 Oct 2016 16:53:42 +0000 Subject: [New-bugs-announce] [issue28445] Wrong documentation for GzipFile.peek Message-ID: <1476464022.39.0.651124050997.issue28445@psf.upfronthosting.co.za> New submission from Evgeny Kapun: >From the documentation for GzipFile.peek(): At most one single read on the compressed stream is done to satisfy the call. If "compressed stream" means the underlying file object, then this is not true. The method tries to return at least one byte, unless the stream is at EOF. It is possible to create arbitrarily long compressed stream that would decompress to nothing, and the implementation would read the entire stream in this case. Because the length of the stream is not known in advance, several reads may be required for this. Perhaps the documentation for GzipFile.peek() should be made the same as that for BZ2File.peek() and LZMAFile.peek(). ---------- assignee: docs at python components: Documentation messages: 278656 nosy: abacabadabacaba, docs at python priority: normal severity: normal status: open title: Wrong documentation for GzipFile.peek versions: Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Oct 14 20:53:08 2016 From: report at bugs.python.org (Alex Regueiro) Date: Sat, 15 Oct 2016 00:53:08 +0000 Subject: [New-bugs-announce] [issue28446] pyvenv generates malformed hashbangs for scripts Message-ID: <1476492788.48.0.267846160291.issue28446@psf.upfronthosting.co.za> New submission from Alex Regueiro: Quotes around hashbangs are not recognised and are considered invalid syntax, at least on Bash on OS X 10.12. There's really no workaround (that I'm aware of) for paths containing spaces, except maybe symlinking the directory in the path the contains the space. Maybe a warning message about this would be best. To reproduce this issue, simply run the following from an empty directory that has a space in its path: ``` pyenv venv/ source ./venv/bin/activate pip ``` The result should be something like: ``` -bash: /Users/me/dir with space/foo/venv/bin/pip: "/Users/me/dir: bad interpreter: No such file or directory ``` ---------- messages: 278676 nosy: alexreg priority: normal severity: normal status: open title: pyvenv generates malformed hashbangs for scripts type: behavior versions: Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Oct 14 21:13:17 2016 From: report at bugs.python.org (George,Y) Date: Sat, 15 Oct 2016 01:13:17 +0000 Subject: [New-bugs-announce] [issue28447] socket.getpeername() failure on broken TCP/IP connection Message-ID: <1476493997.73.0.778740758656.issue28447@psf.upfronthosting.co.za> New submission from George,Y: I need to know the IP address on the other side of a broken TCP/IP connection. "socket.getpeername()" fails to do the job sometimes because the connection has been closed, and Windows Error 10038 tells the connection is no longer a socket so that the method getpeername is wrongly used. Here goes the code in main thread: ----------- mailbox = queue.Queue() read_sockets, write_sockets, error_sockets = select.select(active_socks,[],[],TIMEOUT) for sock in read_sockets: ...... except: mailbox.put( (("sock_err",sock), 'localhost') ) ========= The sub thread get this message from mailbox and try to analyze the broken socket, to simplify I put the code and output together: ------------- print(sock)>>> sock.getpeername()>>> OS.Error[WinError10038]an operation was attempted on something that is not a socket ======= Surprisingly, this kind of error happen occasionally - sometimes the socket object is normal and getpeername() works fine. So once a connection is broken, there is no way to tell the address to whom it connected? ---------- components: Library (Lib) files: socket?????.png messages: 278679 nosy: George,Y priority: normal severity: normal status: open title: socket.getpeername() failure on broken TCP/IP connection type: crash versions: Python 3.4 Added file: http://bugs.python.org/file45095/socket?????.png _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Oct 14 22:09:28 2016 From: report at bugs.python.org (INADA Naoki) Date: Sat, 15 Oct 2016 02:09:28 +0000 Subject: [New-bugs-announce] [issue28448] C implemented Future doesn't work on Windows Message-ID: <1476497368.18.0.628065389536.issue28448@psf.upfronthosting.co.za> New submission from INADA Naoki: _WaitCancelFuture in windows_events.py overrides _schedule_callbacks. C implemented Future should allow overriding _schedule_callbacks. Since `{"_future", PyInit__future},` is not in PC/config.c, _future is not registered as builtin module. So Python 3.6b2 doesn't use it. Instead of registering it, we should try make it split extension module (.pyd file). ---------- assignee: inada.naoki components: asyncio messages: 278685 nosy: gvanrossum, inada.naoki, yselivanov priority: normal severity: normal stage: needs patch status: open title: C implemented Future doesn't work on Windows type: enhancement versions: Python 3.6, Python 3.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Oct 15 05:07:44 2016 From: report at bugs.python.org (Silver Fox) Date: Sat, 15 Oct 2016 09:07:44 +0000 Subject: [New-bugs-announce] [issue28449] tarfile.open(mode = 'r:*', ignore_zeros = True) has 50% chance failed to open compressed tars? Message-ID: <1476522464.39.0.172513688494.issue28449@psf.upfronthosting.co.za> New submission from Silver Fox: Seems all `tarfile.open` will try all compress method(including `raw`) in random order, and `ignore_zeros` also hide the error during detecting compress method. So `raw` is used if tested before the rigth compress method, which is wrong. But there is no warning that the 2 args can not be used together in docs. ---------- components: Library (Lib) messages: 278711 nosy: Silver Fox priority: normal severity: normal status: open title: tarfile.open(mode = 'r:*', ignore_zeros = True) has 50% chance failed to open compressed tars? type: behavior versions: Python 3.4, Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Oct 15 07:00:13 2016 From: report at bugs.python.org (Lele Gaifax) Date: Sat, 15 Oct 2016 11:00:13 +0000 Subject: [New-bugs-announce] [issue28450] Misleading/inaccurate documentation about unknown escape sequences Message-ID: <1476529213.17.0.132534478532.issue28450@psf.upfronthosting.co.za> New submission from Lele Gaifax: Python 3.6+ is stricter about escaped sequences in string literals. The documentation need some improvement to clarify the change: for example https://docs.python.org/3.6/library/re.html#re.sub first says that ?Unknown escapes such as \& are left alone? then, in the ?Changed in? section below, states that ?[in Py3.6] Unknown escapes consisting of '\' and an ASCII letter now are errors?. When such changes are made, usually the documentation reports the ?new?/?current? behaviour, and the history section mention when and how some detail changed. See this thread for details: https://mail.python.org/pipermail/python-list/2016-October/715462.html ---------- assignee: docs at python components: Documentation messages: 278716 nosy: docs at python, lelit priority: normal severity: normal status: open title: Misleading/inaccurate documentation about unknown escape sequences versions: Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Oct 15 12:14:09 2016 From: report at bugs.python.org (Joon-Kyu Park) Date: Sat, 15 Oct 2016 16:14:09 +0000 Subject: [New-bugs-announce] [issue28451] pydoc.safeimport() raises ErrorDuringImport() if __builtin__.__import__ is monkey patched Message-ID: <1476548049.89.0.842528131727.issue28451@psf.upfronthosting.co.za> New submission from Joon-Kyu Park: `pydoc.safeimport()` should return `None` if the module isn't found. If Python's default `__import__` is monkey patched, (e.g., by using gevent) the function misbehaves. According to the current implementation, the function returns `None` by checking the only last entry of the traceback if `ImportError` is thrown during calling `__import__()`. If `__import__` is monkey patched, extra entries can be mixed into the original traceback when `ImportError` is raised. In the case when the module is not found, `ErrorDuringImport` is being raised rather than returning `None` after failing checking the traceback because current implementation only checks the last traceback entry. The important thing is to check whether `ImportError` is raised inside `safeimport()`, I think it's okay to check the whole traceback entries instead of checking the only last item. Please check the attached patch which I suggest. Thank you. ---------- components: Library (Lib) files: pydoc.patch keywords: patch messages: 278726 nosy: Joon-Kyu Park priority: normal severity: normal status: open title: pydoc.safeimport() raises ErrorDuringImport() if __builtin__.__import__ is monkey patched type: behavior versions: Python 2.7 Added file: http://bugs.python.org/file45102/pydoc.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Oct 15 16:13:30 2016 From: report at bugs.python.org (INADA Naoki) Date: Sat, 15 Oct 2016 20:13:30 +0000 Subject: [New-bugs-announce] [issue28452] Remove _asyncio._init_module function Message-ID: <1476562410.69.0.507034204748.issue28452@psf.upfronthosting.co.za> New submission from INADA Naoki: _asyncio._init_module() looks ugly. This patch imports external dependency when importing _asyncio. ---------- components: asyncio files: asyncio-speedup-refactoring.patch keywords: patch messages: 278731 nosy: gvanrossum, inada.naoki, yselivanov priority: normal severity: normal stage: patch review status: open title: Remove _asyncio._init_module function type: enhancement versions: Python 3.6, Python 3.7 Added file: http://bugs.python.org/file45104/asyncio-speedup-refactoring.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Oct 15 23:49:51 2016 From: report at bugs.python.org (=?utf-8?q?Alex_Gr=C3=B6nholm?=) Date: Sun, 16 Oct 2016 03:49:51 +0000 Subject: [New-bugs-announce] [issue28453] SSLObject.selected_alpn_protocol() not documented Message-ID: <1476589791.51.0.926571047111.issue28453@psf.upfronthosting.co.za> New submission from Alex Gr?nholm: the ssl.SSLObject class supports selected_alpn_protocol() like ssl.SSLSocket, but it is not mentioned on the list of supported methods. ---------- assignee: christian.heimes components: SSL messages: 278739 nosy: alex.gronholm, christian.heimes priority: normal severity: normal status: open title: SSLObject.selected_alpn_protocol() not documented versions: Python 3.5, Python 3.6, Python 3.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Oct 16 05:37:12 2016 From: report at bugs.python.org (Xiang Zhang) Date: Sun, 16 Oct 2016 09:37:12 +0000 Subject: [New-bugs-announce] [issue28454] Spurious arguments to PyErr_Format in unicodeobject.c Message-ID: <1476610632.81.0.393973042235.issue28454@psf.upfronthosting.co.za> New submission from Xiang Zhang: In unicodeobject.c, there are some spurious arguments to PyErr_Format as the patch shows. ---------- components: Interpreter Core files: spurious_argument.patch keywords: patch messages: 278757 nosy: ncoghlan, xiang.zhang priority: normal severity: normal stage: patch review status: open title: Spurious arguments to PyErr_Format in unicodeobject.c type: enhancement versions: Python 3.5, Python 3.6, Python 3.7 Added file: http://bugs.python.org/file45114/spurious_argument.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Oct 16 12:19:40 2016 From: report at bugs.python.org (siccegge) Date: Sun, 16 Oct 2016 16:19:40 +0000 Subject: [New-bugs-announce] [issue28455] argparse: convert_arg_line_to_args does not actually expect self argument Message-ID: <1476634780.92.0.551674237036.issue28455@psf.upfronthosting.co.za> New submission from siccegge: Hi! Both the 3.4 version and the current version of python documentation wrt the argparse module imply convert_arg_line_to_args replacements needs to accept two arguments while it acutally only works with one. (Not completely sure about details but documentation really could be clearer!) https://docs.python.org/3.4/library/argparse.html#argparse.ArgumentParser.convert_arg_line_to_args Example from documentation def convert_arg_line_to_args(self, arg_line): return arg_line.split() If codeparser = argparse.ArgumentParser actually does def convert_arg_line_to_args(self, arg_line): return arg_line.split() parser = argparse.ArgumentParser() parser.convert_arg_line_to_args = convert_arg_line_to_args The code fails File "/usr/lib/python3.5/argparse.py", line 1735, in parse_args args, argv = self.parse_known_args(args, namespace) File "/usr/lib/python3.5/argparse.py", line 1767, in parse_known_args namespace, args = self._parse_known_args(args, namespace) File "/usr/lib/python3.5/argparse.py", line 1779, in _parse_known_args arg_strings = self._read_args_from_files(arg_strings) File "/usr/lib/python3.5/argparse.py", line 2037, in _read_args_from_files for arg in self.convert_arg_line_to_args(arg_line): TypeError: convert_arg_line_to_args() missing 1 required positional argument: 'arg_line' ---------- assignee: docs at python components: Documentation messages: 278771 nosy: docs at python, siccegge priority: normal severity: normal status: open title: argparse: convert_arg_line_to_args does not actually expect self argument type: behavior versions: Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Oct 16 17:59:06 2016 From: report at bugs.python.org (Raymond Hettinger) Date: Sun, 16 Oct 2016 21:59:06 +0000 Subject: [New-bugs-announce] [issue28456] Test failures under macOS 10.12 Sierra Message-ID: <1476655146.34.0.248846726633.issue28456@psf.upfronthosting.co.za> New submission from Raymond Hettinger: On a fresh checkout, I'm getting two test failures: $ ./configure && make $ ./python.exe -m test.regrtest -v test_asyncore [snip] ====================================================================== FAIL: test_handle_expt (test.test_asyncore.TestAPI_UseIPv4Poll) ---------------------------------------------------------------------- Traceback (most recent call last): File "/Users/raymond/cleancpython/Lib/test/test_asyncore.py", line 674, in test_handle_expt self.loop_waiting_for_flag(client) File "/Users/raymond/cleancpython/Lib/test/test_asyncore.py", line 514, in loop_waiting_for_flag self.fail("flag not set") AssertionError: flag not set ====================================================================== FAIL: test_handle_expt (test.test_asyncore.TestAPI_UseIPv6Poll) ---------------------------------------------------------------------- Traceback (most recent call last): File "/Users/raymond/cleancpython/Lib/test/test_asyncore.py", line 674, in test_handle_expt self.loop_waiting_for_flag(client) File "/Users/raymond/cleancpython/Lib/test/test_asyncore.py", line 514, in loop_waiting_for_flag self.fail("flag not set") AssertionError: flag not set ---------------------------------------------------------------------- Ran 101 tests in 20.506s FAILED (failures=2, skipped=6) test test_asyncore failed test_asyncore failed 1 test failed: test_asyncore $ ./python.exe -m test.regrtest -v test_eintr [snip] ====================================================================== FAIL: test_poll (__main__.SelectEINTRTest) ---------------------------------------------------------------------- Traceback (most recent call last): File "/Users/raymond/cleancpython/Lib/test/eintrdata/eintr_tester.py", line 446, in test_poll self.assertGreaterEqual(dt, self.sleep_time) AssertionError: 9.176997991744429e-06 not greater than or equal to 0.2 ---------------------------------------------------------------------- Ran 22 tests in 5.288s FAILED (failures=1, skipped=5) --- stderr: --- Traceback (most recent call last): File "/Users/raymond/cleancpython/Lib/test/eintrdata/eintr_tester.py", line 492, in test_main() File "/Users/raymond/cleancpython/Lib/test/eintrdata/eintr_tester.py", line 488, in test_main SelectEINTRTest) File "/Users/raymond/cleancpython/Lib/test/support/__init__.py", line 1849, in run_unittest _run_suite(suite) File "/Users/raymond/cleancpython/Lib/test/support/__init__.py", line 1824, in _run_suite raise TestFailed(err) test.support.TestFailed: Traceback (most recent call last): File "/Users/raymond/cleancpython/Lib/test/eintrdata/eintr_tester.py", line 446, in test_poll self.assertGreaterEqual(dt, self.sleep_time) AssertionError: 9.176997991744429e-06 not greater than or equal to 0.2 --- ---------------------------------------------------------------------- Ran 1 test in 5.424s FAILED (failures=1) test test_eintr failed test_eintr failed 1 test failed: test_eintr Total duration: 5 sec Tests result: FAILURE ---------- components: Interpreter Core messages: 278780 nosy: rhettinger priority: normal severity: normal status: open title: Test failures under macOS 10.12 Sierra versions: Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Oct 16 19:42:23 2016 From: report at bugs.python.org (Raymond Hettinger) Date: Sun, 16 Oct 2016 23:42:23 +0000 Subject: [New-bugs-announce] [issue28457] Make public the current private known hash functions in the C-API Message-ID: <1476661343.12.0.903436836661.issue28457@psf.upfronthosting.co.za> New submission from Raymond Hettinger: The known-hash variants for dict getitem/setitem/delitem have proven useful to us for writing fast C code. They may be useful to others as well. There does not seem to be any other way of getting to this functionality. ---------- components: Interpreter Core messages: 278788 nosy: rhettinger priority: normal severity: normal status: open title: Make public the current private known hash functions in the C-API versions: Python 3.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Oct 17 03:56:45 2016 From: report at bugs.python.org (Attila-Mihaly Balazs) Date: Mon, 17 Oct 2016 07:56:45 +0000 Subject: [New-bugs-announce] [issue28458] from __future__ import print_function does not emulate the flush param from py3k Message-ID: <1476691005.05.0.512321507178.issue28458@psf.upfronthosting.co.za> New submission from Attila-Mihaly Balazs: Doing the following in Python 2.7.12 does not work: from __future__ import print_function print(1, flush=True) It says: "'flush' is an invalid keyword argument for this function" While the following is a perfectly valid python 3k statement: print(1, flush=True) ---------- components: Library (Lib) messages: 278797 nosy: Attila-Mihaly Balazs priority: normal severity: normal status: open title: from __future__ import print_function does not emulate the flush param from py3k versions: Python 3.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Oct 17 06:58:12 2016 From: report at bugs.python.org (Erik Bray) Date: Mon, 17 Oct 2016 10:58:12 +0000 Subject: [New-bugs-announce] [issue28459] _pyio module broken on Cygwin / setmode not usable Message-ID: <1476701892.4.0.598393414511.issue28459@psf.upfronthosting.co.za> New submission from Erik Bray: Since the patch to #24881 was merged the _pyio module has been non-importable on Cygwin, due to an attempt to import from the msvcrt module. However, the msvcrt module is not built on Cygwin (Cygwin does not use MSVCRT). Cygwin's libc does, however, have _setmode. The problem this is trying to solve is to call _setmode (https://msdn.microsoft.com/en-us/library/tw4k6df8.aspx) on file descriptors to ensure that they are O_BINARY instead of O_TEXT (a distinction that needs to made on Windows). Fortunately, on Cygwin, it is fairly rare that a file descriptor will have mode O_TEXT, but it it is possible. See https://cygwin.com/faq/faq.html#faq.programming.msvcrt-and-cygwin This could be tricky to solve though. Removing setmode() call entirely works for me as far as the test suite is concerned. But it leaves _pyio slightly incongruous with the C implementation in this one small aspect, and it *is* a bug. I would propose for Python 3.7 adding an os.setmode() function. On Windows this could be simply an alias for msvcrt.setmode() (or vice-versa). But because setmode() is available also in Cygwin (and technically some other platforms too, though none that are currently supported by Python) it would be a good candidate for inclusion in the os module I think (for those platforms that have it). ---------- components: IO messages: 278802 nosy: erik.bray priority: normal severity: normal status: open title: _pyio module broken on Cygwin / setmode not usable type: crash _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Oct 17 08:44:58 2016 From: report at bugs.python.org (Petr Pulc) Date: Mon, 17 Oct 2016 12:44:58 +0000 Subject: [New-bugs-announce] [issue28460] Minidom, order of attributes, datachars Message-ID: <1476708298.12.0.219819102875.issue28460@psf.upfronthosting.co.za> New submission from Petr Pulc: Hello, just an idea for improvement of minidom. Sometimes it is not convenient that the element attributes are sorted alphabetically. Usually, users do hack the minidom file themselves to force some behaviour, yet the order can be quite nicely defined by the DTD, for example. More on the "issue" side is another idea for improvement. Not all special characters do need to be changed to entities. For example, only < needs to be changed to entity in text data. I guess, that the _write_data function could be then diminished as well... What do you mean of these two ideas? Comments will be appreciated. ---------- components: XML messages: 278804 nosy: Petr Pulc priority: normal severity: normal status: open title: Minidom, order of attributes, datachars type: enhancement versions: Python 3.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Oct 17 09:20:48 2016 From: report at bugs.python.org (Pierre Nugues) Date: Mon, 17 Oct 2016 13:20:48 +0000 Subject: [New-bugs-announce] [issue28461] Replacement of re with the regex package Message-ID: <1476710448.23.0.62948086904.issue28461@psf.upfronthosting.co.za> New submission from Pierre Nugues: I am using Unicode regexes in the form of properties: \p{} and these are not standard in the re module. I have to use the new regex module, which has to be installed separately. I would like to see the replacement of re with regex in the future Python versions. I was not sure where to post my request and I used this bug tracker with the enhancement category. I hope this is not a mistake. ---------- components: Regular Expressions messages: 278806 nosy: ezio.melotti, mrabarnett, pnugues priority: normal severity: normal status: open title: Replacement of re with the regex package type: enhancement versions: Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Oct 17 11:38:04 2016 From: report at bugs.python.org (Vyacheslav Grigoryev) Date: Mon, 17 Oct 2016 15:38:04 +0000 Subject: [New-bugs-announce] [issue28462] subprocess pipe can't see EOF from a child in case of a few children run with subprocess Message-ID: <1476718684.05.0.447400261666.issue28462@psf.upfronthosting.co.za> New submission from Vyacheslav Grigoryev: I'm creating a master stand-alone module on Python which should run some children via subprocess module. Working with children is done in separate worker threads. Additionally I need to receive real-time output from a child so in a worker thread I also create reader helper thread which reads on a pipe from the child. All is working correctly while I have only one worker thread and run only one child. When the child finishes the reader helper thread gets EOF and exits. But when I have two worker threads and run two children, a pipe from early child doesn't see EOF until the second child is finished. Though they are completely unrelated. Let's take a look on simplest example for reproducing the problem. There is a simplest child: ------------------------------ import time, sys # first arg is an ID. Second arg is how long to work in seconds sys.stdout.write("start slave %s\n" % sys.argv[1]) sys.stdout.flush() time.sleep(int(sys.argv[2])) sys.stdout.write("finish slave %s\n" % sys.argv[1]) sys.stdout.flush() ------------------------------ And there is a master module: ------------------------------ import subprocess, sys, os, threading, time g_logLock = threading.Lock() def log(msg): with g_logLock: t = time.time() print "%s.%03d %-5s %s" % \ (time.strftime('%H:%M:%S', time.localtime(t)), int((t - t // 1) * 1000), threading.currentThread().name, msg) def thread1Proc(): def reader(stdout): while True: line = stdout.readline() if not line: break log('slave said: %s' % line.strip()) log('finish slave reader thread') log('thread 1 started') timeToWork = '1' util = subprocess.Popen((sys.executable, 'slave.py', '1', timeToWork), stdout=subprocess.PIPE) readerT = threading.Thread(target=reader, args=(util.stdout,), name='t1-r') readerT.start() log('slave 1 returned %d' % util.wait()) readerT.join() log('thread 1 finished') def thread2Proc(): log('thread 2 started') timeToWork = '3' util = subprocess.Popen((sys.executable, 'slave.py', '2', timeToWork)) log('slave 2 returned %d' % util.wait()) log('thread 2 finished') #--------------------------- log('starting test') threads = (threading.Thread(target=thread1Proc, name='t1'), threading.Thread(target=thread2Proc, name='t2')) for t in threads: t.start() for t in threads: t.join() log('finished test') ------------------------------ Here is what I see on the output (note - slave 1 outputs to the master via pipe, while slave 2 outputs to a console because its output is not redirected): >master.py 08:57:31.342 MainThread starting test 08:57:31.342 t1 thread 1 started 08:57:31.342 t2 thread 2 started 08:57:31.405 t1-r slave said: start slave 1 start slave 2 08:57:32.420 t1-r slave said: finish slave 1 08:57:32.420 t1 slave 1 returned 0 finish slave 2 08:57:34.415 t1-r finish slave reader thread 08:57:34.415 t2 slave 2 returned 0 08:57:34.415 t1 thread 1 finished 08:57:34.431 t2 thread 2 finished 08:57:34.431 MainThread finished test Here you can see that even if the slave 1 finishes at 32.420, its reader thread receives EOF and exits only when the slave 2 finishes also - at 34.415 (slave 1 works 1 second, slave 2 - 3 seconds). Why the reader thread doesn't see EOF just in time? The issue is reproduced in Python 2.7.12 x86 on Windows 7. On Linux Ubuntu 16.04 with system Python 2.7 all works as expected. ---------- components: Library (Lib) messages: 278809 nosy: Vyacheslav Grigoryev priority: normal severity: normal status: open title: subprocess pipe can't see EOF from a child in case of a few children run with subprocess type: behavior versions: Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Oct 17 13:08:59 2016 From: report at bugs.python.org (=?utf-8?b?0JrQvtC90YHRgtCw0L3RgtC40L0g0JLQvtC70LrQvtCy?=) Date: Mon, 17 Oct 2016 17:08:59 +0000 Subject: [New-bugs-announce] [issue28463] Email long headers parsing/serialization Message-ID: <1476724139.73.0.82516539768.issue28463@psf.upfronthosting.co.za> New submission from ?????????? ??????: There is strange thing with long headers serialized, they have \n prefix. Example fails on Python3.4/3.5: from email.message import Message from email import message_from_bytes x = '<147672320775.19544.6718708004153358411 at mkren-spb.root.devdomain.local>' header = 'Message-ID' msg = Message() msg[header] = x data = msg.as_bytes() msg2 = message_from_bytes(data) print(x) print(msg2[header]) assert msg2[header] == x MessageID was generated by email.utils.make_msgid function. ---------- components: email messages: 278820 nosy: barry, r.david.murray, ?????????? ?????? priority: normal severity: normal status: open title: Email long headers parsing/serialization versions: Python 3.4, Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Oct 17 17:54:11 2016 From: report at bugs.python.org (Chris Meyer) Date: Mon, 17 Oct 2016 21:54:11 +0000 Subject: [New-bugs-announce] [issue28464] BaseEventLoop.close should shutdown executor before marking itself closed Message-ID: <1476741251.72.0.37603874415.issue28464@psf.upfronthosting.co.za> New submission from Chris Meyer: BaseEventLoop.close shuts down the executor associated with the event loop. It should do that BEFORE it sets self._closed = True, otherwise any pending executor futures will attempt to 'call_soon' on the event loop when they finish, resulting in a confusing error message that the event loop is already closed. ---------- components: asyncio messages: 278829 nosy: cmeyer, gvanrossum, yselivanov priority: normal severity: normal status: open title: BaseEventLoop.close should shutdown executor before marking itself closed type: behavior versions: Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Oct 17 20:29:06 2016 From: report at bugs.python.org (=?utf-8?b?5pu55b+g?=) Date: Tue, 18 Oct 2016 00:29:06 +0000 Subject: [New-bugs-announce] [issue28465] python 3.5 magic number Message-ID: <1476750546.36.0.931772637731.issue28465@psf.upfronthosting.co.za> New submission from ??: On debian 9 and python 3.5.2: >>> imp.get_magic() b'\x17\r\r\n' On windows and python 3.5.2 >>> imp.get_magic() b'\x16\r\r\n' the same python version, magic number is the same, why not? ---------- components: Build messages: 278830 nosy: ?? priority: normal severity: normal status: open title: python 3.5 magic number type: behavior versions: Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Oct 17 22:52:22 2016 From: report at bugs.python.org (Ryan Petrello) Date: Tue, 18 Oct 2016 02:52:22 +0000 Subject: [New-bugs-announce] [issue28466] SIGALRM fails to interrupt time.sleep() call on Python 3.6 Message-ID: <1476759142.75.0.333626760319.issue28466@psf.upfronthosting.co.za> New submission from Ryan Petrello: I may have found a bug in SIGALRM handling in Python3.5. I've not been able to reproduce the same issue in Python2.7 or 3.4. Here's a simple example that illustrates the issue (which I'm able to reproduce on OS X 10.11.3 El Capitan and Ubuntu 14.04): $ python2 --version; python3.4 --version; python3.5 --version Python 2.7.11 Python 3.4.4 Python 3.5.1 $ cat alarm.py import signal, time def handler(signum, frame): print('Signal handler called with signal %s' % signum) # Set the signal handler and a 1-second alarm signal.signal(signal.SIGALRM, handler) signal.alarm(1) # We should not actually sleep for 10 seconds time.sleep(10) signal.alarm(0) $ time python2 alarm.py Signal handler called with signal 14 python2 alarm.py 0.04s user 0.02s system 5% cpu 1.075 total $ time python3.4 alarm.py Signal handler called with signal 14 python3.4 alarm.py 0.07s user 0.01s system 7% cpu 1.092 total $ time python3.5 alarm.py Signal handler called with signal 14 python3.5 alarm.py 0.09s user 0.02s system 1% cpu 10.115 total Note that when run under python3.5, the program does not exit until 10 seconds have passed. ---------- components: Library (Lib) messages: 278835 nosy: ryan.petrello priority: normal severity: normal status: open title: SIGALRM fails to interrupt time.sleep() call on Python 3.6 versions: Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Oct 18 03:36:23 2016 From: report at bugs.python.org (John Taylor) Date: Tue, 18 Oct 2016 07:36:23 +0000 Subject: [New-bugs-announce] [issue28467] Installer should be a 64-bit executable Message-ID: <1476776183.18.0.489973027211.issue28467@psf.upfronthosting.co.za> New submission from John Taylor: The python-3.6.0b2-amd64.exe binary installs the 64-bit version of python, but the binary itself is only 32-bit. I would like this to be a 64-bit binary so that Python can easily be installed on Windows Server 2016 Nano Server. Since this OS version will only execute 64-bit binaries, Python can not be installed even with the /quiet option. Ideally, I would like to be able to install Python with this command: python-3.6.0b2-amd64.exe /quiet targetdir=C:\Python36 ---------- components: Installation messages: 278844 nosy: jftuga priority: normal severity: normal status: open title: Installer should be a 64-bit executable type: behavior versions: Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Oct 18 04:47:38 2016 From: report at bugs.python.org (Christian Heimes) Date: Tue, 18 Oct 2016 08:47:38 +0000 Subject: [New-bugs-announce] [issue28468] Add platform.linux_os_release() Message-ID: <1476780458.76.0.0265588591799.issue28468@psf.upfronthosting.co.za> New submission from Christian Heimes: #1322 has deprecated platform.linux_distribution(). The feature is going to be removed without replacement functions in the stdlib. It's no longer possible to detect the Linux distribution from stdlib. Let's add a function to read /etc/os-release [1] instead. It's a very simple format and pretty standard for many years. [1] http://0pointer.de/blog/projects/os-release ---------- components: Library (Lib) messages: 278847 nosy: christian.heimes priority: normal severity: normal stage: test needed status: open title: Add platform.linux_os_release() type: enhancement versions: Python 3.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Oct 18 12:13:11 2016 From: report at bugs.python.org (STINNER Victor) Date: Tue, 18 Oct 2016 16:13:11 +0000 Subject: [New-bugs-announce] [issue28469] timeit: use powers of 2 in autorange(), instead of powers of 10 Message-ID: <1476807191.35.0.710869100873.issue28469@psf.upfronthosting.co.za> New submission from STINNER Victor: In the issue #28240, I changed the default repeat from 3 to 5 in timeit. Serhiy wrote (msg277157): "For now default timeit run takes from 0.8 to 8 sec. Adding yet 5 sec makes a user more angry." I propose to use powers to 2, instead of powers of 10, in timeit autorange to reduce the total duration of the microbenchmark. * Without the patch, the worst case: 4.0 * 6 = 24 seconds. * With the patch, the worst case is: 0.4 * 6 = 2.4 seconds * 6: autorange (1 iteration) + 5 repeatition * autorange uses a minimum of 200 ms, so the worst case is 200 ms * 10 before, or 200 ms * 2 after ---------- files: timeit_autorange_pow2.patch keywords: patch messages: 278899 nosy: haypo, serhiy.storchaka priority: normal severity: normal status: open title: timeit: use powers of 2 in autorange(), instead of powers of 10 type: performance versions: Python 3.7 Added file: http://bugs.python.org/file45134/timeit_autorange_pow2.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Oct 18 12:55:09 2016 From: report at bugs.python.org (Chris Byers) Date: Tue, 18 Oct 2016 16:55:09 +0000 Subject: [New-bugs-announce] [issue28470] configure.ac -g debug compiler option when not Py_DEBUG Message-ID: <1476809709.29.0.822288105247.issue28470@psf.upfronthosting.co.za> New submission from Chris Byers: The configure.ac file adds the "-g" debug compiler option to both debug and non-debug builds, so debug information is built for production builds. This seems likely a bug, unless there was a specific reason to do this. Around line 1480 of configure.ac: if test "$Py_DEBUG" = 'true' ; then # Optimization messes up debuggers, so turn it off for # debug builds. if "$CC" -v --help 2>/dev/null |grep -- -Og > /dev/null; then OPT="-g -Og -Wall $STRICT_PROTO" else OPT="-g -O0 -Wall $STRICT_PROTO" fi else OPT="-g $WRAP -O3 -Wall $STRICT_PROTO" fi The else case to the first statement (if test "$Py_DEBUG"...) should not contain -g should it? ---------- components: Build messages: 278910 nosy: Chris Byers priority: normal severity: normal status: open title: configure.ac -g debug compiler option when not Py_DEBUG versions: Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Oct 18 15:18:37 2016 From: report at bugs.python.org (Yury Selivanov) Date: Tue, 18 Oct 2016 19:18:37 +0000 Subject: [New-bugs-announce] [issue28471] Python 3.6b2 crashes with "Python memory allocator called without holding the GIL" Message-ID: <1476818317.21.0.812477817972.issue28471@psf.upfronthosting.co.za> New submission from Yury Selivanov: The following Python program causes a segfault in Python 3.6b2: import socket import asyncio loop = asyncio.get_event_loop() sock = socket.socket() sock.close() async def client(): reader, writer = await asyncio.open_connection( sock=sock, loop=loop) async def runner(): await client() loop.run_until_complete(runner()) ---------- components: Interpreter Core messages: 278921 nosy: haypo, inada.naoki, ned.deily, serhiy.storchaka, yselivanov priority: release blocker severity: normal status: open title: Python 3.6b2 crashes with "Python memory allocator called without holding the GIL" versions: Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Oct 18 18:14:47 2016 From: report at bugs.python.org (Roman Podoliaka) Date: Tue, 18 Oct 2016 22:14:47 +0000 Subject: [New-bugs-announce] [issue28472] SystemTap usage examples in docs are incorrect Message-ID: <1476828887.13.0.166885706979.issue28472@psf.upfronthosting.co.za> New submission from Roman Podoliaka: There are a couple of errors in SystemTap examples from "Instrumenting CPython with DTrace and SystemTap" page (https://docs.python.org/dev/howto/instrumentation.html): 1) in SystemTap double quotes are used to denote string literals. As is examples fail with: parse error: expected literal string or number saw: operator ''' at show_call.stp:1:15 source: probe process('python').mark("function__entry") { 2) stap -c option expects a command as a single string argument, not as a list of strings. As is the following example: $ stap \ show-call-hierarchy.stp \ -c ./python test.py will not run a test.py script, but instead ./python without any args, thus it will print a prompt (i.e. >>>) and wait for user input. ---------- assignee: docs at python components: Documentation files: patch.diff keywords: patch messages: 278944 nosy: docs at python, rpodolyaka priority: normal severity: normal status: open title: SystemTap usage examples in docs are incorrect versions: Python 3.6 Added file: http://bugs.python.org/file45138/patch.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Oct 18 18:39:26 2016 From: report at bugs.python.org (Garrett Nievin) Date: Tue, 18 Oct 2016 22:39:26 +0000 Subject: [New-bugs-announce] [issue28473] mailbox.MH crashes on certain Claws Mail .mh_sequences files Message-ID: <1476830366.57.0.390859510096.issue28473@psf.upfronthosting.co.za> New submission from Garrett Nievin: Using Claws Mail, and mailbox.MH crashes on two different conditions: 1) sequence spans lines, suchly: unseen: 1-222 225-300 990-1024 1048-2048 Not Pythonic, but I fixed it with this update: def get_sequences(self): """Return a name-to-key-list dictionary to define each sequence.""" results = {} with open(os.path.join(self._path, '.mh_sequences'), 'r', encoding='ASCII') as f: all_keys = set(self.keys()) for line in f: try: if line.count(':') == 0: contents = line else: name, contents = line.split(':') keys = set() for spec in contents.split(): if spec.isdigit(): keys.add(int(spec)) 2) Sequence spec appears to be open-ended on the front: 28119-28123 28127 28129 28131 28133-28142 28144-28154 28156-28172 28174-28189 28191-28204 28206-28218 28220-28224 28226 28228-28234 28237-28239 28119-28123 28127 28129 28131 28133-28142 28144-28154 28156-28163 28119-28123 28127 28129 28131 28133-28157 -27920 27923-27945 27947 I'm not sure how to interpret this, so just put in a kludgy fix to get my script running as a workaround (not using sequences). Would also be interested in an option to open a mailbox and process while ignoring sequences. ---------- components: Library (Lib) messages: 278945 nosy: garrettzilla priority: normal severity: normal status: open title: mailbox.MH crashes on certain Claws Mail .mh_sequences files type: crash versions: Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Oct 19 03:28:01 2016 From: report at bugs.python.org (Kelvin You) Date: Wed, 19 Oct 2016 07:28:01 +0000 Subject: [New-bugs-announce] [issue28474] WinError(): Python int too large to convert to C long Message-ID: <1476862081.01.0.00079290874453.issue28474@psf.upfronthosting.co.za> New submission from Kelvin You: // callproc.c static PyObject *format_error(PyObject *self, PyObject *args) { PyObject *result; wchar_t *lpMsgBuf; DWORD code = 0; if (!PyArg_ParseTuple(args, "|i:FormatError", &code)) ^ Here the format string should be "|I:FormatError" return NULL; if (code == 0) code = GetLastError(); lpMsgBuf = FormatError(code); if (lpMsgBuf) { result = PyUnicode_FromWideChar(lpMsgBuf, wcslen(lpMsgBuf)); LocalFree(lpMsgBuf); } else { result = PyUnicode_FromString(""); } return result; } ---------- components: ctypes messages: 278963 nosy: Kelvin You priority: normal severity: normal status: open title: WinError(): Python int too large to convert to C long type: crash versions: Python 2.7, Python 3.3, Python 3.4, Python 3.5, Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Oct 19 03:43:28 2016 From: report at bugs.python.org (Francisco Couzo) Date: Wed, 19 Oct 2016 07:43:28 +0000 Subject: [New-bugs-announce] [issue28475] Misleading error on random.sample when k < 0 Message-ID: <1476863008.28.0.194554202317.issue28475@psf.upfronthosting.co.za> New submission from Francisco Couzo: Improved a bit the error message when k < 0, and also added a comment about it on the documentation and an additional test case. ---------- assignee: docs at python components: Documentation, Library (Lib), Tests files: random_sample.patch keywords: patch messages: 278964 nosy: docs at python, franciscouzo priority: normal severity: normal status: open title: Misleading error on random.sample when k < 0 Added file: http://bugs.python.org/file45141/random_sample.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Oct 19 04:03:45 2016 From: report at bugs.python.org (Francisco Couzo) Date: Wed, 19 Oct 2016 08:03:45 +0000 Subject: [New-bugs-announce] [issue28476] Remove redundant definition of factorial on test_random Message-ID: <1476864225.97.0.189516103276.issue28476@psf.upfronthosting.co.za> Changes by Francisco Couzo : ---------- components: Tests files: test_random.patch keywords: patch nosy: franciscouzo priority: normal severity: normal status: open title: Remove redundant definition of factorial on test_random Added file: http://bugs.python.org/file45142/test_random.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Oct 19 13:34:22 2016 From: report at bugs.python.org (Josh Rosenberg) Date: Wed, 19 Oct 2016 17:34:22 +0000 Subject: [New-bugs-announce] [issue28477] Add optional user argument to pathlib.Path.home() Message-ID: <1476898462.87.0.214098648021.issue28477@psf.upfronthosting.co.za> New submission from Josh Rosenberg: os.path.expanduser supports both '~' and '~username` constructs to get home directories. It seems reasonable for pathlib.Path.home to default to getting the current user's home directory, but support passing an argument to get the home directory for another user. It means no need to use os.path.expanduser for the purpose (which always strikes me as a little "ugly" for portable code; the ~ works, but it's using UNIX syntax in a way that makes it feel non-portable), making pathlib a more complete replacement. ---------- components: Library (Lib) messages: 278988 nosy: josh.r priority: normal severity: normal status: open title: Add optional user argument to pathlib.Path.home() versions: Python 3.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Oct 19 17:02:02 2016 From: report at bugs.python.org (toast12) Date: Wed, 19 Oct 2016 21:02:02 +0000 Subject: [New-bugs-announce] [issue28478] Built-in module 'Time' does not enable functions if -Wno-error specified in the build environment Message-ID: <1476910922.79.0.695929522642.issue28478@psf.upfronthosting.co.za> New submission from toast12: Our build environment uses -Wno-error. However, this causes problems enabling all the functions in built-in module 'time': configure:11130: checking for strftime - - cc1: warnings being treated as errors conftest.c:236: error: conflicting types for built-in function 'strftime' Because strftime was not enabled, we had problems running xmlrpc.client: >>> from xmlrpc import client Traceback (most recent call last): File "", line 1, in File "XXX/lib64/python3.5/xmlrpc/client.py", line 267, in if _day0.strftime('%Y') == '0001': # Mac OS X AttributeError: module 'time' has no attribute 'strftime' >>> As a workaround, I am passing -fno-builtin now. But I believe this should be handled on the python end ---------- components: Extension Modules messages: 278993 nosy: toast12 priority: normal severity: normal status: open title: Built-in module 'Time' does not enable functions if -Wno-error specified in the build environment versions: Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Oct 19 18:37:18 2016 From: report at bugs.python.org (Julien) Date: Wed, 19 Oct 2016 22:37:18 +0000 Subject: [New-bugs-announce] [issue28479] Missing indentation in using/windows.rst Message-ID: <1476916638.92.0.768484757965.issue28479@psf.upfronthosting.co.za> New submission from Julien: Hi, In https://docs.python.org/3.7/using/windows.html, right before https://docs.python.org/3.7/using/windows.html#additional-modules, the "Changed in version 3.6:" content lacks an indentation. It look like it's nothing, but it breaks the PDF generation, by generating invalid latex. I attached the simple patch to fix this, and tested it, it's now rendered with the correct indentation and the PDF builds successfully. A grep -A10 -r 'versionchanged::$' show no other problems of indentation on those blocks (and shows this is the right way to fix it). ---------- assignee: docs at python components: Documentation files: using_windows_versionchanged.patch keywords: patch messages: 278996 nosy: docs at python, sizeof priority: normal severity: normal status: open title: Missing indentation in using/windows.rst type: enhancement versions: Python 3.6, Python 3.7 Added file: http://bugs.python.org/file45145/using_windows_versionchanged.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Oct 19 19:27:58 2016 From: report at bugs.python.org (Masayuki Yamamoto) Date: Wed, 19 Oct 2016 23:27:58 +0000 Subject: [New-bugs-announce] [issue28480] Compile error on Modules/socketmodule.c Message-ID: <1476919678.71.0.954266925792.issue28480@psf.upfronthosting.co.za> New submission from Masayuki Yamamoto: _socket module has failed to compile with --without-threads flag since 554fb699af8c, because Py_END_ALLOW_THREADS macro exists behind the done label ( Modules/socketmodule.c:666 ). If --without-threads flag goes on, Py_END_ALLOW_THREADS macro replaces to just right curly bracket. Therefore, between label and end of block have no statements. There needs meaningless statement (e.g. result = result;) to avoid compile error. I wrote a one line patch as a test. ---------- components: Build, Extension Modules files: socketmodule-behind-label.patch keywords: patch messages: 279000 nosy: masamoto priority: normal severity: normal status: open title: Compile error on Modules/socketmodule.c type: compile error versions: Python 3.6, Python 3.7 Added file: http://bugs.python.org/file45146/socketmodule-behind-label.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Oct 20 00:03:48 2016 From: report at bugs.python.org (MinJae Kwon) Date: Thu, 20 Oct 2016 04:03:48 +0000 Subject: [New-bugs-announce] [issue28481] Weird string comparison bug Message-ID: <1476936228.56.0.395643347684.issue28481@psf.upfronthosting.co.za> New submission from MinJae Kwon: I found bug i think about string comparison > var1 = 'aa' > var1 is 'aa' # This is True But if the string literal has special chacter (e.g., colon), the comparison results in False > var2 = ':bb' > var2 is ':bb' # This is False Check it please. ---------- components: Unicode messages: 279011 nosy: MinJae Kwon, ezio.melotti, haypo priority: normal severity: normal status: open title: Weird string comparison bug type: behavior versions: Python 2.7, Python 3.3, Python 3.4, Python 3.5, Python 3.6, Python 3.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Oct 20 00:23:14 2016 From: report at bugs.python.org (Martin Panter) Date: Thu, 20 Oct 2016 04:23:14 +0000 Subject: [New-bugs-announce] [issue28482] test_typing fails if asyncio unavailable Message-ID: <1476937394.99.0.275548920794.issue28482@psf.upfronthosting.co.za> New submission from Martin Panter: If you compile with ?configure --without-threads?, various tests are already skipped because they rely on multithreading. However test_typing does not seem to handle this. It tries to import ?asyncio?, which seems to depend on multithreading. I presume it is expected that asyncio requires multithreading, so perhaps the affected tests should be skipped in test_typing. Here is my attempt to skip them; please review. ---------- components: Tests files: st-typing.patch keywords: patch messages: 279013 nosy: gvanrossum, martin.panter priority: normal severity: normal stage: patch review status: open title: test_typing fails if asyncio unavailable type: behavior versions: Python 3.5, Python 3.6, Python 3.7 Added file: http://bugs.python.org/file45147/st-typing.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Oct 20 03:01:05 2016 From: report at bugs.python.org (Thomas Becker) Date: Thu, 20 Oct 2016 07:01:05 +0000 Subject: [New-bugs-announce] [issue28483] python --version prints output to stderr Message-ID: <1476946865.44.0.922931581834.issue28483@psf.upfronthosting.co.za> New submission from Thomas Becker: I am using Python 2.7.10 on Windows 8. While writing some code in NodeJS I noticed the following behaviour: `python --version` prints its output to stderr instead of stdout. In most cases this won't make any difference because both streams print to the screen. But if you want to handle the output streams separately it can cause confusion. Here is a piece of code to reproduce this behaviour (requires nodeJs): ``` var exec = require('child_process').exec; exec('python --version', function (err, stdout, stderr) { console.log('stdout: ' + JSON.stringify(stdout)); console.log('stderr: ' + JSON.stringify(stderr)); } ``` ---------- components: Windows messages: 279016 nosy: ctb, paul.moore, steve.dower, tim.golden, zach.ware priority: normal severity: normal status: open title: python --version prints output to stderr type: behavior versions: Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Oct 20 03:26:49 2016 From: report at bugs.python.org (Martin Panter) Date: Thu, 20 Oct 2016 07:26:49 +0000 Subject: [New-bugs-announce] [issue28484] test_capi, test_regrtest fail when multithreading disabled Message-ID: <1476948409.33.0.578194967575.issue28484@psf.upfronthosting.co.za> New submission from Martin Panter: Two tests in test_capi assume that the GIL is always used, but I don?t think it is available when Python is built with ?configure --without-threads?. So I propose to skip these tests if the ?threading? module is unavailable. In test_regrtest, a test is rerun using the -j2 option, which fails if multithreading is disabled. I propose to only run without -j2 if ?threading? does not import. Victor, I grouped these two changes together because both bits of code have your name on them. Hopefully you can give them a quick review :) ---------- components: Tests files: mt-victor.patch keywords: patch messages: 279017 nosy: haypo, martin.panter priority: normal severity: normal stage: patch review status: open title: test_capi, test_regrtest fail when multithreading disabled type: behavior versions: Python 3.6, Python 3.7 Added file: http://bugs.python.org/file45148/mt-victor.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Oct 20 03:39:19 2016 From: report at bugs.python.org (Martin Panter) Date: Thu, 20 Oct 2016 07:39:19 +0000 Subject: [New-bugs-announce] [issue28485] compileall.compile_dir(workers=) does not raise ValueError if multithreading disabled Message-ID: <1476949159.83.0.8638287974.issue28485@psf.upfronthosting.co.za> New submission from Martin Panter: According to the documentation and tests, a negative value for the ?workers? parameter to compileall.compile_dir() should trigger ValueError. But if Python is built with ?configure --without-threads?, the parameter is not checked. So I propose a patch to fix the implementation. ====================================================================== FAIL: test_compile_workers_non_positive (test.test_compileall.CompileallTests) ---------------------------------------------------------------------- Traceback (most recent call last): File "/home/proj/python/cpython/Lib/test/test_compileall.py", line 172, in test_compile_workers_non_positive compileall.compile_dir(self.directory, workers=-1) AssertionError: ValueError not raised ---------- files: mt-compile.patch keywords: patch messages: 279018 nosy: Claudiu.Popa, martin.panter priority: normal severity: normal stage: patch review status: open title: compileall.compile_dir(workers=) does not raise ValueError if multithreading disabled type: behavior versions: Python 3.5, Python 3.6, Python 3.7 Added file: http://bugs.python.org/file45149/mt-compile.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Oct 20 05:41:15 2016 From: report at bugs.python.org (Pavel Cisar) Date: Thu, 20 Oct 2016 09:41:15 +0000 Subject: [New-bugs-announce] [issue28486] Wrong end index and subgroup for group match Message-ID: <1476956475.68.0.446290119738.issue28486@psf.upfronthosting.co.za> New submission from Pavel Cisar: Hi, python re returns wrong end index of searched group and also subgroup itself. Example: In: price_string = u"1 307 000,00 K?" In: match = re.search(r"([,\.]00)\s?.*$", price_string) In: print price_string, "|", match.groups(), "|", match.group(0), "|", match.start(0), "|", match.end(0), "|", match.span() Out: 1?307?000,00?K? | (u',00',) | ,00?K? | 9 | 15 | (9, 15) As I understand documentation start and end functions should return start and endindex of subgroup matched in search. I .groups() output I see subgroup is correct u',00' but end function returns end index for subgroup ',00?K?'. Also calling specific subgroup .group(0) returns incorrect one ',00?K?'. It seems match return end index of whole pattern, not only subgroup. ---------- components: Regular Expressions messages: 279024 nosy: Pavel Cisar, ezio.melotti, mrabarnett priority: normal severity: normal status: open title: Wrong end index and subgroup for group match type: behavior versions: Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Oct 20 08:11:43 2016 From: report at bugs.python.org (Skip Montanaro) Date: Thu, 20 Oct 2016 12:11:43 +0000 Subject: [New-bugs-announce] [issue28487] missing _math.o target in 2.7 Makefile Message-ID: <1476965503.55.0.0398048530012.issue28487@psf.upfronthosting.co.za> New submission from Skip Montanaro: Unless I have my hg repo dependencies incorrect, this target seems to be missing from the 2.7 Makefile.pre.in: # This is shared by the math and cmath modules Modules/_math.o: Modules/_math.c Modules/_math.h $(CC) -c $(CCSHARED) $(PY_CORE_CFLAGS) -o $@ $< My cpython repo pulls from https://hg.python.org/cpython, My 2.7 repo pulls from my cpython repo. I have other branches to build older 3.x versions which also pull from my cpython repo. The math and cmath modules build fine, though they don't seem to have that target either. So perhaps I'm barking up the wrong tree. Either way, 2.7 won't build properly for me unless I explicitly execute make Modules/_math.o ---------- components: Build messages: 279028 nosy: skip.montanaro priority: normal severity: normal status: open title: missing _math.o target in 2.7 Makefile versions: Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Oct 20 09:07:50 2016 From: report at bugs.python.org (Alexander Belchenko) Date: Thu, 20 Oct 2016 13:07:50 +0000 Subject: [New-bugs-announce] [issue28488] shutil.make_archive (xxx, zip, root_dir) is adding './' entry to archive which is wrong Message-ID: <1476968870.46.0.0294634101167.issue28488@psf.upfronthosting.co.za> New submission from Alexander Belchenko: Running shutil.make_archive('a', 'zip', 'subdir') is created wrong and not really needed entry "./" which is visible in zipfile.ZipFile.namelist(): ['./', 'foo/', 'hello.txt', 'foo/bar.txt'] This "./" affects some (windows) unzip tools which produces warnings/errors about this incorrect entry. This error present in Python 2.7.11-12 and Python 3.4.4 (those I have installed right now). But Python 3.3.5 does not have it, maybe because it omits entries for directories at all. I've attached a simple script which illustrates problem. Tested on Windows with mentioned python versions. Can't reproduce on Centos 7.2 with Python 3.4.3 and 2.7.5. I suppose it could be realted to the change I spot in latest 2.7 changelog: - Issue #24982: shutil.make_archive() with the "zip" format now adds entries for directories (including empty directories) in ZIP file. ---------- components: Library (Lib) files: make-archive-test.py messages: 279031 nosy: bialix priority: normal severity: normal status: open title: shutil.make_archive (xxx, zip, root_dir) is adding './' entry to archive which is wrong versions: Python 2.7, Python 3.4 Added file: http://bugs.python.org/file45151/make-archive-test.py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Oct 20 13:23:36 2016 From: report at bugs.python.org (Ryan Gonzalez) Date: Thu, 20 Oct 2016 17:23:36 +0000 Subject: [New-bugs-announce] [issue28489] Fix comment in tokenizer.c Message-ID: <1476984216.11.0.150131580141.issue28489@psf.upfronthosting.co.za> New submission from Ryan Gonzalez: Attached is a little fix for a comment in tokenizer.c. I noticed that it was never updated for the inclusion of f-strings. ---------- assignee: docs at python components: Documentation files: 0001-Fix-comment-in-tokenizer.c.patch keywords: patch messages: 279056 nosy: Ryan.Gonzalez, docs at python priority: normal severity: normal status: open title: Fix comment in tokenizer.c versions: Python 3.6 Added file: http://bugs.python.org/file45156/0001-Fix-comment-in-tokenizer.c.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Oct 20 14:03:19 2016 From: report at bugs.python.org (Steve Newcomb) Date: Thu, 20 Oct 2016 18:03:19 +0000 Subject: [New-bugs-announce] [issue28490] inappropriate OS.Error "Invalid cross-device link" Message-ID: <1476986599.39.0.831888173256.issue28490@psf.upfronthosting.co.za> New submission from Steve Newcomb: os.rename() raises OSError with a misleading message saying "cross-device" when no cross-device activity is involved. Here, running on Ubuntu 16.04.1 using and ext4 filesystem, both filepaths are in the same filesystem, and the error is evidently due to the fact that a file already exists at the target path: (Pdb) os.path.isfile( '/persist/nobackup/backupDisks/d38BasLijPupBak/d38-backup.20161020/d38-_,.,_home2_,.,_rack/.Xauthority') True (Pdb) os.path.isfile( '/persist/nobackup/backupDisks/d38BasLijPupBak/d38-20161020/home2/rack/.Xauthority') True (Pdb) os.rename( '/persist/nobackup/backupDisks/d38BasLijPupBak/d38-backup.20161020/d38-_,.,_home2_,.,_rack/.Xauthority', '/persist/nobackup/backupDisks/d38BasLijPupBak/d38-20161020/home2/rack/.Xauthor\ ity') *** OSError: [Errno 18] Invalid cross-device link: '/persist/nobackup/backupDisks/d38BasLijPupBak/d38-backup.20161020/d38-_,.,_home2_,.,_rack/.Xauthority' -> '/persist/nobackup/backupDisks/d38BasLijPup\ Bak/d38-20161020/home2/rack/.Xauthority' ---------- components: IO messages: 279061 nosy: steve.newcomb priority: normal severity: normal status: open title: inappropriate OS.Error "Invalid cross-device link" versions: Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Oct 20 14:40:27 2016 From: report at bugs.python.org (Zachary Ware) Date: Thu, 20 Oct 2016 18:40:27 +0000 Subject: [New-bugs-announce] [issue28491] Remove bundled libffi for OSX Message-ID: <1476988827.6.0.878520006506.issue28491@psf.upfronthosting.co.za> New submission from Zachary Ware: Here's a patch that at least allows _ctypes to be built against a Homebrew libffi and pass the test_ctypes. It is almost certainly not a complete patch, but may serve as a basis for something that will actually work. ---------- components: Build, ctypes, macOS files: remove_libffi_osx.diff keywords: patch messages: 279063 nosy: Chi Hsuan Yen, matrixise, ned.deily, r.david.murray, ronaldoussoren, zach.ware priority: normal severity: normal stage: test needed status: open title: Remove bundled libffi for OSX type: enhancement versions: Python 3.7 Added file: http://bugs.python.org/file45157/remove_libffi_osx.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Oct 20 15:42:44 2016 From: report at bugs.python.org (Yury Selivanov) Date: Thu, 20 Oct 2016 19:42:44 +0000 Subject: [New-bugs-announce] [issue28492] C implementation of asyncio.Future doesn't set value of StopIteration correctly Message-ID: <1476992564.36.0.624486466512.issue28492@psf.upfronthosting.co.za> New submission from Yury Selivanov: Specifically when the result of the Future is tuple. ---------- components: asyncio messages: 279070 nosy: gvanrossum, inada.naoki, yselivanov priority: normal severity: normal status: open title: C implementation of asyncio.Future doesn't set value of StopIteration correctly versions: Python 3.6, Python 3.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Oct 20 16:27:58 2016 From: report at bugs.python.org (=?utf-8?q?St=C3=A9phane_Wirtel?=) Date: Thu, 20 Oct 2016 20:27:58 +0000 Subject: [New-bugs-announce] [issue28493] Typo in _asynciomodule.c Message-ID: <1476995278.57.0.754389897949.issue28493@psf.upfronthosting.co.za> New submission from St?phane Wirtel: a small fix for a typo. ---------- assignee: yselivanov components: Interpreter Core files: _asynciomodule.diff keywords: patch messages: 279079 nosy: matrixise, yselivanov priority: normal severity: normal status: open title: Typo in _asynciomodule.c versions: Python 3.7 Added file: http://bugs.python.org/file45161/_asynciomodule.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Oct 20 17:08:49 2016 From: report at bugs.python.org (Thomas Waldmann) Date: Thu, 20 Oct 2016 21:08:49 +0000 Subject: [New-bugs-announce] [issue28494] is_zipfile false positives Message-ID: <1476997729.0.0.643464084789.issue28494@psf.upfronthosting.co.za> New submission from Thomas Waldmann: zipfile.is_zipfile has false positives way too easily. I just have seen it in practive when a MoinMoin wiki site with a lot of pdf attachments crashed with 500. This was caused by a valid PDF that just happened to contain PK\005\006 somewhere in the middle - this was enough to satisfy is_zipfile() and triggered further processing as a zipfile, which then crashed with IOError (which was not catched in our code, yet). I have looked into zipfile code: if the usual EOCD structure (with empty comment) is not at EOF, it is suspected that there might be a non-empty comment and ~64K before EOF are searched for the PK\005\006 magic. If it is somewhere there, it is assumed that the file is a zip, without any further validity check. Attached is a failure demo that works with at least 2.7 and 3.5. https://en.wikipedia.org/wiki/Zip_(file_format) ---------- components: Library (Lib) files: isz_fail.py messages: 279084 nosy: Thomas.Waldmann priority: normal severity: normal status: open title: is_zipfile false positives type: behavior versions: Python 2.7, Python 3.5 Added file: http://bugs.python.org/file45162/isz_fail.py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Oct 20 22:06:08 2016 From: report at bugs.python.org (=?utf-8?b?0KHQtdGA0LPQtdC5INCS0LDRgNGO0YXQuNC9?=) Date: Fri, 21 Oct 2016 02:06:08 +0000 Subject: [New-bugs-announce] =?utf-8?q?=5Bissue28495=5D_MagickMock_created?= =?utf-8?q?_by_pat=D1=81h_annotation_refuses_to_apply_function_side=5Feffe?= =?utf-8?q?ct_at_second_time?= Message-ID: <1477015568.71.0.157250761627.issue28495@psf.upfronthosting.co.za> New submission from ?????? ???????: You can see example in test.py. It should fails with AssertionErorr if mock works as expected. But it not fails. ---------- components: Library (Lib) files: test.py messages: 279098 nosy: ?????? ??????? priority: normal severity: normal status: open title: MagickMock created by pat?h annotation refuses to apply function side_effect at second time type: behavior versions: Python 3.4 Added file: http://bugs.python.org/file45166/test.py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Oct 21 06:07:25 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Fri, 21 Oct 2016 10:07:25 +0000 Subject: [New-bugs-announce] [issue28496] Mark up constants 0, 1, -1 in C API docs Message-ID: <1477044445.15.0.0158550181363.issue28496@psf.upfronthosting.co.za> New submission from Serhiy Storchaka: Proposed patch marks up constants 0, 1 and -1 (mostly return values) in C API documentation as literal test. Most occurrences already are marked up. It also changes :const:`ULONG_MAX + 1` to ``ULONG_MAX + 1``, since this is not a constant name. ---------- assignee: serhiy.storchaka components: Documentation files: doc_consts_01.patch keywords: patch messages: 279114 nosy: serhiy.storchaka priority: normal severity: normal stage: patch review status: open title: Mark up constants 0, 1, -1 in C API docs type: enhancement versions: Python 2.7, Python 3.5, Python 3.6, Python 3.7 Added file: http://bugs.python.org/file45171/doc_consts_01.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Oct 21 12:38:11 2016 From: report at bugs.python.org (Miguel) Date: Fri, 21 Oct 2016 16:38:11 +0000 Subject: [New-bugs-announce] [issue28497] future in tkinter Message-ID: <1477067891.18.0.627340061363.issue28497@psf.upfronthosting.co.za> New submission from Miguel: I load the future package. In the new package installed here: python2.7/dist-packages/tkinter/__init__.py it's not possible to import _default_root. One possible solution is to create a method in tkinter module that returns the _default_root object. ``` def default_root(): return _default_root ``` ---------- components: Tkinter messages: 279139 nosy: tkinter priority: normal severity: normal status: open title: future in tkinter versions: Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Oct 21 13:19:17 2016 From: report at bugs.python.org (Pierre Bousquie) Date: Fri, 21 Oct 2016 17:19:17 +0000 Subject: [New-bugs-announce] [issue28499] Logging module documentation needs a rework. Message-ID: <1477070357.17.0.711656351025.issue28499@psf.upfronthosting.co.za> New submission from Pierre Bousquie: At pyconf-fr 2016 Florian Strzelecki (@Exirel) made a great talk on how to make good documentation. At one time he asked "python logging doc?, did you realy found it clear and helpfull?" clear answer from the crowd: not at all. Stephane Wirtel ask us (the unhappy folks) : Hey send a bug request, then the pull request and... i'll be there to help :). So i'm here for first step: fill the bug issue. I'm willing to fix this doc! ---------- assignee: docs at python components: Documentation messages: 279141 nosy: Pierre Bousquie, docs at python priority: normal severity: normal status: open title: Logging module documentation needs a rework. type: enhancement versions: Python 2.7, Python 3.3, Python 3.4, Python 3.5, Python 3.6, Python 3.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Oct 21 13:03:43 2016 From: report at bugs.python.org (Miguel) Date: Fri, 21 Oct 2016 17:03:43 +0000 Subject: [New-bugs-announce] [issue28498] tk busy command Message-ID: <1477069423.12.0.229038359578.issue28498@psf.upfronthosting.co.za> New submission from Miguel: tcl tk 8.6.6 has a new busy command. The new tkinter library doesn't provide an interface for this command. https://www.tcl.tk/man/tcl/TkCmd/busy.htm The solution is to add to the class Misc of tkinter these methods: def tk_busy(self, *args, **kw): self.tk_busy_hold(*args, **kw) def tk_buy_hold(self, cnf=None, **kw) self.tk.call(('tk', 'busy', 'hold', self._w) + self._options(cnf, kw)) def tk_buy_configure(self, cnf=None, **kw): self.tk.call(('tk', 'busy', 'configure', self._w) + self._options(cnf, kw)) def tk_cget(self, option): return self.tk.call('tk', 'busy', 'cget', self._w, option) def tk_busy_forget(self): self.tk_call('tk', 'busy', 'forget', self._w) def tk_busy_current(self, pattern=None): if pattern is None: self.tk.call('tk', 'busy', 'current') else: self.tk.call('tk', 'busy', 'current', pattern) def tk_busy_status(self): return self.tk.call('tk', 'busy', 'status', self._w) ---------- components: Tkinter messages: 279140 nosy: tkinter priority: normal severity: normal status: open title: tk busy command versions: Python 2.7, Python 3.3, Python 3.4, Python 3.5, Python 3.6, Python 3.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Oct 21 17:11:10 2016 From: report at bugs.python.org (Yury Selivanov) Date: Fri, 21 Oct 2016 21:11:10 +0000 Subject: [New-bugs-announce] [issue28500] pep 525/asyncio: Handle when async generators are GCed from another thread Message-ID: <1477084270.15.0.264547427844.issue28500@psf.upfronthosting.co.za> New submission from Yury Selivanov: Proxy for https://github.com/python/asyncio/pull/447 ---------- assignee: yselivanov components: asyncio messages: 279154 nosy: gvanrossum, yselivanov priority: normal severity: normal stage: resolved status: open title: pep 525/asyncio: Handle when async generators are GCed from another thread versions: Python 3.6, Python 3.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Oct 22 01:31:45 2016 From: report at bugs.python.org (Ed Schouten) Date: Sat, 22 Oct 2016 05:31:45 +0000 Subject: [New-bugs-announce] [issue28501] [Patch] Make os.umask() optional Message-ID: <1477114305.1.0.982549548127.issue28501@psf.upfronthosting.co.za> New submission from Ed Schouten: CloudABI is a POSIX-like strongly sandboxed runtime environment, for which we got Python to work (https://mail.python.org/pipermail/python-dev/2016-July/145708.html). Patches for this are slowly being upstreamed. As CloudABI uses a capability-based security model as opposed to a discretionary access control system, there is no support for UNIX credentials and permissions. This means that umask() is also absent. It looks like umask() is only used by Python in its posixmodule. The attached patch adds a new Autoconf check and adds the proper #if logic around its implementation. Changes to the Autoconf/Automake files are not provided by this patch, as my versions of these tools generate files containing unnecessary changes. ---------- components: Extension Modules files: umask-optional.diff keywords: patch messages: 279182 nosy: EdSchouten priority: normal severity: normal status: open title: [Patch] Make os.umask() optional versions: Python 3.6 Added file: http://bugs.python.org/file45183/umask-optional.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Oct 22 01:46:35 2016 From: report at bugs.python.org (Ed Schouten) Date: Sat, 22 Oct 2016 05:46:35 +0000 Subject: [New-bugs-announce] [issue28502] [Patch] Make os.chdir() optional Message-ID: <1477115195.1.0.580287867342.issue28502@psf.upfronthosting.co.za> New submission from Ed Schouten: CloudABI is a POSIX-like strongly sandboxed runtime environment, for which we got Python to work (https://mail.python.org/pipermail/python-dev/2016-July/145708.html). Patches for this are slowly being upstreamed. CloudABI uses a capability-based security model, similar to Capsicum (https://www.cl.cam.ac.uk/research/security/capsicum/). With this model, the file system can only be accessed by using file descriptors to directories. Files inside of them can be used by using openat() (in Python: os.open(dirfd=...). This means that there is no need to provide support for process working directories. chdir() is therefore entirely absent. It looks like chdir() is only used by Python in its posixmodule. The attached patch adds a new Autoconf check and adds the proper #if logic around its implementation. Changes to the Autoconf/Automake files are not provided by this patch, as my versions of these tools generate files containing unnecessary changes. ---------- components: Extension Modules files: chdir-optional.diff keywords: patch messages: 279183 nosy: EdSchouten priority: normal severity: normal status: open title: [Patch] Make os.chdir() optional versions: Python 3.6 Added file: http://bugs.python.org/file45184/chdir-optional.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Oct 22 03:52:55 2016 From: report at bugs.python.org (Ed Schouten) Date: Sat, 22 Oct 2016 07:52:55 +0000 Subject: [New-bugs-announce] [issue28503] [Patch] '_crypt' module: fix implicit declaration of crypt(), use crypt_r() where available Message-ID: <1477122775.81.0.204871394378.issue28503@psf.upfronthosting.co.za> New submission from Ed Schouten: The '_crypt' module provides a binding to the C crypt(3) function. It is used by the crypt.crypt() function. Looking at the C code, there are a couple of things we can improve: - Because crypt() only depends on primitive C types, we currently get away with calling it without it being declared. Ensure that we include , which is the POSIX header file declaring this. - The disadvantage of crypt() is that it's thread-unsafe. Systems like Linux and recent versions of FreeBSD nowadays provide crypt_r() as a replacement. This function allows you to pass in a 'crypt_data' object that will hold the resulting string for you. Extend the code to use this function when available. This patch is actually needed to make this module build on CloudABI (https://mail.python.org/pipermail/python-dev/2016-July/145708.html). CloudABI's C library doesn't provide any thread-unsafe functions, meaning that crypt_r() is the only way you can crypt passwords. ---------- components: Extension Modules files: crypt.diff keywords: patch messages: 279186 nosy: EdSchouten priority: normal severity: normal status: open title: [Patch] '_crypt' module: fix implicit declaration of crypt(), use crypt_r() where available versions: Python 3.6 Added file: http://bugs.python.org/file45185/crypt.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Oct 22 11:25:14 2016 From: report at bugs.python.org (Xiang Zhang) Date: Sat, 22 Oct 2016 15:25:14 +0000 Subject: [New-bugs-announce] [issue28504] Cleanup unicode_decode_call_errorhandler_wchar/writer Message-ID: <1477149914.47.0.152397016067.issue28504@psf.upfronthosting.co.za> New submission from Xiang Zhang: The patch makes several cleanups to unicode_decode_call_errorhandler_wchar/writer: 1. Use U instead O! for argument parser, it ought to be more efficient and write less code. 2. In theory, if inputobj is not bytes, there needs to be a goto onError, or it could crash. But PyUnicodeDecodeError_GetObject is guaranteed to return bytes, so we can remove the incomplete branch. 3. On success, we don't need Xdecref. ---------- components: Interpreter Core files: unicode_decode_call_errorhandler_*.patch keywords: patch messages: 279198 nosy: haypo, serhiy.storchaka, xiang.zhang priority: normal severity: normal stage: patch review status: open title: Cleanup unicode_decode_call_errorhandler_wchar/writer type: enhancement versions: Python 3.7 Added file: http://bugs.python.org/file45189/unicode_decode_call_errorhandler_*.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Oct 22 11:47:17 2016 From: report at bugs.python.org (Wojtek Swiatek) Date: Sat, 22 Oct 2016 15:47:17 +0000 Subject: [New-bugs-announce] [issue28505] pip installation issues with default path on Windows Message-ID: <1477151237.91.0.234072346279.issue28505@psf.upfronthosting.co.za> New submission from Wojtek Swiatek: When installing Python 3.5 on Windows (I checked the 64bits installer but I believe the same issue will be with the 32bits), the default installation path when installing for "everyone" is now C:\ Program Files\Python35. When subsequently installing packages via pip, the installation crashes midway with a cryptic error about "permission denied" (if I remember correctly). I checked with the cryptography module. It is not an issue with access rights but with the whitespace in "Program Files". Reinstalling Python to C:\Python35 fixes the issue (pip install cryptography runs correctly). ---------- components: Installation messages: 279199 nosy: Wojtek Swiatek priority: normal severity: normal status: open title: pip installation issues with default path on Windows type: behavior versions: Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Oct 22 12:30:52 2016 From: report at bugs.python.org (Justin Ting) Date: Sat, 22 Oct 2016 16:30:52 +0000 Subject: [New-bugs-announce] [issue28506] Multiprocessing Pool starmap - struct.error: 'i' format requires -2e10<=n<=2e10 Message-ID: <1477153852.62.0.286648862234.issue28506@psf.upfronthosting.co.za> New submission from Justin Ting: Multiprocessing is throwing this error when dealing with large amounts of data (all floating points an integers), but none of which exceeds the number boundaries in the error that it throws: File "/root/anaconda3/lib/python3.5/multiprocessing/pool.py", line 268, in starmap return self._map_async(func, iterable, starmapstar, chunksize).get() File "/root/anaconda3/lib/python3.5/multiprocessing/pool.py", line 608, in get raise self._value File "/root/anaconda3/lib/python3.5/multiprocessing/pool.py", line 385, in _handle_tasks put(task) File "/root/anaconda3/lib/python3.5/multiprocessing/connection.py", line 206, in send self._send_bytes(ForkingPickler.dumps(obj)) File "/root/anaconda3/lib/python3.5/multiprocessing/connection.py", line 393, in _send_bytes header = struct.pack("!i", n) struct.error: 'i' format requires -2147483648 <= number <= 2147483647 > /root/anaconda3/lib/python3.5/multiprocessing/connection.py(393)_send_bytes() -> header = struct.pack("!i", n) It works fine on any number of subsets of this data, but not when put together. ---------- components: Library (Lib) messages: 279200 nosy: Justin Ting priority: normal severity: normal status: open title: Multiprocessing Pool starmap - struct.error: 'i' format requires -2e10<=n<=2e10 type: behavior versions: Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Oct 22 12:56:11 2016 From: report at bugs.python.org (Chi Hsuan Yen) Date: Sat, 22 Oct 2016 16:56:11 +0000 Subject: [New-bugs-announce] [issue28507] Regenerate ./configure on the default branch Message-ID: <1477155371.02.0.736357632927.issue28507@psf.upfronthosting.co.za> New submission from Chi Hsuan Yen: In 0ea088671bc2 and 3ce29b2452f0, --runstatedir was added to ./configure. Seems Benjamin uses a slightly different version of autoconf than 2.69. As a result, modifying ./configure.ac leads to unrelated changes in ./configure. Later in 17bd5239b886, this option is removed from 3.6 branch. The issue is still in the default branch. Can anyone apply 17bd5239b886 to the default branch? Added authors of aforementioned commits. ---------- components: Build messages: 279204 nosy: Chi Hsuan Yen, benjamin.peterson, ned.deily priority: normal severity: normal status: open title: Regenerate ./configure on the default branch type: behavior versions: Python 3.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Oct 22 13:35:42 2016 From: report at bugs.python.org (Raymond Hettinger) Date: Sat, 22 Oct 2016 17:35:42 +0000 Subject: [New-bugs-announce] [issue28508] Need way to expose incremental size of key sharing dicts Message-ID: <1477157742.67.0.432701852962.issue28508@psf.upfronthosting.co.za> New submission from Raymond Hettinger: In many Python programs much of the memory utilization is due to having many instances of the same object. We have key-sharing dicts that reduce the cost by storing only in the incremental values. It would be nice to have visibility to the savings. One possible way to do this is to have sys.getsizeof(d) report only the incremental space. That would let users make reasonable memory estimates in the form of n_instances * sizeof(vars(inst)). ---------- components: Interpreter Core messages: 279207 nosy: rhettinger priority: normal severity: normal status: open title: Need way to expose incremental size of key sharing dicts versions: Python 3.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Oct 22 15:13:37 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Sat, 22 Oct 2016 19:13:37 +0000 Subject: [New-bugs-announce] [issue28509] Key-sharing dictionaries can inrease the memory consumption Message-ID: <1477163617.95.0.961480932723.issue28509@psf.upfronthosting.co.za> New submission from Serhiy Storchaka: The size of small key-sharing dictionary (PEP 412) can be larger than the size of normal dictionary. Python 3.6: >>> def dictsizes(k): ... d = {'a%d'%i: None for i in range(k)} ... class C: ... def __init__(self): ... self.__dict__.update(d) ... return sys.getsizeof(d), sys.getsizeof(C().__dict__) ... >>> for i in range(20): ... print(i, dictsizes(i)) ... 0 (128, 60) 1 (128, 60) 2 (128, 60) 3 (128, 60) 4 (128, 60) 5 (128, 60) 6 (196, 196) 7 (196, 196) 8 (196, 344) 9 (196, 344) 10 (196, 344) 11 (344, 344) 12 (344, 344) 13 (344, 344) 14 (344, 344) 15 (344, 344) 16 (344, 628) 17 (344, 628) 18 (344, 628) 19 (344, 628) Normal dictionaries of size 8-10 are more compact than corresponding key-sharing dictionaries. Python 3.5: >>> for i in range(20): ... print(i, dictsizes(i)) ... 0 (144, 48) 1 (144, 48) 2 (144, 48) 3 (144, 48) 4 (144, 240) 5 (144, 240) 6 (240, 240) 7 (240, 240) 8 (240, 432) 9 (240, 432) 10 (240, 432) 11 (240, 432) 12 (432, 432) 13 (432, 432) 14 (432, 432) 15 (432, 432) 16 (432, 816) 17 (432, 816) 18 (432, 816) 19 (432, 816) In Python 3.5 normal dictionaries of size 4-5 and 8-11 are more compact than corresponding key-sharing dictionaries. And note that key-sharing dictionaries of size 0-3 consume more memory on 3.6 that on 3.5. I think we should use more thrifty strategy for allocating key-sharing dictionaries. ---------- components: Interpreter Core messages: 279215 nosy: Mark.Shannon, benjamin.peterson, inada.naoki, rhettinger, serhiy.storchaka priority: normal severity: normal status: open title: Key-sharing dictionaries can inrease the memory consumption type: resource usage _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Oct 22 16:53:48 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Sat, 22 Oct 2016 20:53:48 +0000 Subject: [New-bugs-announce] [issue28510] PyUnicodeDecodeError_GetObject always return bytes Message-ID: <1477169628.97.0.862291217974.issue28510@psf.upfronthosting.co.za> New submission from Serhiy Storchaka: Since PyUnicodeDecodeError_GetObject() always returns bytes object, following PyBytes_AsString() never fails and can be replaced with the PyBytes_AS_STRING() macro. This makes error handlers looking a littler clearer and a little faster. The patch is inspired by the patch of Xiang Zhang (issue28504). ---------- components: Interpreter Core files: unicodedecodeerror_object_is_bytes.patch keywords: patch messages: 279218 nosy: serhiy.storchaka, xiang.zhang priority: normal severity: normal stage: patch review status: open title: PyUnicodeDecodeError_GetObject always return bytes type: enhancement versions: Python 3.7 Added file: http://bugs.python.org/file45191/unicodedecodeerror_object_is_bytes.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Oct 22 16:53:54 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Sat, 22 Oct 2016 20:53:54 +0000 Subject: [New-bugs-announce] [issue28511] Use the "U" format for parsing Unicode object arg in PyArg_Parse* Message-ID: <1477169634.11.0.781122860843.issue28511@psf.upfronthosting.co.za> New submission from Serhiy Storchaka: Proposed patch uses the "U" format in PyArg_Parse* functions instead of the "O!" format with &PyUnicode_Type argument. This makes code cleaner, faster, and allows to remove additional PyUnicode_READY checks. The patch is inspired by the patch of Xiang Zhang (issue28504). ---------- components: Interpreter Core files: parse_unicode_arg.patch keywords: patch messages: 279219 nosy: serhiy.storchaka, xiang.zhang priority: normal severity: normal stage: patch review status: open title: Use the "U" format for parsing Unicode object arg in PyArg_Parse* type: enhancement versions: Python 3.7 Added file: http://bugs.python.org/file45192/parse_unicode_arg.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Oct 22 17:50:07 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Sat, 22 Oct 2016 21:50:07 +0000 Subject: [New-bugs-announce] [issue28512] PyErr_SyntaxLocationEx() and PyErr_SyntaxLocationObject() always set the offset attribute to None Message-ID: <1477173007.35.0.842183977255.issue28512@psf.upfronthosting.co.za> New submission from Serhiy Storchaka: The purpose of PyErr_SyntaxLocationEx() function (added in 00e4ce31d404) was setting the offset attribute of raised syntax error to specified value. But this never worked as expected. The offset attribute is set to integer value in Python/errors.c:1067, but then replaced with None in Python/errors.c:1083. ---------- components: Interpreter Core messages: 279224 nosy: benjamin.peterson, serhiy.storchaka priority: normal severity: normal status: open title: PyErr_SyntaxLocationEx() and PyErr_SyntaxLocationObject() always set the offset attribute to None type: behavior versions: Python 3.5, Python 3.6, Python 3.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Oct 23 06:36:17 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Sun, 23 Oct 2016 10:36:17 +0000 Subject: [New-bugs-announce] [issue28513] Documment zipfile CLI Message-ID: <1477218977.25.0.95260452294.issue28513@psf.upfronthosting.co.za> New submission from Serhiy Storchaka: Command-line interface of the zipfile module is supported long time, but it is not documented. Proposed patch documents it. It is based on the documentation of tarfile CLI. ---------- assignee: docs at python components: Documentation files: zipfile_cli_docs.patch keywords: patch messages: 279250 nosy: alanmcintyre, berker.peksag, docs at python, serhiy.storchaka, twouters priority: normal severity: normal stage: patch review status: open title: Documment zipfile CLI type: enhancement versions: Python 2.7, Python 3.5, Python 3.6, Python 3.7 Added file: http://bugs.python.org/file45195/zipfile_cli_docs.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Oct 23 10:02:50 2016 From: report at bugs.python.org (Kamran) Date: Sun, 23 Oct 2016 14:02:50 +0000 Subject: [New-bugs-announce] [issue28514] Crash Message-ID: New submission from Kamran: Hi, I am writing to inform you about the Python Program. Whenever I go onto the program it works but as soon as I save a piece of work it crashes and freezes. After that it says Python.exe has stopped working. The Windows that I am using is Windows 7 Proffessional. Is there any way you can fix this fault??? Please do this as soon as possibe as I need this piece of work ASAP?!? MANY THANKS *Kamran Muhammad* ---------- messages: 279260 nosy: Kamran priority: normal severity: normal status: open title: Crash _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Oct 23 12:29:34 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Sun, 23 Oct 2016 16:29:34 +0000 Subject: [New-bugs-announce] [issue28515] Py3k warnings in Python 2.7 tests Message-ID: <1477240174.09.0.468374420689.issue28515@psf.upfronthosting.co.za> New submission from Serhiy Storchaka: Several warnings are emitted when run Python 2.7 tests with -Wd -3 options. 1. "DeprecationWarning: <> not supported in 3.x; use !=" and "DeprecationWarning: dict.has_key() not supported in 3.x; use the in operator" in Tools/scripts/fixcid.py. 2. "DeprecationWarning: Overriding __eq__ blocks inheritance of __hash__ in 3.x" in Lib/test/pickletester.py. 3. "SyntaxWarning: tuple parameter unpacking has been removed in 3.x" in Lib/lib-tk/turtle.py. Proposed patch fixes these warnings. ---------- components: Tests files: tests_py3k_warns.patch keywords: patch messages: 279268 nosy: benjamin.peterson, serhiy.storchaka priority: normal severity: normal stage: patch review status: open title: Py3k warnings in Python 2.7 tests versions: Python 2.7 Added file: http://bugs.python.org/file45197/tests_py3k_warns.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Oct 23 22:36:51 2016 From: report at bugs.python.org (Walker Hale IV) Date: Mon, 24 Oct 2016 02:36:51 +0000 Subject: [New-bugs-announce] [issue28516] contextlib.ExitStack.__enter__ has trivial but undocumented behavior Message-ID: <1477276611.77.0.31268131141.issue28516@psf.upfronthosting.co.za> New submission from Walker Hale IV: contextlib.ExitStack implies but does not explicitly state that its __enter__ method trivially returns self. This means that if a user invokes pop_all and then uses the resulting ExitStack instance in a with statement, the user will be relying on undocumented behavior. Avoiding undocumented behavior forces the user to instead use a tedious try/finally construct, partially defeating the elegance of context managers. I propose that: 1. The ExitStack.__enter__ method be briefly mentioned as doing nothing besides returning self. 2. The example in pop_all documentation be expanded to show a following with statement that uses the new ExitStack instance. The discussion in section 29.6.3.2 is not sufficient to make this trivial point clear. ---------- messages: 279296 nosy: Walker Hale IV priority: normal severity: normal status: open title: contextlib.ExitStack.__enter__ has trivial but undocumented behavior versions: Python 3.3, Python 3.4, Python 3.5, Python 3.6, Python 3.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Oct 24 01:16:39 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Mon, 24 Oct 2016 05:16:39 +0000 Subject: [New-bugs-announce] [issue28517] Dead code in wordcode Message-ID: <1477286199.46.0.366284805485.issue28517@psf.upfronthosting.co.za> New submission from Serhiy Storchaka: >>> def func(test): ... if test == 1: ... return 1 ... elif test == 2: ... return 2 ... return 3 ... >>> import dis >>> dis.dis(func) Python 3.5: 2 0 LOAD_FAST 0 (test) 3 LOAD_CONST 1 (1) 6 COMPARE_OP 2 (==) 9 POP_JUMP_IF_FALSE 16 3 12 LOAD_CONST 1 (1) 15 RETURN_VALUE 4 >> 16 LOAD_FAST 0 (test) 19 LOAD_CONST 2 (2) 22 COMPARE_OP 2 (==) 25 POP_JUMP_IF_FALSE 32 5 28 LOAD_CONST 2 (2) 31 RETURN_VALUE 6 >> 32 LOAD_CONST 3 (3) 35 RETURN_VALUE Python 3.6: 2 0 LOAD_FAST 0 (test) 2 LOAD_CONST 1 (1) 4 COMPARE_OP 2 (==) 6 POP_JUMP_IF_FALSE 14 3 8 LOAD_CONST 1 (1) 10 RETURN_VALUE 12 JUMP_FORWARD 12 (to 26) 4 >> 14 LOAD_FAST 0 (test) 16 LOAD_CONST 2 (2) 18 COMPARE_OP 2 (==) 20 POP_JUMP_IF_FALSE 26 5 22 LOAD_CONST 2 (2) 24 RETURN_VALUE 6 >> 26 LOAD_CONST 3 (3) 28 RETURN_VALUE Note JUMP_FORWARD after RETURN_VALUE in 3.6 listing. ---------- components: Interpreter Core messages: 279297 nosy: Demur Rumed, serhiy.storchaka priority: normal severity: normal status: open title: Dead code in wordcode type: behavior versions: Python 3.6, Python 3.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Oct 24 07:05:18 2016 From: report at bugs.python.org (Florian Schulze) Date: Mon, 24 Oct 2016 11:05:18 +0000 Subject: [New-bugs-announce] [issue28518] execute("begin immediate") throwing OperationalError Message-ID: <1477307118.31.0.70785963389.issue28518@psf.upfronthosting.co.za> New submission from Florian Schulze: Using: conn = sqlite3.connect(':memory:', isolation_level='IMMEDIATE') conn.execute('begin immediate') Throws: sqlite3.OperationalError: cannot start a transaction within a transaction This didn't happen in previous versions and the conn.in_transaction attribute is False right before the call to execute, so this situation doesn't seem to be detectable upfront for backward compatibility. ---------- components: Library (Lib) messages: 279301 nosy: fschulze priority: normal severity: normal status: open title: execute("begin immediate") throwing OperationalError type: behavior versions: Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Oct 24 08:03:04 2016 From: report at bugs.python.org (Ivan Levkivskyi) Date: Mon, 24 Oct 2016 12:03:04 +0000 Subject: [New-bugs-announce] [issue28519] Update pydoc tool to support generic types Message-ID: <1477310584.34.0.261643270956.issue28519@psf.upfronthosting.co.za> New submission from Ivan Levkivskyi: It was proposed in the discussion of #27989 to update pydoc rendering of documentation of classes supporting generic types. Currently there are two ideas: 1. Keep the class header intact (i.e. listing actual runtime __bases__) and adding a separate section describing generic info using __orig_bases__ and __parameters__. For example: """ class MyClass(typing.List, typing.Mapping): ... (usual info) ... This is a generic class consistent with List[~T], Mapping[str, +VT_co] Type parameters: invariant T, covariant VT_co """ 2. Do not add a separate section, but modify the header to display __orig_bases__. For example: """ class MyClass(List[~T], Mapping[str, +VT_co]): ... (usual info) ... """ Guido prefers the second option. I am a bit afraid that this will cause people to use issubclass() with parameterized generics, but now issubclass(cls, List[T]) is a TypeError, only issubclass(cls, List) is allowed. So that I am more inclined towards first option. ---------- assignee: docs at python components: Documentation, Library (Lib) messages: 279304 nosy: docs at python, gvanrossum, levkivskyi priority: normal severity: normal status: open title: Update pydoc tool to support generic types type: enhancement versions: Python 3.5, Python 3.6, Python 3.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Oct 24 10:32:58 2016 From: report at bugs.python.org (Jack Liu) Date: Mon, 24 Oct 2016 14:32:58 +0000 Subject: [New-bugs-announce] [issue28520] Failed to install Python 3.3.5 on OSX 10.11.6 Message-ID: <1477319578.41.0.653712093309.issue28520@psf.upfronthosting.co.za> New submission from Jack Liu: For some reason. I need to install Python 3.3.5 (64-bit) on OSX 10.11.6. I got installer from http://www.python.org/ftp/python/3.3.5/python-3.3.5-macosx10.6.dmg, failed to install Python 3.3.5 on OSX 10.11.6. See error in attached screenshot. I know it's able to install Python 3.3.5 (64-bit) through pyenv. But I want to know why it's failed to install Python 3.3.5 on OSX 10.11.6 through python official installer. How can I make the python official installer work. ---------- components: Installation files: large.png messages: 279309 nosy: Jack Liu priority: normal severity: normal status: open title: Failed to install Python 3.3.5 on OSX 10.11.6 versions: Python 3.3 Added file: http://bugs.python.org/file45204/large.png _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Oct 24 11:32:25 2016 From: report at bugs.python.org (John Ehresman) Date: Mon, 24 Oct 2016 15:32:25 +0000 Subject: [New-bugs-announce] [issue28521] _PyEval_RequestCodeExtraIndex should return a globally valid index, not a ThreadState specific one Message-ID: <1477323145.97.0.665032370713.issue28521@psf.upfronthosting.co.za> New submission from John Ehresman: The index returned by _PyEval_RequestCodeExtraIndex is currently specific to the current thread state. This means that there will be problems if the index is used on another thread. It would be possible to set things up in my code so that _PyEval_RequestCodeExtraIndex was called once per thread state but there would be a possibility of getting different indices on the different threads and data set on one thread passed to the wrong free function registered on a different thread. ---------- components: Interpreter Core messages: 279314 nosy: jpe priority: normal severity: normal status: open title: _PyEval_RequestCodeExtraIndex should return a globally valid index, not a ThreadState specific one type: behavior versions: Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Oct 24 16:45:13 2016 From: report at bugs.python.org (Big Stone) Date: Mon, 24 Oct 2016 20:45:13 +0000 Subject: [New-bugs-announce] [issue28522] can't make IDLEX work with python._pth and python-3.6.0b2 Message-ID: <1477341913.28.0.0500470674993.issue28522@psf.upfronthosting.co.za> New submission from Big Stone: on WinPython-64bit-3.6.0.0Zerorc2.exe, python-3.6.0b2 based, I can't get IDLEX working with "python._pth". If I put "Lib\site-packages\" in python._pth, python.exe dies. If I put "#Lib\site-packages\", idlexlib is said "unable to located". Could it be a python-3.6.0b2 bug, or just a wrong-doing from WinPython ? "Python._pth"= . Lib import site DLLs #Lib/site-packages #python36.zip ---------- components: Windows messages: 279338 nosy: Big Stone, paul.moore, steve.dower, tim.golden, zach.ware priority: normal severity: normal status: open title: can't make IDLEX work with python._pth and python-3.6.0b2 versions: Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Oct 24 17:37:08 2016 From: report at bugs.python.org (Terry J. Reedy) Date: Mon, 24 Oct 2016 21:37:08 +0000 Subject: [New-bugs-announce] [issue28523] Idlelib.configdialog: use 'color' insteadof 'colour' Message-ID: <1477345028.99.0.578585352452.issue28523@psf.upfronthosting.co.za> New submission from Terry J. Reedy: idlelib.configdialog uses the British spelling 'colour' instead of the American spelling 'color' everywhere except for externally mandated import and parameter names and in some recent comments. idlelib uses 'color' everywhere else. # change 'colour' to 'color' in idlelib.configdialog 3.6 with open('F:/python/dev/36/lib/idlelib/configdialog.py', 'r+') as f: code = f.read().replace('Colour', 'Color').replace('colour', 'color') f.seek(0); f.truncate() f.write(code) produces the attached patch. I would like to apply this before 3.6.0rc. I might wait until a week before that in case I want to backport any configdialog changes to 3.5. (Any such changes might require regenerating the patch.) ---------- assignee: terry.reedy files: color.diff keywords: patch messages: 279340 nosy: terry.reedy priority: normal severity: normal stage: patch review status: open title: Idlelib.configdialog: use 'color' insteadof 'colour' type: enhancement versions: Python 3.6, Python 3.7 Added file: http://bugs.python.org/file45207/color.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Oct 24 17:45:10 2016 From: report at bugs.python.org (Al Sweigart) Date: Mon, 24 Oct 2016 21:45:10 +0000 Subject: [New-bugs-announce] [issue28524] Set default argument of logging.disable() to logging.CRITICAL Message-ID: <1477345510.5.0.68336976066.issue28524@psf.upfronthosting.co.za> New submission from Al Sweigart: As a convenience, we could make the default argument for logging.disable()'s lvl argument as logging.CRITICAL. This would make disabling all logging messages: logging.disable() ...instead of the more verbose: logging.disable(logging.CRITICAL) This one-line change is backwards compatible. ---------- components: Library (Lib) files: default_critical.patch keywords: patch messages: 279341 nosy: Al.Sweigart priority: normal severity: normal status: open title: Set default argument of logging.disable() to logging.CRITICAL type: enhancement Added file: http://bugs.python.org/file45208/default_critical.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Oct 24 19:58:54 2016 From: report at bugs.python.org (Javier Rey) Date: Mon, 24 Oct 2016 23:58:54 +0000 Subject: [New-bugs-announce] [issue28525] Incorrect documented parameter for gc.collect Message-ID: <1477353534.83.0.239839620837.issue28525@psf.upfronthosting.co.za> Changes by Javier Rey : ---------- assignee: docs at python components: Documentation files: gc_collect_doc_fix.patch keywords: patch nosy: docs at python, vierja priority: normal severity: normal status: open title: Incorrect documented parameter for gc.collect versions: Python 3.3, Python 3.4, Python 3.5, Python 3.6, Python 3.7 Added file: http://bugs.python.org/file45209/gc_collect_doc_fix.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Oct 25 04:42:38 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Tue, 25 Oct 2016 08:42:38 +0000 Subject: [New-bugs-announce] [issue28526] Use PyUnicode_AsEncodedString instead of PyUnicode_AsEncodedObject Message-ID: <1477384958.56.0.348226525615.issue28526@psf.upfronthosting.co.za> New submission from Serhiy Storchaka: PyUnicode_AsEncodedObject() can return an object of arbitrary type, while PyUnicode_AsEncodedString() always returns bytes. The code that uses PyUnicode_AsEncodedObject() in the _curses module expects bytes, but does not check the type of the result. This can cause undefined behavior, including a crash. Using PyUnicode_AsEncodedString() is more correct in this case. ---------- assignee: serhiy.storchaka components: Extension Modules files: curses-PyUnicode_AsEncodedString.patch keywords: patch messages: 279377 nosy: serhiy.storchaka, twouters priority: normal severity: normal stage: patch review status: open title: Use PyUnicode_AsEncodedString instead of PyUnicode_AsEncodedObject type: crash versions: Python 2.7, Python 3.5, Python 3.6, Python 3.7 Added file: http://bugs.python.org/file45212/curses-PyUnicode_AsEncodedString.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Oct 25 06:23:40 2016 From: report at bugs.python.org (Jonathan Hogg) Date: Tue, 25 Oct 2016 10:23:40 +0000 Subject: [New-bugs-announce] [issue28527] Hack in `genericpath.commonprefix()` crashes if `m` argument is not indexable Message-ID: <1477391020.72.0.151602828725.issue28527@psf.upfronthosting.co.za> New submission from Jonathan Hogg: If `genericpath.commonprefix()` is called with a non-indexable argument, then the check for passing in a list of lists/tuples will raise an exception due to the `m[0]` test. ---------- components: Library (Lib) messages: 279386 nosy: jonathanhogg priority: normal severity: normal status: open title: Hack in `genericpath.commonprefix()` crashes if `m` argument is not indexable type: crash versions: Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Oct 25 09:12:03 2016 From: report at bugs.python.org (Thomas Kluyver) Date: Tue, 25 Oct 2016 13:12:03 +0000 Subject: [New-bugs-announce] [issue28528] Pdb.checkline() Message-ID: <1477401123.41.0.136094342663.issue28528@psf.upfronthosting.co.za> New submission from Thomas Kluyver: Pdb.checkline() does a hasattr() check to protect against self.curframe not existing. self.curframe can also be None (if self.forget() or self.reset() was called), but checkline() does not handle this. The attached patch treats self.curframe == None as equivalent to the attribute being absent. Background: http://bugs.python.org/issue9230 https://github.com/ipython/ipython/issues/10028 (Georg, I've nosy-listed you as I saw your name on a couple of similar issues; I hope you don't mind) ---------- components: Library (Lib) files: pdb-reset-checkline.patch keywords: patch messages: 279402 nosy: georg.brandl, takluyver priority: normal severity: normal status: open title: Pdb.checkline() type: behavior versions: Python 3.5, Python 3.6, Python 3.7 Added file: http://bugs.python.org/file45217/pdb-reset-checkline.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Oct 25 10:57:20 2016 From: report at bugs.python.org (=?utf-8?b?SsOhY2h5bSBCYXJ2w61uZWs=?=) Date: Tue, 25 Oct 2016 14:57:20 +0000 Subject: [New-bugs-announce] [issue28529] 0 ** 0 should raise ArithmeticError Message-ID: <1477407440.28.0.0137901143197.issue28529@psf.upfronthosting.co.za> New submission from J?chym Barv?nek: 0 ** 0 is mathematically undefined and equivalent to 0/0. 0/0 correctly raises ZeroDivisionError, but 0 ** 0 == 1. Also 0.0 ** 0 == 0 ** 0.0 == 0.0 ** 0.0 == 0.0. Similarly for math.pow. ---------- components: Interpreter Core messages: 279410 nosy: J?chym Barv?nek priority: normal severity: normal status: open title: 0 ** 0 should raise ArithmeticError versions: Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Oct 25 11:46:16 2016 From: report at bugs.python.org (stephan) Date: Tue, 25 Oct 2016 15:46:16 +0000 Subject: [New-bugs-announce] [issue28530] Howto detect if an object is of type os.DirEntry Message-ID: <1477410376.41.0.315236150527.issue28530@psf.upfronthosting.co.za> New submission from stephan: I have a small problem with python 3.5.2 64bit on win7 64 bit: I cannot check if an object is of type DirEntry (os.DirEntry or nt.DirEntry). Did I misunderstand something or what is wrong? Here is a log of my console: ----------------------------------------- In [63]: sd = os.scandir(".") In [64]: de = next(sd) In [65]: type(de) Out[65]: nt.DirEntry In [66]: import nt In [67]: nt.DirEntry --------------------------------------------------------------------------- AttributeError Traceback (most recent call last) in () ----> 1 nt.DirEntry AttributeError: module 'nt' has no attribute 'DirEntry' In [68]: os.DirEntry --------------------------------------------------------------------------- AttributeError Traceback (most recent call last) in () ----> 1 os.DirEntry AttributeError: module 'os' has no attribute 'DirEntry' In [69]: ------------------------------------------ ---------- messages: 279415 nosy: stephan priority: normal severity: normal status: open title: Howto detect if an object is of type os.DirEntry versions: Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Oct 25 12:16:46 2016 From: report at bugs.python.org (Xiang Zhang) Date: Tue, 25 Oct 2016 16:16:46 +0000 Subject: [New-bugs-announce] [issue28531] Improve utf7 encoder memory usage Message-ID: <1477412206.88.0.583380682603.issue28531@psf.upfronthosting.co.za> New submission from Xiang Zhang: Currently utf7 encoder uses an aggressive memory allocation strategy: use the worst case 8. We can tighten the worst case. For 1 byte and 2 byte unicodes, the worst case could be 3*n + 2. For 4 byte unicodes, the worst case could be 6*n + 2. There are 2 cases. First, all characters needs to be encoded, the result length should be upper_round(2.67*n) + 2 <= 3*n + 2. Second, encode and not encode characters appear one by one. For even length, it's 3n < 3n + 2. For odd length, it's exactly 3n + 2. This won't benefit much when the string is short. But when the string is long, it speeds up. Without patch: [bin]$ ./python3 -m perf timeit -s 's = "abc"*10' 's.encode("utf7")' .................... Median +- std dev: 2.79 us +- 0.09 us [bin]$ ./python3 -m perf timeit -s 's = "abc"*100' 's.encode("utf7")' .................... Median +- std dev: 4.55 us +- 0.13 us [bin]$ ./python3 -m perf timeit -s 's = "abc"*1000' 's.encode("utf7")' .................... Median +- std dev: 14.0 us +- 0.4 us [bin]$ ./python3 -m perf timeit -s 's = "abc"*10000' 's.encode("utf7")' .................... Median +- std dev: 178 us +- 1 us With patch: [bin]$ ./python3 -m perf timeit -s 's = "abc"*10' 's.encode("utf7")' .................... Median +- std dev: 2.87 us +- 0.09 us [bin]$ ./python3 -m perf timeit -s 's = "abc"*100' 's.encode("utf7")' .................... Median +- std dev: 4.50 us +- 0.23 us [bin]$ ./python3 -m perf timeit -s 's = "abc"*1000' 's.encode("utf7")' .................... Median +- std dev: 13.3 us +- 0.4 us [bin]$ ./python3 -m perf timeit -s 's = "abc"*10000' 's.encode("utf7")' .................... Median +- std dev: 102 us +- 1 us The patch also removes a check, base64bits can only be not 0 when inShift is not 0. ---------- components: Interpreter Core files: utf7_encoder.patch keywords: patch messages: 279419 nosy: haypo, serhiy.storchaka, xiang.zhang priority: normal severity: normal stage: patch review status: open title: Improve utf7 encoder memory usage type: enhancement versions: Python 3.7 Added file: http://bugs.python.org/file45219/utf7_encoder.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Oct 25 13:51:01 2016 From: report at bugs.python.org (INADA Naoki) Date: Tue, 25 Oct 2016 17:51:01 +0000 Subject: [New-bugs-announce] [issue28532] Show sys.version when -V option is supplied twice. Message-ID: <1477417861.44.0.42778795289.issue28532@psf.upfronthosting.co.za> New submission from INADA Naoki: As discussed on python-dev, this patch adds -VV option to python cmdline. $ ./python -V Python 3.6.0b2+ $ ./python -VV Python 3.6.0b2+ (3.6:84a3c5003510+, Oct 26 2016, 02:47:38) [GCC 6.2.0 20161005] The patch includes doc and man update. Please see, especially my English. ---------- assignee: inada.naoki components: Interpreter Core files: verbose-version.patch keywords: patch messages: 279428 nosy: inada.naoki priority: normal severity: normal status: open title: Show sys.version when -V option is supplied twice. type: behavior versions: Python 3.6, Python 3.7 Added file: http://bugs.python.org/file45221/verbose-version.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Oct 25 14:32:04 2016 From: report at bugs.python.org (Mariatta Wijaya) Date: Tue, 25 Oct 2016 18:32:04 +0000 Subject: [New-bugs-announce] [issue28533] Replace asyncore Message-ID: <1477420324.44.0.338895938894.issue28533@psf.upfronthosting.co.za> New submission from Mariatta Wijaya: Deprecation warning was added to asyncore in https://bugs.python.org/issue25002 asyncore is still used in several tests and should be replaced. ---------- messages: 279439 nosy: Mariatta priority: normal severity: normal status: open title: Replace asyncore _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Oct 25 14:32:53 2016 From: report at bugs.python.org (Mariatta Wijaya) Date: Tue, 25 Oct 2016 18:32:53 +0000 Subject: [New-bugs-announce] [issue28534] Replace asynchat Message-ID: <1477420373.21.0.38842063017.issue28534@psf.upfronthosting.co.za> New submission from Mariatta Wijaya: Deprecation warning was added to asynchat in https://bugs.python.org/issue25002 asynchat is still used in several tests and should be replaced. ---------- components: asyncio messages: 279441 nosy: Mariatta, gvanrossum, yselivanov priority: normal severity: normal status: open title: Replace asynchat _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Oct 25 16:41:35 2016 From: report at bugs.python.org (Mike Williamson) Date: Tue, 25 Oct 2016 20:41:35 +0000 Subject: [New-bugs-announce] [issue28535] round seems to provide floor, not proper rounding Message-ID: <1477428095.53.0.799157743642.issue28535@psf.upfronthosting.co.za> New submission from Mike Williamson: Ran a test that I expected to pass. When the test failed, I was struck by the strange (incorrect) assertion claim when using unittest.assertAlmostEqual: AssertionError: 32.78 != 32.775 within 2 places Uhmm... yes it does! I delved in, discovering that assertAlmostEquals simply calls round. So, I tried it with round, shown below: >>> round(32.775, 2) 32.77 >>> round(32.785, 2) 32.78 >>> round(32.745, 2) 32.74 >>> round(32.746, 2) 32.75 I then looked at the documentation, to understand whether this odd behavior is indeed expected. I saw (on https://docs.python.org/3/library/functions.html#round ): --- If two multiples are equally close, rounding is done toward the even choice (so, for example, both round(0.5) and round(-0.5) are 0, and round(1.5) is 2). --- However, as you can see, this is not the behavior I'm experiencing. So, it looks like a real bug. I am attaching the two files where I was running the unit tests, but I'm not sure you really need them. Thank you! ---------- components: Library (Lib) files: bad_tests.py messages: 279456 nosy: lazarillo priority: normal severity: normal status: open title: round seems to provide floor, not proper rounding type: behavior versions: Python 3.5 Added file: http://bugs.python.org/file45224/bad_tests.py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Oct 25 17:47:29 2016 From: report at bugs.python.org (Ryan Gonzalez) Date: Tue, 25 Oct 2016 21:47:29 +0000 Subject: [New-bugs-announce] [issue28536] Show the qualified name when a call fails Message-ID: <1477432049.19.0.837809051965.issue28536@psf.upfronthosting.co.za> New submission from Ryan Gonzalez: e.g. make this: class X: def __init__(self): pass X(1) print something like this: TypeError: X.__init__() takes 1 positional argument but 2 were given instead of: TypeError: __init__() takes 1 positional argument but 2 were given I'm trying to see if I can create a patch right now, though it probably won't be ready until Thursday. ---------- components: Interpreter Core messages: 279460 nosy: Ryan.Gonzalez priority: normal severity: normal status: open title: Show the qualified name when a call fails versions: Python 3.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Oct 25 19:42:42 2016 From: report at bugs.python.org (Nathaniel Manista) Date: Tue, 25 Oct 2016 23:42:42 +0000 Subject: [New-bugs-announce] [issue28537] abc module fails to reject instantiation of some multiply-inheriting classes that fail to implement abstract methods Message-ID: <1477438962.08.0.688067999531.issue28537@psf.upfronthosting.co.za> New submission from Nathaniel Manista: The attached file when executed should fail (raise an exception) one line above where it actually does. Right? I discovered this in 2.7 but have confirmed that it's still a problem in 3.6.0b2. ---------- components: Library (Lib) files: abc_what.py messages: 279465 nosy: Nathaniel Manista, aleax priority: normal severity: normal status: open title: abc module fails to reject instantiation of some multiply-inheriting classes that fail to implement abstract methods type: behavior versions: Python 2.7, Python 3.3, Python 3.4, Python 3.5, Python 3.6, Python 3.7 Added file: http://bugs.python.org/file45226/abc_what.py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Oct 26 05:38:53 2016 From: report at bugs.python.org (Xavier de Gaye) Date: Wed, 26 Oct 2016 09:38:53 +0000 Subject: [New-bugs-announce] [issue28538] _socket module cross-compilation error on android-24 Message-ID: <1477474733.85.0.0781476042155.issue28538@psf.upfronthosting.co.za> New submission from Xavier de Gaye: On the latest Android API level (android-24), the if_nameindex function is now found by configure in Android libc. But the if_nameindex function and structure are still not defined in the Android net/if.h header. The compilation fails with: clang --sysroot=/opt/android-ndk/platforms/android-24/arch-x86 -target i686-none-linux-androideabi -gcc-toolchain /opt/android-ndk/toolchains/x86-4.9/prebuilt/linux-x86_64 -Wno-unused-result -Wsign-compare -Wunreachable-code -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes -Wno-unused-value -Wno-empty-body -Qunused-arguments -Wno-parentheses-equality -std=c99 -Wextra -Wno-unused-result -Wno-unused-parameter -Wno-missing-field-initializers -I. -IObjects -IInclude -IPython -I/home/xavier/src/android/pyona/build/python3.7-install-android-24-x86/org.bitbucket.pyona/include -I/opt/android-ndk/platforms/android-24/arch-x86/usr/include -I/path/to/android/cpython/Include -I/home/xavier/src/android/pyona/build/python3.7-android-24-x86 -c /path/to/android/cpython/Modules/socketmodule.c -o build/temp.linux-i686-3.7/path/to/android/cpython/Modules/socketmodule.o /path/to/android/cpython/Modules/socketmodule.c:1034:29: warning: comparison of integers of different signs: 'socklen_t' (aka 'int') and 'size_t' (aka 'unsigned int') [-Wsign-compare] if (res->ai_addrlen < addr_ret_size) ~~~~~~~~~~~~~~~ ^ ~~~~~~~~~~~~~ /path/to/android/cpython/Modules/socketmodule.c:1125:25: warning: comparison of integers of different signs: 'socklen_t' (aka 'int') and 'size_t' (aka 'unsigned int') [-Wsign-compare] if (res->ai_addrlen < addr_ret_size) ~~~~~~~~~~~~~~~ ^ ~~~~~~~~~~~~~ /path/to/android/cpython/Modules/socketmodule.c:4925:15: warning: implicit declaration of function 'sethostname' is invalid in C99 [-Wimplicit-function-declaration] res = sethostname(buf.buf, buf.len); ^ /path/to/android/cpython/Modules/socketmodule.c:6242:10: warning: implicit declaration of function 'if_nameindex' is invalid in C99 [-Wimplicit-function-declaration] ni = if_nameindex(); ^ /path/to/android/cpython/Modules/socketmodule.c:6242:8: warning: incompatible integer to pointer conversion assigning to 'struct if_nameindex *' from 'int' [-Wint-conversion] ni = if_nameindex(); ^ ~~~~~~~~~~~~~~ /path/to/android/cpython/Modules/socketmodule.c:6250:9: warning: implicit declaration of function 'if_freenameindex' is invalid in C99 [-Wimplicit-function-declaration] if_freenameindex(ni); ^ /path/to/android/cpython/Modules/socketmodule.c:6254:19: error: subscript of pointer to incomplete type 'struct if_nameindex' for (i = 0; ni[i].if_index != 0 && i < INT_MAX; i++) { ~~^ /path/to/android/cpython/Modules/socketmodule.c:6240:12: note: forward declaration of 'struct if_nameindex' struct if_nameindex *ni; ^ /path/to/android/cpython/Modules/socketmodule.c:6256:19: error: subscript of pointer to incomplete type 'struct if_nameindex' ni[i].if_index, PyUnicode_DecodeFSDefault, ni[i].if_name); ~~^ /path/to/android/cpython/Modules/socketmodule.c:6240:12: note: forward declaration of 'struct if_nameindex' struct if_nameindex *ni; ^ /path/to/android/cpython/Modules/socketmodule.c:6256:62: error: subscript of pointer to incomplete type 'struct if_nameindex' ni[i].if_index, PyUnicode_DecodeFSDefault, ni[i].if_name); ~~^ /path/to/android/cpython/Modules/socketmodule.c:6240:12: note: forward declaration of 'struct if_nameindex' struct if_nameindex *ni; ^ 6 warnings and 3 errors generated. ---------- messages: 279495 nosy: xdegaye priority: normal severity: normal stage: needs patch status: open title: _socket module cross-compilation error on android-24 type: compile error versions: Python 3.6, Python 3.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Oct 26 15:12:47 2016 From: report at bugs.python.org (Charles Stephens) Date: Wed, 26 Oct 2016 19:12:47 +0000 Subject: [New-bugs-announce] [issue28539] httplib/http.client HTTPConnection._get_hostport() regression Message-ID: <1477509167.25.0.917011281654.issue28539@psf.upfronthosting.co.za> New submission from Charles Stephens: Back through the mists of time, there was a change to strip square brackets IPv6 address host literals in HTTPConnection._get_hostport(): https://hg.python.org/cpython/diff/433606e9546c/Lib/httplib.py However, the code mixed tabs and spaces and was "corected" by: https://hg.python.org/cpython/diff/9e2b94a3b5dc/Lib/httplib.py However, the intent was changed in the second diff and brackets won't be stripped. This causes problems when IPv6 address URL's are used with the requests package: In [1]: import httplib In [2]: con = httplib.HTTPConnection('[fe80::26a9:37ff:fe00:f764%eth0]', 15482) In [3]: con.request("GET", "/api/api-version") --------------------------------------------------------------------------- gaierror Traceback (most recent call last) in () ----> 1 con.request("GET", "/api/api-version") /usr/lib/python2.7/httplib.pyc in request(self, method, url, body, headers) 977 def request(self, method, url, body=None, headers={}): 978 """Send a complete request to the server.""" --> 979 self._send_request(method, url, body, headers) 980 981 def _set_content_length(self, body): /usr/lib/python2.7/httplib.pyc in _send_request(self, method, url, body, headers) 1011 for hdr, value in headers.iteritems(): 1012 self.putheader(hdr, value) -> 1013 self.endheaders(body) 1014 1015 def getresponse(self, buffering=False): /usr/lib/python2.7/httplib.pyc in endheaders(self, message_body) 973 else: 974 raise CannotSendHeader() --> 975 self._send_output(message_body) 976 977 def request(self, method, url, body=None, headers={}): /usr/lib/python2.7/httplib.pyc in _send_output(self, message_body) 833 msg += message_body 834 message_body = None --> 835 self.send(msg) 836 if message_body is not None: 837 #message_body was not a string (i.e. it is a file) and /usr/lib/python2.7/httplib.pyc in send(self, data) 795 if self.sock is None: 796 if self.auto_open: --> 797 self.connect() 798 else: 799 raise NotConnected() /usr/lib/python2.7/httplib.pyc in connect(self) 776 """Connect to the host and port specified in __init__.""" 777 self.sock = socket.create_connection((self.host,self.port), --> 778 self.timeout, self.source_address) 779 780 if self._tunnel_host: /usr/lib/python2.7/socket.pyc in create_connection(address, timeout, source_address) 551 host, port = address 552 err = None --> 553 for res in getaddrinfo(host, port, 0, SOCK_STREAM): 554 af, socktype, proto, canonname, sa = res 555 sock = None gaierror: [Errno -2] Name or service not known ---------- components: Library (Lib) files: get_hostport.diff keywords: patch messages: 279509 nosy: cfs-pure priority: normal severity: normal status: open title: httplib/http.client HTTPConnection._get_hostport() regression versions: Python 2.7, Python 3.3, Python 3.4, Python 3.5, Python 3.6, Python 3.7 Added file: http://bugs.python.org/file45233/get_hostport.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Oct 26 17:25:41 2016 From: report at bugs.python.org (Francisco Couzo) Date: Wed, 26 Oct 2016 21:25:41 +0000 Subject: [New-bugs-announce] [issue28540] math.degrees(sys.float_info.max) should throw an OverflowError exception Message-ID: <1477517141.8.0.311598434825.issue28540@psf.upfronthosting.co.za> New submission from Francisco Couzo: Most functions in the math library raise an OverflowError when the arguments are finite but the result is not. >>> math.exp(sys.float_info.max) Traceback (most recent call last): File "", line 1, in OverflowError: math range error >>> math.degrees(sys.float_info.max) inf ---------- messages: 279513 nosy: franciscouzo priority: normal severity: normal status: open title: math.degrees(sys.float_info.max) should throw an OverflowError exception _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Oct 26 23:06:57 2016 From: report at bugs.python.org (Eric Appelt) Date: Thu, 27 Oct 2016 03:06:57 +0000 Subject: [New-bugs-announce] [issue28541] Improve test coverage for json library - loading bytes Message-ID: <1477537617.88.0.425466142378.issue28541@psf.upfronthosting.co.za> New submission from Eric Appelt: Increase test coverage of the json library, specifically the detect_encoding() function in the __init__ module, which is used to handle the autodetection of the encoding of a bytes object passed to json.loads(). This function was added in issue 17909 which extended the json.loads() function to accept bytes. Note that this is a small patch as I am following section 5 of the developer guide and I am trying to acquaint myself with the process as a first time contributor. I found this missing coverage just by semi-randomly looking at individual modules of interest. Please let me know if I have made any general mistakes in constructing this ticket. Thanks! ---------- components: Tests files: mywork.patch keywords: patch messages: 279521 nosy: Eric Appelt priority: normal severity: normal status: open title: Improve test coverage for json library - loading bytes versions: Python 3.6 Added file: http://bugs.python.org/file45234/mywork.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Oct 27 06:17:40 2016 From: report at bugs.python.org (Xavier de Gaye) Date: Thu, 27 Oct 2016 10:17:40 +0000 Subject: [New-bugs-announce] [issue28542] document cross compilation Message-ID: <1477563460.46.0.569265292251.issue28542@psf.upfronthosting.co.za> New submission from Xavier de Gaye: Patch adding a section to the README. ---------- assignee: xdegaye files: readme.patch keywords: patch messages: 279532 nosy: xdegaye priority: normal severity: normal stage: patch review status: open title: document cross compilation type: enhancement versions: Python 3.6, Python 3.7 Added file: http://bugs.python.org/file45238/readme.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Oct 27 10:20:00 2016 From: report at bugs.python.org (Xiang Zhang) Date: Thu, 27 Oct 2016 14:20:00 +0000 Subject: [New-bugs-announce] [issue28543] Incomplete fast path codecs aliases in codecs doc Message-ID: <1477578000.23.0.835433953777.issue28543@psf.upfronthosting.co.za> New submission from Xiang Zhang: The fast path codec aliases in codecs doc is complete especially after 99818330b4c0. ---------- assignee: docs at python components: Documentation files: codecs_doc.patch keywords: patch messages: 279538 nosy: docs at python, haypo, xiang.zhang priority: normal severity: normal stage: patch review status: open title: Incomplete fast path codecs aliases in codecs doc type: enhancement versions: Python 3.6, Python 3.7 Added file: http://bugs.python.org/file45241/codecs_doc.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Oct 27 12:33:11 2016 From: report at bugs.python.org (Yury Selivanov) Date: Thu, 27 Oct 2016 16:33:11 +0000 Subject: [New-bugs-announce] [issue28544] Implement asyncio.Task in C Message-ID: <1477585991.46.0.161960308899.issue28544@psf.upfronthosting.co.za> New submission from Yury Selivanov: The attached patch implements asyncio.Task in C. Besides that, it also implements Argument Clinic for C Future. Performance improvement on a simple echo server implementation using asyncio.streams: Python Future & Task | C Future & Py Task | C Future & C Task 23K req/s | 26K | 30K | ~10-15% boost | ~15% Both Task and Future implemented in C, make asyncio programs up to 25-30% faster. The patch is 100% backwards compatible. I modified asyncio tests to cross test Tasks and Futures implementations, i.e. to run Task+Future, Task+CFuture, CTask+Future, CTask+CFuture tests. No refleaks or other bugs. All uvloop functional tests pass without any problem. Ned, Guido, are you OK if I merge this in 3.6 before beta 3? I'm confident that the patch is stable and even if something comes up we have time to fix it or even retract the patch. The performance boost is very impressive, and I can also make uvloop simpler. ---------- assignee: yselivanov components: asyncio files: ctask.patch keywords: patch messages: 279546 nosy: asvetlov, gvanrossum, haypo, inada.naoki, ned.deily, yselivanov priority: normal severity: normal stage: patch review status: open title: Implement asyncio.Task in C type: performance versions: Python 3.6, Python 3.7 Added file: http://bugs.python.org/file45242/ctask.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Oct 27 14:14:58 2016 From: report at bugs.python.org (Martin Turon) Date: Thu, 27 Oct 2016 18:14:58 +0000 Subject: [New-bugs-announce] [issue28545] socket.bind to AF_PACKET should use passed interface name Message-ID: <1477592098.82.0.815527711646.issue28545@psf.upfronthosting.co.za> New submission from Martin Turon: When binding to AF_PACKET linux kernel sockets, the interface name is not passed in when given -- it is always "". This causes problems, for example, receiving packets to a "monitor0" interface doesn't work. diff -r a6548e230ed6 Modules/socketmodule.c --- a/Modules/socketmodule.c Thu Oct 27 19:33:22 2016 +0300 +++ b/Modules/socketmodule.c Thu Oct 27 11:13:12 2016 -0700 @@ -1344,6 +1344,7 @@ { struct sockaddr_ll *a = (struct sockaddr_ll *)addr; char *ifname = ""; + // ^^ ifname should be set to interface name passed in via sockaddr. struct ifreq ifr; /* need to look up interface name give index */ if (a->sll_ifindex) { ---------- messages: 279558 nosy: mturon priority: normal severity: normal status: open title: socket.bind to AF_PACKET should use passed interface name _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Oct 28 08:55:42 2016 From: report at bugs.python.org (Ian Kelling) Date: Fri, 28 Oct 2016 12:55:42 +0000 Subject: [New-bugs-announce] [issue28546] Better explain setting pdb breakpoints Message-ID: <1477659342.78.0.0469891681289.issue28546@psf.upfronthosting.co.za> New submission from Ian Kelling: https://docs.python.org/3.7/library/pdb.html: "The typical usage to break into the debugger from a running program is to insert import pdb; pdb.set_trace() at the location you want to break into the debugger." A plain read of this says: insert code into a running program. I can do this just fine in gdb, so when reading this, I wonder if attaching is explained elsewhere, or what. Patch to improve this. ---------- assignee: docs at python components: Documentation files: iank-v1.patch keywords: patch messages: 279601 nosy: docs at python, iank priority: normal severity: normal status: open title: Better explain setting pdb breakpoints versions: Python 2.7, Python 3.3, Python 3.4, Python 3.5, Python 3.6, Python 3.7 Added file: http://bugs.python.org/file45253/iank-v1.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Oct 28 08:57:15 2016 From: report at bugs.python.org (Jean-Philippe Landry) Date: Fri, 28 Oct 2016 12:57:15 +0000 Subject: [New-bugs-announce] [issue28547] Python to use Windows Certificate Store Message-ID: <1477659435.87.0.666854637981.issue28547@psf.upfronthosting.co.za> New submission from Jean-Philippe Landry: Hello, Would it be possible for Python to use the Certificate Store in windows instead of a predetermined list of certificates. The use case is as follows: Multiple machines being on a corporate network where there is a man in the middle packet inspection (IT security stuff...) that will resign most of the SSL connections with its own certificate that is unfortunately not part of the python default store. There are also multiple behind the firewall servers using self signed certificates. That means that almost all SSL requests, including pip install will throw the famous [SSL: CERTIFICATE_VERIFY_FAILED] error. This is transparent in Chrome because Chrome is using the Windows store to determine if a certificate is trusted or not and all those custom certificates are in the windows store. However, Python uses its own file (list of approved certificates). I understand that this can be overridden using a custom, manually managed, crt file and set it into the environment variables (REQUESTS_CA_BUNDLE) and it works. However, this involves manual operation and undesired maintenance when a new certificate will be added to the store. The windows store itself gets updated periodically by IT so it is a not an issue. Is there a rationale behind using a specific file instead of the windows store which will work for Chrome, IE, etc... Best regards, Jean-Philippe ---------- assignee: christian.heimes components: SSL messages: 279602 nosy: Jean-Philippe Landry, christian.heimes priority: normal severity: normal status: open title: Python to use Windows Certificate Store type: behavior versions: Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Oct 28 11:57:09 2016 From: report at bugs.python.org (Barry A. Warsaw) Date: Fri, 28 Oct 2016 15:57:09 +0000 Subject: [New-bugs-announce] [issue28548] http.server parse_request() bug and error reporting Message-ID: <1477670229.81.0.419990644201.issue28548@psf.upfronthosting.co.za> New submission from Barry A. Warsaw: This might also affect other Python version; I haven't checked, but I know it affects Python 3.5. In Mailman 3, we have a subclass of WSGIRequestHandler for our REST API, and we got a bug report about an error condition returning a 400 in the body of the response, but still returning an implicit 200 header. https://gitlab.com/mailman/mailman/issues/288 This is pretty easily reproducible with the following recipe. $ git clone https://gitlab.com/mailman/mailman.git $ cd mailman $ tox -e py35 --notest -r $ .tox/py35/bin/python3.5 /home/barry/projects/mailman/trunk/.tox/py35/bin/runner --runner=rest:0:1 -C /home/barry/projects/mailman/trunk/var/etc/mailman.cfg (Note that you might need to run `.tox/py35/bin/mailman info` first, and of course you'll have to adjust the directories for your own local fork.) Now, in another shell, do the following: $ curl -v -i -u restadmin:restpass "http://localhost:8001/3.0/lists/list example.com" Note specifically that there is a space right before the "example.com" bit. Take note also that we're generating an HTTP/1.1 request as per curl default. The response you get is: * Trying 127.0.0.1... * Connected to localhost (127.0.0.1) port 8001 (#0) * Server auth using Basic with user 'restadmin' > GET /3.0/lists/list example.com HTTP/1.1 > Host: localhost:8001 > Authorization: Basic cmVzdGFkbWluOnJlc3RwYXNz > User-Agent: curl/7.50.1 > Accept: */* > Error response

Error response

Error code: 400

Message: Bad request syntax ('GET /3.0/lists/list example.com HTTP/1.1').

Error code explanation: HTTPStatus.BAD_REQUEST - Bad request syntax or unsupported method.

* Connection #0 to host localhost left intact Notice the lack of response headers, and thus the implicit 200 return even though the proper error code is in the body of the response. Why does this happen? Now look at http.server.BaseHTTPRequestHandler. The default_request_version is "HTTP/0.9". Given the request, you'd expect to see the version set to "HTTP/1.1", but that doesn't happen because the extra space messes up the request parsing. parse_request() splits the request line by spaces and when this happens, the wrong number of words shows up. We get 4 words, thus the 'else:' clause in parse_request() gets triggered. So far so good. This eventually leads us to send_error() and from there into send_response() with the error code (properly 400) and message. From there we get to .send_response_only() and tracing into this function shows you where things go wrong. send_response_only() has an explicit test on self.request_version != 'HTTP/0.9', in which case it adds nothing to the _header_buffer. Well, because the request parsing got the unexpected number of words, in fact request_version *is* the default HTTP/0.9. Thus the error headers are never added. There are several problems here. Why are the headers never added when the request is HTTP/0.9? (I haven't read the spec.) Also, since parse_request() isn't setting the request version to 'HTTP/1.1'. It should probably dig out the words[-1] and see if that looks like a version string. Clearly the request isn't properly escaped, but http.server should not be sending an implicit 200 when the request is bogus. ---------- components: Library (Lib) messages: 279611 nosy: barry priority: normal severity: normal status: open title: http.server parse_request() bug and error reporting versions: Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Oct 28 13:51:09 2016 From: report at bugs.python.org (Yutao Yuan) Date: Fri, 28 Oct 2016 17:51:09 +0000 Subject: [New-bugs-announce] [issue28549] curses: calling addch() with an 1-length str segfaults with ncurses6 compiled with --enable-ext-colors Message-ID: <1477677069.87.0.354681142627.issue28549@psf.upfronthosting.co.za> New submission from Yutao Yuan: When addch() is called with an 1-length str, it is converted into a cchar_t. Ncurses6 adds a new field ext_color to cchar_t if it is enabled at compile time, and it is not initialized here, which causes various problems like segfaults or wrong display of characters. ---------- components: Extension Modules messages: 279620 nosy: yyt16384 priority: normal severity: normal status: open title: curses: calling addch() with an 1-length str segfaults with ncurses6 compiled with --enable-ext-colors type: crash versions: Python 3.4, Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Oct 28 14:07:05 2016 From: report at bugs.python.org (=?utf-8?q?Levi_Vel=C3=A1zquez?=) Date: Fri, 28 Oct 2016 18:07:05 +0000 Subject: [New-bugs-announce] [issue28550] if inline statement does not work with multiple assignment. Message-ID: <1477678025.32.0.74165596104.issue28550@psf.upfronthosting.co.za> New submission from Levi Vel?zquez: Normal "if" inline assignment obj = None a = obj.a if obj else None It assign None to a as expected. obj = None a, b = obj.a, obj.b if obj else [None, None] It raises an error " 'NoneType' object has no attribute 'a'" when it should assign None to both a and b. ---------- components: Interpreter Core messages: 279622 nosy: levinvm priority: normal severity: normal status: open title: if inline statement does not work with multiple assignment. type: crash versions: Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Oct 28 17:59:14 2016 From: report at bugs.python.org (Anselm Kruis) Date: Fri, 28 Oct 2016 21:59:14 +0000 Subject: [New-bugs-announce] [issue28551] sysconfig.py wrong _PROJECT_BASE for Py2.7 Windows 64bit PC/VS9.0 Message-ID: <1477691954.87.0.162134126472.issue28551@psf.upfronthosting.co.za> New submission from Anselm Kruis: Affected versions: 2.7.11, 2.7.12 Windows amd64 build with Visual Studio 2008 using the files in PC/VS9.0 If you run test_sysconfig using PC/VS9.0/rt.bat the test case test_get_config_h_filename fails. --8<-----------8<-----------8<-----------8<-----------8<-----------8<--------- D:\kruis_F\fg2\stackless64\stackless>"D:\kruis_F\fg2\stackless64\stackless\PC\VS9.0\amd64\python" -Wd -3 -E -tt "D:\kruis_F\fg2\stackless64\stackless\PC\VS9.0\ \..\..\Lib\test\regrtest.py" -v test_sysconfig == CPython 2.7.11 Stackless 3.1b3 060516 (default, Oct 28 2016, 22:32:20) [MSC v.1500 64 bit (AMD64)] == Windows-7-6.1.7601-SP1 little-endian == c:\users\kruis\appdata\local\temp\test_python_12436 Testing with flags: sys.flags(debug=0, py3k_warning=1, division_warning=1, division_new=0, inspect=0, interactive=0, optimize=0, dont_write_bytecode=0, no_user_ site=0, no_site=0, ignore_environment=1, tabcheck=2, verbose=0, unicode=0, bytes_warning=0, hash_randomization=0) [1/1] test_sysconfig test_get_config_h_filename (test.test_sysconfig.TestSysConfig) ... FAIL test_get_config_vars (test.test_sysconfig.TestSysConfig) ... ok test_get_makefile_filename (test.test_sysconfig.TestSysConfig) ... skipped 'Test is not Windows compatible' test_get_path (test.test_sysconfig.TestSysConfig) ... ok test_get_path_names (test.test_sysconfig.TestSysConfig) ... ok test_get_paths (test.test_sysconfig.TestSysConfig) ... ok test_get_platform (test.test_sysconfig.TestSysConfig) ... ok test_get_scheme_names (test.test_sysconfig.TestSysConfig) ... ok test_platform_in_subprocess (test.test_sysconfig.TestSysConfig) ... skipped 'test only relevant on MacOSX' test_symlink (test.test_sysconfig.TestSysConfig) ... skipped 'module os has no attribute symlink' test_user_similar (test.test_sysconfig.TestSysConfig) ... ok ====================================================================== FAIL: test_get_config_h_filename (test.test_sysconfig.TestSysConfig) ---------------------------------------------------------------------- Traceback (most recent call last): File "D:\kruis_F\fg2\stackless64\stackless\lib\test\test_sysconfig.py", line 239, in test_get_config_h_filename self.assertTrue(os.path.isfile(config_h), config_h) AssertionError: D:\kruis_F\fg2\stackless64\stackless\Include\pyconfig.h --8<-----------8<-----------8<-----------8<-----------8<-----------8<--------- The failure is caused by the migration of the build files from PCbuild to PC\VS9.0, because Lib/sysconfig.py does not know this build location. The attached patch fixes the problem. ---------- components: Library (Lib), Tests, Windows files: fix_sysconfig_py.patch keywords: patch messages: 279631 nosy: anselm.kruis, paul.moore, steve.dower, tim.golden, zach.ware priority: normal severity: normal status: open title: sysconfig.py wrong _PROJECT_BASE for Py2.7 Windows 64bit PC/VS9.0 type: behavior versions: Python 2.7 Added file: http://bugs.python.org/file45256/fix_sysconfig_py.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Oct 28 18:13:05 2016 From: report at bugs.python.org (Alexander P) Date: Fri, 28 Oct 2016 22:13:05 +0000 Subject: [New-bugs-announce] [issue28552] Distutils fail if sys.executable is None Message-ID: <1477692785.38.0.0178074609676.issue28552@psf.upfronthosting.co.za> New submission from Alexander P: For example, Jython 2.7. When we try to execute `jython-standalone -m pip`, distutils.sysconfig tries to parse sys.executable as a path and obviously fails: Traceback (most recent call last): File "/home/ale/dev/3toj/jython-standalone-2.7.0.jar/Lib/runpy.py", line 161, in _run_module_as_main File "/home/ale/dev/3toj/jython-standalone-2.7.0.jar/Lib/runpy.py", line 72, in _run_code File "/home/ale/dev/3toj/jython-standalone-2.7.0.jar/Lib/ensurepip/__main__.py", line 4, in File "/home/ale/dev/3toj/jython-standalone-2.7.0.jar/Lib/ensurepip/__init__.py", line 220, in _main File "/home/ale/dev/3toj/jython-standalone-2.7.0.jar/Lib/ensurepip/__init__.py", line 123, in bootstrap File "/home/ale/dev/3toj/jython-standalone-2.7.0.jar/Lib/ensurepip/__init__.py", line 45, in _run_pip File "/tmp/tmp9QnVEm/pip-1.6-py2.py3-none-any.whl/pip/__init__.py", line 10, in File "/tmp/tmp9QnVEm/pip-1.6-py2.py3-none-any.whl/pip/util.py", line 13, in File "/tmp/tmp9QnVEm/pip-1.6-py2.py3-none-any.whl/pip/backwardcompat/__init__.py", line 115, in File "/home/ale/dev/3toj/jython-standalone-2.7.0.jar/Lib/distutils/sysconfig.py", line 28, in File "/home/ale/dev/3toj/jython-standalone-2.7.0.jar/Lib/posixpath.py", line 367, in realpath File "/home/ale/dev/3toj/jython-standalone-2.7.0.jar/Lib/posixpath.py", line 373, in _joinrealpath File "/home/ale/dev/3toj/jython-standalone-2.7.0.jar/Lib/posixpath.py", line 61, in isabs AttributeError: 'NoneType' object has no attribute 'startswith' ---------- components: Distutils messages: 279633 nosy: dstufft, eric.araujo, iamale priority: normal severity: normal status: open title: Distutils fail if sys.executable is None type: behavior _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Oct 28 20:08:04 2016 From: report at bugs.python.org (Ofek Lev) Date: Sat, 29 Oct 2016 00:08:04 +0000 Subject: [New-bugs-announce] [issue28553] int.to_bytes docs logic error Message-ID: <1477699684.07.0.61979939957.issue28553@psf.upfronthosting.co.za> New submission from Ofek Lev: https://docs.python.org/3/library/stdtypes.html#int.to_bytes To convert an int to the exact number of bytes required, the docs recommend "x.to_bytes((x.bit_length() // 8) + 1, ...)". This is incorrect when length is a multiple of 8, e.g. 296. The correct way is "x.to_bytes((x.bit_length() + 7) // 8, ...)". ---------- assignee: docs at python components: Documentation messages: 279641 nosy: Ofekmeister, docs at python priority: normal severity: normal status: open title: int.to_bytes docs logic error type: enhancement versions: Python 3.3, Python 3.4, Python 3.5, Python 3.6, Python 3.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Oct 29 03:13:51 2016 From: report at bugs.python.org (STINNER Victor) Date: Sat, 29 Oct 2016 07:13:51 +0000 Subject: [New-bugs-announce] [issue28554] Windows: _socket module fails to compile on "AMD64 Windows7 SP1 3.x" buildbot Message-ID: <1477725231.13.0.640835129837.issue28554@psf.upfronthosting.co.za> New submission from STINNER Victor: It looks like the build 8776 was fine, but compilation of _socket started to fail near the build: http://buildbot.python.org/all/builders/AMD64%20Windows7%20SP1%203.x/builds/8777 The related change 16ea07d420b864d786ef9c11a07967fe19c3a9cd seems unrelated. ---------- components: Windows messages: 279658 nosy: haypo, paul.moore, steve.dower, tim.golden, zach.ware priority: normal severity: normal status: open title: Windows: _socket module fails to compile on "AMD64 Windows7 SP1 3.x" buildbot type: compile error versions: Python 3.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Oct 29 05:14:27 2016 From: report at bugs.python.org (Big Stone) Date: Sat, 29 Oct 2016 09:14:27 +0000 Subject: [New-bugs-announce] [issue28555] provid also sha-1 and sha-256 also on download links Message-ID: <1477732467.71.0.578620687465.issue28555@psf.upfronthosting.co.za> New submission from Big Stone: It would be nice to have also sha-1 and sha-256 provided with python-360b3 download links and annoucement (so no separate sites). md5 is dangerously easy to workaround nowodays ---------- messages: 279666 nosy: Big Stone priority: normal severity: normal status: open title: provid also sha-1 and sha-256 also on download links _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Oct 29 11:46:49 2016 From: report at bugs.python.org (Guido van Rossum) Date: Sat, 29 Oct 2016 15:46:49 +0000 Subject: [New-bugs-announce] [issue28556] typing.py upgrades Message-ID: <1477756009.46.0.442279756181.issue28556@psf.upfronthosting.co.za> New submission from Guido van Rossum: Over at https://github.com/python/typeshed we have a number of big changes in store. I'm eager to get these into 3.6, so I'm merging them in now, in time for 3.6b3. (Recall that PEP 484 and typing.py remain provisional until 3.7 rolls around.) ---------- messages: 279680 nosy: gvanrossum priority: normal severity: normal status: open title: typing.py upgrades _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Oct 29 13:07:25 2016 From: report at bugs.python.org (David Szotten) Date: Sat, 29 Oct 2016 17:07:25 +0000 Subject: [New-bugs-announce] [issue28557] error message for bad raw readinto Message-ID: <1477760845.01.0.230790209004.issue28557@psf.upfronthosting.co.za> New submission from David Szotten: Was just tracking down a bug in eventlet, which manifested as "OSError: raw readinto() returned invalid length -1 (should have been between 0 and 8192)" I was misled for a while by the fact that readinto was in fact returning b'', not -1. This improves the error message in that case by including the TypeError from the failed conversion of b'' to an int. Would prefer to still return an OSError with the TypeError as a cause, but couldn't figure out how to do that. Hints/help would be appreciated. ---------- components: IO files: readinto_error.patch keywords: patch messages: 279685 nosy: davidszotten priority: normal severity: normal status: open title: error message for bad raw readinto versions: Python 3.7 Added file: http://bugs.python.org/file45265/readinto_error.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Oct 29 13:21:51 2016 From: report at bugs.python.org (Chris) Date: Sat, 29 Oct 2016 17:21:51 +0000 Subject: [New-bugs-announce] [issue28558] argparse Incorrect Handling of Store Actions Message-ID: <1477761711.09.0.834244461105.issue28558@psf.upfronthosting.co.za> New submission from Chris: argparse does not handle Store actions correctly when "nargs = 1" is provided. The documentation indicates the value should be assigned to the dest, but instead a list with the value as the only item is assigned to dest. ---------- files: test_argparse.py messages: 279686 nosy: Flux priority: normal severity: normal status: open title: argparse Incorrect Handling of Store Actions type: behavior versions: Python 2.7, Python 3.4, Python 3.5 Added file: http://bugs.python.org/file45266/test_argparse.py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Oct 29 14:16:31 2016 From: report at bugs.python.org (Dimitri Merejkowsky) Date: Sat, 29 Oct 2016 18:16:31 +0000 Subject: [New-bugs-announce] [issue28559] Unclear error message when raising wrong type of exceptions Message-ID: <1477764991.61.0.67228056749.issue28559@psf.upfronthosting.co.za> New submission from Dimitri Merejkowsky: Motivation for the patch came from a tweet[1] of David Beazley: def SomeError(Exception): pass raise SomeError('blah') (Note the `def` keyword instead of `class`): If you run that, you get: > TypeError: exceptions must derive from BaseException Which is not very helpful. Attached patch changes the error message to be: > TypeError: exceptions must derive from BaseException, got NoneType (By the way, it's very close to what Python2 used to say in this case) ---------- components: Interpreter Core files: 0001-Fix-error-message-when-raising-with-the-wrong-type.patch keywords: patch messages: 279689 nosy: Dimitri Merejkowsky priority: normal severity: normal status: open title: Unclear error message when raising wrong type of exceptions type: enhancement versions: Python 3.7 Added file: http://bugs.python.org/file45267/0001-Fix-error-message-when-raising-with-the-wrong-type.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Oct 29 17:59:33 2016 From: report at bugs.python.org (Ram Rachum) Date: Sat, 29 Oct 2016 21:59:33 +0000 Subject: [New-bugs-announce] [issue28560] Implement `PurePath.startswith` and `PurePath.endswith` Message-ID: <1477778373.6.0.891058430621.issue28560@psf.upfronthosting.co.za> New submission from Ram Rachum: Today I had to check whether a path object started with `/foo`. The nicest way I could think of was `str(p).startswith('/foo')`. What do you think about implementing `p.startswith('/foo')`? ---------- components: Library (Lib) messages: 279699 nosy: cool-RR, pitrou priority: normal severity: normal status: open title: Implement `PurePath.startswith` and `PurePath.endswith` type: enhancement versions: Python 3.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Oct 30 03:45:51 2016 From: report at bugs.python.org (Xiang Zhang) Date: Sun, 30 Oct 2016 07:45:51 +0000 Subject: [New-bugs-announce] [issue28561] Report surrogate characters range in utf8_encoder Message-ID: <1477813551.36.0.0620162768049.issue28561@psf.upfronthosting.co.za> New submission from Xiang Zhang: In utf8_encoder, when a codecs returns a string with non-ascii characters, it raises encodeerror but the start and end position are not perfect. This seems like an oversight during evolution. Before, utf8_encoder only recognize one surrogate character a time. After 2b5357b38366, it tries to recognize as much as possible a time. Patch also includes some cleanup. ---------- files: utf8_encoder.patch keywords: patch messages: 279712 nosy: haypo, serhiy.storchaka, xiang.zhang priority: normal severity: normal stage: patch review status: open title: Report surrogate characters range in utf8_encoder type: behavior Added file: http://bugs.python.org/file45271/utf8_encoder.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Oct 30 12:52:43 2016 From: report at bugs.python.org (Xavier de Gaye) Date: Sun, 30 Oct 2016 16:52:43 +0000 Subject: [New-bugs-announce] [issue28562] test_asyncio fails on Android upon calling getaddrinfo() Message-ID: <1477846363.43.0.193615088108.issue28562@psf.upfronthosting.co.za> New submission from Xavier de Gaye: The error: ====================================================================== ERROR: test_create_connection_service_name (test.test_asyncio.test_base_events.BaseEventLoopWithSelectorTests) ---------------------------------------------------------------------- Traceback (most recent call last): File "/sdcard/org.bitbucket.pyona/lib/python3.7/unittest/mock.py", line 1179, in patched return func(*args, **keywargs) File "/sdcard/org.bitbucket.pyona/lib/python3.7/test/test_asyncio/test_base_events.py", line 1209, in test_create_connection_service_name t, p = self.loop.run_until_complete(coro) File "/sdcard/org.bitbucket.pyona/lib/python3.7/asyncio/base_events.py", line 449, in run_until_complete return future.result() File "/sdcard/org.bitbucket.pyona/lib/python3.7/concurrent/futures/thread.py", line 55, in run result = self.fn(*self.args, **self.kwargs) File "/sdcard/org.bitbucket.pyona/lib/python3.7/socket.py", line 743, in getaddrinfo for res in _socket.getaddrinfo(host, port, family, type, proto, flags): socket.gaierror: [Errno 9] servname not supported for ai_socktype The same error occurs also in issue 26936. msg266362 lists the conditions under which getaddrinfo() fails on Android. With this patch, the test succeeds on both Android API levels 21 and 23 (there is no level 22). ---------- components: Tests files: getaddrinfo.patch keywords: patch messages: 279731 nosy: xdegaye, yselivanov priority: normal severity: normal stage: patch review status: open title: test_asyncio fails on Android upon calling getaddrinfo() type: behavior versions: Python 3.6, Python 3.7 Added file: http://bugs.python.org/file45279/getaddrinfo.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Oct 30 12:58:41 2016 From: report at bugs.python.org (Carl Ekerot) Date: Sun, 30 Oct 2016 16:58:41 +0000 Subject: [New-bugs-announce] [issue28563] Arbitrary code execution in gettext.c2py Message-ID: <1477846721.72.0.339090840874.issue28563@psf.upfronthosting.co.za> New submission from Carl Ekerot: The c2py-function in the gettext module is seriously flawed in many ways due to its use of eval to create a plural function: return eval('lambda n: int(%s)' % plural) My first discovery was that nothing prevents an input plural string that resembles a function call: gettext.c2py("n()")(lambda: os.system("sh")) This is of course a low risk bug, since it requires control of both the plural function string and the argument. Gaining arbitrary code execution using only the plural function string requires that the security checks are bypassed. The security checks utilize the tokenize module and makes sure that no NAME-tokens that are not "n" exist in the string. However, it does not check if the parser succeeds without any token.ERRORTOKEN being present. Hence, the following input will pass the security checks: gettext.c2py( '"(eval(foo) && ""' )(0) ----> 1 gettext.c2py( '"(eval(foo) && ""' )(0) gettext.pyc in (n) NameError: global name 'foo' is not defined It will pass since it recognizes the entire input as a STRING token, and subsequently fails with an ERRORTOKEN. Passing a string in the argument to eval will however break the exploit since the parser will read the start-of-string in the eval argument as end-of-string, and the eval argument will be read as a NAME-token. Instead of passing a string to eval, we can build a string from characters in the docstrings available in the context of the gettext module: gettext.c2py('"(eval(' 'os.__doc__[152:155] + ' # os. 'os.__doc__[46:52] + ' # system 'os.__doc__[318] + ' # ( 'os.__doc__[55] + ' # ' 'os.__doc__[10] + ' # s 'os.__doc__[42] + ' # h 'os.__doc__[55] + ' # ' 'os.__doc__[329]' # ) ') && ""')(0) This will successfully spawn a shell in Python 2.7.11. Bonus: With the new string interpolation in Python 3.7, exploiting gettext.c2py becomes trivial: gettext.c2py('f"{os.system(\'sh\')}"')(0) The tokenizer will recognize the entire format-string as just a string, thus bypassing the security checks. To mitigate these vulnerabilities, eval should be avoided by implementing a custom parser for the gettext plural function DSL. ---------- components: Library (Lib) messages: 279734 nosy: Carl Ekerot priority: normal severity: normal status: open title: Arbitrary code execution in gettext.c2py type: security versions: Python 2.7, Python 3.3, Python 3.4, Python 3.5, Python 3.6, Python 3.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Oct 30 16:02:39 2016 From: report at bugs.python.org (Marian Beermann) Date: Sun, 30 Oct 2016 20:02:39 +0000 Subject: [New-bugs-announce] [issue28564] shutil.rmtree is inefficient due to listdir() instead of scandir() Message-ID: <1477857759.23.0.231777495226.issue28564@psf.upfronthosting.co.za> New submission from Marian Beermann: The use of os.listdir severely limits the speed of this function on anything except solid-state drives. Using the new-in-Python 3.5 os.scandir should eliminate this bottleneck. ---------- components: Library (Lib) messages: 279745 nosy: enkore priority: normal severity: normal status: open title: shutil.rmtree is inefficient due to listdir() instead of scandir() versions: Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Oct 31 01:48:57 2016 From: report at bugs.python.org (lilydjwg) Date: Mon, 31 Oct 2016 05:48:57 +0000 Subject: [New-bugs-announce] [issue28565] datetime.strptime %Z doesn't get included in the result Message-ID: <1477892937.56.0.524633393868.issue28565@psf.upfronthosting.co.za> New submission from lilydjwg: With %z, the result gets a tzinfo, but with %Z, it succeeds but the result is without timezone info: >>> datetime.datetime.strptime('2016-10-31T03:58:24 CST', '%Y-%m-%dT%H:%M:%S %Z') datetime.datetime(2016, 10, 31, 3, 58, 24) >>> datetime.datetime.strptime('2016-10-31T03:58:24 +0800', '%Y-%m-%dT%H:%M:%S %z') datetime.datetime(2016, 10, 31, 3, 58, 24, tzinfo=datetime.timezone(datetime.timedelta(0, 28800))) So the first one loses infomation (and will result in wrong values if the programmer isn't aware of this, and the local timezone is different than the one in the string). ---------- messages: 279761 nosy: lilydjwg priority: normal severity: normal status: open title: datetime.strptime %Z doesn't get included in the result type: behavior _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Oct 31 05:41:12 2016 From: report at bugs.python.org (Anish Patel) Date: Mon, 31 Oct 2016 09:41:12 +0000 Subject: [New-bugs-announce] [issue28566] Python installation fails on Windows because of pip feature Message-ID: <1477906872.22.0.975968443395.issue28566@psf.upfronthosting.co.za> New submission from Anish Patel: Originally created issue: https://github.com/pypa/pip/issues/4033#issuecomment-256865622 Copied text below: I had already Python 3 installed with the environment variable PYTHONHOME=C:\Program Files\Python35. I attempted to install Python 2, but received this issue (although I was installing python 2 after having installed 3): http://stackoverflow.com/questions/23349957/solving-install-issues-with-python-3-4-on-windows After multiple attempts, I was able to successfully install Python 2 by doing either of following: * Removing the pip feature from Python 2 installation * Removing my PYTHONHOME environment variable and running a complete Python 2 installation Although I resolved my issue, I would like to file this as a bug if it hasn't been filed already. ---------- components: Installation, Windows messages: 279774 nosy: Anish Patel, paul.moore, steve.dower, tim.golden, zach.ware priority: normal severity: normal status: open title: Python installation fails on Windows because of pip feature type: crash versions: Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Oct 31 06:26:17 2016 From: report at bugs.python.org (Alex Croitor) Date: Mon, 31 Oct 2016 10:26:17 +0000 Subject: [New-bugs-announce] [issue28567] Bus error / segmentation fault on macOS debug build when using ctypes OpenGL Message-ID: <1477909577.25.0.765804576339.issue28567@psf.upfronthosting.co.za> New submission from Alex Croitor: Hi, I'm building Python 2.7.11 with debug symbols and no optimizations, but without the --with-debug switch, on macOS 10.11.5, El Capitan + XCode 7.3.1. Whenever I try to execute an OpenGL demo or example, I get a segmentation fault or a bus error with a weird back trace. If I build Python2 in regular release mode (-O2) the demos run fine without crashing. I also tried building Python 3.5.2, both in release, and debug mode, and the demos do not crash either. What I tried after, was to update the files used in Modules/_ctypes/libffi_osx folder, with the latest version (libffi-3.2.1), and some small build adjustments, and then it doesn't crash anymore with -O0. But then I did a diff of libffi_osx on Python 2 and 3, and there are no significant differences there. So I assume the issue is somewhere in the _ctypes module code. Providing configure line for python2 (it was mostly the same for python3) ./configure --prefix="/usr/local/Cellar/python/2.7.11_custom" --enable-ipv6 --datarootdir=/usr/local/Cellar/python/2.7.11_custom/share --datadir=/usr/local/Cellar/python/2.7.11_custom/share --enable-framework=/usr/local/Cellar/python/2.7.11_custom/Frameworks --without-gcc MACOSX_DEPLOYMENT_TARGET=10.11 CFLAGS="-O0 -fno-inline -fno-omit-frame-pointer -g" LDFLAGS="-O0" CPPFLAGS="-O0" OPT="-O0 -g" CC="clang" Setting just -O0 without the no-inline and no-omit-frame-pointer does not influence anything, Python2 still crashes. Attaching a small python test from the opengl source package. And here is the backtrace: Process 32599 stopped * thread #1: tid = 0x15ecc1, 0x00007fff95bb2d11 AppKit`-[NSView _drawRect:clip:] + 3689, queue = 'com.apple.main-thread', stop reason = EXC_BAD_ACCESS (code=EXC_I386_GPFLT) frame #0: 0x00007fff95bb2d11 AppKit`-[NSView _drawRect:clip:] + 3689 AppKit`-[NSView _drawRect:clip:]: -> 0x7fff95bb2d11 <+3689>: movss %xmm0, (%r13,%r15) 0x7fff95bb2d18 <+3696>: movss 0x4(%r13,%r15), %xmm1 ; xmm1 = mem[0],zero,zero,zero 0x7fff95bb2d1f <+3703>: ucomiss %xmm0, %xmm1 0x7fff95bb2d22 <+3706>: jbe 0x7fff95bb2d2b ; <+3715> (lldb) bt error: unable to find CIE at 0x00000018 for cie_id = 0x00000004 for entry at 0x00000018. error: unable to find CIE at 0x00000050 for cie_id = 0x00000004 for entry at 0x00000050. error: time.so debug map object file '/Users/alex/Dev/python2_debug/Python-2.7.11/debug/build/temp.macosx-10.11-x86_64-2.7-pydebug/Users/alex/Dev/python2_debug/Python-2.7.11/Modules/timemodule.o' has changed (actual time is 0x58171936, debug map time is 0x58171933) since this executable was linked, file will be ignored * thread #1: tid = 0x15ecc1, 0x00007fff95bb2d11 AppKit`-[NSView _drawRect:clip:] + 3689, queue = 'com.apple.main-thread', stop reason = EXC_BAD_ACCESS (code=EXC_I386_GPFLT) * frame #0: 0x00007fff95bb2d11 AppKit`-[NSView _drawRect:clip:] + 3689 frame #1: 0x00007fff95c0acad AppKit`-[NSView _recursiveDisplayAllDirtyWithLockFocus:visRect:] + 1873 frame #2: 0x00007fff95c0b08a AppKit`-[NSView _recursiveDisplayAllDirtyWithLockFocus:visRect:] + 2862 frame #3: 0x00007fff95bb03fb AppKit`-[NSView _recursiveDisplayRectIfNeededIgnoringOpacity:isVisibleRect:rectIsVisibleRectForView:topView:] + 838 frame #4: 0x00007fff95bafbe0 AppKit`-[NSThemeFrame _recursiveDisplayRectIfNeededIgnoringOpacity:isVisibleRect:rectIsVisibleRectForView:topView:] + 334 frame #5: 0x00007fff95badfeb AppKit`-[NSView _displayRectIgnoringOpacity:isVisibleRect:rectIsVisibleRectForView:] + 2449 frame #6: 0x00007fff95ba93f5 AppKit`-[NSView displayIfNeeded] + 1950 frame #7: 0x00007fff95ba8c3c AppKit`-[NSWindow displayIfNeeded] + 232 frame #8: 0x00007fff9622d41b AppKit`___NSWindowGetDisplayCycleObserver_block_invoke6365 + 476 frame #9: 0x00007fff95ba85d6 AppKit`__37+[NSDisplayCycle currentDisplayCycle]_block_invoke + 941 frame #10: 0x00007fff8ba17f71 QuartzCore`CA::Transaction::run_commit_handlers(CATransactionPhase) + 85 frame #11: 0x00007fff8ba1742c QuartzCore`CA::Context::commit_transaction(CA::Transaction*) + 160 frame #12: 0x00007fff8ba170ec QuartzCore`CA::Transaction::commit() + 508 frame #13: 0x00007fff8ba22977 QuartzCore`CA::Transaction::observer_callback(__CFRunLoopObserver*, unsigned long, void*) + 71 frame #14: 0x00007fff8dd47067 CoreFoundation`__CFRUNLOOP_IS_CALLING_OUT_TO_AN_OBSERVER_CALLBACK_FUNCTION__ + 23 frame #15: 0x00007fff8dd46fd7 CoreFoundation`__CFRunLoopDoObservers + 391 frame #16: 0x00007fff8dd25ef8 CoreFoundation`CFRunLoopRunSpecific + 328 frame #17: 0x00007fff8c95c3f6 Foundation`-[NSRunLoop(NSRunLoop) limitDateForMode:] + 201 frame #18: 0x00000001051c0232 GLUT`-[GLUTApplication run] + 269 frame #19: 0x00000001051cce59 GLUT`glutMainLoop + 254 frame #20: 0x00000001017818af _ctypes.so`ffi_call_unix64 + 79 at darwin64.S:76 frame #21: 0x000000010178253f _ctypes.so`ffi_call(cif=0x00007fff5fbfe610, fn=(GLUT`glutMainLoop), rvalue=0x00007fff5fbfe6a0, avalue=0x00007fff5fbfe6a0) + 1487 at x86-ffi64.c:581 frame #22: 0x000000010177782c _ctypes.so`_call_function_pointer(flags=4353, pProc=(GLUT`glutMainLoop), avalues=0x00007fff5fbfe6a0, atypes=0x00007fff5fbfe6a0, restype=0x00000001017899b0, resmem=0x00007fff5fbfe6a0, argcount=0) + 332 at callproc.c:836 frame #23: 0x0000000101776fd1 _ctypes.so`_ctypes_callproc(pProc=(GLUT`glutMainLoop), argtuple=0x0000000100321060, flags=4353, argtypes=0x0000000100321060, restype=0x0000000100213a28, checker=0x0000000000000000) + 1345 at callproc.c:1179 frame #24: 0x0000000101768214 _ctypes.so`PyCFuncPtr_call(self=0x0000000105276060, inargs=0x0000000100321060, kwds=0x0000000000000000) + 1172 at _ctypes.c:3965 frame #25: 0x0000000100016d32 Python`PyObject_Call(func=0x0000000105276060, arg=0x0000000100321060, kw=0x0000000000000000) + 130 at abstract.c:2546 frame #26: 0x0000000100156dd6 Python`do_call(func=0x0000000105276060, pp_stack=0x00007fff5fbfec80, na=0, nk=0) + 566 at ceval.c:4568 frame #27: 0x000000010015466a Python`call_function(pp_stack=0x00007fff5fbfec80, oparg=0) + 2138 at ceval.c:4373 frame #28: 0x000000010014e843 Python`PyEval_EvalFrameEx(f=0x0000000101625660, throwflag=0) + 65187 at ceval.c:2987 frame #29: 0x000000010013e893 Python`PyEval_EvalCodeEx(co=0x00000001016283b0, globals=0x0000000100395958, locals=0x0000000100395958, args=0x0000000000000000, argcount=0, kws=0x0000000000000000, kwcount=0, defs=0x0000000000000000, defcount=0, closure=0x0000000000000000) + 4979 at ceval.c:3582 frame #30: 0x000000010013d515 Python`PyEval_EvalCode(co=0x00000001016283b0, globals=0x0000000100395958, locals=0x0000000100395958) + 85 at ceval.c:669 frame #31: 0x000000010018ce22 Python`run_mod(mod=0x0000000103824050, filename="./test_glutinit.py", globals=0x0000000100395958, locals=0x0000000100395958, flags=0x00007fff5fbff660, arena=0x0000000101503b40) + 98 at pythonrun.c:1370 frame #32: 0x000000010018d28f Python`PyRun_FileExFlags(fp=0x00007fff7ae2b050, filename="./test_glutinit.py", start=257, globals=0x0000000100395958, locals=0x0000000100395958, closeit=1, flags=0x00007fff5fbff660) + 223 at pythonrun.c:1356 frame #33: 0x000000010018c5e9 Python`PyRun_SimpleFileExFlags(fp=0x00007fff7ae2b050, filename="./test_glutinit.py", closeit=1, flags=0x00007fff5fbff660) + 729 at pythonrun.c:948 frame #34: 0x000000010018c03c Python`PyRun_AnyFileExFlags(fp=0x00007fff7ae2b050, filename="./test_glutinit.py", closeit=1, flags=0x00007fff5fbff660) + 140 at pythonrun.c:752 frame #35: 0x00000001001afdff Python`Py_Main(argc=2, argv=0x00007fff5fbff700) + 4271 at main.c:640 frame #36: 0x0000000100000f82 Python`___lldb_unnamed_function1$$Python + 34 frame #37: 0x00007fffa03a25ad libdyld.dylib`start + 1 ---------- components: ctypes files: test_glutinit.py messages: 279777 nosy: Alex Croitor priority: normal severity: normal status: open title: Bus error / segmentation fault on macOS debug build when using ctypes OpenGL type: crash versions: Python 2.7 Added file: http://bugs.python.org/file45289/test_glutinit.py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Oct 31 12:43:09 2016 From: report at bugs.python.org (Anselm Kruis) Date: Mon, 31 Oct 2016 16:43:09 +0000 Subject: [New-bugs-announce] [issue28568] Build files in PC/VS9.0 contain an outdated sqlite version number Message-ID: <1477932189.44.0.0903388711161.issue28568@psf.upfronthosting.co.za> New submission from Anselm Kruis: Python 2.7 only. Tested with 2.7.12. Commit fa68df1d5e65 for #19450 changes the sqlite version for Python 2.7 on Windows from 3.6.21 to 3.8.11.0, but only for the build files in PCbuild. The documentation states, that the build files under PC\VS9.0 are also fully supported, but they still refer to sqlite version 3.6.21. This causes the command "PC\VS9.0\build.bat -r -e" to fail, because it first fetches sqlite 3.9.11.0 from svn.python.org and then tries to build sqlite 3.6.21, which is of course not available. The attached patch fixes the problem. ---------- components: Build, Windows files: fix-sqlite-version.patch keywords: patch messages: 279802 nosy: anselm.kruis, paul.moore, steve.dower, tim.golden, zach.ware priority: normal severity: normal status: open title: Build files in PC/VS9.0 contain an outdated sqlite version number type: compile error versions: Python 2.7 Added file: http://bugs.python.org/file45295/fix-sqlite-version.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Oct 31 13:32:14 2016 From: report at bugs.python.org (Andrey Fedorov) Date: Mon, 31 Oct 2016 17:32:14 +0000 Subject: [New-bugs-announce] [issue28569] mock.attach_mock should work with return value of patch() Message-ID: <1477935134.31.0.733482108189.issue28569@psf.upfronthosting.co.za> New submission from Andrey Fedorov: The attach_mock in the following code sample fails silently: >>> from mock import patch, Mock >>> p = patch('requests.get', autospec=True) >>> manager = Mock() >>> manager.attach_mock(p.start(), 'requests_get') >>> import requests >>> requests.get('https://google.com') >>> manager.mock_calls [] >>> p.stop() >>> manager.mock_calls [] It seems this would be a useful use-case, especially given that this code would work as-expected if 'requests.get' in the second line were replaced with a path to a class. ---------- components: Library (Lib) messages: 279812 nosy: Andrey Fedorov, michael.foord priority: normal severity: normal status: open title: mock.attach_mock should work with return value of patch() type: behavior versions: Python 2.7, Python 3.3, Python 3.4, Python 3.5, Python 3.6, Python 3.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Oct 31 15:51:23 2016 From: report at bugs.python.org (Cory Benfield) Date: Mon, 31 Oct 2016 19:51:23 +0000 Subject: [New-bugs-announce] [issue28570] httplib mishandles unknown 1XX status codes Message-ID: <1477943483.09.0.68269146794.issue28570@psf.upfronthosting.co.za> New submission from Cory Benfield: Long story short ~~~~~~~~~~~~~~~~ http.client does not tolerate non-100 or 101 status codes from the 1XX block in a sensible manner: it treats them as final responses, rather than as provisional ones. Expected behaviour ~~~~~~~~~~~~~~~~~~ When http.client receives a 1XX status code that it does not recognise, it should either surface these to a user that expects them by means of a callback, or it should ignore them and only show the user the eventual final status code. This is required by RFC 7231 Section 6.2 (Informational 1xx), which reads: > A client MUST be able to parse one or more 1xx responses received prior to a final response, even if the client does not expect one. A user agent MAY ignore unexpected 1xx responses. Actual behaviour ~~~~~~~~~~~~~~~~ http.client treats the 1XX status code as final. It parses the header block as though it were a response in the 2XX or higher range. http.client will assume that there is no content in the 1XX response, and so will leave the following final response unconsumed in the socket buffer. This means that if the HTTPConnection is re-used, the user will see the final response following the 1XX as the response to the next request, even though it is not. Steps to reproduce ~~~~~~~~~~~~~~~~~~ The following "server" can demonstrate the issue: import socket import time document = b''' title

Hello, world!

''' s = socket.socket() s.setsockopt(socket.SOL_SOCKET, socket.SO_REUSEADDR, 1) s.bind(('localhost', 8080)) s.listen(5) while True: new_socket, _ = s.accept() data = b'' while not data.endswith(b'\r\n\r\n'): data += new_socket.recv(8192) new_socket.sendall( b'HTTP/1.1 103 Early Hints\r\n' b'Server: socketserver/1.0.0\r\n' b'Link: ; rel=preload; as=style\r\n' b'Link: ; rel=preload; as=script\r\n' b'\r\n' ) time.sleep(1) new_socket.sendall( b'HTTP/1.1 200 OK\r\n' b'Server: socketserver/1.0.0\r\n' b'Content-Type: text/html\r\n' b'Content-Length: %s\r\n' b'Link: ; rel=preload; as=style\r\n' b'Link: ; rel=preload; as=script\r\n' b'Connection: close\r\n' b'\r\n' % len(document) ) new_socket.sendall(document) new_socket.close() If this server is run directly, the following client can be used to test it: from http.client import HTTPConnection c = HTTPConnection('localhost', 8080) c.request('GET', '/') r = c.getresponse() print("Status: {} {}".format(r.status, r.reason)) print("Headers: {}".format(r.getheaders())) print("Body: {}".format(r.read())) This client will print Status: 103 Early Hints Headers: [('Content-Length', '0'), ('Server', 'socketserver/1.0.0'), ('Link', '; rel=preload; as=style'), ('Link', '; rel=preload; as=script')] Body: b'' This response is wrong: the 200 header block is hidden from the client. Unfortunately, http.client doesn't allow us to ask for the next response: another call to "getresponse()" raises a "ResponseNotReady: Idle" exception. ---------- components: Library (Lib) messages: 279823 nosy: Lukasa priority: normal severity: normal status: open title: httplib mishandles unknown 1XX status codes type: behavior versions: Python 3.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Oct 31 17:19:59 2016 From: report at bugs.python.org (=?utf-8?b?TGx1w61z?=) Date: Mon, 31 Oct 2016 21:19:59 +0000 Subject: [New-bugs-announce] [issue28571] llist and scipy.stats conflicts, python segfault Message-ID: <1477948799.58.0.602345743052.issue28571@psf.upfronthosting.co.za> New submission from Llu?s: I'm running this small script that produces a segfault: https://gist.github.com/anonymous/d24748d5b6de88b31f18965932744211 My python version is Python 3.5.2 (default, Jun 28 2016, 08:46:01) [GCC 6.1.1 20160602] on linux. And running scipy version 0.18.1. Can someone confirm if this segfaults with other systems ? ---------- components: Interpreter Core messages: 279828 nosy: Llu?s priority: normal severity: normal status: open title: llist and scipy.stats conflicts, python segfault type: crash versions: Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Oct 31 17:21:59 2016 From: report at bugs.python.org (Terry J. Reedy) Date: Mon, 31 Oct 2016 21:21:59 +0000 Subject: [New-bugs-announce] [issue28572] IDLE: add tests for config dialog. Message-ID: <1477948919.57.0.703261528011.issue28572@psf.upfronthosting.co.za> New submission from Terry J. Reedy: The current test_configdialog creates an instance of ConfigDialog. Time to add some real tests so I can comfortably work on multiple other configdialog issues. The challenge is to do it so tests run without a blocking mainloop call and without IDLE's tcl update calls. Explicit root.update call can be added if needed. I also want to test without making the dialog visible. This is a problem for at least some event_generate calls, but their seem to be (mostly) better options. Buttons and Radiobuttons for both tk and ttk have an invoke method that works fine. Entry widget insert seems to work also to trigger that test action. Attached are partial tests for two of the four main tabs. ---------- assignee: terry.reedy files: config_dialog_test.diff keywords: patch messages: 279829 nosy: terry.reedy priority: normal severity: normal stage: needs patch status: open title: IDLE: add tests for config dialog. type: enhancement versions: Python 3.6, Python 3.7 Added file: http://bugs.python.org/file45297/config_dialog_test.diff _______________________________________ Python tracker _______________________________________